HL7 FHIR R4: the first Normative release and the race to interoperability

AIHealth

On-premise clinical platform with local LLMs, RAG on FHIR/DICOM data, diagnostic support, remote follow-up. Architecture designed for the MDR pathway.

Discover AIHealth →

Digital Health

Medical software development compliant with CE and MDR regulatory standards. Clinical decision support systems, AI integration in clinical workflows.

Discover →

From “Trial Use” to “Normative”

Almost five years after the publication of DSTU 1, HL7 released on 30 December 2018 the Release 4 of FHIR — version 4.0.0 of the standard. Four intermediate steps — DSTU 1, DSTU 2, STU 3 — allowed feedback collection, backward-incompatible changes where necessary, and consolidation of the more stable parts.

R4 is the first release that introduces the concept of Normative content: for a set of resources and infrastructural components, HL7 takes an explicit commitment to backward compatibility within the R4 family and in future releases. This is a qualitative difference from the previous DSTU/STU releases: anyone building on a Normative component has a technical base that will not be broken unilaterally.

What is Normative in R4

The Normative set at R4’s debut includes the base infrastructure — Resource, Extension, primitive data types, XML/JSON representation conventions — and the full REST API (read, vread, update, patch, delete, history, create, search, capabilities, transaction, batch).

Among the clinical resources, some of the most central move to Normative status in R4:

• Patient — patient demographics
• Observation — clinical observations (measurements, findings, laboratory reports, vital signs)
• Encounter — clinical contacts (visits, admissions, teleconsultations)
• Condition — diagnoses and problems
• Practitioner, Organization, Location
• AllergyIntolerance
• DiagnosticReport
• Medication, MedicationRequest, MedicationStatement

The rest of the content — about 60% of resources — remains in Trial Use (STU) status, with explicit maturity-level signalling per resource (Maturity Level 0-5, FMM).

SMART on FHIR

Alongside the stabilisation of R4, the FHIR stack has been enriched with specifications that standardise typical application scenarios. The most relevant is SMART on FHIR — Substitutable Medical Applications, Reusable Technologies — an initiative of the Boston Children’s Hospital and Harvard Medical School groups led by Josh Mandel and Ken Mandl.

SMART defines an authentication and authorisation profile based on OAuth 2.0 and OpenID Connect, enabling a third-party application (“SMART app”) to access a patient’s or professional’s FHIR data in a controlled way:

