Chủ đề 1.6 — An toàn lâm sàng và quản lý rủi ro

Tóm lại trong một câu: An toàn lâm sàng là thực hành có kỷ luật, có bằng chứng nhằm tìm ra những cách công nghệ số của bạn có thể gây hại cho bệnh nhân và kiểm soát các mối nguy đó trước khi chúng đến với bất kỳ ai — an toàn được thiết kế vào từ bản phác thảo đầu tiên, chứ không phải gắn thêm trước khi đưa vào vận hành.

Vì sao điều này quan trọng trong y tế và chăm sóc#

Ở hầu hết các lĩnh vực, một lỗi phần mềm là một sự bất tiện: một trang không tải được, một đơn hàng bị trùng, một báo cáo bị trễ. Trong y tế và chăm sóc, cùng loại lỗi đó có thể giết người. Một ô nhập thuốc cắt mất dấu thập phân, một màn hình kết quả hiển thị sai bệnh nhân, một thuật toán phân loại lặng lẽ ngừng đánh dấu một triệu chứng, một tích hợp âm thầm làm rơi các bản ghi dị ứng — mỗi cái là một lỗi phần mềm, và mỗi cái cũng là một mối nguy lâm sàng có thể gây tổn hại nghiêm trọng hoặc tử vong. Đó là lý do an toàn lâm sàng không phải là một sự chỉn chu về chất lượng chồng lên kỹ thuật tốt; nó là một ngành riêng biệt, được quản lý, có các tiêu chuẩn, vai trò và bằng chứng của riêng mình.

Rủi ro mang tính bất đối xứng và thường vô hình. Khi một hệ thống số hoạt động, không ai thấy tác hại mà nó đã ngăn chặn; khi nó thất bại, tác hại có thể thảm khốc, chậm trễ và lan khắp hàng nghìn bệnh nhân trước khi ai đó nhận ra một mô thức. Sự kết hợp đó — hậu quả cao, khả năng quan sát thấp, bán kính ảnh hưởng rộng — nghĩa là bạn không thể trông cậy vào người dùng để bắt lỗi hay vào các sự cố để dạy bạn mọi thứ. Bạn phải lập luận về tác hại một cách chủ động, trước khi triển khai, và tiếp tục lập luận khi hệ thống đang chạy. Ở Vương quốc Anh, lập luận chủ động này không phải tùy chọn: các tổ chức NHS và nhà cung cấp của họ có nghĩa vụ theo hợp đồng và nghề nghiệp phải áp dụng các tiêu chuẩn quản lý rủi ro lâm sàng quốc gia, và phải có khả năng trình bày cách làm của mình. Làm đúng điều này không thể tách rời khỏi bằng chứng (xem Chủ đề 1.3 — Quyết định dựa trên bằng chứng), khỏi quản trị thông tin và an ninh mạng (xem Chủ đề 1.7 — Quản trị thông tin, bảo vệ dữ liệu và an ninh mạng), và khỏi cách bạn vận hành các dịch vụ khi chúng đã chạy (xem Chủ đề 3.8 — Quản lý dịch vụ và vận hành trực tiếp).

Các khái niệm cốt lõi#

An toàn bệnh nhân và quản lý rủi ro. An toàn bệnh nhân là việc phòng ngừa, giảm thiểu, báo cáo và phân tích tác hại đối với bệnh nhân từ việc chăm sóc. Quản lý rủi ro lâm sàng áp dụng ngành quản lý rủi ro nói chung — nhận diện, đánh giá, ưu tiên và kiểm soát rủi ro — vào câu hỏi cụ thể về cách một hệ thống CNTT y tế có thể góp phần gây hại cho bệnh nhân. Hai tiêu chuẩn quốc gia chi phối điều này ở Anh là DCB0129 và DCB0160 (DCB là viết tắt của Data Coordination Board; đây là các tiêu chuẩn của Ủy ban Tiêu chuẩn hóa về Tiêu chuẩn Thông tin Chăm sóc / SCCI được bắt buộc theo Đạo luật Y tế và Chăm sóc Xã hội 2012). DCB0129 đặt nghĩa vụ lên nhà sản xuất hoặc nhà cung cấp hệ thống CNTT y tế; DCB0160 đặt nghĩa vụ lên tổ chức y tế triển khai và sử dụng nó. Chúng bổ sung cho nhau: hồ sơ an toàn sạch của nhà cung cấp không giải phóng nghĩa vụ của bệnh viện triển khai về việc đánh giá các mối nguy do cấu hình, quy trình và bối cảnh riêng của họ đưa vào.

Cán bộ An toàn Lâm sàng (CSO). Cả hai tiêu chuẩn đều yêu cầu một Cán bộ An toàn Lâm sàng có tên, đủ trình độ và kinh nghiệm — một bác sĩ lâm sàng đã đăng ký, đang hành nghề, đã hoàn thành đào tạo an toàn lâm sàng được công nhận — để sở hữu hoạt động quản lý rủi ro lâm sàng và đích thân phê duyệt hồ sơ an toàn. Vai trò CSO là một yêu cầu về năng lực, không phải một chức danh bạn có thể giao cho bất kỳ ai đang rảnh. CSO xác nhận rằng các mối nguy đã được nhận diện và kiểm soát đến mức chấp nhận được; đó là một phán đoán nghề nghiệp đi kèm trách nhiệm giải trình nghề nghiệp.

