Bộ Hướng dẫn Triển khai Core FHIR cho Việt Nam - Draft for Community Review (v0.6.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ợp đồng 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, đóng gói nộp lên FHIR server bằng một transaction Bundle atomic.

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 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 thật trong IG.

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. Actor & 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 use case).
• QĐ 3176/QĐ-BYT (29/10/2024) — chuẩn dữ liệu đầu ra KCB: trường MALYDO (loại KCB), KETQUA (kết quả điều trị), MA_LUOT_KCB.
• 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. Cơ chế nộp dữ liệu — Transaction Bundle (quyết định kiến trúc VN Core)

VN Core nộp một lượt khám/đợt điều trị = một transaction Bundle (Bundle.type = transaction). Toàn bộ resource trong đợt được áp dụng atomic: hoặc tất cả thành công, hoặc rollback toàn bộ. Đây là khác biệt có chủ ý so với nền tảng SATUSEHAT (Indonesia POST từng resource rời).

Ví dụ chuẩn: Bundle-ExampleBundleInpatientTransaction — nộp atomic toàn bộ đợt viêm ruột thừa.

5.1 Hai pattern entry được VN Core chấp nhận

Trong ví dụ, 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 (audit trail, NĐ 137/2024).
• 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

1 Condition = 1 chẩn đoán mỗi resource (chống gộp đa chẩn đoán). Mọi datetime có offset +07:00.

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

VNCoreEncounter: status = finished + period.end + extension[treatmentOutcome] (KETQUA — ví dụ 1 = Khỏi) + hospitalization.dischargeDisposition (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: 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 khớp số ngày period.end − period.start (7 ngày: 10/3 → 17/3).

11. Phụ lục terminology (pointer)

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

12. Validation checklist + lỗi thường gặp

Checklist trước khi nộp 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 = đúng 1 mã ICD-10; chẩn đoán ra viện có mặt khi finished.
• Mỗi MedicationDispense có authorizingPrescription (không cấp phát "mồ côi").
• Claim có dòng ngày giường khớp số ngày 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) phải khớp số ngày 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

Use case nội trú thuộc phạm vi harden cho pilot — xem Pilot readiness.

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), submitted to the FHIR server as a single atomic transaction Bundle — a deliberate VN Core architectural choice (unlike SATUSEHAT's resource-by-resource POST). A real, SUSHI-validated example (ExampleBundleInpatientTransaction) demonstrates the PUT update-as-create pattern over a complete acute appendicitis case, alongside the discharge-summary document Bundle and the BHYT submission collection Bundle. The page lists prerequisites, resource sequence (anchored on real Example Instances), terminology bindings with Vietnamese legal basis, a validation checklist with OperationOutcome samples; previously remaining profile gaps (MedicationAdministration, EpisodeOfCare) are now resolved.