With FHIR Release 4, published by HL7 in late December 2018, for the first time part of the standard passes a Normative ballot and goes into submission to ANSI as a normative standard. The 4.0.0 build is dated 27 December; the announcement on the HL7 blog is from early January 2019. For anyone writing clinical software the news is not the new resources, but the fact that some parts of the standard now come with an explicit commitment not to break backward compatibility in the releases that follow.

Context

FHIR — Fast Healthcare Interoperability Resources — started in 2011 from HL7’s attempt to get around the practical limits of HL7 v2 and CDA (Clinical Document Architecture), moving the healthcare data model onto a REST API with JSON and XML representations. The releases up to here — DSTU 1 (2014), DSTU 2 (2015), STU 3 (2017) — were all Trial Use: good for implementing, but with the declared freedom to break compatibility at every step. Whoever had written a client against STU 2 knew they would have to touch the code to move to STU 3, and they did.

This is where R4 comes in. A specification that reworks itself at every release is fine for experimenting, much less so for systems that must stay in production for years in a domain — clinical software — where the software is rarely replaced and certification is costly.

What is Normative in R4

The Normative set at R4’s debut is narrow by design. It covers the base infrastructure and the API, not the bulk of the clinical resources:

  • the REST API as a whole — read, vread, update, create, delete, history, search, capabilities, transaction, batch
  • the XML and JSON representations
  • the primitive datatypes and base infrastructure (Resource, extensions, serialisation conventions)
  • the terminology layer and the conformance framework (StructureDefinition, CapabilityStatement, ValueSet, CodeSystem)

On the clinical-resource side, Normative status touches a small nucleus: in particular Patient and Observation. Everything else stays Trial Use, each resource with its own declared maturity level — the FHIR Maturity Model (FMM), 0 to 5 — that tells you how far that resource has been tested in the field. A resource central to real workflows such as MedicationRequest or DiagnosticReport, however widespread in implementations, remains formally STU in R4.

In practice the backward-compatibility commitment covers the mechanics of exchange — how you talk to the server, how a resource is serialised, how the server declares what it offers — but covers the clinical content only in part. An application that leans on the structure of Observation has stable ground; one that leans on the exact shape of an STU resource knows that shape can still change.

The critical point: a backward compatibility with a boundary

“Normative” in FHIR means one precise, circumscribed thing: future changes to a Normative artefact will not break existing conformant implementations. It does not mean the artefact is complete, nor that it covers every use case, nor that the still-STU related resources are stable.

This boundary deserves reading slowly, for two reasons.

First: stability of the API does not bring stability of the data with it. I can write a client against the Normative REST API and have the guarantee that search and read will keep responding in future releases; but if that client interprets the payload of an STU resource, the evolution of that resource touches it all the same. The Normative promise protects transport more than meaning.

Second: FHIR permits extensions everywhere. The flexibility that makes it adoptable across different contexts — every element may carry extensions, every resource may be profiled — is also what ties real interoperability to agreed profiles rather than to core conformance alone. Two servers both conformant to R4 can remain non-interoperable if they fill the same fields differently or rely on different extensions. Normative status of the core does not untie this knot: it shifts it onto the profiles.

Implications: where real interoperability is played out

For this reason the work that weighs is not only in the specification core but in the Implementation Guides that constrain its use to a context. In the United States it was already in motion: the US Core Implementation Guide, heir to the profiles agreed by the Argonaut project (a consortium of EHR vendors and healthcare organisations started in 2014), sets out which resources, which fields and which vocabularies a system must handle to call itself interoperable in that market.

On top of the FHIR core, application-level specifications are also settling that do not touch the data model but the way applications talk to it. SMART App Launch defines, over OAuth 2.0 and OpenID Connect, how a third-party application obtains controlled access to FHIR data from the context of an electronic health record or a patient portal, with granular scopes (patient/Observation.read, launch/patient). CDS Hooks — whose first stable specification, 1.0, is from 2018 — defines how an EHR calls external decision-support services at precise points in the workflow (patient-view, medication-prescribe) and receives textual guidance back. These are distinct from the core, with their own maturity cycle, but it is their combination with R4 that makes FHIR a basis for application integration and not only for document exchange.

On the US regulatory front, in February 2019 ONC (Office of the National Coordinator for Health IT) issued a Notice of Proposed Rulemaking — published in the Federal Register on 4 March 2019 — proposing to adopt FHIR R4 as the standard for certified EHR APIs, with USCDI (United States Core Data for Interoperability) as the minimum clinical dataset. The rule is not yet final, but the direction is declared: if confirmed, it ties US health-software certification to R4.

The implementation ecosystem moves in the same direction. HAPI FHIR (Java, Apache 2.0) handles R4; the Firely .NET SDK covers the .NET stack; both Microsoft and IBM released open-source FHIR servers in late 2018. Finding these parties together on the same standard is in itself a signal of expected adoption.

Limits

R4 is the first Normative release, not an entirely Normative one: the bulk of clinical resources remain STU, and in design decisions they must be treated as such. In Europe the picture is more fragmented — as of 2019 there is no equivalent of the 21st Century Cures Act, cross-border exchange (eHDSI) still rests on CDA R2, and individual states move at different speeds; in Italy FHIR adoption is exploratory and the national electronic health record stays anchored to CDA R2. Normative status of part of the standard is a necessary condition for building systems with multi-year horizons, but on its own it does not produce interoperability: that still depends on agreed profiles, shared terminologies and regulatory constraints which, outside the United States, remain largely to be written.

Cover image: Conceptual diagram of the FHIR architecture: a doctor and a patient connected through a FHIR REST API and a FHIR Health Server with… — diagram by ClinDCast, CC0 — https://commons.wikimedia.org/wiki/File:FHIR_Academy_-_ClinDCast.webp