Các hiện vật quản lý rủi ro lâm sàng. Ba tài liệu neo giữ ngành này. Hồ sơ quản lý rủi ro lâm sàng là vật chứa toàn bộ bằng chứng an toàn của một hệ thống. Nhật ký mối nguy là sổ đăng ký sống về mọi mối nguy đã nhận diện, nguyên nhân, hậu quả, xếp hạng rủi ro, biện pháp kiểm soát và rủi ro còn lại. Hồ sơ an toàn lâm sàng là lập luận có cấu trúc, được bằng chứng hỗ trợ, rằng hệ thống an toàn ở mức chấp nhận được cho mục đích sử dụng dự kiến trong bối cảnh dự kiến — kèm theo một báo cáo hồ sơ an toàn tóm tắt lập luận để phê duyệt. Đây không phải giấy tờ vì giấy tờ; chúng là cách lập luận an toàn được làm cho rõ ràng, có thể rà soát và bền vững.

Phân tích mối nguy: nhận diện, phân tích, đánh giá, kiểm soát. Vòng lặp cốt lõi là: nhận diện mối nguy (tưởng tượng một cách có hệ thống cách hệ thống có thể góp phần gây hại — qua hội thảo, các buổi đi qua quy trình lâm sàng, phân tích chế độ lỗi), phân tích rủi ro (ước lượng mức độ nghiêm trọng của tác hại và khả năng xảy ra), đánh giá rủi ro (so sánh rủi ro ước lượng với tiêu chí chấp nhận được), và kiểm soát rủi ro (đưa vào các biện pháp — thay đổi thiết kế, cảnh báo, đào tạo, quy trình — để giảm rủi ro không chấp nhận được, rồi đánh giá lại rủi ro còn lại). Rủi ro được giảm xuống mức thấp nhất có thể thực hiện một cách hợp lý (ALARP): bạn tiếp tục kiểm soát cho đến khi việc giảm thêm sẽ trở nên quá tương xứng một cách nghiêm trọng so với lợi ích thu được.

Quy định thiết bị y tế, MHRA và Phần mềm như một Thiết bị Y tế (SaMD). Một số công nghệ y tế số là thiết bị y tế được quản lý. Phần mềm có mục đích y tế — chẩn đoán, phòng ngừa, theo dõi, dự đoán, điều trị — tự nó có thể là một thiết bị y tế: Phần mềm như một Thiết bị Y tế (SaMD). Ở Vương quốc Anh, Cơ quan Quản lý Thuốc và Sản phẩm Chăm sóc Sức khỏe (MHRA) quản lý thiết bị y tế, bao gồm SaMD, và tiêu chuẩn vòng đời phần mềm IEC 62304 chi phối cách phần mềm như vậy phải được phát triển. Quyết định công nghệ của bạn có phải là thiết bị được quản lý hay không là một câu hỏi ngưỡng với hệ quả lớn, và nó tách biệt với — dù nằm cạnh — quản lý rủi ro lâm sàng DCB0129/0160.

Tiêu chí Đánh giá Công nghệ Số (DTAC). DTAC là chuẩn cơ sở quốc gia mà các tổ chức NHS và chăm sóc xã hội dùng để đánh giá các sản phẩm số trước khi mua sắm, bao gồm an toàn lâm sàng (bằng chứng tuân thủ DCB0129), bảo vệ dữ liệu, an ninh kỹ thuật, khả năng tương tác và tính dễ dùng. Nó không thay thế quản lý rủi ro lâm sàng; nó kiểm tra rằng nhà cung cấp đã làm việc đó.

Yếu tố con người và văn hóa an toàn. Yếu tố con người (công thái học) là nghiên cứu khoa học về cách con người tương tác với hệ thống trong điều kiện thực — mệt mỏi, gián đoạn, tải nhận thức, mệt mỏi vì cảnh báo. Phần lớn tác hại số phát sinh không phải từ mã "sai" mà từ những thiết kế khiến hành động an toàn trở nên khó và hành động không an toàn trở nên dễ. Văn hóa an toàn là cam kết của tổ chức trong việc đưa ra, báo cáo và học hỏi từ rủi ro mà không đổ lỗi — sự khác biệt giữa một nhóm che giấu những suýt xảy ra và một nhóm khai thác chúng để cải tiến.

Báo cáo và học hỏi từ sự cố. Ở Anh, Learn from Patient Safety Events (LFPSE — Học hỏi từ các sự kiện an toàn bệnh nhân) là dịch vụ quốc gia để ghi nhận các sự kiện an toàn bệnh nhân, và Khung Ứng phó Sự cố An toàn Bệnh nhân (PSIRF) nêu cách các tổ chức NHS ứng phó và học hỏi từ sự cố — nhấn mạnh phân tích nguyên nhân gốc tương xứng, dựa trên hệ thống hơn là đổ lỗi. Các hệ thống đang chạy tạo ra các mối nguy mới, nên an toàn lâm sàng tiếp tục sau khi vận hành thông qua phản hồi sự cố vào nhật ký mối nguy.

Thực hành tốt nhất#

1. Bổ nhiệm một Cán bộ An toàn Lâm sàng đủ năng lực và trao cho họ quyền hạn thực sự. Hãy nêu tên một bác sĩ lâm sàng đã đăng ký, đang hành nghề, có đào tạo an toàn lâm sàng được công nhận làm CSO cho mọi hệ thống trong phạm vi, và bảo đảm sự phê duyệt của họ là một cổng thực sự, không phải con dấu cao su vào ngày trước khi ra mắt. CSO phải có thể nói "chưa được" và được lắng nghe — nghĩa là bảo vệ thời gian, sự độc lập và vị thế của họ với hội đồng chương trình. Một CSO bị áp lực triển khai lấn át là một hư cấu về quản trị.

