Khi Bức Tường Bị Phá Vỡ — Thiết Kế Hệ Thống Y Tế Theo Nguyên Lý Safety-II

95% Bị Bỏ Qua

Năm 2014, Erik Hollnagel xuất bản một cuốn sách đã âm thầm thay đổi cách các nhà khoa học an toàn tư duy^[1]. Lập luận của ông đơn giản nhưng đáng suy ngẫm: ngành an toàn đã dành hàng thập kỷ nghiên cứu tỷ lệ nhỏ các trường hợp sai sót, trong khi gần như hoàn toàn bỏ qua đại đa số trường hợp mọi thứ diễn ra đúng.

Ông gọi cách tiếp cận truyền thống là Safety-I — xác định các dạng thất bại, xây dựng phòng tuyến, ngăn chặn hậu quả xấu. Đó là nền tảng của mọi bảng kiểm (checklist), mọi cơ chế an toàn, mọi hộp thoại "bạn có chắc không?". Và nó hiệu quả. Trừ khi không.

Phương án thay thế, Safety-II, khởi đầu từ một câu hỏi khác: thay vì hỏi tại sao mọi thứ đôi khi thất bại, hãy hỏi tại sao chúng thường thành công. Câu trả lời không phải "vì chúng ta xây phòng tuyến tốt", mà là "vì con người thích ứng". Điều dưỡng ứng biến. Bác sĩ điều chỉnh quy trình khi quy trình không phù hợp. Nhân viên hậu cần tìm ra giải pháp thay thế mà không ai lên kế hoạch trước.

Safety-I coi sự biến đổi này là vấn đề. Safety-II coi nó là nguồn lực chính của tính kiên cường (resilience).

Kịch Bản Phá Vỡ Tư Duy Safety-I

Chúng tôi đang xây dựng xGrid, một nền tảng hậu cần y tế thảm họa chạy ngoại tuyến trên thiết bị Raspberry Pi. Trong giai đoạn đầu phát triển, thiết kế hoàn toàn theo Safety-I: quét mã vạch, xác minh danh tính, hộp thoại xác nhận nhiều bước, kiểm soát truy cập theo vai trò.

Rồi chúng tôi chạy một bài tập mô phỏng tình huống. Kịch bản:

Ba trong tám trạm y tế buộc phải sơ tán đồng thời. Tại thời điểm sơ tán, các hoạt động sau đang diễn ra:

• Truyền máu với yêu cầu nghiêm ngặt về chuỗi giám sát (chain of custody)
• Phẫu thuật đang tiến hành, phải tạm ngừng và tiếp tục ở trạm khác
• Thuốc đang vận chuyển giữa các trạm cần được phân bổ lại

Hệ thống Safety-I xử lý từng bước kiểm tra riêng lẻ tốt. Điều nó không xử lý được là toàn bộ tình huống. Hệ thống giả định điều kiện vận hành ổn định. Thực tế cung cấp điều ngược lại.

Chúng tôi cần thứ gì đó không chỉ ngăn lỗi trong điều kiện bình thường, mà chủ động giúp con người thành công trong điều kiện bất thường.

Bốn Nguyên Tắc Rút Ra

1. Làm Cho Sự Bất Định Trở Nên Hiện Hữu

Bản năng trong thiết kế phần mềm là trình bày thông tin rõ ràng, tự tin. Con số không có điều kiện kèm theo. Chỉ báo trạng thái chỉ xanh hoặc đỏ, không bao giờ vàng.

Trong tình huống thảm họa, sự tự tin này nguy hiểm. Nếu dữ liệu kho chưa đồng bộ ba ngày, việc hiển thị số lượng cũ như thể nó hiện tại dẫn đến quyết định sai. Một điều dưỡng có thể bỏ qua kiểm đếm thực tế vì hệ thống hiển thị 12 đơn vị. Thực tế có thể chỉ còn 4.

xGrid gắn thẻ siêu dữ liệu độ tươi (freshness metadata) cho mọi điểm dữ liệu. Khi đồng bộ vượt quá ngưỡng, giao diện hiển thị nhãn stale (lỗi thời). Đây không phải chỉ báo lỗi — mà là tín hiệu trung thực. Nó nói với người vận hành: "Con số này có thể sai. Hãy xác minh trước khi hành động."

Một hệ thống thừa nhận sự bất định đáng tin cậy hơn một hệ thống che giấu nó. Người dùng học cách tin tưởng hệ thống chính vì nó cho họ biết khi nào không nên tin dữ liệu.

2. Suy Giảm Uyển Chuyển, Không Phải Bỏ Lỏng

Khi hệ thống chuyển sang chế độ khẩn cấp, nhà thiết kế đối mặt nan đề. Khóa chặt mọi thứ và có nguy cơ chặn hoạt động quan trọng? Hay mở toàn bộ và chấp nhận rủi ro sai sót?

Hầu hết hệ thống chọn một thái cực. xGrid không chọn cực nào.

Trong chế độ khẩn cấp, chúng tôi loại bỏ các trường không thiết yếu. Địa chỉ, số bảo hiểm, tài liệu dị ứng chi tiết — tất cả có thể bỏ qua. Nhưng ba bước xác nhận vẫn bắt buộc bất kể trạng thái hệ thống:

• Xác minh danh tính bệnh nhân
• Xác nhận tên thuốc và liều lượng
• Xác minh phản ứng chéo chế phẩm máu (cross-match)

Triết lý thiết kế: con người dưới áp lực sẽ tự nhiên bỏ qua các bước. Đó không phải lỗi hành vi — đó là sự thích ứng. Nhiệm vụ của hệ thống là cho phép họ bỏ qua các bước có thể chờ, đồng thời không cho phép bỏ qua các bước không thể chờ.

