Glossary HL7 / FHIR — Thuật ngữ Anh-Việt

Đơn vị quốc gia của HL7 International, được trao quyền sub-publish Implementation Guide, tổ chức ballot và đại diện cộng đồng tiêu chuẩn y tế tại quốc gia đó. Mỗi Affiliate hoạt động độc lập về tài chính nhưng tuân thủ chính sách bản quyền và quy trình ballot của HL7 International.

Ngữ cảnh VN: Omi HealthTech đang chuẩn bị nền tảng kỹ thuật và cơ chế Working Group cho lộ trình HL7 Affiliate Việt Nam. Nếu Affiliate được thành lập, vai trò điều phối VN Core IG sẽ cần được xác lập theo governance chính thức.

Khái niệm cốt lõi của openEHR. Archetype mô tả một concept lâm sàng đơn lẻ (ví dụ Blood Pressure, Body Temperature) ở mức tối đa, độc lập với use case cụ thể. Khi triển khai thực tế, người dùng tổ hợp Archetype thành Template để khớp với form nhập liệu.

Ngữ cảnh VN: Archetype `openEHR-EHR-OBSERVATION.blood_pressure.v2` được dùng rộng rãi trong các EHR mở. Việt Nam có thể tham chiếu Archetype này khi mapping sang FHIR Observation.

Profile IHE mô tả audit trail và node authentication cho các actor/transaction áp dụng. Yêu cầu ATNA, transport và mutual authentication phải đọc theo đúng profile, actor, option và version được chọn; không suy rộng thành nghĩa vụ giống nhau cho mọi node.

Ngữ cảnh VN: Khi triển khai HIE theo IHE, đội dự án lập ma trận actor/transaction và áp dụng ATNA khi profile đã chọn yêu cầu. ATNA hỗ trợ kiểm soát kỹ thuật nhưng không tự chứng minh tuân thủ Luật 91/2025/QH15.

FHIR Resource ghi nhận các sự kiện bảo mật và quyền riêng tư đáng kiểm toán — như đăng nhập, truy cập hồ sơ, sửa đổi dữ liệu, xuất dữ liệu. AuditEvent thường được dùng để xây dựng audit log phục vụ tuân thủ pháp lý, nhưng bản thân nó không tự động ghi nhận mọi access; phạm vi do hệ thống và Implementation Guide quy định.

Ngữ cảnh VN: Để hỗ trợ khả năng giải trình theo Luật 91/2025/QH15 và NĐ 356/2025/NĐ-CP, hệ thống cần xác định sự kiện phải audit từ phân tích pháp lý, threat model và chính sách truy cập, rồi kiểm thử bản ghi AuditEvent tương ứng.

Hệ thống bảo hiểm y tế quốc gia của Việt Nam, do Bảo hiểm Xã hội Việt Nam quản lý. VN Core v0.9.0 hỗ trợ hai định dạng số thẻ: 10 chữ số hiện hành (cùng giá trị số với mã số BHXH) và 15 ký tự legacy gồm 2 chữ + 13 số. Số CCCD 12 chữ số là định danh riêng và không được ghi dưới hệ `sid/bhyt`.

Ngữ cảnh VN: VN Core IG ánh xạ thẻ BHYT vào FHIR Coverage; định danh dùng URI `http://fhir.hl7.org.vn/core/sid/bhyt`. Quy tắc thanh toán BHYT căn cứ Nghị định 188/2025/NĐ-CP.

Mức độ bắt buộc của ValueSet đối với một element. FHIR R4 định nghĩa 4 mức: required (bắt buộc dùng code trong ValueSet), extensible (dùng code trong ValueSet nếu có concept phù hợp), preferred (khuyến khích nhưng không bắt buộc), example (chỉ minh họa).

Ngữ cảnh VN: Trong VN Core Patient, element `gender` có binding strength = required với ValueSet AdministrativeGender; trong khi `maritalStatus` thường ở mức extensible để cho phép code địa phương.

FHIR Resource chứa nhiều Resource khác trong một gói duy nhất. FHIR R4 định nghĩa 9 giá trị cho `Bundle.type` (required binding): document, message, transaction, transaction-response, batch, batch-response, history, searchset, collection. Mỗi loại có quy tắc xử lý riêng tại server.

Ngữ cảnh VN: Khi server FHIR trả kết quả tìm kiếm `GET /Patient?name=Nguyen`, response là Bundle với `type=searchset`. Khi gửi cả bệnh án (Composition + nhiều Resource), dùng `type=document`.

URL định danh duy nhất, không đổi cho một artifact (Profile, Extension, ValueSet, CodeSystem) trong FHIR. Canonical URL khác với URL truy cập file: nó là định danh logic, có thể không resolve được nhưng phải bất biến qua các version.

Ngữ cảnh VN: VN Core Patient có canonical URL `http://fhir.hl7.org.vn/core/StructureDefinition/vn-core-patient`. Instance có thể khai URL này trong `Patient.meta.profile` để tuyên bố tuân thủ; tuyên bố đó vẫn phải được validator kiểm tra và không phải điều kiện duy nhất để dữ liệu thực sự phù hợp profile.

FHIR Resource mô tả các Resource và Operation mà một FHIR server hoặc client hỗ trợ. Server bắt buộc phải expose CapabilityStatement qua endpoint `GET [base]/metadata`. Client dùng CapabilityStatement để khám phá năng lực server trước khi gọi API.

