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 participate in several paradigms: RESTful API, Documents, Messaging, or Operations/Services. Whether a Patient can be read through REST, packaged in a Document, or used in a message depends on the paradigm and contract implemented by the system.

FHIR is published under CC0. The newest published base specification is R5 (5.0.0), which is labelled Trial Use; artifacts that were already Normative in R4 retain that status. VN Core uses R4 (4.0.1) as its base for compatibility with the R4 toolchain and reference material; for example, the current US Core 9.0.0 line remains R4-based.

The word "Fast" reflects a design goal of shorter specification-feedback cycles and reuse of familiar REST/JSON skills. Implementation still requires teams to learn the Resource model, Profiles, terminology, security, and use-case workflows.

2. Why FHIR? Context after HL7 v2/v3

To understand FHIR's design context, 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 and remains present in many long-running HIS/LIS integrations. Actual prevalence varies by market and vendor. V2 deployments commonly need message profiles and bilateral agreements to resolve segment, field, and transport differences.

HL7 v3 (early 2000s) uses the Reference Information Model (RIM) and XML to provide a more formal model. It has a higher learning and implementation cost, but remains in use in specific programs and products; CDA also developed from the v3 foundation.

FHIR took an implementation-oriented approach: use REST + JSON familiar to web developers, keep common elements in Resources, and handle local requirements through governed extensions. The specification includes examples; open-source implementations such as HAPI FHIR and public sandboxes support experimentation. FHIR also underpins many interoperability requirements and Implementation Guides, including regulations in the United States.

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

FHIR defines a REST model and interactions such as read, create, update, delete, and search. A server is not required to support every Resource or interaction: its actual scope must be declared in a CapabilityStatement. The specification 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

When supported by the endpoint, POST can create, GET can read or search, PUT can update, and DELETE can remove. HTTP status codes and OperationOutcome depend on the interaction and processing result. Clients must inspect the CapabilityStatement and test the contract rather than infer full CRUD support from the base specification.

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)

FHIR defines representations of a Resource in JSON, XML, and Turtle/RDF. They are designed to carry the same FHIR content, but implementations must still validate conversions, extensions, and out-of-spec data rather than assume every round trip is lossless.

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).

A Profile remains derived from its base Resource. A base-FHIR client may parse base elements, but it must handle extensions and modifierExtension under the safety rules; this does not automatically establish conformance or semantic interoperability with VN Core.

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). The example uses FHIR R4 syntax; full conformance validation requires the VN Core package and its dependencies to be loaded by the server or validator.

{
  "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 asserts the profile the instance is intended to satisfy; it is not proof of conformance. A validator must still check the payload against the exact vn-core-patient canonical and version.
• 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.
• CodeableConcept.text is optional; a profile or implementation guide may require it when a Vietnamese display must be preserved alongside coding.
• 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:

An implementation normally selects the Resources required by its use case and applicable IG, such as Patient, Encounter, Observation, or MedicationRequest. There is no universal core count for every EMR; the supported set must be published in the CapabilityStatement.

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 groups entries in one payload; R4 defines nine 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.
• transaction-response — the result of a transaction.
• batch — non-atomic; each entry is independent.
• batch-response — the result of a batch.
• history — version history for a single Resource.
• searchset — search results.
• collection — entries without transaction, document, or message semantics.

Vietnam trial example: a visit containing Encounter + Condition + Procedure + MedicationRequest + Observation may be packaged as a transaction Bundle when the endpoint declares that interaction and each entry conforms to the applicable IG.

8. FHIR versions (DSTU1 → R5) and why VN Core uses R4

R4 is a mature implementation baseline and was the first release to include Normative material, which is governed by stricter inter-version change rules. R5 (5.0.0, March 2023) is the newer published base specification, but its release cycle is labelled Trial Use. A project should therefore choose R4 or R5 from the applicable CapabilityStatements, IGs, and end-to-end compatibility evidence—not from the release number alone.

VN Core IG chose R4 to remain comparable with the 2024 VN Core repository, reuse a mature R4 ecosystem, and reduce coordination cost across implementers. Deriving or reusing a profile from another IG still requires checking the exact package, version, and dependency chain.

Details: FHIR Versions — DSTU1 to R5.

9. FHIR in Vietnam — VN Core IG

Two public sources in Vietnam must be distinguished by provenance and canonical URL:

• The repository github.com/hl7vn/vn-core-ig — its published repository/IG metadata names “Department of Information Technology - Ministry of Health” as publisher and http://fhir.ehealth.gov.vn/core/ as canonical URL. Those metadata fields identify publishing provenance and the technical namespace; by themselves they are not evidence that a competent authority has recognized the repository or its content as an official national standard.
• The hl7.org.vn trial-use initiative — VN Core IG, launched and developed openly by Omi HealthTech under a CC-BY-4.0 license. The canonical URL is http://fhir.hl7.org.vn/core/, and the goal is a trustworthy technical baseline before any formal governance route with the competent authorities.

The trial-use VN Core IG models Vietnam-specific needs that base FHIR does not cover out of the box: identifiers (national ID card / CCCD per the Identity Law, the 10-digit Vietnam Social Security / BHXH number, the current 10-digit BHYT number or the legacy 15-character BHYT card number, passports, and 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 reference use cases for referrals, BHYT payment, VNeID, and the personal health record. Actual integration remains subject to each target system's specification and governance.

Circular 13/2025/TT-BYT on electronic medical records, Law 91/2025/QH15 on Personal Data Protection, and Decree 356/2025/NĐ-CP establish requirements for EMRs, sensitive data, and data-protection governance; they do not mandate FHIR. The trial-use VN Core project is testing FHIR as an exchange layer, while BHYT and VNeID connections remain subject to each system's official data standard, API, and governance.

10. FHIR vs HL7 v2 — comparison table

There is no universal date for FHIR to replace HL7 v2. The standards may coexist while devices, vendors, or partners retain different dependencies. Each interface must select a standard from its use case, data contract, and endpoint capabilities; a parallel gateway is one transition option, not a mandatory model.

11. Frequently asked questions

Will FHIR replace HL7 v2?

There is no universal replacement timeline. Retaining, migrating, or running both depends on devices, partners, message profiles, target IGs, and test evidence. A gateway is one option for bridging v2 and FHIR, not a requirement for every system.

Is FHIR free?

Yes. The FHIR base specification is published under CC0. Products, terminology packages, and supporting libraries may carry separate licenses, so implementers must still review their dependencies.

Which FHIR server should I buy?

Common options include:

• Open-source self-hosted: HAPI FHIR (Java), Microsoft FHIR Server (OSS) (.NET), and Medplum (TypeScript, OSS plus a hosted cloud). Operations and support still require budgeting.
• 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?

Circular 13/2025/TT-BYT does not prescribe FHIR as a mandatory standard. A facility needs FHIR when its use case, partner, or applicable IG requires it; BHYT transactions currently remain on the legally prescribed data-output standard. A synthetic-data sandbox can evaluate Patient, Encounter, or Observation before production, but the scope must follow actual needs and capability.

R4 or R5 — which version should VN Core use?

VN Core currently uses R4. No R5 migration date has been approved; a future decision should follow package/profile impact analysis, participant capability checks, implementation evidence, and the release-governance process. A migration date should not be inferred solely from another country's IG roadmap.

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 — 145 Vietnamese health legal documents.