2. Nhận diện mối nguy sớm, với bác sĩ lâm sàng có mặt trong phòng. Bắt đầu các hội thảo mối nguy trong giai đoạn khám phá và thiết kế, không phải trước khi vận hành, vì các biện pháp kiểm soát rẻ nhất và hiệu quả nhất là các thay đổi thiết kế thực hiện trước khi xây dựng bất cứ thứ gì (xem Chủ đề 3.5 — Vòng đời triển khai). Hãy mời các bác sĩ tuyến đầu, không chỉ nhà phân tích, vì họ biết công việc thực sự diễn ra như thế nào — những gián đoạn, những cách xoay xở, cách một màn hình được đọc lúc 3 giờ sáng. Hãy đi qua các kịch bản lâm sàng thực tế và hỏi không ngừng: "hệ thống này có thể góp phần khiến bệnh nhân bị hại như thế nào?"

3. Giữ một nhật ký mối nguy sống, không phải một tài liệu ngày ra mắt. Hãy xem nhật ký mối nguy là một sổ đăng ký bền vững mở ra từ giai đoạn khám phá và không bao giờ đóng khi hệ thống còn đang chạy. Mỗi mối nguy ghi lại nguyên nhân, tác hại tiềm tàng, xếp hạng rủi ro ban đầu, các biện pháp kiểm soát đã áp dụng và rủi ro còn lại sau kiểm soát. Khi một sự cố, một thay đổi hoặc một suýt xảy ra làm lộ ra một mối nguy mới, nó đi vào nhật ký và được xử lý qua cùng vòng lặp — nhật ký là trí nhớ của lập luận an toàn của bạn.

4. Để tổ chức triển khai sở hữu DCB0160, ngay cả khi có nhà cung cấp tuân thủ. Hồ sơ an toàn DCB0129 của nhà cung cấp bao phủ sản phẩm như được chế tạo; nó không thể bao phủ cách bạn cấu hình nó, những quy trình bạn bọc quanh nó, hay những nhóm dân số nào của bạn sử dụng nó. Hãy thực hiện đánh giá DCB0160 của chính bạn cho các mối nguy địa phương — tích hợp với các hệ thống khác của bạn, chất lượng dữ liệu của bạn, các lộ trình lâm sàng của bạn — và giữ nhật ký mối nguy riêng. Cho rằng sự đảm bảo của nhà cung cấp bao phủ bối cảnh của bạn là một lối tắt phổ biến và nguy hiểm.

5. Làm cho kiểm soát rủi ro tương xứng và ưu tiên thiết kế hơn cảnh báo. Xếp hạng các biện pháp kiểm soát theo độ mạnh: thiết kế loại bỏ mối nguy (ràng buộc, mặc định, cơ chế bắt buộc) thắng một cảnh báo trên màn hình, và cảnh báo thắng một dòng trong sổ tay đào tạo. Dành sự đảm bảo nặng nhất cho các mối nguy có hậu quả cao nhất và áp dụng quy trình nhẹ hơn, nhanh hơn cho các thay đổi thực sự rủi ro thấp — sự tương xứng là điều cho phép an toàn theo kịp việc triển khai. Giảm rủi ro xuống ALARP và ghi lại vì sao rủi ro còn lại là chấp nhận được.

6. Thiết kế cho yếu tố con người, và tôn trọng mệt mỏi vì cảnh báo. Giả định người dùng bận rộn, bị gián đoạn và đang khớp mô thức, và thiết kế sao cho hành động an toàn là hành động dễ, mặc định. Đề phòng quá tải cảnh báo: một cảnh báo kích hoạt quá thường xuyên sẽ bị phớt lờ, nên mỗi cảnh báo bổ sung phải xứng đáng với vị trí của nó, nếu không nó làm suy giảm những cảnh báo quan trọng. Thử nghiệm khả năng sử dụng trong điều kiện thực tế là một hoạt động an toàn lâm sàng, không chỉ là sự tế nhị của thiết kế.

7. Xác định tình trạng quy định của bạn một cách có chủ đích. Hãy sớm hỏi liệu phần mềm của bạn có đáp ứng định nghĩa thiết bị y tế hay SaMD không, và nếu có, hãy tham gia các yêu cầu của MHRA và IEC 62304 ngay từ đầu thay vì phát hiện nghĩa vụ muộn. Phân loại sai tốn kém theo cả hai chiều — một thiết bị chưa đăng ký là thất bại pháp lý và an toàn, trong khi phân loại quá mức một công cụ đơn giản làm lãng phí năng lực đảm bảo khan hiếm. Khi nghi ngờ, hãy xin tư vấn quy định và ghi lại lập luận.

8. Dùng DTAC như một mức sàn, không phải vạch đích. Xem Tiêu chí Đánh giá Công nghệ Số là kiểm tra đầu vào tối thiểu cho bất kỳ sản phẩm số nào được mua sắm, xác nhận rằng an toàn lâm sàng, bảo vệ dữ liệu, an ninh, khả năng tương tác và tính dễ dùng đã được giải quyết. Vượt qua DTAC nghĩa là nhà cung cấp đã làm công việc; không có nghĩa là sản phẩm an toàn trong bối cảnh của bạn, vì vậy hãy ghép nó với đánh giá DCB0160 của riêng bạn và giám sát khi vận hành.

9. Khép vòng từ các sự cố đang xảy ra vào nhật ký mối nguy. Nối việc báo cáo sự cố của bạn — các báo cáo LFPSE, các cuộc điều tra PSIRF, báo cáo suýt xảy ra tại chỗ — trở lại quản lý rủi ro lâm sàng để tác hại thực tế và các suýt xảy ra cập nhật các mối nguy và biện pháp kiểm soát của bạn. Một hồ sơ an toàn không bao giờ được xem lại sau khi vận hành sẽ mục nát, vì các hệ thống đang chạy, tích hợp và thực hành lâm sàng đều trôi dạt (xem Chủ đề 3.8 — Quản lý dịch vụ và vận hành trực tiếp). Việc học dựa trên hệ thống và có ý thức về đổ lỗi, không phải tìm ai đó để trừng phạt.

