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

Playbook Nội trú

Playbook Nội trú — KCB nội trú (Inpatient)

Hướng dẫn tích hợp đầu–cuối cho một đợt điều trị nội trú: từ nhập viện → điều trị/phẫu thuật → ra viện → thanh toán BHYT. Trang minh họa 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.

Trang này là integration spec cho vendor HIS/EMR. Để xem walkthrough lâm sàng kể chuyện, đọc Tình huống lâm sàng. Để hiểu bối cảnh thiết kế (đối sánh nền tảng SATUSEHAT Indonesia), xem tài liệu phân tích nội bộ của dự án.

Ca minh họa tổng hợp xuyên suốt: Nguyễn Văn An (nam, CCCD 001085012345, BHYT loại DN 80%) nhập viện BV Chợ Rẫy ngày 10/3/2026 vì viêm ruột thừa cấp (K35.8) có giấy chuyển tuyến hợp lệ (đúng tuyến), phẫu thuật cắt ruột thừa nội soi, nằm viện 7 ngày, ra viện ổn định ngày 17/3/2026. Mọi resource trong trang là Example Instance tổng hợp, không phải hồ sơ người bệnh thật.

1. Phạm vi & khi nào dùng

Áp dụng cho mọi CSKCB có giường bệnh, hướng tới yêu cầu bệnh án điện tử theo TT 13/2025/TT-BYT (cơ sở KCB khác hoàn thành chậm nhất 31/12/2026).

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

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

• TT 13/2025/TT-BYT — bệnh án điện tử (nền tảng ca sử dụng).
• QĐ 4210/QĐ-BYT (2017) — nguồn legacy cho MA_LYDO_VVIEN (4 mã). Mã 5 của VNInsuranceVisitTypeCS là mở rộng dự án chờ nguồn.
• QĐ 3176/QĐ-BYT (29/10/2024) — chuẩn dữ liệu đầu ra KCB hiện hành: MA_DOI_TUONG_KCB, KET_QUA_DTRI, MA_LOAI_RV và khóa MA_LK. MA_LUOT_KCB là convention cộng đồng của VN Core, chỉ giữ tương thích với MA_LK khi trao đổi BHYT.
• NĐ 188/2025/NĐ-CP (hiệu lực 15/8/2025) — quy tắc thanh toán & mức hưởng BHYT; cấp cứu/đúng tuyến.
• QĐ 697/QĐ-BYT (19/3/2026, triển khai 01/7/2026) — mẫu bảng kê chi phí KCB: 12 nhóm danh mục chi phí, gồm ngày giường.
• NĐ 164/2025/NĐ-CP (29/6/2025) — giao dịch điện tử trong BHXH (cơ sở pháp lý cho nộp dữ liệu điện tử).
• QĐ 4469/QĐ-BYT — ICD-10 VN; TT 23/2024/TT-BYT + QĐ 387/QĐ-BYT — DVKT/ICD-9-CM.

4. Điều kiện tiên quyết

Trước khi nộp đợt nội trú, các resource sau PHẢI tồn tại/được nộp kèm:

5. Phương án gửi dữ liệu bằng Transaction Bundle

Khi máy chủ công bố hỗ trợ tương tác transaction, có thể gửi một lượt khám/đợt điều trị bằng Bundle.type = transaction. Toàn bộ resource trong transaction được áp dụng atomic: hoặc tất cả thành công, hoặc toàn bộ thay đổi được hoàn tác. Trước khi áp dụng, bên triển khai phải xác nhận transaction trong CapabilityStatement và hợp đồng tích hợp; hệ thống MAY dùng các tương tác khác đã được công bố.

Ví dụ tổng hợp: Bundle-ExampleBundleInpatientTransaction — minh họa gửi atomic toàn bộ đợt viêm ruột thừa.

5.1 Hai pattern entry khi dùng transaction

Trong ví dụ tổng hợp, dữ liệu chủ (Patient/Coverage/Practitioner/Organization) và resource lâm sàng đều dùng PUT update-as-create — đơn giản, idempotent, dễ đối soát BHXH. Tham chiếu nội bộ dùng dạng tương đối ResourceType/{id} (hợp lệ trong transaction).

5.2 Quy tắc đóng gói

• Atomicity: nếu một resource sai (vd Encounter thiếu serviceProvider), toàn bộ Bundle bị từ chối → tránh dữ liệu nửa vời.
• Thứ tự không quan trọng trong transaction (server tự giải tham chiếu), nhưng nên xếp dữ liệu chủ trước cho dễ đọc.
• Bundle.timestamp bắt buộc (dấu vết kiểm toán, NĐ 137/2024/NĐ-CP).
• Idempotency: nộp lại cùng Bundle (cùng id) bằng PUT không tạo bản trùng.

5.3 Ba loại Bundle trong vòng đời một đợt nội trú

6. Sơ đồ luồng đợt nội trú

Patient ─▶ Coverage(BHYT đúng tuyến) ─▶ Encounter(IMP, in-progress)
                                            │  hospitalization.admitSource = chuyển tuyến
        ┌────────────────────────────────────┼─────────────────────────────────┐
        ▼                                    ▼                                  ▼
  Condition(vào viện: K35.8)        location[period] (chuyển khoa)        Observation(theo dõi)
        ▼
  ServiceRequest ▶ Specimen ▶ DiagnosticReport (giải phẫu bệnh)
        ▼
  Procedure(cắt ruột thừa nội soi)  +  MedicationRequest(y lệnh) ▶ MedicationDispense(cấp phát)
        ▼
  Encounter(finished + treatmentOutcome=Khỏi + dischargeDisposition=Ra viện)
        ▼
  Composition(tóm tắt xuất viện, LOINC 18842-5)
        ▼
  Claim(12 nhóm + 7 ngày giường) ─▶ ClaimResponse ─▶ ExplanationOfBenefit
        │
        └────────────────── tất cả gói trong 1 transaction Bundle ──────────────────┘

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

