Hướng dẫn điều trị đưa vào hệ thống: từ văn bản tới quy tắc chạy được

Đưa một hướng dẫn điều trị vào hệ thống nghe như công việc kỹ thuật. Thực tế nó là công việc lâm sàng, và nó phơi bày mọi chỗ mơ hồ của chính hướng dẫn.

Khoảng cách giữa văn bản và quy tắc

Hướng dẫn điều trị được viết cho người đọc có phán đoán lâm sàng. Vì vậy chúng chứa nhiều diễn đạt mềm:

• "Cân nhắc..."
• "Ở người bệnh phù hợp..."
• "Nếu không có chống chỉ định..."
• "Nên đánh giá..."
• "Trong trường hợp nguy cơ cao..."

Những diễn đạt này cố ý để mở, vì tác giả biết rằng thực hành có quá nhiều biến thể để quy định cứng.

Nhưng máy cần một ngưỡng cụ thể. Quá trình chuyển đổi vì thế buộc phải trả lời những câu mà bản gốc tránh trả lời.

Các câu phải quyết định

Với mỗi quy tắc, cần làm rõ:

Định nghĩa quần thể áp dụng

"Người bệnh có bệnh X" — định nghĩa bằng mã chẩn đoán nào? Chẩn đoán chính hay cả chẩn đoán kèm? Chẩn đoán trong đợt này hay cả tiền sử?

Định nghĩa biến số

"Chức năng thận suy giảm" — theo chỉ số nào, công thức nào, ngưỡng nào? Lấy giá trị gần nhất hay trung bình? Hiệu lực trong bao lâu?

Định nghĩa chống chỉ định

"Nếu không có chống chỉ định" — hệ thống biết được những chống chỉ định nào từ dữ liệu có cấu trúc? Những cái không biết thì xử lý thế nào?

Thời điểm kích hoạt

Quy tắc chạy khi nào — lúc nhập viện, lúc kê đơn, hằng ngày, hay khi có kết quả xét nghiệm mới?

Xử lý dữ liệu thiếu

Nếu biến số cần thiết không có, quy tắc không chạy, chạy với giả định, hay báo thiếu dữ liệu?

Ai quyết định

Đây phải là quyết định lâm sàng, không phải quyết định kỹ thuật.

Mô hình nên có:

• Một hội đồng chuyên môn của chính cơ sở.
• Có đại diện các khoa liên quan và dược lâm sàng.
• Ghi biên bản từng quyết định kèm lý do.
• Có chu kỳ rà soát định kỳ.

Việc để người lập trình hoặc nhà cung cấp tự quyết các điểm mơ hồ là nguồn gốc của nhiều quy tắc không phù hợp với thực hành tại chỗ.

Quản trị phiên bản

Hướng dẫn thay đổi. Quy tắc cũng phải thay đổi theo. Và cần biết được một quyết định trong quá khứ dựa trên phiên bản nào.

Cần lưu:

• Phiên bản hướng dẫn nguồn và ngày ban hành.
• Nội dung quy tắc đã cấu hình.
• Ngày có hiệu lực và ngày hết hiệu lực.
• Ai phê duyệt.
• Lý do của các quyết định về điểm mơ hồ.

Không có thông tin này thì việc rà soát hồi cứu — "vì sao hệ thống lại gợi ý như vậy vào thời điểm đó" — gần như không làm được.

Khi có hướng dẫn mới

Quy trình nên có:

1. Rà soát xem những quy tắc nào bị ảnh hưởng.
2. Đánh giá tác động — bao nhiêu người bệnh đang điều trị theo phác đồ cũ, việc chuyển đổi có ảnh hưởng gì?
3. Quyết định áp dụng cho ca mới hay cả ca đang điều trị.
4. Cập nhật có kiểm soát, có thử nghiệm trước khi áp dụng toàn bộ.
5. Thông báo cho người dùng về nội dung thay đổi.
6. Theo dõi tác động sau khi áp dụng.

Bước năm hay bị bỏ qua. Một quy tắc thay đổi lặng lẽ khiến người dùng thấy hệ thống hành xử khác đi mà không hiểu vì sao — và điều đó làm giảm lòng tin vào toàn bộ hệ thống.

Vấn đề hướng dẫn mâu thuẫn nhau

Một người bệnh có nhiều bệnh kèm có thể rơi vào phạm vi của nhiều hướng dẫn, và các hướng dẫn này không phải lúc nào cũng tương thích.

Hệ thống cần có cách xử lý:

• Hiển thị cả hai và để người dùng cân nhắc.
• Có thứ tự ưu tiên được định trước.
• Hoặc tắt quy tắc trong các tình huống đã biết là mâu thuẫn.

Cách xử lý sai nhất là để cả hai cùng cảnh báo mà không nói rõ chúng mâu thuẫn — người dùng sẽ bỏ qua cả hai.

Lợi ích phụ ít ai nghĩ tới

Quá trình số hoá hướng dẫn thường phát hiện ra những điều hữu ích ngoài mục tiêu ban đầu:

• Các chỗ mơ hồ trong chính hướng dẫn mà lâu nay mỗi người hiểu một cách.
• Sự khác biệt trong thực hành giữa các khoa mà trước đó không ai biết.
• Các dữ liệu cần thiết nhưng chưa được thu thập có cấu trúc.
• Các định nghĩa không nhất quán trong hệ thống mã hoá.

Nhiều cơ sở nhận thấy rằng bản thân việc thảo luận để thống nhất các điểm này đã tạo ra giá trị — trước cả khi quy tắc được bật lên.

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