Ngữ cảnh VN: Khi tích hợp với HIS bệnh viện qua FHIR, nhà cung cấp đầu tiên gọi `GET https://fhir.bv.vn/metadata` để biết server hỗ trợ Patient, Encounter và những search parameter nào.

Quy định số lần tối thiểu và tối đa một element xuất hiện trong instance. Ký hiệu min..max: `0..1` (tùy chọn, đơn lẻ), `1..1` (bắt buộc, đơn lẻ), `0..*` (tùy chọn, nhiều), `1..*` (bắt buộc, ít nhất một). Profile có thể siết cardinality của base resource nhưng không được nới lỏng.

Ngữ cảnh VN: Patient.identifier base có cardinality `0..*`; VNCorePatient siết thành `1..*` và yêu cầu slice CCCD `1..1`. Trường hợp chưa có CCCD vẫn giữ slice này với `data-absent-reason` và căn cứ thay thế hợp lệ theo invariant của profile.

Số định danh cá nhân 12 chữ số do Bộ Công an cấp, in trên thẻ Căn cước công dân hoặc thẻ Căn cước. Là primary identifier cho công dân Việt Nam từ 01/7/2025, thay thế dần CMND 9 số và mã số thuế cá nhân theo lộ trình tích hợp VNeID.

Ngữ cảnh VN: Trong VN Core Patient, CCCD là Must Support identifier với system URI `http://fhir.hl7.org.vn/core/sid/cccd`. Điều 1 khoản 3 TT 13/2025/TT-BYT yêu cầu kết nối thông tin bệnh án điện tử với số định danh cá nhân của công dân Việt Nam và của người nước ngoài đã được cấp tài khoản định danh điện tử; không đặt tài khoản VNeID như một identifier thay thế.

Tiêu chuẩn HL7 v3 cho tài liệu lâm sàng có cấu trúc, dạng XML. CDA gồm header (thông tin định danh, tác giả, ngày tạo) và body (nội dung lâm sàng). CDA Release 2 vẫn được dùng rộng rãi cho tóm tắt xuất viện, đơn thuốc, kết quả xét nghiệm.

Ngữ cảnh VN: SS-MIX2 của Nhật Bản lưu trữ chuẩn hóa chủ yếu từ message HL7 v2 và có thể quản lý tài liệu ở lớp nội dung phù hợp; không nên đồng nhất SS-MIX2 với CDA. Việt Nam chọn CDA hay FHIR document theo contract và use case.

Tiêu chuẩn HL7 cho phép EMR gọi dịch vụ Clinical Decision Support (CDS) tại các điểm hook xác định trong workflow lâm sàng — như lúc mở hồ sơ bệnh nhân, kê đơn thuốc, đặt y lệnh. CDS service trả về Card chứa cảnh báo, gợi ý hoặc liên kết SMART app.

Ngữ cảnh VN: Một CDS Hook khi bác sĩ kê đơn thuốc kháng sinh có thể trả Card cảnh báo dị ứng dựa trên AllergyIntolerance của bệnh nhân, hỗ trợ tuân thủ Luật 134/2025/QH15 về AI có giám sát con người.

FHIR data type bọc nhiều `Coding` (mỗi Coding là một cặp system + code) và trường `text` mô tả tự do tùy chọn. Cho phép một concept được mã hóa đồng thời theo nhiều terminology — ví dụ vừa SNOMED CT vừa ICD-10 VN.

Ngữ cảnh VN: Một chẩn đoán "Tăng huyết áp nguyên phát" có thể được biểu diễn bằng CodeableConcept với 2 Coding: ICD-10 VN `I10` và SNOMED CT `38341003`, kèm text Việt cho người đọc.

FHIR Resource mô tả một hệ mã và cách nội dung của hệ mã được công bố. CodeSystem có canonical URL và có thể có version; `content` cho biết artifact chứa toàn bộ concept, một phần, supplement hay không chứa concept. CodeSystem là foundation cho ValueSet và Coding.

Ngữ cảnh VN: `vn-ethnicity-cs` đóng gói concept trong IG; ngược lại, `vn-icd10-cs` là metadata wrapper có `content = not-present`, nên toàn bộ 15.026 mã ICD-10 VN được phát hành qua download surface riêng.

FHIR data type cơ bản nhất để mã hóa một khái niệm: gồm `system` (URL canonical của CodeSystem), `code` (giá trị mã), `display` (text hiển thị), tùy chọn `version` và `userSelected`. CodeableConcept chứa một hoặc nhiều Coding.

Ngữ cảnh VN: Theo hướng dẫn hiện hành của VN Core, ICD-10 coding dùng `system = http://hl7.org/fhir/sid/icd-10`; artifact `vn-icd10-cs` trên IG là metadata wrapper, không phải nội dung code đóng gói để validator tự tra cứu.

FHIR Resource tổ chức nội dung và ngữ cảnh chứng thực của một tài liệu lâm sàng, có vai trò gần với CDA header nhưng không đồng nhất mô hình. Trong document Bundle, Composition là entry đầu và các section có thể tham chiếu các Resource khác trong gói.

Ngữ cảnh VN: Một trao đổi bệnh án có thể dùng document Bundle với Composition ở entry đầu. Composition mô tả loại, ngày, tác giả và attester; chữ ký mật mã, nếu cần, phải theo chính sách và cơ chế chữ ký áp dụng như Bundle.signature hoặc Provenance.signature.

