Một ca bị bỏ sót. Hệ thống hỗ trợ có tham gia vào quy trình. Câu hỏi đầu tiên thường được đặt ra là: lỗi của máy hay của người?
Đây là câu hỏi sai, và nó dẫn phân tích đi sai hướng ngay từ đầu.
Vì sao câu hỏi đó sai
Hầu hết sự cố trong y tế không đến từ một điểm hỏng duy nhất. Chúng đến từ việc nhiều lớp phòng vệ cùng thất bại — mỗi lớp có một lỗ hổng, và trong ca này các lỗ hổng tình cờ thẳng hàng.
Dừng phân tích ở một nguyên nhân duy nhất để lại mọi lỗ hổng khác nguyên vẹn.
Các lớp cần tách
Lớp 1: dữ liệu đầu vào
- Dữ liệu có đầy đủ không?
- Chất lượng có đạt mức hệ thống cần không?
- Có trường hợp nào hệ thống lẽ ra phải từ chối xử lý nhưng vẫn cho kết quả không?
Lớp 2: hoạt động của mô hình
- Hệ thống có đưa ra kết quả không, hay không xử lý được?
- Kết quả là gì?
- Ca này có nằm trong phạm vi mà mô hình được kiểm định không?
- Phiên bản nào đang chạy?
Lớp 3: cách trình bày
- Kết quả hiển thị ở đâu, có dễ thấy không?
- Mức độ nổi bật có tương xứng với mức khẩn không?
- Có lẫn trong nhiều thông tin khác không?
Lớp 4: tiếp nhận của người dùng
- Người dùng có thấy không?
- Nếu thấy mà bỏ qua, lý do là gì?
- Họ có được đào tạo về hệ thống không?
- Khối lượng công việc lúc đó thế nào?
Lớp 5: đường đáp ứng
- Nếu có cảnh báo, nó tới đúng người không?
- Người nhận có biết phải làm gì không?
- Có đủ nguồn lực để hành động không?
- Có cơ chế chuyển lên cấp cao hơn không?
Lớp 6: bối cảnh tổ chức
- Nhân lực có đủ không?
- Ca trực nào, thời điểm nào?
- Có thay đổi quy trình gần đây không?
- Có sự cố tương tự đã xảy ra chưa?
Bẫy: thiên lệch do biết trước kết quả
Đây là bẫy lớn nhất và khó tránh nhất.
Khi đã biết kết cục xấu, mọi dấu hiệu trước đó trông rõ ràng hơn nhiều so với lúc chúng thực sự xuất hiện.
Người phân tích nhìn lại và thấy "lẽ ra phải nhận ra" — trong khi vào thời điểm đó, dấu hiệu đó nằm giữa hàng chục dấu hiệu khác, phần lớn không dẫn tới gì.
Cách giảm thiên lệch:
- Tái dựng bối cảnh đầy đủ: người trong cuộc biết gì tại thời điểm đó, và không biết gì.
- Hỏi: có bao nhiêu ca tương tự trong tuần đó mà không có kết cục xấu?
- Hỏi: nếu gặp lại đúng bối cảnh đó, một người có năng lực bình thường sẽ làm gì?
Câu thứ hai đặc biệt hữu ích: nếu cùng một mẫu hình xuất hiện hai mươi lần trong tuần và mười chín lần không có vấn đề gì, thì việc không phản ứng ở lần thứ hai mươi không phải là sự cẩu thả.
Các câu hỏi đặc thù khi có hệ thống tự động
- Hệ thống có được thiết kế để bắt loại ca này không? Nếu không, đó không phải lỗi của hệ thống mà là khoảng trống trong phạm vi bao phủ.
- Ca này có nằm trong phân bố dữ liệu huấn luyện không?
- Người dùng có hiểu đúng giới hạn của hệ thống không?
- Việc có hệ thống có làm giảm sự cảnh giác không? Đây là câu khó hỏi nhưng cần hỏi.
- Đã có mẫu hình tương tự trong dữ liệu giám sát chưa?
Câu thứ tư chạm vào hiện tượng thiên lệch tự động hoá, và câu trả lời trung thực đòi hỏi một môi trường mà người trong cuộc không sợ bị quy trách nhiệm.
Văn hoá an toàn
Phân tích chỉ có giá trị khi người trong cuộc nói thật.
Điều kiện:
- Tách rõ phân tích an toàn khỏi quy trình kỷ luật.
- Tập trung vào hệ thống, không vào cá nhân.
- Phân biệt rõ giữa sai sót trung thực và hành vi cố ý vi phạm quy trình.
- Bảo mật danh tính người tham gia phân tích.
Không có các điều kiện này, phân tích sẽ thu được một phiên bản đã được gọt giũa của sự việc — và bài học thật bị mất.
Kết quả phân tích nên dẫn tới gì
Không phải một khuyến nghị chung về việc cần cẩn thận hơn. Đó không phải hành động cải tiến.
Các hành động có hiệu quả, xếp theo độ bền:
| Loại hành động | Độ bền |
|---|---|
| Thay đổi thiết kế để lỗi không xảy ra được | Cao nhất |
| Thêm lớp kiểm tra tự động | Cao |
| Thay đổi quy trình làm việc | Trung bình |
| Danh sách kiểm | Trung bình |
| Đào tạo | Thấp |
| Nhắc nhở cẩn thận hơn | Gần bằng không |
Mỗi hành động cần có người chịu trách nhiệm, thời hạn, và cách kiểm tra đã thực hiện.
Theo dõi sau đó
- Các hành động đã được thực hiện chưa?
- Chúng có tác dụng không — đo bằng gì?
- Có sự cố tương tự lặp lại không?
- Có phát sinh vấn đề mới từ chính thay đổi đó không?
Mục cuối đáng lưu ý: một biện pháp khắc phục có thể tạo ra gánh nặng mới ở chỗ khác. Cần kiểm lại sau một thời gian.
Chia sẻ bài học
Một sự cố ở một cơ sở thường phản ánh vấn đề có thể xảy ra ở nơi khác dùng cùng hệ thống.
Việc chia sẻ — với nhà cung cấp, với mạng lưới chuyên môn, với cơ quan quản lý khi phù hợp — là cách duy nhất để bài học không phải trả giá nhiều lần.
Câu hỏi thường gặp
Vì sao không nên dừng ở việc quy nguyên nhân cho máy hoặc cho người?
Vì hầu hết sự cố là kết quả của nhiều lớp phòng vệ cùng thất bại chứ không phải một điểm hỏng duy nhất. Dừng ở một nguyên nhân duy nhất khiến các lỗ hổng khác vẫn nguyên vẹn và sự cố tương tự sẽ lặp lại.
Các lớp cần tách khi phân tích là gì?
Thường gồm: dữ liệu đầu vào, hoạt động của mô hình, cách kết quả được trình bày, việc người dùng tiếp nhận ra sao, đường đáp ứng sau đó, và bối cảnh tổ chức như khối lượng công việc hay nhân lực.
Bẫy phổ biến nhất trong phân tích là gì?
Thiên lệch do biết trước kết quả: khi đã biết kết cục xấu, mọi dấu hiệu trước đó trông rõ ràng hơn nhiều so với lúc chúng thực sự xuất hiện. Điều này dẫn tới đánh giá quá khắt khe với quyết định của người trong cuộc.
Kết quả phân tích nên dẫn tới gì?
Các thay đổi hệ thống cụ thể có người chịu trách nhiệm và có thời hạn, không phải một khuyến nghị chung chung về việc cần cẩn thận hơn. Một hành động cải tiến không thay đổi được điều kiện làm việc thì sẽ không ngăn được sự cố lặp lại.