Làm Chủ Kiểu Dữ Liệu FHIR: Từ Nền Tảng Đến Chuyên Sâu Cho BA, PM Và Kỹ Sư Y Tế Số
Trong các dự án triển khai chuẩn FHIR (Fast Healthcare Interoperability Resources), Business Analyst, Product Manager và đội kỹ thuật thường gặp khoảng cách “ngôn ngữ” – đặc biệt khi trao đổi về dữ liệu. Hiểu đúng và thống nhất về datatype không chỉ giúp rút ngắn vòng lặp phát triển, mà còn là nền tảng để tích hợp hệ thống y tế an toàn, mạch lạc.
1. Bốn Viên Gạch Căn Bản Của Dữ Liệu FHIR
STRING – Chuỗi ký tự
Định nghĩa: Văn bản nằm trong ngoặc kép, chứa tên, chẩn đoán, ghi chú.
Ví dụ: “Maria Garcia”, “Type 2 Diabetes”
Ứng dụng: Lưu tên bệnh nhân, tên thuốc, ghi chú bác sĩ.
NUMBER – Giá trị số
Định nghĩa: Dữ liệu số, không có ngoặc kép.
Ví dụ: 65 (tuổi), 120 (huyết áp), 98.6 (nhiệt độ)
Ứng dụng: Phân tích chỉ số, cảnh báo, chấm điểm rủi ro.
ARRAY – Danh sách giá trị
Định nghĩa: Danh sách liên quan, đặt trong dấu [].
Ví dụ: [“Penicillin”, “Shellfish”, “Latex”]
Ứng dụng: Dị ứng, bệnh nền, thuốc đang dùng, lịch sử khám.
OBJECT – Đối tượng cấu trúc
Định nghĩa: Hồ sơ nhiều trường, dạng cặp tên-giá trị; có thể lồng các kiểu dữ liệu khác.
Ví dụ:
Một profile gồm họ tên (string), tuổi (number), địa chỉ (string), dị ứng (array).Ứng dụng: Chính là cấu trúc của mọi resource trong FHIR như Patient, Observation, Encounter.
2. Lý Do BA/PM Nên Thành Thạo Kiểu Dữ Liệu
Cụ thể hóa yêu cầu, giảm hiểu nhầm: “Cần tên bệnh nhân (string), tuổi (number), dị ứng (array)” thay vì chỉ “thông tin bệnh nhân”.
Tối ưu vòng đời phát triển: Đầu vào rõ ràng giúp backend mapping FHIR resources nhanh, giảm lỗi, tránh code lại.
Kết nối đội lâm sàng & kỹ thuật: Giúp developer dễ coding, test, BA/PM validate dễ dàng, project tiết kiệm thời gian.
3. Góc Nhìn Chuyên Sâu: Phân Tích Kỹ Thuật Về Datatype Trong FHIR
Khi bước vào triển khai thực tế hoặc tích hợp đa hệ thống, đòi hỏi kỹ sư phải hiểu sâu từng kiểu dữ liệu, constraint, cũng như best practice chuẩn quốc tế.
A. KIỂU DỮ LIỆU PRIMITIVE
string: Unicode (giới hạn dài tùy ngữ cảnh), loại bỏ control char.
boolean: True/False, dùng cho trạng thái, cờ.
integer, decimal: Số nguyên, số thực; kiểm soát min/max.
date, dateTime, instant: ISO-8601, chú ý time zone.
B. KIỂU PHỨC HỢP (COMPLEX TYPES)
HumanName: Họ, tên, prefix, dùng cho đa dạng các nền văn hóa.
Address: Nhiều trường cho line, city, postalCode, country.
ContactPoint: Loại liên hệ (điện thoại, email…), dùng regex kiểm định.
Quantity: Gồm value, đơn vị (UCUM) – cần truy xuất nguồn chuẩn hệ đơn vị.
Coding & CodeableConcept: Lưu nhiều code/terminology (ICD-10, SNOMED-CT…), hỗ trợ interoperability.
Reference: Kết nối resource khác (vd: Observation.reference tới Patient/123).
C. ARRAY & CARDINALITY
Hầu hết trường có thể là array. Cardinality xác định min/max phần tử, required/optional, uniqueness.
Xử lý array lồng object phức hợp (như allergies, medications) là kỹ năng bắt buộc với dev FHIR.
D. CONSTRAINT, VALIDATION, TERMINOLOGY
Đa số kiểu dữ liệu đều có constraint: regex cho string, value set cho code, min/max, binding với terminology (radLex, loinc, ICD-10).
Thực triển khai phải mapping chặt chẽ giữa yêu cầu nghiệp vụ và các constraint này trong schema.
E. EXTENSION & CUSTOM STRUCTURE
Không mở rộng tùy tiện (custom field), chỉ dùng extension khi thực sự thiếu field chuẩn.
Document đầy đủ schema, constraint, logic mapping để bảo toàn khả năng liên thông lâu dài.
4. Ví Dụ Mapping Thực Tế
Yêu cầu nghiệp vụ: “Lưu thông tin dị ứng và cân nặng của bệnh nhân”
allergyIntolerance(array objects): code (CodeableConcept), onsetDateTime (dateTime)weight(Observation): valueQuantity (value, unit, system)
FHIR JSON:
json
{
"resourceType": "Patient",
"name": [{ "family": "Tran", "given": ["Bao"] }],
"allergyIntolerance": [
{ "code": { "coding": [{ "system": "http://snomed.info/sct", "code": "91936005", "display": "Dị ứng penicillin" }] }, "onsetDateTime": "2015-04-12" }
]
}
json
{
"resourceType": "Observation",
"subject": { "reference": "Patient/123" },
"code": { "coding": [{ "system": "http://loinc.org", "code": "29463-7", "display": "Body Weight" }] },
"valueQuantity": { "value": 60.5, "unit": "kg", "system": "http://unitsofmeasure.org", "code": "kg" }
}
5. Tổng Kết – Thực Hành Vững Vàng, Tích Hợp Dễ Dàng
BA/PM: Định hình yêu cầu rõ ràng với các datatype chuẩn, mô tả logic mapping tới FHIR resource.
Dev/Integration: Mapping đúng kiểu dữ liệu, kiểm soát constraint, validation, cardinality từ đầu.
Tất cả cùng hợp tác: Giao tiếp nhất quán, giảm rủi ro dự án, tăng khả năng liên thông và chất lượng cấu trúc dữ liệu y tế số.
Bạn đang gặp khó khăn về datatype, terminology hay extension trong FHIR? Đặt câu hỏi hoặc chia sẻ trải nghiệm thực tế để được hỗ trợ sâu hơn!
Trải nghiệm miễn phí
💡 Đặc biệt: Chúng tôi cung cấp chương trình dùng thử miễn phí 3 tháng dành cho các bệnh viện, phòng khám tại Việt Nam! Đây là cơ hội tuyệt vời để bạn trải nghiệm toàn bộ tính năng của VR-PACS mà không cần lo lắng về chi phí ban đầu.
📌 Hãy liên hệ ngay hôm nay để khám phá cách VR-PACS có thể thay đổi cách vận hành của bệnh viện bạn:
Website: https://phanthanh.id.vn / https://plm.id.vn
Facebook: https://www.facebook.com/thanhpacs
LinkedIn: https://www.linkedin.com/in/thanhpacs
Gọi ngay: +84 976-099-099 hoặc email: lpthanh.plm@gmail.com
Experienced in Healthcare IT, I specialize in implementing and optimizing PACS, HIS/RIS, and HL7-FHIR interoperability to enhance efficiency and patient care. My expertise includes:
✔ PACS Solutions – Streamlining medical image storage, communication, and integration with HIS/RIS & HL7-FHIR systems – Ensuring seamless data exchange across healthcare systems.
Passionate about digital transformation in healthcare, I help organizations improve connectivity and operations. Let’s connect!
Luu Phan Thanh (Tyler) Solutions Consultant at PACS Ecosystem Mobile +84 976 099 099
Web www.plm.id.vn Email tyler.luu@plm.id.vn / lpthanh.plm@gmail.com