Nghĩa vụ báo cáo sự cố liên quan tới phần mềm y tế

Hệ thống giám sát sau lưu hành của thiết bị y tế dựa vào một nguồn dữ liệu chính: báo cáo từ nơi sử dụng.

Với phần mềm, nguồn này hoạt động kém hơn so với thiết bị vật lý — và có lý do cụ thể.

Vì sao sự cố phần mềm khó nhận ra

Không có hỏng hóc nhìn thấy được

Một máy hỏng thì rõ ràng. Một mô hình bỏ sót thì không có dấu hiệu gì.

Hậu quả gián tiếp

Thường phải qua nhiều bước: hệ thống bỏ sót, người dùng không phát hiện, chẩn đoán chậm, kết quả xấu đi.

Quy kết nguyên nhân về phần mềm đòi hỏi một chuỗi lập luận, và ở mỗi mắt xích đều có yếu tố khác cùng góp phần.

Bị coi là hạn chế cố hữu

Đây là rào cản lớn nhất. Ai cũng biết mô hình không hoàn hảo, nên một lần bỏ sót thường được coi là "trong dự kiến" chứ không phải sự cố cần báo.

Nhưng nếu không báo, không ai biết tỷ lệ bỏ sót thực tế có vượt mức đã công bố hay không.

Không rõ quy trình

Người phát hiện thường không biết báo cho ai và theo mẫu nào.

Những gì nên được báo cáo

Không chỉ các trường hợp gây hại. Danh sách nên gồm:

• Hệ thống bỏ sót một tình trạng mà nó được thiết kế để phát hiện.
• Báo động sai dẫn tới can thiệp không cần thiết.
• Kết quả sai rõ ràng — con số vô lý, phân vùng sai hoàn toàn.
• Hệ thống ngừng hoạt động trong thời gian có thể ảnh hưởng chăm sóc.
• Kết quả gán nhầm người bệnh.
• Hành vi khác so với mô tả trong tài liệu.
• Trường hợp suýt xảy ra — lỗi được phát hiện kịp trước khi gây hại.

Mục cuối có giá trị cao nhất về mặt cải tiến: nó cho biết về lỗ hổng mà chưa phải trả giá.

Báo cho ai

Hệ thống nội bộ

Báo cáo sự cố của cơ sở. Đây là kênh đầu tiên và cần dễ tiếp cận nhất.

Nhà sản xuất

Họ là bên duy nhất sửa được vấn đề trong sản phẩm, và họ cũng có nghĩa vụ tổng hợp báo cáo từ mọi nơi sử dụng.

Một mẫu hình chỉ xuất hiện khi gom dữ liệu từ nhiều cơ sở — mỗi nơi thấy một lần có thể nghĩ là ngẫu nhiên.

Cơ quan quản lý

Tuỳ mức độ nghiêm trọng và tuỳ quy định tại nơi áp dụng. Cần tra cụ thể ngưỡng và thời hạn báo cáo.

Nội dung một báo cáo hữu ích

• Mô tả sự việc theo trình tự thời gian.
• Phiên bản phần mềm và cấu hình đang dùng.
• Dữ liệu đầu vào — loại thiết bị, thông số, chất lượng.
• Kết quả hệ thống đưa ra.
• Kết quả đúng là gì và xác định bằng cách nào.
• Hậu quả thực tế hoặc tiềm tàng.
• Đã phát hiện bằng cách nào.
• Đã xử lý thế nào.

Mục thứ bảy đáng chú ý: nếu lỗi được phát hiện nhờ một lớp kiểm tra khác, đó là thông tin có giá trị về việc lớp nào đang hoạt động hiệu quả.

Rào cản văn hoá

Ngay cả khi có quy trình, tỷ lệ báo cáo thường thấp. Các lý do lặp lại:

• Lo bị quy trách nhiệm.
• Tốn thời gian điền biểu mẫu.
• Cảm giác báo cũng chẳng thay đổi được gì.
• Không chắc đây có phải sự cố không.
• Không biết báo ở đâu.

Các biện pháp có hiệu quả

• Tách báo cáo an toàn khỏi quy trình kỷ luật — đây là điều kiện nền tảng.
• Biểu mẫu ngắn, điền được trong vài phút.
• Báo cáo được ngay từ trong hệ thống đang dùng, không phải mở ứng dụng khác.
• Phản hồi lại cho người báo — đây là yếu tố quyết định nhất.
• Công bố các thay đổi đã thực hiện nhờ báo cáo.

Yếu tố phản hồi đáng nhấn mạnh: khi người báo cáo thấy việc mình làm dẫn tới thay đổi thật, tỷ lệ báo cáo tăng. Khi không có phản hồi gì, nó giảm dần tới gần bằng không.

Phân tích nội bộ

Ngoài việc báo ra ngoài, cơ sở nên tự phân tích:

• Gom các báo cáo liên quan tới cùng hệ thống theo chu kỳ.
• Tìm mẫu hình lặp lại.
• Đối chiếu với dữ liệu giám sát hiệu năng.
• Quyết định có cần điều chỉnh cấu hình, đào tạo lại, hay tạm dừng.

Một báo cáo đơn lẻ có thể là ngẫu nhiên. Năm báo cáo cùng kiểu là một tín hiệu.

Điều cần có trong hợp đồng

• Kênh và thời hạn báo cáo sự cố cho nhà sản xuất.
• Nghĩa vụ của nhà sản xuất phản hồi trong thời gian xác định.
• Nghĩa vụ thông báo ngược — khi nhà sản xuất phát hiện vấn đề ở nơi khác, họ phải báo cho mọi cơ sở đang dùng.
• Quy trình khi cần tạm ngừng sử dụng.

Mục thứ ba quan trọng và thường không có trong hợp đồng chuẩn: một cơ sở cần biết khi sản phẩm mình đang dùng có vấn đề được phát hiện ở nơi khác.

Câu hỏi thường gặp