10. Xây dựng một văn hóa an toàn công bằng, khuyến khích báo cáo. Làm cho việc báo cáo suýt xảy ra và thách thức một lần ra mắt vì lý do an toàn trở nên an toàn và được kỳ vọng, vì các mối nguy bạn không bao giờ nghe thấy là các mối nguy bạn không thể kiểm soát. Các nhà lãnh đạo định giọng điệu này bằng cách phản hồi tin xấu bằng sự tò mò và cải tiến thay vì đổ lỗi, và bằng cách xem sự thận trọng của CSO là quý giá chứ không phải cản trở. Văn hóa là nền tảng mà mọi thực hành khác ở đây dựa vào.

Câu hỏi để thảo luận với nhóm của bạn#

1. Trong danh mục hiện tại của chúng ta, chúng ta đang dựa vào sự đảm bảo an toàn của nhà cung cấp để bao phủ những rủi ro mà thực ra thuộc về chúng ta ở đâu? Câu hỏi này thăm dò sự phân chia DCB0129/DCB0160 mà các nhóm thường xuyên làm mờ. Hồ sơ an toàn DCB0129 của nhà cung cấp giải quyết sản phẩm như được chế tạo, nhưng ngay khi bạn cấu hình nó, kết nối nó với các hệ thống khác của bạn, bọc các quy trình địa phương quanh nó và hướng nó vào quần thể bệnh nhân cụ thể của bạn, bạn đưa vào những mối nguy mà nhà cung cấp chưa từng đánh giá và không thể đánh giá. Căng thẳng trung thực là thực hiện đánh giá DCB0160 của riêng bạn tốn thời gian lâm sàng và phân tích khan hiếm, và thật cám dỗ khi xem sự đảm bảo sạch của nhà cung cấp và một lần vượt qua DTAC là đủ. Hãy đi qua một triển khai đang chạy hoặc sắp tới và hỏi cụ thể: CSO có tên của chúng ta cho nó là ai, chúng ta có nhật ký mối nguy riêng không, và những mối nguy nào phát sinh thuần túy từ bối cảnh địa phương của chúng ta chứ không phải từ chính sản phẩm? Một câu trả lời tốt gọi tên các hệ thống cụ thể nơi đánh giá địa phương còn mỏng, phân biệt mối nguy của sản phẩm với mối nguy của triển khai, và cam kết sở hữu cái sau thay vì giả định chúng đã được bao phủ.

2. Quy trình an toàn lâm sàng của chúng ta tương xứng đến đâu — chúng ta có đang chôn các thay đổi rủi ro thấp trong giấy tờ trong khi các thay đổi hậu quả cao lọt qua nhờ đà không? Chủ đề chủ trương sự đảm bảo nên co giãn theo rủi ro lâm sàng: sự soi xét nặng nhất cho các mối nguy có hậu quả cao nhất, quy trình nhẹ hơn, nhanh hơn ở nơi rủi ro thực sự thấp. Câu hỏi này kiểm tra liệu tổ chức của bạn có thực sự hiệu chỉnh, hay áp dụng một mức cứng nhắc. Cả hai chiều thất bại đều có thật và tốn kém — một quy trình nặng đồng đều dạy các nhóm xem an toàn lâm sàng như một khoản thuế quan liêu và đi vòng nó, trong khi một quy trình nhẹ đồng đều để một thay đổi trong công cụ tính liều thuốc đi qua với cùng công sức như một thay đổi ở trang trợ giúp. Mối nguy tinh vi hơn là đà, chứ không phải rủi ro, quyết định sự soi xét: một chương trình hàng đầu với sự chú ý của ban điều hành có thể có hào quang tất yếu làm nản lòng CSO nói "chưa được". Hãy xem hai hoặc ba thay đổi gần đây có rủi ro rõ ràng khác nhau và hỏi công sức bỏ ra có khớp với khả năng gây hại không, và có ai cảm thấy có thể làm chậm thay đổi nổi bật kia không. Một câu trả lời trung thực thừa nhận chỗ quy trình bị hiệu chỉnh sai theo cả hai hướng và xem sự tương xứng là một phán đoán rõ ràng, bảo vệ được chứ không phải phản xạ.

3. Khi có điều gì suýt sai với một trong các hệ thống số của chúng ta, điều gì thực sự đã xảy ra sau đó — và một bác sĩ tuyến đầu có nói rằng nêu nó ra là an toàn không? Câu hỏi này xem xét văn hóa an toàn và vòng học từ sự cố, nơi các cam kết đã tuyên bố gặp thực tế. An toàn lâm sàng phụ thuộc vào việc nghe về các suýt xảy ra, nhưng người ta chỉ báo cáo khi việc báo cáo cảm thấy an toàn và đáng giá, và khi họ thấy nó dẫn đến thay đổi chứ không phải đổ lỗi. Căng thẳng là dưới áp lực triển khai và danh tiếng, bản năng là giải thích đi một suýt xảy ra, đóng nó nhanh và đi tiếp — đặc biệt nếu làm lộ nó đầy đủ sẽ trì hoãn một lần ra mắt hoặc làm bẽ mặt một nhà bảo trợ cấp cao. Cách tiếp cận dựa trên hệ thống, có ý thức về đổ lỗi của PSIRF tồn tại chính vì việc tìm một cá nhân để quy lỗi sẽ kìm hãm việc báo cáo bạn cần và bỏ lỡ các nguyên nhân hệ thống thực sự. Hãy dựa cuộc thảo luận trên một suýt xảy ra hay sự cố cụ thể gần đây: nó có được ghi nhận không, có đến nhật ký mối nguy không, có một cuộc điều tra tương xứng không, và có điều gì thực sự thay đổi không? Một câu trả lời tốt thẳng thắn về việc báo cáo có cảm thấy an toàn không, phân biệt việc học thực sự với việc đóng giấy tờ, và gọi tên những hành vi cụ thể mà các lãnh đạo sẽ áp dụng để người tiếp theo phát hiện mối nguy sẽ lên tiếng.

