1. Bối cảnh doanh nghiệp & phạm vi
Hệ thống kê đơn điện tử (e-Prescription) của chuỗi phòng khám MedCare xử lý trung bình 9.200 đơn thuốc mỗi ngày trên 24 cơ sở, phục vụ cả bệnh nhân nhi khoa, người lớn và người cao tuổi có chức năng thận suy giảm — mỗi nhóm có ngưỡng liều an toàn khác nhau đáng kể. Drug Safety Module là lớp bảo vệ cuối cùng trước khi đơn thuốc được gửi tới nhà thuốc, chịu trách nhiệm chặn các tổ hợp thuốc chống chỉ định tuyệt đối và cảnh báo liều vượt ngưỡng an toàn theo cân nặng/tuổi/chức năng thận — một lỗi bỏ sót ở đây có thể trực tiếp đe doạ tính mạng bệnh nhân, khác hẳn mức độ rủi ro tài chính của các domain khác.
Phạm vi kiểm thử bài này gồm: (1) engine kiểm tra tương tác thuốc (drug-drug interaction) dựa trên cơ sở dữ liệu tham chiếu chuẩn cập nhật định kỳ, (2) engine tính liều an toàn theo cân nặng/tuổi/chức năng thận (dosage calculation with clinical grounding), và (3) cơ chế cảnh báo phân tầng theo mức độ nghiêm trọng (chặn cứng / cảnh báo cần xác nhận / thông tin tham khảo). Ràng buộc nghiêm ngặt: mọi cảnh báo an toàn hiển thị cho bác sĩ phải có căn cứ (grounding) từ nguồn dữ liệu y khoa đã kiểm chứng, không được để engine tự suy luận hay AI tự sinh nội dung cảnh báo không kiểm chứng — đây là yêu cầu sống còn khi tích hợp AI vào luồng lâm sàng.
Phạm vi tự động hoá
- API kiểm tra tương tác thuốc theo cặp/nhóm thuốc
- API tính liều an toàn theo cân nặng/tuổi/eGFR
- Cơ chế cảnh báo phân tầng theo mức độ nghiêm trọng
- Luồng E2E: bác sĩ kê đơn có tương tác → hệ thống chặn/cảnh báo đúng
- Kiểm tra grounding của nội dung cảnh báo AI-assisted
2. Kiến trúc & luồng nghiệp vụ
Kiến trúc gồm Prescription Service nhận đơn thuốc từ bác sĩ, Drug Interaction Engine tra cứu cơ sở dữ liệu tương tác thuốc chuẩn (cập nhật hàng tháng từ nhà cung cấp dữ liệu y khoa bên thứ ba) để phát hiện cặp/nhóm thuốc chống chỉ định, Dosage Engine tính liều tối đa/tối thiểu an toàn dựa trên hồ sơ bệnh nhân (cân nặng, tuổi, eGFR mới nhất), và Alert Service tổng hợp kết quả từ 2 engine trên thành cảnh báo phân tầng hiển thị cho bác sĩ. Toàn bộ luồng phải chạy đồng bộ với timeout dưới 800ms vì bác sĩ chờ ngay trên màn hình kê đơn, khác với các luồng hậu kiểm có thể chạy bất đồng bộ.
Điểm khó khi kiểm thử
- Cơ sở dữ liệu tương tác thuốc cập nhật định kỳ — test phải chạy trên phiên bản dữ liệu hiện hành, không hard-code danh sách cặp thuốc
- Liều an toàn phụ thuộc nhiều biến (cân nặng, tuổi, eGFR) cùng lúc — cần combinatorial testing có kiểm soát
- Cảnh báo AI-assisted phải luôn trace được về nguồn dữ liệu gốc (grounding), không được để AI tự diễn giải mức độ nghiêm trọng
3. Mô hình dữ liệu & bất biến nghiệp vụ (oracle)
Thực thể trung tâm gồm Prescription (gắn PatientProfile tại thời điểm kê đơn — snapshot cân nặng/tuổi/eGFR, không tham chiếu động vì hồ sơ có thể thay đổi sau), InteractionCheckResult (kết quả tra cứu từng cặp thuốc kèm mức độ nghiêm trọng), và DosageCheckResult (liều đề xuất vs khoảng an toàn tính toán). Bất biến quan trọng nhất: mọi cặp thuốc ở mức 'chống chỉ định tuyệt đối' (contraindicated) phải luôn dẫn tới BLOCK cứng, không có đường vòng nào (kể cả override của bác sĩ) được phép bỏ qua kiểm tra này trong hệ thống.
Bất biến nghiệp vụ (oracle) bắt buộc
- Cặp thuốc mức 'chống chỉ định tuyệt đối' luôn BLOCK cứng, không override được bởi bất kỳ vai trò nào
- Liều kê phải nằm trong [liều tối thiểu, liều tối đa] tính theo cân nặng thực tại thời điểm kê đơn — vượt trần trên luôn bị chặn
- Snapshot dữ liệu bệnh nhân dùng để tính liều phải cố định tại thời điểm kê đơn, không tính lại theo dữ liệu mới nếu đơn đã phát hành
- Mọi cảnh báo hiển thị cho bác sĩ phải có nguồn tham chiếu cụ thể (drugId, ruleId, tài liệu y khoa) — không hiển thị cảnh báo không có nguồn gốc
- Cảnh báo mức 'cần xác nhận' yêu cầu bác sĩ tick xác nhận rõ ràng kèm ghi log lý do trước khi đơn được gửi đi
💬 Bình luận (0)
Chưa có bình luận nào. Hãy là người đầu tiên!