3. Thiết Kế Hồ Sơ Để Học Hỏi, Không Phải Để Truy Cứu

Mỗi lần bàn giao trong xGrid đều tạo một bản ghi. Mỗi lần cấp phát thuốc, mỗi lần chuyển viện, mỗi lần biến động kho. Dữ liệu đủ chi tiết để tái dựng toàn bộ dòng thời gian sự kiện.

Nhưng chúng tôi thiết kế hệ thống ghi chép với mục đích mà hầu hết hệ thống kiểm toán bỏ lỡ: học từ thành công, không chỉ từ thất bại.

Ví dụ: sau một cuộc sơ tán đặc biệt suôn sẻ, hồ sơ cho thấy một điều dưỡng đã chủ động quét dữ liệu chế phẩm máu vào điện thoại ba phút trước khi lệnh sơ tán đến. Điều này không có trong bất kỳ quy trình nào. Đó là ứng biến. Và nó tiết kiệm mười lăm phút quét lại tại trạm tiếp nhận.

Safety-I sẽ không bao giờ phát hiện điều này, vì Safety-I chỉ điều tra khi có sai sót. Safety-II điều tra thường xuyên, bởi nguyên nhân thành công cũng đáng nghiên cứu như nguyên nhân thất bại. Sự ứng biến đó của điều dưỡng giờ đã trở thành quy trình được khuyến nghị.

4. Cung Cấp Cách Hợp Pháp Để Phá Vỡ Quy Tắc

Quy trình cấp phát thuốc bình thường: bác sĩ kê đơn, dược sĩ xác minh, điều dưỡng xác nhận, cấp phát. Ba cổng kiểm soát. Safety-I vững chắc.

Thực tế thảm họa: bác sĩ đang phân loại hai mươi bệnh nhân. Dược sĩ ở trạm khác. Bệnh nhân đang xuất huyết. Điều dưỡng cần thuốc cầm máu ngay lập tức.

Nếu hệ thống nói "không có đơn, không cấp phát", điều dưỡng sẽ tìm cách lách — ghi giấy, ra lệnh miệng, mở tủ thuốc trực tiếp. Thuốc được sử dụng. Hệ thống không ghi nhận gì.

xGrid cung cấp cơ chế ghi đè khẩn cấp 24 giờ (break-glass). Điều dưỡng có thể kích hoạt ủy quyền khẩn cấp. Hệ thống ghi nhận hành động, đánh dấu là được ủy quyền khẩn cấp, và gắn cờ để xét duyệt. Hoạt động tiếp tục với dấu vết kiểm toán đầy đủ.

Đây không phải là bỏ qua an toàn. Đây là một tính năng an toàn. Điều nguy hiểm nhất mà hệ thống có thể làm là buộc con người làm việc bên ngoài nó, bởi khi đó bạn mất toàn bộ khả năng giám sát. Một hành vi phá vỡ quy tắc hợp pháp, được ghi nhận, an toàn hơn vô hạn so với một giải pháp lách luật vô hình.

Bằng Chứng: Patient I

Bộ kiểm thử E2E của chúng tôi bao gồm Patient I — Bài Kiểm Tra Hợp Nhất (Consolidation Test). Nó được thiết kế để thử thách tối đa.

Thiết lập: 8 trạm, 3 trạm buộc sơ tán đồng thời. Trong quá trình sơ tán:

• Truyền máu đang diễn ra (chuỗi giám sát phải được duy trì)
• Phẫu thuật đang tiến hành (phải ngắt, ghi nhận qua bàn giao ISBAR, vận chuyển, tiếp tục)
• Thuốc đang chuyển giữa các trạm (phải phân bổ lại cho các trạm còn hoạt động)

Kết quả:

Xac minh	Ket qua
Danh tinh benh nhan duoc bao toan qua chuyen tram	Dat
Chuoi giam sat mau duoc duy tri, phan ung cheo tai tram moi	Dat
Phau thuat tiep tuc voi ho so ban giao ISBAR day du	Dat
Kho duoc doi chieu qua tat ca cac tram hop nhat	Dat
34 buoc thuc hien, 34 dat, khong mat du lieu	Dat

Đây là Safety-II trong thực tiễn. Kịch bản không phải "ngăn sơ tán" — bạn không thể. Kịch bản là "làm cho sơ tán thành công". Mọi điểm dữ liệu tồn tại. Mọi bàn giao được ghi nhận. Mọi cổng an toàn giữ vững nơi cần thiết, và nhường đường nơi cần nhường.

Bổ Sung, Không Phải Thay Thế

Safety-II không phản đối các phòng tuyến. xGrid vẫn có quét mã vạch, xác minh danh tính, kiểm tra liều lượng, kiểm soát truy cập theo vai trò. Các cơ chế Safety-I này ngăn chặn những sai sót có thể ngăn chặn được.

Safety-II xử lý tất cả những trường hợp còn lại — khi điều kiện quá xuống cấp cho quy trình bình thường, khi quy trình giả định nguồn lực bạn không có, khi câu trả lời sách giáo khoa không phù hợp với tình huống trước mắt.

Trong moi truong on dinh, Safety-I thuong la du. Trong moi truong tham hoa, no can thiet nhung chua du.

Buc tuong se bi pha vo. Cau hoi quan trong la dieu gi xay ra tiep theo.

---

Bai lien quan: Bai Kiem Tra "Bo Di" — Thiet Ke Phan Mem Ton Tai Lau Hon Nguoi Tao Ra No

---

Tai lieu tham khao

1. Hollnagel E. Safety-I and Safety-II: The Past and Future of Safety Management. Ashgate Publishing; 2014. DOI