Thực chiến y tế: đặt lịch khám, hồ sơ EMR, chuẩn HL7/FHIR & quyền riêng tư PHI

1. Bối cảnh doanh nghiệp & phạm vi

Chuỗi phòng khám đa khoa giả định MedCare vận hành 24 cơ sở, phục vụ trung bình 7.500 lượt khám mỗi ngày, với hệ thống Đặt lịch & Hồ sơ điện tử (Appointment & EMR Platform) là xương sống nghiệp vụ kết nối bệnh nhân, bác sĩ, và dữ liệu lâm sàng. Hệ thống phải tuân thủ chuẩn trao đổi dữ liệu y tế HL7 v2 (giao tiếp với hệ thống xét nghiệm cũ) và FHIR R4 (giao tiếp với ứng dụng di động mới, cổng bảo hiểm y tế), đồng thời tuân thủ nguyên tắc bảo vệ Thông tin sức khỏe được bảo vệ (PHI - Protected Health Information) tương đương chuẩn HIPAA dù hoạt động tại Việt Nam, theo cam kết với đối tác bảo hiểm quốc tế.

Phạm vi kiểm thử bài này gồm: (1) module đặt lịch khám với ràng buộc không double-booking (một bác sĩ không thể có 2 lịch trùng giờ), (2) module truy cập EMR theo phân quyền RBAC dựa trên vai trò và nguyên tắc need-to-know, và (3) tầng audit log ghi vết mọi truy cập PHI phục vụ thanh tra tuân thủ. Ràng buộc nghiêm ngặt: dữ liệu bệnh nhân của các khoa nhạy cảm (tâm thần, HIV) phải cô lập thêm một lớp phân quyền bổ sung ngoài RBAC thông thường, và tính năng 'break-glass' (truy cập khẩn cấp vượt quyền) phải luôn có lý do bắt buộc kèm cảnh báo tức thời.

Phạm vi tự động hoá

• API đặt lịch khám & kiểm tra double-booking
• API truy cập EMR theo RBAC + break-glass
• Kiểm tra transform HL7 v2 ↔ FHIR R4
• Audit log cho mọi thao tác đọc/ghi PHI
• Luồng E2E: bệnh nhân đặt lịch → bác sĩ xem hồ sơ → ghi chẩn đoán

2. Kiến trúc & luồng nghiệp vụ

Kiến trúc gồm Scheduling Service quản lý slot bác sĩ với khoá pessimistic ở tầng database để chặn double-booking khi nhiều bệnh nhân cùng chọn 1 khung giờ, FHIR Gateway làm tầng chuyển đổi giữa hệ thống xét nghiệm cũ (HL7 v2 qua MLLP) và các client mới (FHIR R4 qua REST), và EMR Service áp RBAC theo policy engine riêng (không hard-code trong controller) để dễ audit và thay đổi quy tắc phân quyền. Giao tiếp giữa Scheduling và EMR là đồng bộ vì bác sĩ cần thấy lịch sử khám ngay khi mở ca khám, còn đồng bộ dữ liệu xét nghiệm từ lab về EMR chạy bất đồng bộ qua hàng đợi với retry có backoff.

Điểm khó khi kiểm thử

• Double-booking chỉ lộ ra khi test đồng thời thật (concurrency), test tuần tự không bắt được
• Transform HL7↔FHIR có thể mất/méo trường dữ liệu khi mapping code hệ thống khác biệt
• Break-glass cần test cả trường hợp lạm dụng (nhiều lần truy cập bất thường) để cảnh báo sớm

3. Mô hình dữ liệu & bất biến nghiệp vụ (oracle)

Thực thể trung tâm gồm Appointment (gắn duy nhất 1 DoctorSlot và 1 Patient), EMRRecord (gắn 1 Patient, nhiều Encounter theo thời gian), và AccessAuditLog ghi mọi lượt đọc/ghi PHI kèm actorId, resourceId, action, timestamp, và lý do nếu là break-glass. Bất biến quan trọng nhất là DoctorSlot chỉ được gán cho đúng 1 Appointment tại một thời điểm — vi phạm bất biến này nghĩa là double-booking, gây hậu quả vận hành nghiêm trọng (bác sĩ phải từ chối khám 1 trong 2 bệnh nhân đã xác nhận lịch).

Bất biến nghiệp vụ (oracle) bắt buộc

• 1 DoctorSlot ⇔ tối đa 1 Appointment active tại 1 thời điểm — không double-booking dưới mọi mức đồng thời
• Mọi truy cập PHI (đọc/ghi) đều phải có bản ghi AccessAuditLog tương ứng, không thể sửa/xoá (append-only/WORM)
• RBAC theo need-to-know: vai trò không liên quan trực tiếp điều trị bệnh nhân (lễ tân, IT) không được xem nội dung lâm sàng
• Dữ liệu khoa nhạy cảm (tâm thần, HIV) có policy phân quyền bổ sung, mặc định ẩn khỏi bác sĩ ngoài khoa trừ khi break-glass
• Break-glass luôn yêu cầu lý do bắt buộc (không rỗng) và kích hoạt cảnh báo tức thời cho DPO (Data Protection Officer)