FHIR Resource khai báo quan hệ giữa các concept thuộc các hệ mã hoặc tập giá trị. Trong R4, equivalence có các giá trị như relatedto, equivalent, equal, wider, subsumes, narrower, specializes, inexact, unmatched và disjoint; hướng ánh xạ phải được ghi rõ.

Ngữ cảnh VN: VN Core có thể công bố ConceptMap giữa mã nhóm chi phí BHYT và mã adjudication. Chuyển đổi toàn bộ XML sang Claim/EOB cần đặc tả ánh xạ cấu trúc hoặc adapter riêng, không phải một ConceptMap.

Sự kiện kiểm thử do HL7, IHE hoặc cộng đồng triển khai tổ chức, nơi nhiều hệ thống chạy kịch bản conformance/interoperability đã công bố. Kết quả chỉ là bằng chứng cho actor, option, phiên bản và test case đã chạy; không tự chứng minh toàn bộ IG hay sản phẩm đã sẵn sàng production.

Ngữ cảnh VN: Định hướng của Omi HealthTech là chuẩn bị một connectathon hoặc sandbox kiểm thử FHIR tại Việt Nam khi Working Group và các bên triển khai có đủ kịch bản, dữ liệu mẫu và quy trình công bố kết quả.

FHIR Resource biểu diễn lựa chọn hoặc cam kết của bệnh nhân về cách dữ liệu của họ được xử lý, chia sẻ. Consent dùng để mô hình hóa các obligation về quyền riêng tư, nhưng việc dùng tài nguyên này không tự động được luật pháp Việt Nam yêu cầu — tuỳ Implementation Guide quyết định.

Ngữ cảnh VN: Khi mô hình hóa nghĩa vụ thu thập sự đồng ý theo Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP, các hệ thống có thể dùng Consent để ghi nhận thời điểm, phạm vi, mục đích xử lý dữ liệu.

Tiêu chuẩn quốc tế cho hình ảnh y tế và dữ liệu liên quan, do NEMA quản lý. DICOM định nghĩa cả định dạng file (.dcm), giao thức truyền (DIMSE qua TCP), từ điển dữ liệu, và mô hình thông tin cho nhiều modality (CT, MRI, X-quang, siêu âm).

Ngữ cảnh VN: Nhiều PACS/RIS hỗ trợ DICOM, nhưng phải kiểm tra DICOM Conformance Statement của đúng sản phẩm và phiên bản. VN Core có thể tham chiếu study qua FHIR ImagingStudy.

Bộ giao thức HTTP/REST kế thừa các dịch vụ DIMSE truyền thống, gồm WADO-RS (truy xuất ảnh), QIDO-RS (truy vấn metadata), STOW-RS (gửi ảnh), UPS-RS (workflow). Cho phép tích hợp DICOM vào kiến trúc web/cloud hiện đại.

Ngữ cảnh VN: Một viewer chạy trên trình duyệt có thể gọi `GET /studies?PatientID={cccd}` (QIDO-RS) để liệt kê study của bệnh nhân, sau đó WADO-RS để load DICOM frame.

Đánh giá tác động xử lý dữ liệu cá nhân là hồ sơ mô tả hoạt động xử lý và rủi ro. Luật 91/2025/QH15 và NĐ 356/2025/NĐ-CP phân công trách nhiệm theo vai trò, với Báo cáo Mẫu số 10 và các trường hợp/miễn trừ áp dụng; không mặc định một hồ sơ mới cho từng API.

Ngữ cảnh VN: Khi bổ sung FHIR server hoặc tích hợp VNeID, đơn vị đối chiếu hoạt động mới với hồ sơ hiện có và cập nhật hoặc lập hồ sơ theo vai trò, phạm vi và điều kiện pháp lý thực tế.

Data Protection Officer — cách gọi phổ biến cho bộ phận hoặc nhân sự bảo vệ dữ liệu. Nghĩa vụ bố trí áp dụng chung theo Luật 91/2025/QH15 Điều 33 khoản 2; ngoại lệ hẹp tại Điều 38 khoản 2–3 không áp dụng cho tổ chức trực tiếp xử lý dữ liệu nhạy cảm như cơ sở KCB. Điều kiện nhân sự theo NĐ 356/2025/NĐ-CP Điều 13–16.

Ngữ cảnh VN: Không có quy tắc chung chỉ dựa trên hạng bệnh viện và không mặc định DPO phải ký mọi DPIA. Đơn vị cần xác định mô hình chịu trách nhiệm và đầu mối theo hoạt động xử lý cụ thể.

Trạng thái ballot HL7 cũ, áp dụng cho các tiêu chuẩn đã qua bước thử nghiệm cộng đồng nhưng chưa Normative. Từ 2017, HL7 đổi tên thành STU (Standard for Trial Use). FHIR DSTU1 ra mắt 30/9/2014, DSTU2 năm 2015, sau đó STU3 (2017), R4 (2019), R5 (2023).

Ngữ cảnh VN: Khi đọc tài liệu cũ, "FHIR DSTU2" tương đương "FHIR STU2"; cả hai đều ám chỉ phiên bản Mar 2015 — version đã được R4 thay thế.