4. Chúng ta đã xác định trung thực những sản phẩm nào của mình là thiết bị y tế được quản lý chưa — và ai chịu trách nhiệm về quyết định đó? Tình trạng quy định là một câu hỏi ngưỡng với hệ quả không tương xứng, và dễ bỏ ngỏ vì trả lời nó có thể bất tiện. Phần mềm chẩn đoán, dự đoán, theo dõi hoặc điều trị có thể tự nó là Phần mềm như một Thiết bị Y tế, kéo theo các nghĩa vụ của MHRA và tiêu chuẩn vòng đời IEC 62304 — tách biệt với, và bổ sung cho, quản lý rủi ro lâm sàng DCB0129/0160. Căng thẳng đi theo cả hai hướng: phân loại thấp khiến bạn đưa ra một thiết bị chưa đăng ký, một thất bại pháp lý và an toàn có thể bộc lộ thảm khốc ở quy mô lớn, trong khi phân loại quá mức một công cụ hành chính đơn giản đốt cháy năng lực đảm bảo khan hiếm mà bạn cần ở nơi khác. Nguy cơ là việc phân loại rơi giữa các vai trò — bác sĩ cho rằng kỹ sư đã quyết định, kỹ sư cho rằng nhóm quy định hoặc thương mại đã quyết định, và không ai thực sự viết ra lập luận. Hãy xem cụ thể những sản phẩm trong danh mục của bạn nằm gần ranh giới nhất — bất cứ thứ gì có quy tắc phân loại, điểm số rủi ro, thuật toán cảnh báo — và hỏi ai đã đưa ra xác định thiết bị, dựa trên cơ sở nào, và liệu nó có được ghi chép và xem lại khi các tính năng thay đổi không. Một câu trả lời trung thực gọi tên các sản phẩm ở ranh giới, chỉ ra một lập luận được ghi lại và bảo vệ được cho từng cái, và thẳng thắn ở nơi quyết định chưa bao giờ thực sự được đưa ra.

5. Chúng ta đang thiết kế để loại bỏ mối nguy, hay đang lặng lẽ tích lũy các cảnh báo mà bác sĩ của chúng ta đã học cách phớt lờ? Chủ đề xếp hạng các biện pháp kiểm soát theo độ mạnh — thiết kế loại bỏ mối nguy thắng một cảnh báo trên màn hình, và cảnh báo thắng một dòng trong sổ tay đào tạo — thế nhưng cảnh báo là con đường ít kháng cự nhất, vì thêm một cảnh báo thì nhanh và gây cảm giác có trách nhiệm trong khi thiết kế lại một quy trình thì chậm và gây tranh cãi. Theo thời gian, thiên lệch này tích tụ thành mệt mỏi vì cảnh báo: quá nhiều cảnh báo kích hoạt đến mức bác sĩ khớp mô thức bỏ qua tất cả, kể cả cái quan trọng, nên mỗi cảnh báo mới thực ra có thể làm giảm an toàn. Căng thẳng thực sự là mỗi cảnh báo không cần thiết đều có một người bảo trợ đã thêm nó với thiện chí sau một sự cố nào đó, khiến cảnh báo khó bị gỡ bỏ về mặt chính trị ngay cả khi chúng đang làm suy giảm hệ thống. Yếu tố con người là ngành ở đây — thiết kế sao cho hành động an toàn là hành động dễ, mặc định với một người dùng bận rộn, bị gián đoạn đang đọc một màn hình lúc 3 giờ sáng — và thử nghiệm khả năng sử dụng trong điều kiện thực tế là một hoạt động an toàn lâm sàng, không phải sự tế nhị của thiết kế. Hãy xem xét một hệ thống mà các nhóm của bạn thực sự dùng và hỏi một bác sĩ gặp bao nhiêu cảnh báo trong một nhiệm vụ điển hình, những cảnh báo nào thực sự thay đổi hành vi, và nơi một cơ chế bắt buộc hoặc một mặc định tốt hơn có thể đã thay thế hoàn toàn một cảnh báo. Một câu trả lời tốt cưỡng lại phản xạ thêm một cảnh báo nữa, xem tải cảnh báo là một mối nguy đo lường được tự nó, và sẵn lòng gỡ bỏ các cảnh báo không còn xứng đáng với vị trí của chúng.

