1. Why is it necessary to standardize medical data?
Imagine you go to hospital A for a check-up, are diagnosed with type 2 diabetes and prescribed medication. Next week, you go to hospital B for another reason. Doctors at hospital B cannot see your medical records at hospital A — because the two systems cannot "talk" to each other at all.
This is not a rare story. Actually, this is most common problem in the digital health industry globally. Each hospital and each clinic uses different software, stores data in different ways, and does not have a "common language" to exchange information.
What is interoperability?
Interoperability (interoperability) in healthcare is the ability of different healthcare information systems to:
- Data exchange (Exchange) — send and receive data between systems
- Understand the data (Interpret) — the receiving system can understand the correct meaning of the data
- Data usage (Use) — the data received can be used to support clinical decision making
There are 4 levels of Interoperability:
| Level | Name | Description | For example |
|---|---|---|---|
| 1 | Foundational | Send/receive data between 2 systems | Send PDF file of test results |
| 2 | Structural | Data has a uniform structure | Send test results as HL7 v2 message |
| 3 | Semantics | Both sides understand the same meaning | ICD-10 code "E11.9" is understood as "Type 2 diabetes mellitus" |
| 4 | Organizational | There are processes, policies, and legal support | The circular allows data sharing between hospitals |
Consequences of Lack of Interoperability
Repeat testing — the patient had to retake the test because the new hospital did not have the old results
Medical errors — The doctor does not know what medications the patient is allergic to or what medications he is taking
Costs increase — it is estimated that the US wastes $30 billion/year due to lack of interoperability
Delay treatment — have to wait for paper transfer documents
Medical research is limited — multicenter data cannot be aggregated
2. HL7 International — The organization behind the medical data standard
HL7 (Health Level Seven) International is a non-profit standards organization founded in 1987, headquartered in Ann Arbor, Michigan, USA. The name "Level Seven" refers to the 7th layer (Application Layer) in the OSI model — the layer where applications communicate with each other.
HL7 International has more 1,600 members more words 55 countries, including medical software vendors, hospitals, government organizations, insurance carriers, and research organizations.
HL7 standards have evolved
Over more than 35 years, HL7 has developed many data standards, each addressing the needs of the times:
3. HL7 Version 2 (v2) — The world's most popular standard
History
HL7 v2 was released first this year 1989 and quickly became the world's most popular medical data exchange standard. To date, est 95% of hospitals in the US and 35+ countries Use HL7 v2.
HL7 v2 Message structure
HL7 v2 uses a text format with pipe-delimited characters:
MSH|^~\&|HIS|BVBACHMAI|LIS|LABXN|202603301000||ADT^A01|MSG00001|P|2.5
EVN|A01|202603301000
PID|1||MRN12345^^^BVBACHMAI||NGUYEN^VAN^A||19850315|M|||123 Le Loi^^HCM^^700000^VN
PV1|1|I|W4B^401^1|||||||||||||||VN001|||||||||||||||||||||||||202603300800
Explanation:
MSH — Message Header: information about the message (source, destination, type, version)
EVN — Event: event that triggers the message (A01 = hospitalization)
PID — Patient Identification: patient information
PV1 — Patient Visit: information about visits/hospitalizations
Advantages and disadvantages
| Advantages | Disadvantages |
|---|---|
| Widely popular, well supported | Too many options, each implementation is different |
| Simple, lightweight | There is no strict model (each field can be used differently) |
| Millions of interfaces running | Backward compatibility complex (v2.1 → v2.9) |
| Many support tools (Mirth, Rhapsody) | Does not support web/REST natively |
4. HL7 Version 3 and Reference Information Model (RIM)
Ambition for radical standardization
Realizing the limitations of v2, HL7 began to develop v3 since the late 1990s with the ambition to create a unified, coherent data model for the entire healthcare sector.
At the heart of HL7 v3 is RIM (Reference Information Model) — an abstract object model that describes all concepts in healthcare:
Act — medical actions (examination, testing, prescription...)
Entity — entity (patient, doctor, drug, device...)
Role — role (patient, healthcare worker, provider...)
Participation — participate (who participates in which action)
ActRelationship — relationships between actions
RoleLink — relationships between roles
Issues with HL7 v3
Although v3/RIM is very tight in theory, in practice:
Too complicated — XML messages are cumbersome and difficult to implement
Difficult learning curve — need a deep understanding of RIM to be able to deploy
High cost — the time and resources to implement are huge
Low adoption — very few organizations have successfully deployed pure HL7 v3
5. CDA (Clinical Document Architecture)
CDA is the most successful HL7 v3 standard, widely used for clinical document exchange. CDA uses XML to structure medical documents, including:
Header — metadata (patient, author, institution, creation date)
Body — clinical content, possible at 3 levels:
- Level 1: non-structured body (PDF/text)
- Level 2: sections with narrative text
- Level 3: fully structured, coded entries
CDA is widely used in C-CDA (Consolidated CDA) in the US for Meaningful Use/Promoting Interoperability, and in many projects in Europe and Japan.
Limitations of CDA
Just fits document-based exchange (exchange documents)
Not supported data-level exchange (query each data field)
XML is complex, need to understand RIM
Does not support modern mobile/web apps
6. FHIR is born — the new "Fire" for interoperability
Origin
Year 2011, Grahame Grieve — one of HL7's most veteran developers — proposes a completely new approach. Instead of trying to model everything (like v3), he suggested:
"Build a set of simple, dynamically composable Resources, based on modern web technologies (REST, JSON, OAuth), and apply the 80/20 principle — solving 80% use-cases with 20% complexity."
Name FHIR (pronounced "fire") is an abbreviation for Fast Healthcare Interoperability Resources, reflecting the goals:
Fast — quick to implement, easy to learn
Healthcare — focuses on health
Interoperability — interoperability between systems
Resources — basic composable unit of data
Development milestones of FHIR
| Year | Version | Outstanding features |
|---|---|---|
| 2012 | DSTU 0 (Draft) | First test version |
| 2014 | DSTU 1 (R1) | First Draft Standard for Trial Use |
| 2015 | DSTU 2 (R2) | Adoptions began to increase sharply |
| 2017 | STU 3 (R3) | Standard for Trial Use, many new Resources |
| 2019 | R4 | Normative first — Patient, Observation, Bundle stable |
| 2020 | R4B | Small update of R4 |
| 2023 | R5 | Current version — Topic-based subscriptions, many improvements |
| ~2026+ | R6 | In development — AI/ML integration, improved Workflow |
Why is FHIR successful?
Based on web standards — REST, JSON, XML, OAuth 2.0, HTTP
Easy to implement — many developers have interfaces running in 1 day
Specifications are free — no license fee
Many libraries support — HAPI FHIR (Java), fhir.js, fhirclient.py, Firely (.NET)
Good extensibility — Extension mechanism allows extension without breaking the standard
Human-readable — each Resource has an HTML narrative section
Supports multiple paradigms — REST, Messaging, Documents, Services
Government required — US (ONC/CMS), Australia, UK, EU all have mandate
7. Compare HL7 standards
| Criteria | HL7 v2 | HL7 v3 | CDA | FHIR |
|---|---|---|---|---|
| Year of birth | 1989 | ~2000 | 2005 | 2014 |
| Format | Pipe-delimited text | XML | XML | JSON, XML, RDF |
| Data model | Implicit (loose) | RIM (strict) | RIM (document) | Resources (composable) |
| Paradigm | Messaging | Messaging | Document | REST + Messaging + Documents |
| Implementation complexity | Average | Very high | High | Low |
| Web/Mobile support | No | No | Limitations | Native |
| Adoption | Very high (legacy) | Low | Average | Increase quickly |
| Human-readable | No | No | Yes (narrative section) | Yes (resource narrative) |
8. FHIR globally — Who is using it?
United States
21st Century Cures Act (2020): Require EHR vendors to support FHIR API (US Core)
CMS Interoperability Rules: Require payers (insurance) to provide Patient Access API based on FHIR
ONC TEFCA: National Data Exchange Framework, FHIR is the foundation
Epic, Cerner (Oracle Health), Allscripts all have FHIR APIs
Europe
European Health Data Space (EHDS): EU Regulation uses FHIR for cross-border health data
International Patient Summary (IPS): Based on FHIR, allows international sharing of clinical summaries
Australia
AU Base Implementation Guide: Standard FHIR profile for the whole country
My Health Record: National health records system using FHIR
Vietnam
There is no official mandate on FHIR, but it is on the roadmap to digitize healthcare
Circular 54/2017/TT-BYT regulating medical data interoperability standards (FHIR not yet used)
Circular 46/2018/TT-BYT on electronic medical records
Several pioneering projects are testing FHIR
Great opportunity for building Vietnam FHIR Implementation Guide
9. Basic FHIR concepts you need to know first
Before diving into the next articles, let's get familiar with some important terms:
| Terminology | Explanation | For example |
|---|---|---|
| Resource | Basic unit of data in FHIR | Patient, Observation, Encounter |
| Data Type | The data type used in Resources | HumanName, Address, CodeableConcept |
| Extension | How to add custom data to Resource | Add the "ethnicity" field to Patient |
| Profile | Bind Resources to specific use cases | US Core Patient Profile |
| Terminology | Medical code system | ICD-10, SNOMED CT, LOINC |
| Bundle | Gather many Resources | Search results, transactions |
| Reference | Links between Resources | Observation.subject → Patient/123 |
| Implementation Guide | Context-specific FHIR implementation guidance | US Core IG, IPS IG |
10. Summary
In this article, we learned:
Interoperability is the biggest challenge in digital health, including 4 levels
HL7 International is a leading medical standards organization, operating since 1987
HL7 v2 Most popular but lacks consistency
HL7 v3/RIM Tight but too complicated
CDA successful for document exchange but limited for data-level access
FHIR Combines all the advantages, based on web standards, easy to implement
FHIR R5 is the current version, R4 standard is the most used stable version
Many countries have required Using FHIR, Vietnam is on the roadmap
Next article, we will go deeper FHIR R5 architecture — understand Resources, Data Types, Extensibility, and core design principles.