Mã danh mục dịch vụ kỹ thuật do Bộ Y tế ban hành, hiện theo Thông tư 23/2024/TT-BYT (có hiệu lực 18/10/2024, thay TT 43/2013/TT-BYT và TT 21/2017/TT-BYT). Mỗi DVKT có mã, tên, đơn giá, phân loại theo chuyên khoa.

Ngữ cảnh VN: Trong FHIR Claim của VN Core, `Claim.item.productOrService` ánh xạ vào DVKT codes; ví dụ "Siêu âm tổng quát ổ bụng" có mã DVKT cụ thể trong TT 23/2024/TT-BYT.

Ngôn ngữ truy vấn của SNOMED CT, cho phép viết biểu thức ràng buộc concept theo quan hệ phân cấp và thuộc tính. ECL được dùng để định nghĩa subset (intensional ValueSet) trong FHIR.

Ngữ cảnh VN: Biểu thức `<< 73211009 |Diabetes mellitus|` chọn mọi concept là loại của "Đái tháo đường" — dùng làm filter trong ValueSet `vn-diabetes-vs`.

Electronic Health Record — hồ sơ y tế tổng hợp xuyên suốt cuộc đời bệnh nhân, kết hợp dữ liệu từ nhiều cơ sở khám chữa bệnh và chuyên khoa. Khác với EMR (chỉ trong một cơ sở), EHR mang tính liên thông.

Ngữ cảnh VN: Sổ Sức khỏe điện tử trên VNeID (Quyết định 1332/QĐ-BYT) là một dạng EHR cấp quốc gia, tổng hợp dữ liệu khám chữa bệnh của công dân từ nhiều bệnh viện.

Electronic Medical Record — bản số hóa bệnh án trong phạm vi một cơ sở khám chữa bệnh. Bao gồm tiền sử, chẩn đoán, kết quả cận lâm sàng, đơn thuốc và biểu mẫu điều dưỡng. Thông tư 13/2025/TT-BYT đặt mốc 30/9/2025 cho bệnh viện và 31/12/2026 cho cơ sở KCB khác.

Ngữ cảnh VN: FHIR document Bundle là một phương án kỹ thuật để trao đổi hồ sơ; TT 13/2025/TT-BYT không tự thân bắt buộc cơ sở xuất Bundle FHIR lên VNeID. Định dạng và endpoint phải theo đặc tả liên thông được cơ quan có thẩm quyền công bố.

FHIR Resource biểu diễn một lượt tương tác giữa bệnh nhân với cơ sở KCB — khám ngoại trú, nhập viện, cấp cứu, hội chẩn từ xa. Encounter có thời điểm bắt đầu/kết thúc, loại, lý do, người tham gia (Practitioner), địa điểm.

Ngữ cảnh VN: Trong VN Core Encounter, Extension `tuyenKCB` ghi nhận đúng tuyến / trái tuyến / thông tuyến — chính sách chi trả BHYT theo Nghị định 188/2025/NĐ-CP.

FHIR Resource trả lời chi tiết của đơn vị bảo hiểm cho một Claim: phần được duyệt, phần từ chối, lý do từ chối, số tiền chi trả, đồng chi trả của bệnh nhân.

Ngữ cảnh VN: Khi BHXH Việt Nam phản hồi yêu cầu thanh toán theo Quyết định 697/QĐ-BYT (mẫu bảng kê 12 danh mục), dữ liệu trả về có thể được map sang ExplanationOfBenefit.

Cơ chế của FHIR cho phép thêm field vào base Resource hoặc DataType mà không phá vỡ tính liên thông. Mỗi Extension có canonical URL riêng, definition (StructureDefinition), và context cho biết áp dụng được vào đâu.

Ngữ cảnh VN: VN Core định nghĩa Extension `vn-ext-ethnicity` (54 dân tộc) áp dụng cho Patient. URL canonical: `http://fhir.hl7.org.vn/core/StructureDefinition/vn-ext-ethnicity`.

Tiêu chuẩn của HL7 cho trao đổi dữ liệu y tế điện tử. FHIR thường được triển khai qua REST + JSON, nhưng cũng hỗ trợ XML, Turtle, và các pattern phi-REST như messaging, documents, services. Mỗi loại dữ liệu được mô hình hóa thành Resource có URL riêng.

Ngữ cảnh VN: VN Core IG dựa trên FHIR R4 (4.0.1, công bố 2019). Canonical URL của VN Core: `http://fhir.hl7.org.vn/core/`.

Path expression language để điều hướng và truy vấn trong instance FHIR, tương tự XPath cho XML. Dùng cho invariant (rule kiểm tra), search parameter, slicing discriminator, và CDS Hooks.

Ngữ cảnh VN: Biểu thức `Patient.identifier.where(system = 'http://fhir.hl7.org.vn/core/sid/cccd').value` lấy ra số CCCD của bệnh nhân.

Mô hình đánh giá độ trưởng thành của artifact FHIR theo thang 0-5. FMM và Standards Status là hai trục riêng: Normative, Trial Use, Draft hoặc Informative không phải “bậc tiếp theo” sau FMM 5. FMM phản ánh bằng chứng triển khai, kiểm thử và mức ổn định theo quy trình HL7.

Ngữ cảnh VN: Khi đánh giá một Resource cho VN Core, đọc cả FMM lẫn Standards Status của đúng phiên bản FHIR; không suy ra Normative chỉ từ một mức FMM cao.