• SMART App Launch Framework — handshake sequence for launching the app from within an EHR context (EHR launch) or from a patient portal (standalone launch)
• Granular scopes — patient/Observation.read, user/*.read, launch/patient, offline_access
• OpenID Connect for user identity
• Support for backend services with client credential grant (SMART Backend Services, relevant for large data access)

SMART is today the reference authorisation mechanism for clinical apps consuming FHIR; the main US EHR vendors (Epic, Cerner, Allscripts) expose certified SMART on FHIR endpoints.

CDS Hooks

Where SMART on FHIR solves “how the app accesses the data”, CDS Hooks — specification v1.0 published in 2018 — solves “how the EHR interfaces with external decision support services”. The model:

• The EHR exposes hooks (patient-view, medication-prescribe, order-sign, order-select) that fire at specific points in the clinical flow
• Remote CDS Services (hosted by vendors, payers, research institutions) receive a FHIR context and return Cards (textual recommendations, suggestions, links to SMART apps)
• The EHR integrates the Cards into the user interface, keeping the clinician at the centre of the decision

CDS Hooks thus completes an ecosystem in which FHIR data become the entry point for distributed clinical decision support logic, without each EHR needing to host its own rule engine.

Bulk Data Access

Another piece in development at the time of R4 is FHIR Bulk Data Access (Flat FHIR): a specification for the asynchronous export of large volumes of FHIR data, typically for analytics and research. The output format is NDJSON (newline-delimited JSON), with an asynchronous $export endpoint and a polling mechanism for retrieval. The specification is in STU status at R4, but in practice many server implementations already support it.

Bulk Data is FHIR’s answer to the need for data lakes and analytical pipelines: rather than querying millions of resources one by one via REST, one exports a snapshot at a date and processes it offline.

US Core, Argonaut and US regulatory push

Adoption of FHIR R4 in the United States is accelerated by a specific regulatory factor. The 21st Century Cures Act of 2016 has tasked ONC (Office of the National Coordinator for Health IT) with defining interoperability requirements for Certified Health IT. In February 2019 ONC published a Notice of Proposed Rulemaking proposing FHIR R4 as the required standard for certified EHR APIs, referencing USCDI (United States Core Data for Interoperability) as the minimum clinical dataset.

Final adoption is expected over 2019/2020. If confirmed, it will make FHIR R4 the de facto healthcare exchange standard in the US, with pull-through effects also on non-US markets. The work of the Argonaut Project — a consortium launched in December 2014 among EHR vendors and healthcare organisations — paved the way with agreed profiles, which have flowed into the US Core Implementation Guide.

Open source implementations

The implementation ecosystem is by now broad and mature:

• HAPI FHIR (James Agnew, University Health Network) — remains the Java reference implementation. The 4.x version is already available with full R4 support, including JPA server, client, validator, terminology server
• Firely .NET SDK — .NET library maintained by Firely (formerly Furore, Netherlands), heir to fhir-net-api; Firely also distributes Vonk Server (commercial with open components)
• Microsoft FHIR Server for Azure — .NET Core-based open source server, released in October 2018 on GitHub under the MIT licence, with PostgreSQL and Cosmos DB backend support
• IBM FHIR Server — open source server also released in October 2018, Java, Apache 2.0 licence
• Google Cloud Healthcare API — not open source, but exposes conformant FHIR R4 APIs as a managed service
• HL7 FHIR Validator command line — official validation tool

The simultaneous presence of Microsoft, IBM and Google with FHIR offerings is an indicator of the direction of the cloud market for healthcare.

What this means in Europe

In Europe the picture is more fragmented. At Union level there is no 2019 equivalent of the 21st Century Cures Act; the eHealth directives work on cross-border scope with their own profiles (eHDSI uses CDA R2 for patient summary and e-prescription, with FHIR evolution under discussion). Individual Member States move at different speeds: UK with NHS Digital Care Connect based on FHIR STU3, Germany with gematik and the gemSpec specification, Nordic countries with FHIR profiles for national interoperability.

In Italy FHIR adoption as of 2019 is exploratory. HL7 Italia has set up working groups on Italian FHIR profiles, but there are no national Implementation Guides yet published with the status of official reference documents. The FSE remains anchored to CDA R2; the reflection on adopting FHIR for the second-generation FSE is under way but awaits policy decisions.

What changes

With R4 FHIR leaves the experimentation phase and becomes a technical stack on which to build production systems with multi-year horizons. The triple mechanism — stable REST resources + SMART on FHIR for authorisation + CDS Hooks for external workflow — composes a model of interoperability that is not only document exchange but application integration: an external app can read the patient’s clinical state, propose actions, record decisions, return to the EHR without the EHR having to know that app in advance.

It is a paradigm shift that in medicine has implications well beyond technology, onto the ways clinical software is built, certified and updated. Next steps will concern the maturation of national Implementation Guides in Europe, integration with Member States’ digital identity mechanisms, and the evolution of the regulatory role — with MDR and the impending European reflection on AI in healthcare intertwined with platform technical choices.

References: HL7 FHIR Release 4 (30 December 2018). SMART App Launch Framework, Boston Children’s Hospital / Harvard Medical School. CDS Hooks 1.0. FHIR Bulk Data Access STU. US Core Implementation Guide. HAPI FHIR, Firely, Microsoft FHIR Server for Azure, IBM FHIR Server. ONC Notice of Proposed Rulemaking, February 2019.