What is FHIR? The modern healthcare data exchange standard

1. What is FHIR? Quick definition

FHIR stands for Fast Healthcare Interoperability Resources — the healthcare data exchange standard developed by HL7 (Health Level Seven International). The DSTU1 release (Draft Standard for Trial Use) shipped on 30/09/2014. Grahame Grieve started the project, building on his "Resources for Health" prototype from 2011.

Rather than defining a proprietary file format, FHIR describes the healthcare data model as independent Resources that can be exchanged through several paradigms: RESTful API (most common), Documents (similar to CDA), Messaging (similar to HL7 v2), or Operations/Services. The same Patient resource can be fetched via REST, attached inside a Document, or sent through a message — same schema, same semantics throughout.

FHIR is published under an HL7 license that allows free use (FHIR® License plus some CC0 content). The current spec is R4 (4.0.1), released in October 2019 — the first version with "Normative" content (Patient, Observation, and several core Resources are stable and cannot have breaking changes), while the rest remains STU (Standard for Trial Use). VN Core IG, US Core, JP Core, KR Core, and AU Core all use R4 as the baseline.

The word "Fast" in the name has two meanings: fast spec development (short release cycles, frequent feedback from implementers) and fast implementation (web developers already know REST/JSON, so there's no new model to learn from scratch).

2. Why FHIR? Context after HL7 v2/v3

To understand why FHIR took off, it helps to look at the two prior generations of HL7 standards.

HL7 v2 (V2.0 released September 1988) is a pipe-delimited messaging standard. It still runs on most HIS/LIS systems worldwide. The downsides: the syntax is hard to debug (everything is strings of | and ^), the schema is loose so each vendor interprets it differently, and the default transport (MLLP over TCP on the local network) doesn't fit web, mobile, or cloud environments.

HL7 v3 (early 2000s) tried to fix v2's weaknesses with the rigorous Reference Information Model (RIM) and XML encoding. The problem: a steep learning curve, heavyweight XML, and very limited adoption outside a handful of countries (notably the UK NHS with CDA).

FHIR took the opposite approach: use REST + JSON, the stack every web developer already knows, and apply the "80% rule" — core Resources cover 80% of use cases and the remaining 20% are handled through extensions. The spec is concise, has examples, ships with a reference server (HAPI FHIR), and offers a public sandbox for developers to try immediately. The result: just five years after DSTU1, FHIR became a mandate in the U.S. ONC Cures Act and the backbone of nearly every new national IG.

3. The name "FHIR" — pronunciation and meaning

FHIR is pronounced "fire" /faɪər/ — like the English word for flame. Don't spell it out as "F-H-I-R". HL7 picked an orange-red brand color for FHIR to match the "fire" metaphor — hot, fast-spreading, energetic.

Each of the four letters carries technical meaning:

• Fast — fast development and fast implementation.
• Healthcare — focused on the healthcare domain, not general purpose.
• Interoperability — the core goal: connecting systems together.
• Resources — the unit of data, inspired by the "resource" concept in REST architecture.

4. FHIR's four design pillars

4.1. REST + HTTP (the most common paradigm)

FHIR defines a standard RESTful API for every Resource. This is the most common deployment style, although the spec also supports Documents, Messaging, and Operations.

# Read a Patient
curl -H "Accept: application/fhir+json" \
     https://hapi.fhir.org/baseR4/Patient/example

# Search
curl -H "Accept: application/fhir+json" \
     "https://hapi.fhir.org/baseR4/Patient?family=Nguyen&given=Lan"

# Create
curl -X POST -H "Content-Type: application/fhir+json" \
     -d @patient.json \
     https://hapi.fhir.org/baseR4/Patient

Standard CRUD: POST to create, GET to read, PUT to update, DELETE to remove, and GET with a query string to search. Standard HTTP status codes (200/201/404/410/422) apply. If you've built REST APIs before, the FHIR API will feel familiar.

4.2. Modular Resources

R4 has 146 Resources. Each is an independent type of healthcare data — Patient for the patient, Observation for lab results and vital signs, Encounter for a visit, MedicationRequest for a prescription, and so on. Every Resource has a StructureDefinition describing its schema and a canonical URL such as http://hl7.org/fhir/StructureDefinition/Patient.

Think of it as LEGO: you assemble Resources via references (Encounter.subject points to Patient, Observation.encounter points to Encounter, etc.) to describe a complete clinical episode.

4.3. Multiple formats (JSON / XML / Turtle)

The same Resource can be serialized as JSON (most common, used for web and mobile), XML (for backward compatibility with HL7 v3 and IHE XDS), or Turtle/RDF (for semantic web and medical research). The spec guarantees lossless round-trips between formats.

4.4. Profile + Extension (controlled extensibility)

This is the key to FHIR being both globally standardized and locally adaptable. A Profile adds constraints to a base Resource (for example, VN Core Patient marks CCCD as Must Support and slices identifiers by type). An Extension is a new field that base FHIR doesn't have (for example, vn-ext-bhyt-card for BHYT card information, or vn-ext-ethnicity for the 54 Vietnamese ethnic groups).

The golden rule: a profile must still validate as the base Resource. A client that doesn't know VN Core can still read the basic Patient — it just won't understand the Vietnamese extensions. Backward compatibility is guaranteed.

Go deeper: Profiling and Implementation Guide.

5. What does a Resource look like?

Below is a Patient under VN Core IG, with a Vietnamese name, the Kinh ethnicity, and a national ID card (CCCD). This sample satisfies the VNCorePatient profile constraints (CCCD identifier slice, ethnicity expressed as valueCodeableConcept) and is copy-paste runnable on any FHIR R4 server.

{
  "resourceType": "Patient",
  "id": "vn-001",
  "meta": {
    "profile": [
      "http://fhir.hl7.org.vn/core/StructureDefinition/vn-core-patient"
    ]
  },
  "extension": [
    {
      "url": "http://fhir.hl7.org.vn/core/StructureDefinition/vn-ext-ethnicity",
      "valueCodeableConcept": {
        "coding": [
          {
            "system": "http://fhir.hl7.org.vn/core/CodeSystem/vn-ethnicity-cs",
            "code": "01",
            "display": "Kinh"
          }
        ],
        "text": "Kinh"
      }
    }
  ],
  "identifier": [
    {
      "use": "official",
      "type": {
        "coding": [
          {
            "system": "http://fhir.hl7.org.vn/core/CodeSystem/vn-identifier-type-cs",
            "code": "CCCD",
            "display": "Căn cước công dân"
          }
        ],
        "text": "Căn cước công dân"
      },
      "system": "http://fhir.hl7.org.vn/core/sid/cccd",
      "value": "001234567890"
    }
  ],
  "name": [
    {
      "use": "official",
      "family": "Nguyễn",
      "given": ["Thị", "Lan"]
    }
  ],
  "gender": "female",
  "birthDate": "1985-03-15",
  "address": [
    {
      "use": "home",
      "city": "Hà Nội",
      "country": "VN"
    }
  ]
}

A few things worth noticing:

• meta.profile declares that this instance conforms to vn-core-patient, so a server can validate it strictly.
• identifier.system uses the URI http://fhir.hl7.org.vn/core/sid/cccd as defined by the VN Core NamingSystem (not a NamingSystem/... URL).
• The ethnicity Extension uses valueCodeableConcept (not valueCoding) — required by VNCoreExtEthnicity — and the CodeSystem ID has the -cs suffix.
• Every CodeableConcept includes a text field to preserve the Vietnamese display when a terminology server can't resolve the code.
• JSON is UTF-8 — names with diacritics like "Nguyễn" are stored directly, no escaping needed.

6. 146 Resources in FHIR R4 — by category

FHIR R4 (4.0.1) defines 146 Resources, organized by HL7 into "modules" by domain. The table below groups them into six buckets that are easy to remember for newcomers:

You don't need to learn all 146 Resources. Most real EMR projects only use 15-25 core ones (Patient, Encounter, Condition, Observation, MedicationRequest, DiagnosticReport, ServiceRequest, Procedure, Practitioner, Organization, Location, Coverage, Claim, Bundle, DocumentReference, Composition, AllergyIntolerance, etc.).

Full table with use cases per Resource: FHIR Resources list.

7. Bundle — multiple Resources in one payload

In practice, a healthcare action often involves multiple Resources at once. Bundle is a special Resource for grouping other Resources into a single payload, with six types:

• document — a Composition plus related Resources (similar to a CDA document).
• message — a workflow event (similar to an HL7 v2 message).
• transaction — atomic; either everything succeeds or the whole bundle rolls back.
• batch — non-atomic; each entry is independent.
• history — version history for a single Resource.
• searchset — search results.

Vietnam use case (future target): a single visit including Encounter + Condition + Procedure + MedicationRequest + Observation can be packaged as a transaction Bundle and pushed to a central EMR or an internal gateway.

8. FHIR versions (DSTU1 → R5) and why R4 wins

R4 is the current production baseline for the FHIR ecosystem. It's the first version where HL7 stamped a portion of the spec as "Normative" — meaning Patient, Observation, and several foundation Resources are stable and will not see breaking changes. The rest of R4 remains STU (Standard for Trial Use). R5 (5.0.0, March 2023) has been published and is being adopted gradually, but most of the ecosystem (FHIR servers, national IGs, the HAPI library, SMART on FHIR apps) is still on R4 for stability.

VN Core IG chose R4 for the same reasons: maximum compatibility with US Core, JP Core, KR Core, and AU Core; HAPI FHIR and Microsoft FHIR Server both ship production-ready R4 servers; and the SUSHI/IG Publisher toolchain is solid for R4.

Details: FHIR Versions — DSTU1 to R5.

9. FHIR in Vietnam — VN Core IG

Vietnam's FHIR localization work runs on two parallel tracks:

• The original repository github.com/hl7vn/vn-core-ig — initiated in 2024 by staff at the Department of Information Technology (Ministry of Health), with canonical URL http://fhir.ehealth.gov.vn/core/. It contains 8 base profiles (Patient, Practitioner, Encounter, ServiceRequest, Specimen, Location, HealthcareDepartment, CodeableConcept). The repository currently has 9 commits, was last updated in July 2024, and has not yet attracted broad community contribution.
• The hl7.org.vn community initiative — VN Core IG, launched and developed openly by Omi HealthTech (OmiGroup) under a CC-BY-4.0 license. The canonical URL is http://fhir.hl7.org.vn/core/, and the goal is comprehensive completion before pursuing official endorsement by state regulators.

The current VN Core IG addresses Vietnam-specific needs that base FHIR doesn't cover out of the box: identifiers (national ID card / CCCD per the Identity Law, the 10-digit Vietnam Social Security / BHXH number, the 15-character BHYT health insurance card, passports, internal MRNs); terminology (54 ethnic groups per the General Statistics Office, ICD-10 VN per Decision 4469/QĐ-BYT, the administrative division catalog of 34 provinces after Resolution 202/2025/QH15); and workflows (BHYT inter-tier referrals, payment under Decree 188/2025/NĐ-CP, integration with VNeID — Vietnam's national digital identification app — and the personal health record).

