# Hướng dẫn Must Support - Bộ Hướng dẫn Triển khai Core FHIR cho Việt Nam v0.5.0

## Hướng dẫn Must Support

# Hướng dẫn Must Support — Must Support Guidance

Cách hiểu và cách triển khai **Must Support** trong VN Core cho HIS, EMR, cổng liên thông và hệ thống nhận dữ liệu — phân biệt `Must Support` với cardinality thuần túy, xác định khi nào được để trống có giải trình, và gán đúng trách nhiệm cho từng vai trò trong chuỗi HIS → FHIR → gateway → hệ thống nhận.

## Must Support phải đi cùng guidance và testing

`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ử**.

* Không dùng `Must Support` như cách vá mọi yêu cầu nghiệp vụ vào cardinality.
* Không coi một phần tử là “đã triển khai được” nếu chưa có hướng dẫn cho sender/receiver và chưa có ví dụ hoặc kiểm tra tương ứng.
* Với các phần tử có rủi ro hiểu sai cao, phải đọc kèm [Kiểm tra hợp lệ](validation-guidance.md), [Hành vi tìm kiếm](search-behavior.md) hoặc `CapabilityStatement` theo vai trò triển khai.

-------

## Nguyên tắc diễn giải

### Must Support không đồng nghĩa với bắt buộc phải có giá trị

Khi một phần tử được đánh dấu **Must Support**:

* **Hệ thống gửi** phải gửi phần tử đó nếu dữ liệu có sẵn và thuộc phạm vi nghiệp vụ của giao dịch.
* **Hệ thống nhận** phải có khả năng tiếp nhận, lưu trữ, xử lý, hiển thị hoặc chuyển tiếp phần tử đó mà không gây lỗi.
* **Hệ thống triển khai** không được tự tạo dữ liệu giả chỉ để làm đầy phần tử Must Support.

Must Support có thể đi cùng `0..1`, `0..*`, `1..1` hoặc `1..*`.

| | | |
| :--- | :--- | :--- |
| `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 |

### Must Support trong VN Core được hiểu theo ngữ cảnh nghiệp vụ

VN Core áp dụng Must Support theo ba lớp:

* **Lớp pháp lý**: dữ liệu được văn bản hiện hành yêu cầu hoặc là thành phần cốt lõi của hồ sơ số.
* **Lớp liên thông**: dữ liệu cần có để hệ thống bên nhận hiểu đúng resource.
* **Lớp vận hành**: dữ liệu không bắt buộc trong mọi ca, nhưng nếu có thì phải bảo toàn khi trao đổi.

Ví dụ:

* `Patient.identifier[CCCD]` là Must Support vì là định danh cá nhân lõi 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.

### Trách nhiệm theo vai trò triển khai

| | |
| :--- | :--- |
| 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ệ. |

### Hệ thống nhận cần làm gì

Đối với phần tử Must Support, hệ thống nhận cần tối thiểu:

* Đọc được phần tử và không báo lỗi cú pháp/ngữ nghĩa khi phần tử hợp lệ.
* Giữ lại dữ liệu khi lưu hoặc chuyển tiếp.
* Hiển thị được cho người dùng nếu đây là dữ liệu cần đọc ở giao diện.
* Không làm mất dữ liệu khi chuyển đổi nội bộ.
* Nếu chưa khai thác hết, vẫn phải bảo toàn dữ liệu nguyên bản.

-------

## Bảng quy ước khi thiếu dữ liệu

### Nguyên tắc chung

* Không tạo phần tử rỗng.
* Không điền giá trị giả như `"N/A"`, `"Không rõ"`, `"000000000000"` vào trường chuẩn hóa.
* Chỉ dùng `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ệ.
* Với dữ liệu có ràng buộc pháp lý riêng, phải kết hợp thêm phần giải trình tương ứng của VN Core nếu có.

### Ma trận xử lý

| | | |
| :--- | :--- | :--- |
| 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` |

### Các trường hợp hay gặp trong VN Core

| | |
| :--- | :--- |
| `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 |

-------

## Quy ước triển khai theo kiểu dữ liệu

### Định danh

* Không dùng một trường text tự do để thay thế `identifier`.
* Mỗi loại định danh phải có `system` rõ ràng.
* Với định danh hiện hành và định danh lịch sử cùng tồn tại, phải phân biệt bằng lát cắt hoặc `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ử.

### Dữ liệu mã hóa

