Hướng dẫn triển khai FHIR cốt lõi Việt Nam — VN Core FHIR Implementation Guide - Draft for Community Review (v0.10.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Playbook Cấp cứu

Playbook Cấp cứu — KCB cấp cứu (Emergency)

Hướng dẫn tích hợp cho một lượt cấp cứu: tiếp nhận → triage → xử trí → kết cục (ra viện / nhập viện / chuyển tuyến / tử vong). Trang minh hoạ phương án gửi bằng Bundle.type = transaction khi CapabilityStatement áp dụng cho máy chủ công bố hỗ trợ transaction.

Cùng bộ playbook: Ngoại trú · Nội trú · Dược · Chuyển tuyến.

Điểm khác biệt VN cốt lõi: cấp cứu xử lý y tế TRƯỚC, định danh & BHYT SAU. BHYT cấp cứu được hưởng như đúng tuyến tại bất kỳ cơ sở (Luật BHYT 51/2024 Điều 22; NĐ 188/2025/NĐ-CP). Bệnh nhân có thể chưa rõ danh tính lúc tiếp nhận.

Ca minh hoạ tổng hợp: Nguyễn Văn An vào cấp cứu BV Chợ Rẫy 20/4/2026 sau tai nạn giao thông, gãy cổ xương đùi S72.0, ổn định qua đêm, chuyển khoa Chấn thương–Chỉnh hình. Ca chưa định danh xem ExamplePatientUnknown. Tất cả dữ liệu ví dụ đều là dữ liệu tổng hợp, không phải hồ sơ người bệnh thật.

1. Phạm vi

Tiếp nhận cấp cứu, triage, xử trí ban đầu; kết cục: ra viện / nhập viện (→ Nội trú) / chuyển tuyến / tử vong.

2. Vai trò triển khai và hệ thống

Khoa Cấp cứu (chủ luồng), điều dưỡng triage, LIS/RIS cấp cứu, cổng BHXH (xác minh hồi tố).

3. Căn cứ pháp lý

TT 13/2025/TT-BYT; QĐ 4210/QĐ-BYT (legacy MA_LYDO_VVIEN=2 cấp cứu); QĐ 3176/QĐ-BYT (KET_QUA_DTRI, MA_LOAI_RV và chuẩn dữ liệu hiện hành); Luật BHYT 51/2024 Điều 22 + NĐ 188/2025/NĐ-CP (cấp cứu hưởng đúng tuyến); TT 06/2026/TT-BYT + QĐ 1849/QĐ-BYT (ICD-10 hiện hành; QĐ 4469/QĐ-BYT/QĐ 98/QĐ-BYT chỉ provenance legacy từ 01/07/2026); QĐ 697/QĐ-BYT (chi phí).

4. Điều kiện tiên quyết — rút gọn

| # | Hành động | Ghi chú VN | |—|—|—| | P1–P3 | Org / Location / Practitioner | như ngoại trú | | P4 | Định danh bệnh nhân — 2 nhánh | (a) có CCCD → VNCorePatient chuẩn; VNeID chỉ là ngữ cảnh xác thực/tích hợp; (b) chưa định danh → Patient có định danh tạm theo profile (ExamplePatientUnknown), sau đó cập nhật hoặc liên kết khi xác minh được CCCD | | P5 | BHYT — hồi tố | tạo/cập nhật VNCoreCoverage SAU xử trí. Ghi loại KCB hiện hành bằng Encounter.type (MA_LOAI_KCB theo QĐ 1804/QĐ-BYT). Extension insuranceVisitType mang MA_LYDO_VVIEN của chuỗi QĐ 4210/QĐ-BYT là legacy-only trước 01/07/2024 — vẫn hợp lệ (0..1) để đọc và tái tạo dữ liệu cũ, như ExampleEncounterEmergency minh hoạ, nhưng KHÔNG dùng làm trường trao đổi BHXH hiện hành |

Để không cản trở cấp cứu, máy chủ có hỗ trợ thao tác create SHOULD cho phép tạo Patient bằng định danh tạm theo chính sách công bố trong CapabilityStatement; sau khi xác minh, hệ thống cập nhật hoặc liên kết hồ sơ bằng Patient.link. Khi xuất dữ liệu BHYT mà thiếu SO_CCCD, phải có mã lý do bất khả kháng theo VN-RULE-BHYT-001.

5. Phương án gửi bằng Transaction Bundle

Khi máy chủ công bố hỗ trợ transaction, có thể gửi lượt cấp cứu dưới dạng transaction Bundle để áp dụng atomic. Ví dụ tổng hợp: Bundle-ExampleBundleEmergencyTransaction (Patient, Coverage, Encounter EMER, Condition S72.0 — PUT update-as-create). Hệ thống MAY dùng tương tác khác nếu CapabilityStatement và hợp đồng tích hợp cho phép. Chi tiết các pattern Bundle xem Playbook Nội trú §5.

6. Sơ đồ luồng

Patient(tạm/CCCD) ─▶ Encounter(EMER, arrived→triaged→in-progress)
        ▼
 Observation(triage: mức ưu tiên + sinh hiệu) ─▶ Condition(S72.0)
        ▼
 ServiceRequest(XN/CĐHA cấp, priority=stat) ▶ Observation/DiagReport
        ▼
 Procedure(xử trí) + MedicationRequest/Dispense(thuốc cấp cứu)
        ▼
 Encounter(finished + treatmentOutcome + dischargeDisposition) ──┬─▶ Ra viện ─▶ Claim(BHYT)
                                                                 ├─▶ Nhập viện ─▶ [Nội trú]
                                                                 ├─▶ Chuyển tuyến ─▶ DocumentReference
                                                                 └─▶ Tử vong ─▶ DocumentReference(báo tử)
        (sau cùng) cập nhật CCCD/BHYT hồi tố nếu lúc đầu định danh tạm

7. Các bước gửi dữ liệu

| # | Bước | Profile | Element chính | Example | |—|—|—|—|—| | 1 | Tiếp nhận | VNCoreEncounter | class=EMER, status: arrived→…→finished, insuranceVisitType=Cấp cứu, referralMode=Cấp cứu | Emergency | | 2 | Triage | VNCoreObservationVitalSigns + VNCoreObservationTriageAcuity | sinh hiệu + mức ưu tiên 1–5 (VNTriageAcuityVS — thang đề xuất VN Core tham chiếu ATS; căn cứ nguyên tắc ưu tiên: QĐ 01/2008/QĐ-BYT, văn bản không quy định số mức) | Triage cấp độ 2 | | 3 | Chẩn đoán | VNCoreConditionDiagnosis | ICD-10 S72.0 | FemurFracture | | 4 | Cận lâm sàng cấp | ServiceRequest/Specimen/Observation/ImagingStudy/DiagnosticReport | priority=stat | — | | 5 | Xử trí | VNCoreProcedure | DVKT | — | | 6 | Thuốc cấp cứu | VNCoreMedicationRequest + VNCoreMedicationDispense | whenHandedOver | — | | 7 | Kết cục | VNCoreEncounter | treatmentOutcome (KET_QUA_DTRI; xem VNTreatmentOutcomeVS), hospitalization.dischargeDisposition (MA_LOAI_RV) | (trong Encounter) |

8. Đóng lượt & BHYT

treatmentOutcome + dischargeDisposition. Nếu chuyển nhập viện → liên kết sang Encounter nội trú (Encounter.partOf hoặc EpisodeOfCare [GAP P2]). Claim cấp cứu: subType=Cấp cứu để giám định áp đúng mức hưởng. Ca chưa định danh: ExampleBHYTSubmissionEmergencyUnknownIdentity (Patient tạm + Coverage tạm + Claim priority=stat).

9. Phụ lục terminology

ICD-10 VN (edition 2026 theo TT 06/2026/TT-BYT + QĐ 1849/QĐ-BYT — 16.052 mã đã đối soát, business version 2026-07-01); MA_LYDO_VVIEN legacy (QĐ 4210/QĐ-BYT); KET_QUA_DTRI và MA_LOAI_RV (QĐ 3176/QĐ-BYT); nhóm chi phí (QĐ 697/QĐ-BYT).

9b. Ca tử vong — bốn câu hỏi hay gặp

Bổ sung 16/08/2026 sau khi rà từ góc người triển khai: bốn câu dưới đây là những chỗ kỹ sư tích hợp phải dừng lại đoán, nay trả lời bằng căn cứ văn bản.

Tử vong thì MA_LOAI_RV ghi mã nào? Bảng MA_LOAI_RV của QĐ 3176/QĐ-BYT có đúng 5 mã — ra viện, chuyển tuyến theo yêu cầu chuyên môn, trốn viện, xin ra viện, chuyển tuyến theo yêu cầu người bệnh — và không có mã tử vong. Đó không phải thiếu sót của danh mục: hai chỉ tiêu trả lời hai câu khác nhau. MA_LOAI_RV mô tả CÁCH người bệnh rời cơ sở; KET_QUA_DTRI mô tả KẾT CỤC LÂM SÀNG, và tử vong là mã 5 (tại cơ sở KCB) hoặc mã 8 (ngoại viện) của chỉ tiêu đó. Trong FHIR: Encounter.hospitalization.dischargeDisposition mang MA_LOAI_RV, còn Encounter.extension[treatmentOutcome] mang KET_QUA_DTRI. Đừng tìm mã tử vong trong VNDischargeDispositionCS — nó không có và không nên có.

Ghi tử vong ở đâu ngoài lượt điều trị? Patient.deceasedDateTime — xem VNCorePatient mục deceased[x]. Hai chỗ không thay nhau: deceased[x] thuộc hồ sơ NHÂN KHẨU và còn giá trị mãi; KET_QUA_DTRI thuộc MỘT LƯỢT điều trị. Hệ thống ghi mã 5 mà quên cập nhật deceased[x] sẽ để người đã mất tiếp tục xuất hiện như đang sống ở mọi truy vấn khác.

Nguyên nhân trực tiếp, nguyên nhân nền và bệnh góp phần — phân biệt thế nào? Mã hoá nguyên nhân tử vong theo ICD-10 áp dụng TT 06/2026/TT-BYT và QĐ 1849/QĐ-BYT; từng nguyên nhân biểu diễn bằng một Condition.

IG 0.10.0 chưa có cách máy-đọc-được để phân ba vai này. Encounter.diagnosis.rank là "thứ hạng chẩn đoán" của FHIR, KHÔNG được IG lẫn văn bản Việt Nam định nghĩa là "rank 1 = nguyên nhân trực tiếp"; dùng nó theo nghĩa đó là quy ước cục bộ của từng hệ, không phải hợp đồng. Nếu hai bên trao đổi cần phân biệt chặt, hãy thoả thuận trong hợp đồng tích hợp và nêu nhu cầu trong phản hồi cộng đồng để cân nhắc một CodeSystem vai-nguyên-nhân cho 0.11. Đây là khoảng trống đã biết, ghi ra để người triển khai không tưởng IG đã quy định.

Giấy báo tử: Composition hay DocumentReference? Dùng DocumentReference khi giấy báo tử là VĂN BẢN ĐÃ KÝ được đính kèm — đó là cách ExampleBHYTSubmissionDeathCertificate làm. Composition chỉ dùng khi hệ thống thực sự dựng nội dung giấy báo tử theo cấu trúc trong FHIR. Sơ đồ mục 6 trước đây ghi Composition(báo tử) trong khi ví dụ duy nhất của IG dùng DocumentReference — đã sửa sơ đồ cho khớp ví dụ.

9c. Số ngày điều trị SO_NGAY_DTRI

Công thức của QĐ 3176/QĐ-BYT, theo MA_LOAI_KCB:

Hai điểm nguyên văn của QĐ 3176/QĐ-BYT: công thức cộng 1, nên vào và ra cùng ngày vẫn tính 1 ngày chứ không phải 0; và khi người bệnh đến khám rồi được hẹn vào điều trị nội trú thì số ngày điều trị không bao gồm thời gian chờ theo hẹn.

Trong FHIR, Encounter.period mang NGAY_VAO/NGAY_RA. IG không quy định Encounter.length phải bằng SO_NGAY_DTRI — hai đại lượng tính khác nhau (length là độ dài thực của lượt, còn SO_NGAY_DTRI theo công thức hành chính ở trên); nếu hệ thống ghi cả hai thì phải chấp nhận chúng có thể lệch nhau và không suy ra cái này từ cái kia.

10. Danh sách kiểm tra hợp lệ + lỗi thường gặp

• Encounter class=EMER + thời điểm arrived có mặt.
• Áp dụng đúng profile cho người bệnh chưa rõ danh tính: định danh tạm, cơ chế thiếu CCCD có giải trình và quy trình cập nhật/liên kết sau xác minh.
• Xuất BHYT thiếu SO_CCCD → phải có mã lý do bất khả kháng (VN-RULE-BHYT-001).
• Cập nhật CCCD/BHYT hồi tố → merge đúng Patient, không tạo trùng — cách làm ở VNCorePatient mục link: hồ sơ tạm đặt link.type = replaced-by + active = false, KHÔNG xoá và KHÔNG chép dữ liệu sang hồ sơ mới.
• Kết cục = tử vong → có Condition/Observation nguyên nhân + thời điểm.

Mã lỗi tra tại Danh mục quy tắc; ví dụ OperationOutcome có sẵn: ExampleOperationOutcomeBHYTClaimReview.

11. Khoảng trống profile (GAP)

| GAP | Ảnh hưởng | Priority | |—|—|—| | Observation triage acuity | ✅ Đã bổ sung VNCoreObservationTriageAcuity + VNTriageAcuityCS (thang 5 mức đề xuất tham chiếu ATS; căn cứ nguyên tắc QĐ 01/2008/QĐ-BYT, văn bản không quy định số mức) | resolved | | EpisodeOfCare (nối cấp cứu→nội trú) | ✅ Đã bổ sung VNCoreEpisodeOfCare | resolved | | Quy tắc bệnh nhân chưa định danh + merge | ✅ Đã tài liệu hoá ở Định danh người bệnh & MPI (§3–4) + rule VN-RULE-PAT-004/005 | resolved |

Liên hệ với các trang khác

| Nếu cần | Đọc tiếp | |—|—| | Chuyển tiếp nội trú | Playbook Nội trú | | Quy ước OperationOutcome | OperationOutcome & Registry | | Liên thông BHYT | BHYT Submission |

English Summary

Emergency integration playbook for a synthetic traffic-accident and femoral-neck-fracture (S72.0) scenario. It illustrates an atomic transaction Bundle (ExampleBundleEmergencyTransaction) when the applicable server CapabilityStatement advertises transaction support. The workflow supports temporary local identifiers for initially unidentified patients and later record update or linkage; Patient create/update behavior is declared by the applicable CapabilityStatement. Emergency BHYT processing and the resolved triage/identity guidance are linked to the relevant profiles and VN-RULE registry.