6. Khi các hệ thống đang chạy, tích hợp và lộ trình lâm sàng của chúng ta trôi dạt theo thời gian, làm sao chúng ta biết hồ sơ an toàn của mình vẫn còn đúng? An toàn lâm sàng không kết thúc lúc vận hành; các hệ thống đang chạy tạo ra mối nguy mới, và thế giới quanh một hệ thống không ngừng chuyển động — một tích hợp thượng nguồn đổi dữ liệu của nó, một lộ trình lâm sàng được thiết kế lại, một nhà cung cấp phát hành bản cập nhật, một nhóm bệnh nhân mới bắt đầu dùng công cụ. Một hồ sơ an toàn được phê duyệt hai năm trước mô tả một hệ thống và bối cảnh có thể không còn tồn tại, nên câu hỏi là nhật ký mối nguy của bạn là một sổ đăng ký sống hay một tài liệu đã được ký một lần rồi để mục nát (xem Chủ đề 3.8 — Quản lý dịch vụ và vận hành trực tiếp). Căng thẳng là việc duy trì lập luận an toàn sau khi ra mắt cạnh tranh với triển khai mới cho cùng thời gian CSO và lâm sàng khan hiếm, và sự trôi dạt diễn ra dần dần và vô hình theo kiểu hiếm khi thu hút sự chú ý cho đến khi có thứ gì đó hỏng. Các góc độ cụ thể gồm kiểm soát thay đổi kích hoạt lại đánh giá mối nguy khi cấu hình hoặc tích hợp thay đổi, rà soát định kỳ các mối nguy hậu quả cao nhất, và giám sát có thể thực sự phát hiện một biện pháp kiểm soát suy giảm âm thầm. Hãy chọn một hệ thống đã chạy một năm trở lên và hỏi các mối nguy của nó được xem lại lần cuối khi nào, điều gì đã thay đổi bên dưới nó kể từ khi phê duyệt, và ai sẽ nhận ra nếu một biện pháp kiểm soát then chốt ngừng hoạt động. Một câu trả lời trung thực phân biệt các hệ thống có quản lý an toàn liên tục thực sự với những hệ thống đang trượt trên một hồ sơ an toàn cũ, và cam kết một nhịp rà soát tương xứng gắn với thay đổi thực thay vì chỉ lịch.

Trong thực tế: một ví dụ về y tế và chăm sóc#

Một hệ thống chăm sóc tích hợp (ICS) đang triển khai một công cụ chuyển tuyến điện tử dùng chung cho phép các bác sĩ gia đình chuyển bệnh nhân thẳng vào các dịch vụ cộng đồng, với một bộ quy tắc phân loại tích hợp định tuyến các ca khẩn cấp vào hàng đợi nhanh hơn. Một cách tiếp cận do triển khai dẫn dắt sẽ lấy hồ sơ an toàn DCB0129 của nhà cung cấp, vượt qua DTAC, và vận hành để kịp ngày đã hứa với hội đồng.

Thay vào đó, chương trình bổ nhiệm một bác sĩ gia đình đang hành nghề có đào tạo an toàn lâm sàng làm Cán bộ An toàn Lâm sàng và mở một hồ sơ quản lý rủi ro lâm sàng cùng nhật ký mối nguy ngay từ đầu giai đoạn thiết kế. Các hội thảo mối nguy sớm với bác sĩ gia đình, điều dưỡng cộng đồng và nhân viên hành chính làm lộ ra một số mối nguy mà hồ sơ cấp sản phẩm của nhà cung cấp chưa từng chạm đến — tất cả phát sinh từ việc triển khai tại chỗ. Mối nguy tệ nhất: các quy tắc phân loại được cấu hình theo định nghĩa dịch vụ của chính ICS, và một lỗi ánh xạ có thể định tuyến một ca chuyển tuyến ung thư da khẩn cấp vào hàng đợi da liễu thường quy với thời gian chờ nhiều tuần. Mối nguy đó được xếp hạng mức nghiêm trọng cao, khả năng xảy ra hợp lý.

Làm việc qua vòng lặp kiểm soát rủi ro, nhóm ưu tiên thiết kế hơn cảnh báo. Họ thêm một cơ chế bắt buộc để cờ lâm sàng khẩn cấp không thể bị logic định tuyến ghi đè một cách âm thầm, một báo cáo đối chiếu mà bác sĩ rà soát hằng ngày, và — thấp nhất trong thứ bậc — một ghi chú đào tạo. Rủi ro còn lại được xếp hạng lại và được đánh giá là chấp nhận được và ALARP; CSO ghi lại vì sao. Vì công cụ chỉ định tuyến và tự nó không chẩn đoán, nhóm đánh giá nó không đạt ngưỡng SaMD, ghi lại lập luận đó và lưu hồ sơ. Thử nghiệm yếu tố con người phát hiện một vấn đề riêng: một cảnh báo "chuyển tuyến trùng lặp" quá hăng kích hoạt thường đến mức các bác sĩ gia đình đã phớt lờ nó, nên nó được thiết kế lại chỉ kích hoạt với các trùng lặp thực sự.

Khi vận hành, hồ sơ an toàn DCB0160 được CSO phê duyệt, chứ không phải giám đốc chương trình. Ba tuần sau, một báo cáo LFPSE và một suýt xảy ra do một nhân viên lễ tân đánh dấu làm lộ một mối nguy mới — một ô văn bản tự do bị dùng để lén đưa thông tin khẩn cấp mà việc định tuyến không bao giờ thấy. Theo PSIRF, một cuộc rà soát tương xứng, dựa trên hệ thống được tiến hành, mối nguy đi vào nhật ký, một thay đổi thiết kế được lên lịch, và một biện pháp kiểm soát tạm thời được phổ biến ngay trong tuần. Hồ sơ an toàn là một lập luận sống, và hồ sơ cho thấy chính xác mỗi mối nguy đã được lập luận ra sao — điều mà một thanh tra viên, một điều tra viên pháp y, hay một CSO mới hai năm sau sẽ cần.

Góc nhìn theo khu vực#

Mọi người đều mang cùng nghĩa vụ kiểm soát rủi ro lâm sàng, nhưng bộ máy, động cơ và áp lực khác nhau rõ rệt giữa các tổ chức.

Công ty khởi nghiệp#