Domain-specific language để viết Profile, Extension, ValueSet, Example… ngắn gọn hơn so với JSON/XML thô. FSH được biên dịch thành StructureDefinition JSON bằng SUSHI. Là công cụ chuẩn để xây IG.

Ngữ cảnh VN: VN Core IG được viết bằng FSH trong thư mục `input/fsh/`. Ví dụ: `Profile: VNCorePatient` + ràng buộc `* identifier 1..* MS` siết cardinality.

FHIR Resource biểu diễn output từ một dịch vụ Clinical Decision Support, ví dụ kết quả của một CDS Hook hoặc một AI inference. Chứa decision (status), recommendation, evidence, và provenance.

Ngữ cảnh VN: Khi bác sĩ đặt y lệnh chỉ định CT có cản quang, CDS service có thể trả GuidanceResponse cảnh báo nguy cơ suy thận dựa trên creatinine gần nhất từ Observation.

Implementation Java mã nguồn mở của FHIR (server + client + data layer), do Smile CDR/UHN duy trì. Là FHIR server được triển khai phổ biến nhất trong nghiên cứu, prototype và một số production lớn.

Ngữ cảnh VN: Một POC FHIR điển hình có thể khởi đầu với HAPI FHIR server vì miễn phí, có tài liệu phong phú và dễ chạy sandbox nội bộ.

Hạ tầng cho phép chia sẻ dữ liệu y tế giữa nhiều tổ chức — bệnh viện, phòng khám, nhà thuốc, bảo hiểm. HIE thường gồm patient registry, document registry, terminology service, và chính sách bảo mật.

Ngữ cảnh VN: Sổ Sức khỏe điện tử trên VNeID là một dạng HIE cấp quốc gia. Nghị định 278/2025/NĐ-CP quy định kết nối, chia sẻ dữ liệu bắt buộc, mốc 31/12/2026 cho chuẩn hóa.

Tổ chức tiêu chuẩn dữ liệu y tế quốc tế, thành lập 1987, trụ sở Ann Arbor (Michigan, Hoa Kỳ). "Level 7" tham chiếu lớp Application trong mô hình OSI. HL7 ban hành các tiêu chuẩn v2, v3, CDA, FHIR và CDS Hooks.

Ngữ cảnh VN: HL7 International có hệ thống Affiliate quốc gia. Omi HealthTech đang chuẩn bị nền tảng kỹ thuật và hồ sơ governance cho lộ trình HL7 Affiliate Việt Nam khi đủ điều kiện.

Hệ thống phân loại bệnh tật của WHO. Việt Nam ban hành phiên bản Việt hóa theo Quyết định 4469/QĐ-BYT (28/10/2020), được bổ sung mã COVID-19 (U07.1, U07.2) qua Quyết định 98/QĐ-BYT (14/01/2022).

Ngữ cảnh VN: `vn-icd10-cs` trên public IG có `content = not-present`; bộ mã đầy đủ nằm ở download surface. `VNCoreCondition.code` là bắt buộc nhưng binding với `vn-condition-code-vs` ở mức extensible, và ICD-10 coding dùng system chuẩn `http://hl7.org/fhir/sid/icd-10`.

Gói tài liệu chuẩn hóa cho một use case hoặc một quốc gia, gồm: Profile, Extension, ValueSet/CodeSystem, Example, narrative pages, CapabilityStatement. IG được publish dưới dạng package npm và website tĩnh.

Ngữ cảnh VN: VN Core IG (id `hl7.fhir.vn.core`) là Implementation Guide cho ngữ cảnh y tế Việt Nam, do Omi HealthTech khởi xướng và công bố tại fhir.hl7.org.vn.

Consortium quốc tế ban hành Profile tích hợp dựa trên các tiêu chuẩn nền (HL7, DICOM, W3C). Mỗi Profile (XDS, PIX, ATNA, MHD…) mô tả cách phối hợp nhiều chuẩn để giải quyết một workflow cụ thể.

Ngữ cảnh VN: MHD là một nguồn tham chiếu cho document sharing bằng FHIR khi các bên chọn đúng actor, transaction, option và version. Chỉ kiểm thử conformance đầu-cuối mới chứng minh khả năng tương tác trong phạm vi đã thử.

IG quốc tế của HL7 cho bản tóm tắt bệnh nhân tối thiểu, dùng cho trao đổi xuyên biên giới. IPS định nghĩa Composition gồm các section bắt buộc: dị ứng, thuốc đang dùng, vấn đề lâm sàng, và một số section khuyến nghị.

Ngữ cảnh VN: IPS có thể được đánh giá như mẫu Patient Summary; không mặc định sinh từ VNeID. Chỉ dùng khi dataset/contract cho phép và instance được validate với đúng package, version và terminology.

Bộ mã cho xét nghiệm, observation lâm sàng và document type, do Regenstrief Institute duy trì theo giấy phép LOINC. Trong FHIR, chỉ dùng LOINC cho `Observation.code` khi binding, use case và hệ thống nhận yêu cầu hoặc chấp nhận đúng mã/version.

Ngữ cảnh VN: Mã LOINC `718-7` (Hemoglobin [Mass/volume]) được dùng trong Observation kết quả công thức máu, kết hợp với UCUM unit `g/dL`.

