Bộ Hướng dẫn Triển khai Core FHIR cho Việt Nam
0.3.0 - STU1 Draft
Bộ Hướng dẫn Triển khai Core FHIR cho Việt Nam - Local Development build (v0.3.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Trang này giải thích cách hiểu và cách triển khai Must Support trong VN Core FHIR IG theo hướng thực dụng cho HIS, EMR, cổng liên thông và hệ thống nhận dữ liệu.
Must Support.Một điểm yếu của cách làm cũ là dễ coi profile là đủ. VN Core hiện tại cố ý đi xa hơn: Must Support chỉ có giá trị khi đi cùng hướng dẫn theo vai trò triển khai, yêu cầu tuân thủ, ví dụ và bộ kiểm thử.
Must Support như cách vá mọi yêu cầu nghiệp vụ vào cardinality.CapabilityStatement theo vai trò triển khai.Khi một phần tử được đánh dấu Must Support:
Must Support có thể đi cùng 0..1, 0..*, 1..1 hoặc 1..*.
| Cardinality | Must Support | Cách hiểu trong triển khai |
|---|---|---|
1..1 + MS |
Bắt buộc và phải hỗ trợ đầy đủ | Không được bỏ trống; nếu quy định cho phép thiếu có giải trình thì phải dùng cơ chế thay thế hợp lệ |
0..1 + MS |
Không bắt buộc phải luôn có | Nếu có dữ liệu trong nguồn thì phải đưa ra và bên nhận phải xử lý được |
0..* + MS |
Không bắt buộc có ít nhất một giá trị | Nếu nguồn có nhiều giá trị thì phải hỗ trợ lặp đúng cấu trúc |
VN Core áp dụng Must Support theo ba lớp:
Ví dụ:
Patient.identifier[CCCD] là Must Support vì là trục định danh hiện hành.Encounter.reasonCode là Must Support vì phản ánh lý do đến khám.Coverage.relationship là Must Support vì quyết định ngữ nghĩa người thụ hưởng và người đóng/đại diện.| Vai trò triển khai | Kỳ vọng tối thiểu |
|---|---|
| Sender | SHALL gửi phần tử Must Support khi dữ liệu có thật và thuộc phạm vi giao dịch; SHALL NOT tạo dữ liệu giả để “đủ profile”. |
| Receiver | SHALL tiếp nhận, lưu giữ hoặc chuyển tiếp được dữ liệu Must Support hợp lệ mà không làm mất ngữ nghĩa. |
| Server | SHOULD hỗ trợ các cơ chế thiếu dữ liệu hợp lệ như data-absent-reason khi profile hoặc hướng dẫn của VN Core cho phép. |
| Client | SHALL NOT coi mọi trường hợp thiếu dữ liệu là lỗi nếu profile hoặc hướng dẫn đã cho phép cách giải trình hợp lệ. |
Đối với phần tử Must Support, hệ thống nhận cần tối thiểu:
"N/A", "Không rõ", "000000000000" vào trường chuẩn hóa.data-absent-reason khi phần tử được phép thiếu hoặc profile đã quy định rõ cách diễn đạt ngoại lệ.| Tình huống | Cách biểu diễn khuyến nghị | Ghi chú |
|---|---|---|
| Có dữ liệu trong HIS | Gửi giá trị thật | Đây luôn là ưu tiên số 1 |
| Chưa biết nhưng có khả năng sẽ có sau | data-absent-reason = temp-unknown |
Ví dụ đang chờ kết quả hoặc đang xác minh |
| Đã hỏi nhưng không biết | data-absent-reason = asked-unknown |
Ví dụ không nhớ chính xác tiền sử |
| Không áp dụng | data-absent-reason = not-applicable |
Ví dụ dữ liệu không có ý nghĩa trong ca này |
| Bị che do bảo mật/quyền riêng tư | data-absent-reason = masked |
Chỉ dùng khi thật sự có chính sách che giấu |
| Hệ thống nguồn chưa hỗ trợ | data-absent-reason = unsupported |
Cần coi là trạng thái chuyển tiếp, không nên kéo dài |
| Không thực hiện xét nghiệm/thủ thuật | data-absent-reason = not-performed |
Chủ yếu dùng cho kết quả/quan sát |
| Có định danh thay thế hợp lệ | Giữ slice định danh chính theo quy tắc profile và gửi thêm định danh thay thế đúng system |
Không dùng forceMajeureReason chỉ vì bệnh nhân dùng hộ chiếu, GKS hoặc định danh hợp lệ khác |
| Thiếu CCCD trong ca bất khả kháng | data-absent-reason + lý do bất khả kháng của VN Core |
Xem thêm trang kiểm tra hợp lệ và profile Patient |
| Resource / phần tử | Cách xử lý |
|---|---|
Patient.identifier[CCCD] |
Nếu chưa có CCCD do ca bất khả kháng, dùng data-absent-reason trên value và kèm lý do bất khả kháng hợp lệ |
Patient.birthDate |
Nếu chưa xác định được ngày sinh, dùng data-absent-reason; không ghi ngày giả |
Observation.value[x] |
Nếu không có giá trị vì không thực hiện hoặc lỗi quy trình, dùng dataAbsentReason của Observation |
Coverage.relationship |
Không được bỏ khi đã có subscriber khác beneficiary |
Claim.item.productOrService |
Nếu tạm thời chưa có mã chuẩn trong ví dụ/test, chỉ dùng data-absent-reason trong phạm vi bộ dữ liệu kiểm thử có chủ đích, không dùng cho dữ liệu triển khai thật |
identifier.system rõ ràng.system, không trộn vào một giá trị duy nhất.Ví dụ trong VN Core:
CCCD là định danh cá nhân hiện hành.GPHN là định danh hành nghề hiện hành.CCHN chỉ giữ để liên thông dữ liệu lịch sử.required, phải dùng mã nằm trong ValueSet.extensible, ưu tiên mã trong ValueSet; chỉ dùng mã ngoài khi thật sự không có tương đương phù hợp.text của CodeableConcept;data-absent-reason nếu đúng bản chất là thiếu dữ liệu, không phải thiếu mapping.Với phần tử Must Support kiểu Reference:
Nguồn HIS thường có
Ánh xạ khuyến nghị
| Dữ liệu HIS | Resource / phần tử |
|---|---|
| Mã bệnh nhân nội bộ | Patient.identifier[MRN] |
| CCCD | Patient.identifier[CCCD] |
| Mã số BHXH | Patient.identifier[BHXH] |
| Số thẻ BHYT | Patient.identifier[BHYT] hoặc Coverage.identifier[BHYT] theo ngữ cảnh |
| Họ tên cha/mẹ/người giám hộ | RelatedPerson.name hoặc Patient.contact.name |
| Quan hệ với bệnh nhân | RelatedPerson.relationship / Patient.contact.relationship |
Quy tắc vận hành
GKS, BHXH, BHYT, RelatedPerson và lý do thiếu CCCD khi cần.Patient.name hoặc Patient.identifier.Nguồn HIS thường có
Ánh xạ khuyến nghị
| Dữ liệu HIS | Resource / phần tử |
|---|---|
| Số lượt khám | Encounter.identifier hoặc phần mở rộng/ngữ nghĩa riêng của payer layer |
| Thời gian vào/ra | Encounter.period |
| Lý do đến khám | Encounter.reasonCode |
| Khoa/phòng tiếp nhận | Encounter.location hoặc serviceProvider + Location |
Quy tắc vận hành
Khi dùng Composition
Khi dùng DocumentReference
Ánh xạ khuyến nghị
| Nguồn tài liệu | Resource |
|---|---|
| Bệnh án điện tử có cấu trúc | Composition |
| Bản PDF giấy ra viện / bản scan | DocumentReference |
| Tập tài liệu và chữ ký | DocumentReference + Provenance |
Nguồn HIS/BHYT thường có
Ánh xạ khuyến nghị
| Dữ liệu | Resource / phần tử |
|---|---|
| Thẻ BHYT | Coverage.identifier[BHYT] |
| Người thụ hưởng | Coverage.beneficiary |
| Người đóng/người đại diện | Coverage.subscriber |
| Quan hệ | Coverage.relationship |
| Nơi đăng ký KCB ban đầu | phần mở rộng tương ứng của VN Core |
Quy tắc vận hành
subscriber khác beneficiary, không được để relationship = self.Nguyên tắc cốt lõi
MA_LK và các bảng XML là ràng buộc của lớp liên thông hồ sơ BHYT, không phải lý do để làm méo mô hình resource lõi.Chuỗi tối thiểu
| Nghiệp vụ | Hướng mô hình hóa |
|---|---|
| Đợt khám chữa bệnh | Encounter + Coverage + Claim |
| Chẩn đoán | Condition / Claim.diagnosis |
| Dịch vụ / thuốc / vật tư | Claim.item và các resource chuyên ngành liên quan |
| Tài liệu hỗ trợ | DocumentReference, Composition, DiagnosticReport |
| Xuất XML/gửi cổng | lớp liên thông hồ sơ BHYT (BHYT Submission) |
data-absent-reason.This page explains how VN Core interprets Must Support in practice. It clarifies that Must Support does not mean mandatory cardinality, defines how senders and receivers should behave, provides a pragmatic absent-data matrix using data-absent-reason, and includes a short HIS-to-FHIR cookbook for Patient, Encounter, documents, Coverage, and Claim workflows. The intent is to reduce ambiguity for early implementers while keeping VN Core aligned with Vietnamese legal and operational requirements.