Mỗi Condition biểu diễn một vấn đề/chẩn đoán lâm sàng. Condition.code có thể chứa nhiều Coding tương đương cho cùng khái niệm, chẳng hạn một coding ICD-10 VN bắt buộc và một coding SNOMED CT; không gộp nhiều chẩn đoán khác nghĩa vào một resource. Mọi datetime có offset +07:00.

8. Đóng đợt nội trú

VNCoreEncounter: status = finished + period.end + extension[treatmentOutcome] (KET_QUA_DTRI — ví dụ 1 = Khỏi) + hospitalization.dischargeDisposition (MA_LOAI_RV — ví dụ 1 = Ra viện). Chẩn đoán ra viện (Condition category/diagnosis.use) phải có mặt khi đóng.

9. Tài liệu tổng hợp — Tóm tắt xuất viện

Cuối đợt, lập VNCoreComposition tóm tắt xuất viện (LOINC 18842-5 — Discharge summary) với các section chuẩn theo TT 13/2025/TT-BYT: lý do nhập viện, chẩn đoán, thủ thuật, thuốc, khám trước ra viện, tóm tắt ra viện. Đóng gói thành document Bundle (Composition là entry[0]) để ký số và lưu trữ bất biến.

Ví dụ Composition: ExampleCompositionDischargeSummary. Ví dụ document Bundle hoàn chỉnh (Composition là entry[0]): ExampleBundleInpatientDischarge.

Có thể đồng thời cập nhật Sổ Sức khỏe điện tử (VNeID) dạng VNCoreCompositionHealthRecordSummary (IPS, LOINC 60591-5) — bản tóm tắt longitudinal.

10. Tích hợp BHYT/Claim

Kiểm tra ngày giường: số lượng item[category=2.2].quantity phải được tính theo quy tắc nghiệp vụ/giám định hiện hành và đối chiếu với Encounter.period. Không suy ra máy móc chỉ bằng phép trừ hai timestamp khi có ngày vào/ra không trọn ngày, chuyển khoa hoặc ngoại lệ thanh toán. Trong ca minh họa, kết quả nghiệp vụ là 7 ngày (10/3 → 17/3).

11. Phụ lục terminology (pointer)

Xem thêm Hướng dẫn terminology.

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

Checklist khi chọn phương án transaction Bundle:

• Bundle.type = transaction và mỗi entry có request.method + request.url (FHIR bdl-3).
• Encounter: class=IMP, có subject + serviceProvider + period.start + hospitalization.admitSource.
• Mỗi Condition biểu diễn một chẩn đoán; code có coding ICD-10 VN bắt buộc và có thể có thêm coding tương đương, không gộp nhiều chẩn đoán khác nghĩa.
• Mỗi MedicationDispense có authorizingPrescription (không cấp phát "mồ côi").
• Claim có dòng ngày giường được tính theo quy tắc nghiệp vụ/giám định hiện hành và đối chiếu với đợt nằm viện; đúng 1 thẻ BHYT focal=true.
• Mọi datetime có offset +07:00.
• Tham chiếu nội bộ giải được trong Bundle (relative ResourceType/{id} hoặc urn:uuid).

Ví dụ OperationOutcome — Encounter thiếu serviceProvider (cả Bundle bị từ chối):

{"resourceType":"OperationOutcome","issue":[{"severity":"error","code":"required",
"details":{"text":"Encounter.serviceProvider là bắt buộc (VN-RULE-ENC-001)"},
"expression":["Bundle.entry[4].resource.serviceProvider"]}]}

Ví dụ — số ngày giường không khớp:

{"resourceType":"OperationOutcome","issue":[{"severity":"error","code":"business-rule",
"details":{"text":"Số ngày giường (item 2.2) không phù hợp quy tắc nghiệp vụ/giám định hoặc không đối chiếu được với đợt nằm viện (VN-RULE-CLM-014)"},
"expression":["Bundle.entry[11].resource.item.where(category.coding.code='2.2')"]}]}

Lỗi thường gặp: | Lỗi | Nguyên nhân | Xử lý | |—|—|—| | Cả Bundle bị từ chối dù chỉ 1 resource sai | Bản chất atomic của transaction | Sửa resource lỗi, nộp lại toàn bộ | | Tạo bản trùng khi retry | Dùng POST không có ifNoneExist | Chuyển sang PUT update-as-create hoặc thêm ifNoneExist | | Tham chiếu không giải được | Trộn urn:uuid và id thật không nhất quán | Thống nhất 1 kiểu reference trong Bundle |

13. Khoảng trống profile (GAP) & maturity

Ca sử dụng nội trú thuộc phạm vi gia cố cho thí điểm — xem Checklist sẵn sàng thí điểm.

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

English Summary

This page is the inpatient integration playbook for VN Core. It specifies the end-to-end FHIR workflow for one inpatient stay (admission → treatment/surgery → discharge → BHYT claim). A coherent synthetic example (ExampleBundleInpatientTransaction) demonstrates the PUT update-as-create pattern in an atomic transaction Bundle when the applicable server CapabilityStatement advertises transaction support, alongside a discharge-summary document Bundle and a BHYT submission collection Bundle. The page lists prerequisites, the resource sequence, terminology bindings with Vietnamese legal basis, and a validation checklist with OperationOutcome samples.