Một công ty khởi nghiệp y tế số thường gặp an toàn lâm sàng như một cổng mua sắm: một người mua NHS yêu cầu DTAC và hồ sơ an toàn DCB0129, và có một cuộc chạy đua. Nước đi chiến thắng là xây quản lý rủi ro lâm sàng vào từ sprint đầu tiên — một nhật ký mối nguy cạnh backlog, một Cán bộ An toàn Lâm sàng dễ tiếp cận (thường được thuê ngoài chứ không phải nhân viên, nhưng thực sự có năng lực và được trao quyền) — vì lắp hồ sơ an toàn hồi tố lên một sản phẩm đã hoàn thiện thì chậm, tốn kém và thiếu thuyết phục. Các nhà sáng lập cũng phải đối diện câu hỏi SaMD một cách trung thực và sớm, vì phát hiện giữa chừng khi mở rộng rằng sản phẩm là một thiết bị y tế chưa đăng ký là một rủi ro pháp lý và an toàn mang tính sống còn. Làm tốt, các hiện vật an toàn lâm sàng trưởng thành trở thành một tài sản thương mại rút ngắn chu kỳ bán hàng cho NHS.

Doanh nghiệp nhỏ#

Một nhà cung cấp nhỏ đã thành lập — một phòng khám bác sĩ gia đình, một hiệu thuốc cộng đồng, một nhà dưỡng lão, một cơ sở chăm sóc tại nhà, một phòng khám đơn lẻ, hoặc một nhà cung cấp công nghệ y tế nhỏ đã qua giai đoạn chưa có doanh thu — mang cùng nghĩa vụ DCB0160 như một bệnh viện lớn khi triển khai và cấu hình các hệ thống số, nhưng không có chút năng lực dư nào để thực hiện nó. Hiếm khi có một CSO hay nhà phân tích an toàn chuyên trách trong biên chế, nên con đường thực tế là thuê một bác sĩ hành nghề có năng lực theo hợp đồng và giữ một nhật ký mối nguy gọn nhưng thật thay vì giả vờ nghĩa vụ không áp dụng. Các mối nguy địa phương sắc nhất thường là các mối nguy về cấu hình và quy trình — cách hồ sơ dùng chung được thiết lập, cách các cờ khẩn cấp được xử lý, cách một cách xoay xở của một nhân viên hành chính bán thời gian trở thành rủi ro định tuyến — chính xác là những mối nguy mà hồ sơ DCB0129 của nhà cung cấp không bao giờ bao phủ. Sự tương xứng là bạn của nhà cung cấp nhỏ ở đây: tập trung ít thời gian đảm bảo bạn có vào các mối nguy hậu quả cao nhất, dùng DTAC và hồ sơ an toàn của nhà cung cấp làm mức sàn khi chọn sản phẩm, và dựa vào các nguồn lực dùng chung như hỗ trợ an toàn lâm sàng của ICS thay vì cố tự xây cả bộ máy.

Doanh nghiệp lớn#

Một bệnh viện NHS hoặc ICS mang trách nhiệm giải trình kép: nó triển khai hệ thống của người khác theo DCB0160 và thường tự xây hoặc cấu hình sâu hệ thống của riêng mình theo DCB0129. Kiểu thất bại đặc trưng mang tính thể chế — một chương trình hồ sơ bệnh án điện tử hàng đầu có ngày vận hành mang sức nặng chính trị, nên sự thận trọng của CSO bị lặng lẽ xem là chướng ngại. Cách khắc phục mang tính cấu trúc: trao cho CSO sự độc lập và quyền phủ quyết thực sự, giữ một nhật ký mối nguy sống trên toàn hệ thống thay vì một kệ tài liệu ngày ra mắt, và nối việc học từ LFPSE và PSIRF trở lại quản lý rủi ro lâm sàng như một quy trình thường trực. Ở quy mô doanh nghiệp, các mối nguy lớn nhất là mối nguy về tích hợp và cấu hình, mà không sự đảm bảo nào của nhà cung cấp bao phủ, nên quyền sở hữu tại chỗ là không thể thương lượng.

Chính phủ#

Một cơ quan quốc gia — NHS England, MHRA, DHSC, NICE — đặt ra các tiêu chuẩn mà người khác phải đáp ứng, nên phương thức làm việc của nó định hình cả hệ thống: DCB0129/0160, DTAC và quy định SaMD là các công cụ của an toàn ở quy mô dân số. Các quyết định ở đây thu hút sự soi xét của cơ quan quản lý, Nghị viện và công chúng, và một hệ thống bắt buộc toàn quốc mang một mối nguy tiềm ẩn phân tán tác hại đó lên hàng triệu người trước khi ai thấy mô thức. Các nghĩa vụ là sự tương xứng được làm rõ trong các tiêu chuẩn công bố, minh bạch về rủi ro còn lại, và giữ khung quy định luôn cập nhật khi công nghệ — đặc biệt là AI — vượt xa nó (xem Chủ đề 8.4 — Quản trị AI và công nghệ mới nổi). Rủi ro đặc thù ở quy mô này mang tính hệ thống: bắt buộc một công nghệ trên toàn hệ thống dựa trên bằng chứng an toàn mỏng sẽ củng cố một mối nguy ở khắp nơi cùng lúc.

Các kiểu thất bại thường gặp#