* Nếu profile dùng binding `required`, phải dùng mã nằm trong ValueSet.
* Nếu `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.
* Nếu tạm thời chưa mã hóa được nhưng vẫn cần trao đổi, nên cân nhắc: 
* Dùng `text` của `CodeableConcept`;
* Hoặc dùng `data-absent-reason` nếu đúng bản chất là thiếu dữ liệu, không phải thiếu mapping.
 

### Tham chiếu

Với phần tử Must Support kiểu `Reference`:

* Phải trỏ đến đúng loại resource mà profile cho phép;
* Không thay bằng chuỗi text nếu quy trình cần liên thông máy đọc được;
* Nếu hệ thống nguồn chưa có resource đích, cần coi đó là khoảng trống tích hợp, không phải lý do để bỏ hẳn tham chiếu lâu dài.

### Ngày giờ

* Không dùng text tự do thay cho kiểu ngày/giờ chuẩn.
* Nếu chỉ biết một phần thông tin, cân nhắc dùng đúng mức độ chi tiết mà FHIR cho phép.
* Với lớp BHYT export, vẫn phải tuân thủ format thời gian riêng của cổng giám định ở lớp mapping/export.

-------

## Cookbook HIS -> FHIR

### Bệnh nhân và người liên quan

**Nguồn HIS thường có**

* Mã bệnh nhân nội bộ;
* CCCD hoặc mã số BHXH hoặc số thẻ BHYT;
* Họ tên;
* Ngày sinh;
* Địa chỉ hành chính;
* Thông tin cha/mẹ/người giám hộ trong hồ sơ trẻ em.

**Ánh xạ khuyến nghị**

| | |
| :--- | :--- |
| 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**

* Trẻ em không có CCCD không phải là ngoại lệ để bỏ mô hình định danh; phải diễn đạt đúng bằng `GKS`, `BHXH`, `BHYT`, `RelatedPerson` và lý do thiếu CCCD khi cần.
* Không trộn thông tin người giám hộ vào cùng `Patient.name` hoặc `Patient.identifier`.

### Lượt khám và điều trị

**Nguồn HIS thường có**

* Số lượt khám;
* Hình thức vào khám;
* Thời gian vào, ra;
* Khoa/phòng;
* Lý do đến khám hoặc chẩn đoán vào viện.

**Ánh xạ khuyến nghị**

| | |
| :--- | :--- |
| 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**

* Không chỉ lưu lý do đến khám ở text nội bộ nếu hệ thống đã có dữ liệu cấu trúc.
* Nếu Encounter là đầu mối cho hồ sơ tài liệu, nên bảo đảm các tài liệu và kết quả cùng tham chiếu về đúng Encounter.

### Tài liệu y tế

**Khi dùng `Composition`**

* Tài liệu có cấu trúc lôgic, có tiêu đề, tác giả, phần mục và giá trị pháp lý như tóm tắt ra viện hoặc bệnh án điện tử.

**Khi dùng `DocumentReference`**

* Tài liệu đính kèm, bản scan, PDF, ảnh, file xuất từ hệ thống khác, hoặc bản ghi tài liệu cần tra cứu/tải xuống.

**Ánh xạ khuyến nghị**

| | |
| :--- | :--- |
| 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` |

### Bảo hiểm y tế

**Nguồn HIS/BHYT thường có**

* Số thẻ BHYT;
* Nơi đăng ký khám chữa bệnh ban đầu;
* Mức hưởng;
* Người thụ hưởng;
* Người đại diện hoặc người đóng trong hồ sơ phụ thuộc.

**Ánh xạ khuyến nghị**

| | |
| :--- | :--- |
| 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**

* Nếu `subscriber` khác `beneficiary`, không được để `relationship = self`.
* Không dùng một example trẻ em tự hưởng quyền lợi để suy diễn cho mọi ca phụ thuộc có người đại diện.

### Liên thông hồ sơ BHYT

**Nguyên tắc cốt lõi**

* Dữ liệu phải được mô hình hóa theo FHIR trước.
* Lớp liên thông hồ sơ thanh toán BHYT là lớp chuyển đổi sau cùng.
* `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**

| | |
| :--- | :--- |
| Đợ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`) |

-------

## Checklist triển khai cho đơn vị HIS

* Xác định rõ phần tử Must Support nào đã có sẵn trong cơ sở dữ liệu.
* Ghi nhận phần tử nào chưa có dữ liệu và phần tử nào chưa có khả năng xuất.
* Không đưa giá trị giả vào các trường định danh, ngày giờ, mã hóa.
* Thống nhất quy tắc dùng `data-absent-reason`.
* Kiểm thử ít nhất một bộ dữ liệu thật cho mỗi nhóm: bệnh nhân, lượt khám, tài liệu, BHYT.
* Chạy cả kiểm tra cú pháp và kiểm tra Tier 2 của repo trước khi chia sẻ dữ liệu.

-------

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

| | |
| :--- | :--- |
| Nắm quy tắc tổng quát về tên tiếng Việt, địa chỉ, định danh, Organization/Location | [Hướng dẫn chung](general-guidance.md) |
| Tra các quy tắc kiểm tra mức profile, mức nghiệp vụ và mức xuất BHYT | [Hướng dẫn kiểm tra hợp lệ](validation-guidance.md) |
| Xem ví dụ luồng dữ liệu đầu-cuối theo tình huống lâm sàng | [Tình huống lâm sàng](clinical-scenarios.md) |
| Tra danh sách các profile và phần tử Must Support của từng profile | [Hồ sơ](profiles.md) |

-------

## English Summary

This page explains how VN Core interprets Must Support in practice. It distinguishes Must Support from cardinality, assigns sender and receiver responsibilities, defines the absent-data patterns that may be used, and provides implementation guidance for common HIS-to-FHIR workflows.