The main legal driver for FHIR adoption in Vietnam is Circular 13/2025/TT-BYT on electronic medical records (EMR), issued on 06/06/2025 and effective 21/07/2025, alongside Law 91/2025/QH15 on Personal Data Protection (effective 01/01/2026) and Decree 356/2025/NĐ-CP implementing it. The 2026-2027 goal is to build a FHIR-based interop layer connecting EMR + BHYT + VNeID.

10. FHIR vs HL7 v2 — comparison table

FHIR doesn't replace HL7 v2 overnight. Over the next 10-15 years, both standards will coexist: HL7 v2 in long-standing internal HIS/LIS integrations; FHIR for every new integration, especially cross-organization EMR, BHYT APIs, VNeID, mobile health apps, and AI/ML pipelines. Most hospitals will run both side-by-side through an interoperability gateway.

11. Frequently asked questions

Will FHIR replace HL7 v2?

Gradually, yes — over the next 10-15 years for new integrations. HL7 v2 still runs reliably across thousands of HIS/LIS systems globally, so a complete swap won't happen in the short term. The realistic model is a gateway that bridges both standards in parallel.

Is FHIR free?

Yes. The FHIR spec is published under an HL7 license that permits free use, and parts of it are CC0. You can implement, host servers, and sell software using FHIR without paying license fees to HL7.