Profile IHE cho trao đổi tài liệu qua FHIR. Bản R4 sử dụng các profile trên `DocumentReference`, `List`, `Bundle` và `Binary`; SubmissionSet/Folder được mô hình bằng `List`, không phải `DocumentManifest`. MHD không phải bản thay thế một-một cho XDS.

Ngữ cảnh VN: Chọn MHD cho một Sổ SKĐT chỉ khi contract yêu cầu đúng actor, transaction, option và version; thêm PDF/JPEG không tự tạo conformance MHD.

Giao thức transport TCP cho HL7 v2 messaging. Mỗi message v2 được bọc trong khung `<VT>...message...<FS><CR>` và gửi qua một socket TCP. Đến nay vẫn được dùng phổ biến trong tích hợp HIS-LIS-PACS.

Ngữ cảnh VN: Một interface HIS–máy xét nghiệm có thể dùng MLLP + HL7 v2 ORU^R01 khi thiết bị hỗ trợ. TLS, VPN hoặc kiểm soát tương đương phải theo threat model và security contract; Luật không tự chỉ định TLS cho mọi kết nối MLLP.

Cờ trên element của Profile. Khi gắn `MS`, Implementation Guide bắt buộc phải định nghĩa rõ "support có ý nghĩa" nghĩa là gì — có thể là phải đọc, phải ghi, phải hiển thị, hoặc kết hợp. MS không tự động đồng nghĩa với cardinality và không tự động yêu cầu cả đọc lẫn ghi; profile/IG là nơi quy định chi tiết.

Ngữ cảnh VN: VN Core Patient có `identifier MS` và phần narrative giải thích: server FHIR ở VN phải đọc/lưu được CCCD; client phải hiển thị CCCD trên UI bệnh án.

FHIR Resource đăng ký các URI dùng làm `system` cho Identifier (CCCD, BHYT, BHXH, MRN, hộ chiếu…). NamingSystem giúp các bên thống nhất cách phân biệt định danh từ các authority khác nhau.

Ngữ cảnh VN: VN Core v0.9.0 publish 36 artifact NamingSystem, bao quát định danh công dân, bảo hiểm, cơ sở/nhân lực y tế, tài liệu, giao dịch và endpoint tích hợp. Nhóm định danh lõi gồm CCCD, CMND, BHXH, BHYT, mã CSKCB, CCHN, hộ chiếu, MRN và giấy khai sinh. URI mẫu: `http://fhir.hl7.org.vn/core/sid/cccd`.

Một Standards Status của HL7 với quy tắc quản lý thay đổi chặt chẽ nhằm bảo vệ tính tương thích ngược. Normative độc lập với FMM và không bảo đảm rằng mọi chi tiết sẽ bất biến trong mọi phiên bản sau.

Ngữ cảnh VN: Khi nâng VN Core sang release FHIR khác, vẫn phải đánh giá chênh lệch và package dependency dù Resource gốc có Standards Status = Normative.

Authorization framework của IETF (RFC 6749); OAuth 2.0 không tự là authentication. SMART App Launch profile hóa OAuth/OIDC cho các use case FHIR, nhưng một FHIR endpoint có thể dùng cơ chế khác nếu IG và security contract cho phép.

Ngữ cảnh VN: PKCE áp dụng cho các client/flow tương ứng theo profile OAuth/SMART đã chọn. Luật 91/2025/QH15 và NĐ 356/2025/NĐ-CP không tự bắt buộc OAuth, PKCE hay refresh token cho mọi FHIR server.

FHIR Resource biểu diễn lỗi, cảnh báo hoặc thông tin xử lý qua danh sách `issue` với severity, code và diagnostics. FHIR khuyến nghị trả OperationOutcome cho lỗi ở tầng FHIR, nhưng không bắt buộc mọi response 4xx/5xx đều có body này; lỗi proxy, xác thực hoặc hạ tầng có thể rỗng hay dùng định dạng khác.

Ngữ cảnh VN: Khi Patient không đạt VN Core, server có thể trả mã HTTP phù hợp với interaction và hợp đồng API kèm OperationOutcome chỉ ra phần tử vi phạm; client vẫn phải xử lý an toàn nếu không có OperationOutcome.

Hai Profile của IHE cho identity management: PIX ánh xạ định danh bệnh nhân giữa các domain, còn PDQ truy vấn thông tin demographic theo identifier. Bản FHIR-native là IHE PIXm và PDQm. Việc áp dụng các profile này cho VNeID hoặc Sổ SKĐT hiện chỉ là kiến trúc tham chiếu, không phải API prescription khi chưa có đặc tả API công khai.

Ngữ cảnh VN: Một kiến trúc tương lai có thể dùng PIXm để liên kết MRN nội bộ với số định danh cá nhân và PDQm để truy vấn demographic, nhưng chỉ khi đặc tả chính thức của dịch vụ quốc gia quy định các endpoint và profile tương ứng.

StructureDefinition derive từ một Resource hoặc DataType cơ sở, thêm các ràng buộc: cardinality, terminology binding, slicing, MS flag, invariant. Profile không tạo Resource mới, chỉ thu hẹp cách dùng base Resource.

Ngữ cảnh VN: VNCorePatient (id `vn-core-patient`, canonical `http://fhir.hl7.org.vn/core/StructureDefinition/vn-core-patient`) derive từ FHIR Patient, thêm slicing cho CCCD/BHYT/MRN và extension dân tộc. Địa chỉ dùng VNCoreAddress với extension mã tỉnh và xã/phường.