• An toàn gắn thêm ở cuối. Lập hồ sơ an toàn trong tuần trước khi vận hành để thỏa mãn một cổng. Giải pháp: mở nhật ký mối nguy từ giai đoạn khám phá; thiết kế loại bỏ những mối nguy lớn nhất.
• Nhầm sự đảm bảo của nhà cung cấp với an toàn tại chỗ. Xem hồ sơ DCB0129 và một lần vượt qua DTAC là bao phủ việc triển khai của bạn. Giải pháp: sở hữu đánh giá DCB0160 và nhật ký mối nguy địa phương của bạn.
• CSO như con dấu cao su. Một Cán bộ An toàn Lâm sàng không có thời gian, sự độc lập hay thẩm quyền để nói "chưa được". Giải pháp: bảo vệ vai trò và làm cho sự phê duyệt là một cổng thực sự.
• Nhật ký mối nguy chết. Một tài liệu viết một lần và không bao giờ xem lại sau khi ra mắt. Giải pháp: giữ nó sống; đưa sự cố và thay đổi vào nó.
• Quá tải cảnh báo. Quá nhiều cảnh báo khiến bác sĩ phớt lờ tất cả, kể cả những cái thiết yếu. Giải pháp: thiết kế theo yếu tố con người; mỗi cảnh báo phải xứng đáng với vị trí của nó.
• Văn hóa đổ lỗi. Trừng phạt cá nhân vì những suýt xảy ra, khiến việc báo cáo cạn kiệt. Giải pháp: một văn hóa công bằng, dựa trên hệ thống, phù hợp với PSIRF.
• Bỏ lỡ ngưỡng quy định. Đưa ra SaMD mà không nhận ra nó là thiết bị được quản lý. Giải pháp: đánh giá và ghi lại tình trạng thiết bị y tế sớm.

Mô hình trưởng thành#

Danh sách kiểm tra#

• Một Cán bộ An toàn Lâm sàng có năng lực, đang hành nghề, được đào tạo được nêu tên cho mỗi hệ thống, với thời gian và thẩm quyền để nói "chưa được".
• Một hồ sơ quản lý rủi ro lâm sàng, nhật ký mối nguy sống và hồ sơ an toàn lâm sàng tồn tại cho mỗi hệ thống trong phạm vi.
• Việc nhận diện mối nguy bắt đầu từ giai đoạn khám phá, với bác sĩ tuyến đầu có mặt trong phòng.
• Tổ chức triển khai đã thực hiện đánh giá DCB0160 của riêng mình, không chỉ chấp nhận hồ sơ DCB0129 của nhà cung cấp.
• Các biện pháp kiểm soát rủi ro ưu tiên loại bỏ bằng thiết kế hơn cảnh báo hơn đào tạo, với rủi ro còn lại được giảm xuống ALARP và được biện minh.
• Tình trạng thiết bị y tế / SaMD đã được đánh giá và ghi chép, và các nghĩa vụ MHRA / IEC 62304 được áp dụng khi liên quan.
• DTAC đã được hoàn thành như một mức sàn, kèm quản lý rủi ro lâm sàng tại chỗ.
• Thử nghiệm yếu tố con người và khả năng sử dụng trong điều kiện thực tế đã được thực hiện; tải cảnh báo được kiểm soát.
• Các sự cố đang xảy ra (LFPSE) và việc học từ PSIRF phản hồi vào nhật ký mối nguy như một quy trình thường trực.
• Báo cáo suýt xảy ra và thách thức một lần ra mắt vì lý do an toàn là an toàn và được kỳ vọng một cách rõ ràng.

Nguồn chính#

• NHS England — DCB0129: Clinical Risk Management: its Application in the Manufacture of Health IT Systems.
• NHS England — DCB0160: Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems.
• NHS England — đào tạo Cán bộ An toàn Lâm sàng và hướng dẫn quản lý rủi ro lâm sàng.
• NHS England — Tiêu chí Đánh giá Công nghệ Số (DTAC).
• MHRA — hướng dẫn Software and Artificial Intelligence (AI) as a Medical Device.
• IEC — IEC 62304: Medical device software — software life cycle processes.
• ISO — ISO 14971: Application of risk management to medical devices.
• NHS England — dịch vụ Learn from Patient Safety Events (LFPSE).
• NHS England — Patient Safety Incident Response Framework (PSIRF).
• Tổ chức Y tế Thế giới — Global Patient Safety Action Plan 2021–2030.

Tài liệu tham khảo#

1. Patient safety — Wikipedia — https://en.wikipedia.org/wiki/Patient_safety
2. Risk management — Wikipedia — https://en.wikipedia.org/wiki/Risk_management
3. Hazard analysis — Wikipedia — https://en.wikipedia.org/wiki/Hazard_analysis
4. Safety case — Wikipedia — https://en.wikipedia.org/wiki/Safety_case
5. Medical device — Wikipedia — https://en.wikipedia.org/wiki/Medical_device
6. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
7. Ergonomics (human factors) — Wikipedia — https://en.wikipedia.org/wiki/Ergonomics
8. Safety culture — Wikipedia — https://en.wikipedia.org/wiki/Safety_culture
9. As low as reasonably practicable (ALARP) — Wikipedia — https://en.wikipedia.org/wiki/As_low_as_reasonably_practicable
10. Root-cause analysis — Wikipedia — https://en.wikipedia.org/wiki/Root-cause_analysis
11. IEC 62304 — Wikipedia — https://en.wikipedia.org/wiki/IEC_62304
12. DCB0129: Clinical Risk Management in the Manufacture of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
13. DCB0160: Clinical Risk Management in the Deployment and Use of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
14. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
15. Software and Artificial Intelligence (AI) as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
16. IEC 62304: Medical device software — software life cycle processes — International Electrotechnical Commission — https://www.iso.org/standard/38421.html
17. ISO 14971: Application of risk management to medical devices — International Organization for Standardization — https://www.iso.org/standard/72704.html
18. Learn from Patient Safety Events (LFPSE) service — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/learning-from-patient-safety-events/
19. Patient Safety Incident Response Framework (PSIRF) — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/incident-response-framework/
20. Global Patient Safety Action Plan 2021–2030 — World Health Organization — https://www.who.int/teams/integrated-health-services/patient-safety/policy/global-patient-safety-action-plan