Which FHIR server should I buy?

There are two clear groups:

• Open source self-hosted (free): HAPI FHIR (Java, the most common reference server), Microsoft FHIR Server (OSS) (.NET, open-sourced by Microsoft), and Medplum (TypeScript, OSS plus a hosted cloud).
• Managed services (paid): Google Cloud Healthcare API, Azure Health Data Services, and AWS HealthLake — billed by storage and request volume. They are not free and cannot be self-hosted.

Can FHIR store Vietnamese characters with diacritics?

Yes. JSON FHIR is UTF-8 by default, so "Nguyễn Thị Lan" stores directly without escaping. XML is also UTF-8. Vietnamese name, address, and display fields work fine as long as the server and client both use UTF-8.

Do district and commune-level hospitals need FHIR?

For purely internal use it's not yet mandatory. However, to integrate with BHYT (via the current data-output standard), with upper-tier hospitals through inter-tier referrals, with VNeID for the personal health record, and to comply with Circular 13/2025/TT-BYT on EMR (deadline 31/12/2026 for non-hospital healthcare facilities), it's wise to plan FHIR adoption now. Large facilities such as Bach Mai Hospital, Cho Ray Hospital, and provincial general hospitals have already piloted FHIR for cross-system EMR integration.

R4 or R5 — which version should VN Core use?

R4 for 2026-2028. R5 was only published in 03/2023 and the ecosystem isn't stable yet (HAPI FHIR R5, IG Publisher R5, and SMART on FHIR R5 are all new). An R4 → R5 migration can be considered after 2028 once the ecosystem matures and reference national IGs (US Core, JP Core) have moved as well.

12. Further reading

In the hl7.org.vn knowledge hub

Official sources

• FHIR R4 specification (4.0.1) — hl7.org/fhir/R4
• List of 146 Resources in R4
• FHIR Version History — DSTU1 30/09/2014
• FHIR R5 specification (5.0.0)
• HAPI FHIR public sandbox — free test server

Vietnamese legal documents

• Circular 13/2025/TT-BYT (06/06/2025) — Electronic medical records, effective 21/07/2025.
• Law 91/2025/QH15 (26/06/2025) — Personal Data Protection, effective 01/01/2026.
• Decree 356/2025/NĐ-CP (31/12/2025) — Implementation of the Personal Data Protection Law, effective 01/01/2026.
• Decision 3176/QĐ-BYT (29/10/2024) — Healthcare data-output standard for Vietnam Social Security.
• Resolution 202/2025/QH15 (12/06/2025) — Reorganization of administrative units to 34 provinces.
• Full reference: Legal Corpus — 57 Vietnamese health legal documents.