FHIR Resource ghi nhận nguồn gốc và hoạt động tạo, sửa hoặc biến đổi Resource: tác nhân, thời điểm, thực thể nguồn và chữ ký nếu có. Provenance không tự tạo audit log đầy đủ, chống chối bỏ hay hiệu lực pháp lý; các thuộc tính đó còn phụ thuộc cơ chế ký, chứng thư, dữ liệu được ký và kiểm soát vận hành.

Ngữ cảnh VN: Khi quy trình yêu cầu chữ ký điện tử, `Provenance.signature` có thể mang chữ ký và metadata liên quan; hệ thống vẫn phải xác minh chữ ký và đáp ứng chính sách pháp lý áp dụng.

Ba mốc phiên bản cần phân biệt. R4 (4.0.1, công bố 2019) là baseline của VN Core, hỗn hợp Normative + STU và gồm 146 Resource. R5 (5.0.0, công bố 03/2023) là major release mới nhất đã publish và vẫn thuộc Trial Use. R6 hiện là bản CI/ballot, chưa phải release ổn định.

Ngữ cảnh VN: VN Core sushi-config đặt `fhirVersion: 4.0.1`. Việc phát hành VN Core trên phiên bản khác chỉ nên thực hiện sau khi đánh giá tương thích IG đích, package dependency, validator và endpoint.

Đơn vị dữ liệu cốt lõi trong FHIR — mỗi loại dữ liệu y tế (Patient, Encounter, Observation, MedicationRequest…) là một Resource type riêng. FHIR R4 có 146 Resource type. Các interaction REST như GET, POST, PUT và DELETE chỉ khả dụng khi endpoint khai báo hỗ trợ trong CapabilityStatement.

Ngữ cảnh VN: `GET https://fhir.bv.vn/Patient/12345` trả về một Patient resource dạng JSON, với Resource.id = "12345" và Resource.meta.versionId tăng theo mỗi lần update.

Phong cách kiến trúc cho web API, do Roy Fielding mô tả trong luận án 2000. Đặc trưng: stateless, resource-oriented, dùng HTTP verbs (GET/POST/PUT/DELETE), URL biểu diễn tài nguyên. FHIR REST API là cách triển khai phổ biến nhất của FHIR.

Ngữ cảnh VN: FHIR REST API: `GET /Patient?identifier=cccd|012345678901` để tìm bệnh nhân theo CCCD. Server trả Bundle (searchset) chứa các Patient match.

Mô hình thông tin nền tảng của HL7 v3, mô tả 6 lớp gốc (Act, Entity, Role, Participation, RoleLink, ActRelationship) và mọi message v3 đều derive từ đó. RIM cực kỳ trừu tượng, là một phần lý do v3 ít được triển khai.

Ngữ cảnh VN: Mặc dù FHIR không trực tiếp dùng RIM, một số Resource (Encounter, Observation) vẫn mượn khái niệm Act-Participation để mô hình hóa hành động và người tham gia.

Định nghĩa cách truy vấn một Resource theo các trường nhất định: name, identifier, date, _id, _lastUpdated. Mỗi Resource có search parameter chuẩn, IG có thể publish thêm parameter riêng cho ngữ cảnh nội địa.

Ngữ cảnh VN: VN Core có thể publish search parameter `cccd` cho Patient để cho phép `GET /Patient?cccd=012345678901` thay vì syntax phức tạp `identifier=http://fhir.hl7.org.vn/core/sid/cccd|012345678901`.

Cơ chế của Profile để chia một array element thành nhiều "slice" theo discriminator (giá trị hoặc pattern phân biệt). Mỗi slice có cardinality và ràng buộc riêng.

Ngữ cảnh VN: VNCorePatient v0.9.0 slice `identifier` bằng discriminator `#pattern` tại path `type`: CCCD `1..1 MS`, BHYT `0..1 MS`, MRN `0..* MS`. MRN dùng URI `system` riêng theo từng cơ sở; slice CCCD có thể mang `data-absent-reason` trong trường hợp ngoại lệ hợp lệ.

Tiêu chuẩn HL7 cho launch các app y tế (EHR-launched, standalone) trên một FHIR server, dùng OAuth 2.0 + OpenID Connect + scope đặc thù y tế (`patient/Observation.read`, `user/*.read`). Foundation cho hệ sinh thái app FHIR.

Ngữ cảnh VN: Khi triển khai app điện thoại tra cứu Sổ SKĐT VNeID cho bệnh nhân, SMART on FHIR là pattern chuẩn để app đăng nhập bằng VNeID và đọc Patient/Observation từ FHIR server quốc gia (mô hình tham chiếu — chờ spec chính thức).

Bộ thuật ngữ lâm sàng lớn nhất thế giới do SNOMED International quản lý, có khoảng 350.000 concept với cấu trúc phân cấp đa trục. Việt Nam đang xây dựng SNOMED CT VN qua các Quyết định 2427/QĐ-BYT (Body Structure), 2493/QĐ-BYT (Morphologic Abnormality), 2805/QĐ-BYT (Allergy + Finding) năm 2025.

Ngữ cảnh VN: Concept SNOMED CT `38341003 |Hypertensive disorder, systemic arterial|` được dịch sang tiếng Việt và publish trong CodeSystem `vn-snomed-cs` thuộc QĐ 2805/QĐ-BYT.

