FHIR R4 explained for ministries of health: what to require
FHIR (Fast Healthcare Interoperability Resources) is the HL7 International standard for exchanging health information as small, defined units called resources through a web API. Release 4, published in 2019, was the first release with normative content, which is why ministries specify FHIR R4 when they need systems that will still exchange data reliably in ten years. For a national programme, FHIR matters less as a technology than as a contract: it fixes how patient, encounter, laboratory and medication data leave one system and arrive in another.
A ministry of health rarely buys one system. It inherits laboratory systems, pharmacy systems, a national reporting platform, donor funded programme tools and, increasingly, hospital and clinic records. The question that decides whether these investments add up to a health information system is whether they can exchange data without a custom interface for every pair. FHIR is the standard most programmes now use to answer that question. This guide explains what FHIR is, what Release 4 changed, the two companion specifications that matter most to ministries (SMART App Launch and Bulk Data Access), and what to write into a tender.
What FHIR is, in plain terms
The FHIR specification describes resources as "the common building blocks for all exchanges" [1]. Each resource type represents one healthcare entity, such as a Patient, an Encounter, an Observation or a MedicationRequest. Every resource has a web address, common metadata, a human readable summary, defined data elements and a framework for extensions [1]. Release 4 defines 145 resource types, up from 49 in the first draft published in 2013 [1][3].
Four characteristics explain why FHIR spread faster than earlier health standards:
- A web API. FHIR defines a small set of interactions (create, read, update, delete, search, history, transaction and operation) that map directly to ordinary HTTP methods and URL patterns [1]. Any developer who has built a web service can read it.
- Familiar formats. Resources are represented in JSON, XML or RDF, always in UTF 8 encoding [1].
- More than one way to exchange. Beyond the API, groups of resources can be exchanged as documents, as messages or through services [1]. A discharge summary, a laboratory order and a referral can all use the same building blocks.
- Controlled variation. Because health practice varies between countries and organisations, FHIR provides an extensibility framework and profiles, which define richer or more specific content on top of the base resources [1]. This is where national decisions are recorded.
Why Release 4 is the version to specify
FHIR was published in successive drafts before it carried normative content. The United States Office of the National Coordinator for Health IT (ONC) summarises the history as follows [3].
| Release | Year | Status and significance |
|---|---|---|
| DSTU1 | 2013 | First publication, 49 resources |
| DSTU2 | 2015 | Wider market acceptance |
| STU3 | 2017 | Standard for trial use |
| R4 | 2019 | First release with normative content |
| R5 | Later | Now supersedes R4 in the specification; R4 remains the release major programmes reference |
In R4 the RESTful API, the JSON and XML formats, the Patient and Observation resources and nine further resources became normative [3]. ONC explains that normative content is content accepted by the American National Standards Institute as an American National Standard [3]. The R4 table of contents marks which parts are normative and which remain trial use, and notes that version 5.0.0 now supersedes it [2].
For a ministry, the practical reading is straightforward. R4 is the release on which major programmes have settled: the 2020 ONC final rule under the 21st Century Cures Act made FHIR R4 the standard required for health IT certification in the United States [3], and the International Patient Summary implementation guide is built on R4 [10]. Specifying R4 aligns a national procurement with the largest body of tested implementations, tools and trained developers.
Where FHIR sits in national digital health strategy
The WHO Global strategy on digital health 2020 to 2025 asks Member States to define a national digital health architecture blueprint or road map, and to develop or adapt a set of open health data standards for digital health interventions [9]. It treats syntactic and semantic interoperability, built on WHO norms and standards, as a cornerstone of health information [9].
In July 2023 WHO and HL7 International signed a project collaboration agreement to support the adoption of open interoperability standards globally [7]. WHO describes FHIR as an open, API based data exchange standard and a principal standard for person centred digital solutions [7]. The agreement's objectives include building capacity in Member States, making WHO guidance available as globally applicable specifications that can be adapted locally, and supporting the WHO Family of International Classifications within the FHIR community [7].
Three pieces of international work now depend on FHIR:
- WHO SMART Guidelines. WHO publishes its recommendations in layers. Layer 2 is a Digital Adaptation Kit (data dictionary, decision support logic, indicators and requirements) and layer 3 is a FHIR implementation guide [8]. A system that speaks FHIR can consume these guides as they are released.
- The International Patient Summary. The IPS is an extract of essential health information designed to support unplanned and cross border care. Its dataset is deliberately minimal rather than exhaustive, and independent of specialty and condition [10]. It is specified in EN 17269 and ISO 27269 and expressed in FHIR [10].
- OpenHIE. The OpenHIE architecture describes the data exchange workflows of a national health information exchange. It names IHE profiles as the building blocks of those workflows and FHIR resources as part of the standards picture [13]. The architecture is covered in more depth in building a national health information system on routine care.
Profiles: where national decisions are made
Base FHIR resources are intentionally generic. A Patient resource can carry any identifier; an Observation can carry any code. Interoperability in a country depends on the profiles that narrow these choices: which identifier system is the national one, which code system describes a laboratory test, which facility list is authoritative.
Research in Nigeria shows why this work comes first. A team designing FHIR profiles for maternal and child health referrals in Ebonyi State surveyed 24 frontline doctors, midwives and nurses and reviewed the paper referral forms in use. They identified 27 data sets and found many different data elements on the forms and in survey responses, even in urban settings [12]. The profile they built mapped those elements to the FHIR Patient resource, added extensions for missing elements and used ICD 10 for terminology [12]. The lesson for a ministry is that FHIR exchanges whatever content is agreed; it does not agree the content.
A national FHIR profile set should settle at least the following.
| Decision | FHIR resource | Typical national choice |
|---|---|---|
| Who the patient is | Patient | National health identifier plus facility numbers |
| Where care happened | Organization, Location | Codes from the national facility registry |
| Type of contact | Encounter | Outpatient, inpatient, emergency, community |
| Diagnoses | Condition | ICD 10 or ICD 11, with SNOMED CT where licensed |
| Laboratory results | Observation, DiagnosticReport | LOINC codes for tests |
| Medicines | MedicationRequest | National essential medicines list codes |
| Permission to share | Consent | National consent policy |
The terminology choices in this table are explained in clinical terminologies: ICD, SNOMED CT and LOINC, and identifier strategy in master patient index and unique health identifiers.
SMART on FHIR: admitting approved applications safely
The SMART App Launch implementation guide, published by HL7, defines how a user facing application is authorised to connect to a FHIR server [4]. It can pass launch context, such as the patient currently open in the record, so that the application opens on the right patient without a second search [4]. It is built on OAuth 2.0 [4].
Permissions are expressed as scopes. A scope such as user/Encounter.rs allows an application to read and search the encounters that the authorising user may already access, and nothing more [4]. A separate pattern, Backend Services, covers automated clients where no user is directly involved and permissions are assigned in advance by the system owner [4].
For a ministry this has three consequences:
- New tools, such as a programme dashboard or a specialist calculator, can be added to the record without a bespoke integration for each one.
- An application sees only what the signed in clinician is permitted to see, so role based access in the record continues to apply.
- Authorisation is a published standard, so security review can be performed against a known specification rather than a vendor's private design.
Bulk FHIR: population level data without spreadsheets
Ministries need data about populations, not one patient at a time. The FHIR Bulk Data Access implementation guide defines an asynchronous way for an authorised client to request large datasets [5]. Exports can be requested at three levels: the whole system, all patients, or a defined group of patients such as a cohort or a facility's register [5]. Servers must support newline delimited JSON, all exchanges must use TLS 1.2 or later, and implementers are encouraged to authorise clients through SMART Backend Services [5]. The guide names server backup among its uses [5].
HL7 began work on the bulk API in 2017, published the first implementation guide in 2019 and a second version in 2021 [6]. Under the Cures Act rule, certified systems in the United States must provide standardised export of large quantities of health information as specified in that guide [6].
Bulk export gives a ministry three things it often lacks: a standard route for analytics and research extracts, a standard route for migration when systems change, and assurance that its data can be retrieved in a documented format rather than through a supplier's proprietary tool.
What FHIR does not do
FHIR is necessary for a modern national architecture; it is not sufficient. Four limits should be understood before a tender is written.
- It does not replace HL7 v2 overnight. A systematic review of 80 FHIR implementation studies concluded that FHIR might take years or decades to replace legacy standards [11]. Laboratory analysers and hospital interfaces will continue to use HL7 v2 messaging for some time; the relationship is explained in HL7 v2, FHIR, DICOM and IHE: which standard does what.
- It does not supply the vocabulary. FHIR carries codes; ICD, LOINC and SNOMED CT supply them.
- It does not settle governance. The WHO strategy calls for national data governance mechanisms and a legal base that protects privacy, confidentiality, integrity and availability of data [9]. FHIR can enforce access rules; it cannot write them.
- A claim is not conformance. HL7's maturity model considers a resource mature when it is in use in at least five distinct production systems in at least two countries [3]. "FHIR compliant" in a proposal should be tested against the ministry's own profiles before contract award.
How Moana approaches FHIR
Moana is built around one patient record that is shared across the Moana EHR, MOANA Desktop workspaces for doctors, nurses, pharmacy, laboratory, radiology and administration, MOANA Mobile and the patient portal. FHIR R4 is the external language of that record, so a ministry's systems receive clinical data in the structure the standard defines rather than in a Moana specific format.
Three capabilities follow directly from the sections above:
- SMART on FHIR app launch. Approved applications can be launched from inside the record with the patient already in context, governed by the same role based access and audit log that apply to every clinician.
- FHIR bulk export. A ministry or authorised research body can export population level data at system, patient or group level for analytics, research and migration, under the access rules the ministry sets.
- Standards beneath the resources. Diagnoses can be coded in ICD 10 and ICD 11, laboratory tests in LOINC and clinical concepts in SNOMED CT, with production use of SNOMED CT subject to the country's affiliate licence. Aggregate indicators are reported into DHIS2 as the national reporting platform.
Moana also exchanges HL7 v2 messages with hospital systems and integrates with laboratory analysers and instruments, because a national architecture has to work with the systems already installed. Imaging is handled in DICOM through MOANA PACS.
The principle behind these choices is that the organisation that collects the data owns it. Standard exchange and standard export are how that principle is made real: a ministry should never need its supplier's permission to move its own data. The full set of standards is described on the interoperability page, and national use on the national systems page.
Key questions for procurement
Should a tender specify FHIR R4 or R5?
Most ministries should specify R4 as the required release, because it carries the first normative content and is the release referenced by the largest national and international programmes [3][10]. A tender can ask suppliers to state their plan for later releases without making R5 a requirement.
Is "FHIR compliant" enough as a requirement?
No. Require conformance to named profiles: the ministry's own national profiles where they exist, and international guides such as the International Patient Summary where they do not. Ask for a capability statement and test it against those profiles before award.
What is the difference between SMART on FHIR and FHIR itself?
FHIR defines the data and the API. SMART App Launch defines how an application is authorised to use that API on behalf of a user, using OAuth 2.0 and scopes [4]. A ministry that wants to add tools to the record over time should require both.
Why does bulk export matter if the system already produces reports?
Reports answer questions that were defined in advance. Bulk export lets the ministry ask new questions, run research and migrate data, using a documented format and authorisation pattern [5][6]. It is also the clearest technical guarantee that the ministry can retrieve its data.
Does FHIR replace the national reporting platform?
No. FHIR moves patient level data between systems. Aggregate indicators are still reported to the national platform, which in many countries is DHIS2. The two work together when indicators are calculated from coded patient level records.
Sources
- FHIR R4 overview for developers, HL7 International, 2019
- FHIR Release 4 table of contents and standards status, HL7 International, 2019
- FHIR Version History Fact Sheet, Office of the National Coordinator for Health IT, 2021
- SMART App Launch implementation guide, STU 2.2, HL7 International, 2024
- Bulk Data Access implementation guide, export specification, HL7 International, 2020
- ONC supports adoption and implementation of bulk data APIs, Office of the National Coordinator for Health IT, 2023
- WHO and HL7 collaborate to support adoption of open interoperability standards, World Health Organization, 2023
- WHO SMART Guidelines, World Health Organization, accessed 2026
- Global strategy on digital health 2020 to 2025, World Health Organization, 2021
- International Patient Summary implementation guide, HL7 International, accessed 2026
- The FHIR standard: systematic literature review of implementations, applications, challenges and opportunities, JMIR Medical Informatics, 2021
- Standardising primary health care referral data sets in Nigeria: practitioners' survey, form reviews and FHIR profiling, JMIR Formative Research, 2022
- OpenHIE Architecture Specification, OpenHIE, accessed 2026
