HL7 FHIR DSTU 1: a resource and REST API model for healthcare 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 →

Why a new standard

In 2014 HL7 published the Draft Standard for Trial Use 1 of FHIR — Fast Healthcare Interoperability Resources. The work had started around 2011, championed by Grahame Grieve and a group of HL7 experts, in response to a long-standing unease in the healthcare interoperability community: the two dominant standards were HL7 v2 — pragmatic and widespread but not self-describing, poor on semantics, heavily customised — and the HL7 v3 + CDA R2 pair, rigorous but widely regarded as too complex, with high implementation costs and actual uptake below expectations.

At the same time the broader IT industry had moved to HTTP RESTful APIs, JSON as the preferred exchange format, OAuth for authorisation. The healthcare ecosystem — in particular US EHR vendors and patient-facing tools built outside hospitals — demanded a technical entry point on par with the rest of the web.

FHIR is HL7’s answer to that demand: an information model recognisable to anyone coming from v2/CDA, exposed with the technical conventions of the modern web.

DSTU 1: a first stepping stone

FHIR DSTU 1 was approved in ANSI ballot on 17 February 2014 and published as an HL7 standard with Draft status — explicitly subject to revision in the next releases, based on the experience of the first implementers. From the outset it was supported by twice-yearly Connectathons where vendors, researchers and public services implemented and tested resources side by side.

DSTU 1 defines 49 core Resources, including Patient, Practitioner, Encounter, Observation, Condition, Procedure, MedicationOrder, MedicationDispense, MedicationAdministration, DiagnosticReport, Immunization, AllergyIntolerance, Organization, Location, Substance, Device, DocumentReference.

Six design principles

FHIR was designed with explicit goals, which can be read against the limits of the preceding standards:

1. Resource as atomic unit — every clinical or organisational entity is a self-contained Resource, with its URL, identity and lifecycle
2. Composability — resources reference one another through reference and can be aggregated into Bundle for documents, searches, messages and transactions
3. REST API — every resource is exposed with HTTP conventions: GET, POST, PUT, DELETE on pattern [base]/[Resource]/[id], with _search, _history, _include
4. Two equivalent serialisations — XML and JSON, with published reference schemas and mapping between the two forms
5. Human readability — every resource contains a text section with XHTML narrative, a direct inheritance from the CDA R2 readability principle
6. 80/20 — the core standard covers 80% of common use cases; the remaining 20% is handled via Extensions, with a uniform mechanism for adding attributes without breaking the specification

On top of the six principles is a conformance-driven design mechanism: for each use context a Profile is defined (serialised as a StructureDefinition resource) that constrains, extends and restricts the base resources. Profile conformance is automatically verifiable — machine-readable conformance is a first-class citizen of the standard.

Example: a Patient in JSON

A FHIR patient in JSON runs a few dozen lines:

{
  "resourceType": "Patient",
  "id": "example",
  "identifier": [{
    "system": "urn:oid:2.16.840.1.113883.2.9.4.3.2",
    "value": "RSSMRA50T25H501U"
  }],
  "name": [{
    "use": "official",
    "family": ["Rossi"],
    "given": ["Mario"]
  }],
  "gender": "male",
  "birthDate": "1950-12-25"
}

The same information in XML uses the http://hl7.org/fhir namespace. The two forms are interchangeable — one of the most visible differences compared with CDA R2, which only allows XML.

Search, references, bundle

Search is based on HTTP parameters: GET [base]/Observation?patient=123&code=http://loinc.org|1558-6 returns a Bundle of type searchset. Parameters support modifiers (:exact, :missing, :contains), numeric prefixes (gt, lt, ge, le), and chained search (Observation?patient.name=Rossi). _include and _revinclude pull referenced resources into the bundle.

The atomic transaction is modelled as a transaction Bundle: a single POST [base] atomically performs multiple create/update operations.

The CC0 licence

One of the more significant — and unusually open for HL7 — aspects is the licence choice: FHIR is released under Creative Commons CC0 (public domain) both for the specification and for the schemas and examples. Unrestricted reusability was a strategic choice to lower the barrier to adoption for anyone — vendor, researcher, startup, public administration — in contrast with the more restrictive regime historically adopted by HL7 International.

First open source implementations

DSTU 1 is supported from the start by open reference implementations:

• HAPI FHIR — Java library, developed by James Agnew (University Health Network) as an extension of the HAPI ecosystem born for HL7 v2. Covers client, parser, server, with high-level APIs
• Spark — open source .NET reference server developed by Furore (Netherlands) under the lead of Ewout Kramer, a key contributor to the standard
• fhir-net-api — .NET client/server library, also from Furore
• FHIR Test Server public instance by University Health Network, used for interoperability testing at Connectathons

Alongside these stand modelling tools like Forge for profile construction, and command-line validators distributed by HL7.

What it means for Italy and Europe

As of 2014, FHIR adoption in the Italian context is still exploratory. Regional FSE programmes are based on CDA R2, and the national technical rules — arriving through the DPCM implementing Article 12 of DL 179/2012 — are designed around CDA documents. FHIR enters for now as a topic of interest in the HL7 Italia working groups, with assessments of possible Italian profiles and use cases where the REST API would offer added value over the signed document (queryable patient summaries, patient data access from apps, programmatic interface for clinical trials).

DSTU 1 is explicitly a base for gathering feedback: HL7 has declared that subsequent revisions will bring backward-incompatible changes in some areas. In the community’s intent, it is the beginning of a multi-year stabilisation path that will go through several DSTU steps before a stable Normative release.

References: HL7 FHIR DSTU 1, ANSI approved 17 February 2014. HL7 International. HAPI FHIR (University Health Network). Spark / fhir-net-api (Furore). Creative Commons CC0 licence.