Terminology server mã nguồn mở cho SNOMED CT, phát triển bởi SNOMED International, dựa trên Elasticsearch. Hỗ trợ ECL, FHIR Terminology Service ($lookup, $expand, $validate-code).

Ngữ cảnh VN: Khi xây dựng terminology service quốc gia, Snowstorm có thể được host nội địa, load SNOMED CT VN + ICD-10 VN + DVKT, expose qua FHIR Terminology Service cho mọi HIS truy vấn.

Trình biên dịch FSH thành StructureDefinition / ValueSet / CodeSystem JSON. SUSHI viết bằng TypeScript, chạy qua Node.js. Là build tool tiêu chuẩn de facto cho mọi FHIR IG hiện đại.

Ngữ cảnh VN: Quy trình build VN Core: viết FSH trong `input/fsh/` → chạy `sushi .` để biên dịch ra JSON → chạy IG Publisher để render website tĩnh.

FHIR Resource định nghĩa schema của một Resource type, DataType, Profile, hoặc Extension. Là metadata nền tảng — IG về bản chất là một bộ StructureDefinition cộng với ValueSet, CodeSystem và narrative.

Ngữ cảnh VN: Mọi Profile (VNCorePatient, VNCoreEncounter…) và Extension (vn-ext-ethnicity, vn-ext-bhyt-card-type…) trong VN Core đều là StructureDefinition.

Bộ mã chuẩn dùng để đảm bảo tính nhất quán và máy đọc được — bao gồm CodeSystem (định nghĩa code) và ValueSet (subset code dùng cho một field cụ thể). Terminology là cốt lõi của semantic interoperability trong FHIR.

Ngữ cảnh VN: VN Core terminology gồm: ICD-10 VN, SNOMED CT VN, LOINC, UCUM, DVKT (TT 23/2024/TT-BYT), 54 dân tộc, 34 đơn vị hành chính theo NQ 202/2025/QH15.

Bộ mã chuẩn cho đơn vị đo lường trong y tế và khoa học, do Regenstrief Institute duy trì. Base FHIR Quantity không bắt buộc UCUM; profile hoặc Implementation Guide có thể yêu cầu hay khuyến nghị UCUM để hỗ trợ kiểm tra và chuyển đổi đơn vị.

Ngữ cảnh VN: Observation glucose có thể dùng `{ value: 5.5, unit: "mmol/L", system: "http://unitsofmeasure.org", code: "mmol/L" }`. Chỉ chuyển đổi sau khi kiểm tra đúng đại lượng, ngữ cảnh xét nghiệm và quy tắc profile; UCUM không tự bảo đảm mọi phép đổi là hợp lệ lâm sàng.

FHIR Resource định nghĩa một tập con code lấy từ một hoặc nhiều CodeSystem, dùng để bind vào một element. ValueSet có thể extensional (liệt kê code trực tiếp) hoặc intensional (định nghĩa filter, ECL).

Ngữ cảnh VN: VN Core ValueSet `vn-ethnicity-vs` chọn toàn bộ 54 concept từ CodeSystem `vn-ethnicity-cs`. Bind vào Patient.extension.ethnicity với binding strength = required.

Ứng dụng định danh điện tử quốc gia của Việt Nam, do Bộ Công an quản lý. VNeID tích hợp CCCD, BHXH/BHYT, GPLX, Sổ Sức khỏe điện tử (Quyết định 1332/QĐ-BYT). Là kênh chính để công dân tương tác với các dịch vụ công số.

Ngữ cảnh VN: Điều 1 khoản 3 TT 13/2025/TT-BYT yêu cầu kết nối thông tin bệnh án điện tử với số định danh cá nhân của công dân Việt Nam và của người nước ngoài đã được cấp tài khoản định danh điện tử. Điều này không tự quy định API, định dạng hoặc luồng đồng bộ VNeID.

Profile của IHE cho document sharing xuyên tổ chức, dùng ebXML Registry Information Model và web services. XDS Affinity Domain gồm các actor như Document Source, Document Repository, Document Registry và Document Consumer. MHD cung cấp giao diện dựa trên FHIR cho một tập use case document-sharing, nhưng không thay thế toàn bộ XDS/XCA.

Ngữ cảnh VN: Dự án phải chọn XDS, MHD hoặc mô hình FHIR-native theo use case, hạ tầng hiện hữu và yêu cầu conformance; không có lộ trình mặc định áp dụng cho Việt Nam.

Định dạng XML do Bộ Y tế ban hành cho dữ liệu đầu ra phục vụ Bảo hiểm Xã hội. QĐ 4210/QĐ-BYT là văn bản gốc đã được thay thế bằng QĐ 130/QĐ-BYT (2023); QĐ 130/QĐ-BYT sau đó được sửa đổi qua QĐ 4750/QĐ-BYT (2023) và QĐ 3176/QĐ-BYT (2024). Tên gọi "XML 4210" vẫn được dùng quen thuộc trong cộng đồng dù chain văn bản đã chuyển.

Ngữ cảnh VN: Khi xây đặc tả chuyển đổi XML hiện hành sang FHIR Claim/EOB, tham chiếu là chuỗi QĐ 130/QĐ-BYT, QĐ 4750/QĐ-BYT và QĐ 3176/QĐ-BYT, không chỉ QĐ 4210/QĐ-BYT gốc.