HL7 promoted FHIR to Draft Standard for Trial Use 1 with the ANSI ballot of 17 February 2014, and the specification circulates as version v0.0.82. It is the first HL7 standard to model clinical entities as resources queried over HTTP in XML or JSON, rather than as pipe-delimited segments or signed documents. After a few years writing parsers for v2 messages and reading CDA documents, I took the time to note where the model really changes.

Context

Anyone integrating healthcare systems in Italy works almost always with two families of standards. The first is HL7 v2, the format of the ADT, ORM, ORU messages that run through the hospital: segments separated by |, pervasive but not self-describing, and dependent on local agreements over which fields and which Z-segments to use. The second is CDA R2 — Clinical Document Architecture, built on top of the HL7 v3 Reference Information Model — which serves as the technical base for the documents of the regional Electronic Health Record: rigorous, expressive, but with a steep implementation curve and an actual uptake below the expectations stated in the early 2000s.

Meanwhile the rest of application integration moved to HTTP APIs, JSON as the exchange format and OAuth for authorisation. Patient-facing tools and EHR products, particularly in the United States, were asking for an entry point to clinical data with the same conventions as the rest of the web. FHIR — Fast Healthcare Interoperability Resources, started around 2011 by Grahame Grieve within HL7 — was born to answer that request.

Architecture

The base unit is the Resource: a clinical or organisational entity with a type, an identity and a URL. DSTU 1 defines a restricted set of core types, among them Patient, Practitioner, Encounter, Observation, Condition, Procedure, DiagnosticReport, Immunization, AllergyIntolerance, MedicationPrescription, MedicationDispense, MedicationAdministration, Organization, Location, Device, DocumentReference. A note on the name MedicationPrescription: in this version the medication order is called this, not by the name it will take in later revisions.

Each resource is exposed under HTTP conventions, on the pattern [base]/[Type]/[id]:

GET    [base]/Patient/example
POST   [base]/Patient
PUT    [base]/Patient/example
DELETE [base]/Patient/example
GET    [base]/Patient/example/_history

Resources reference one another through reference and aggregate into a Bundle, the container used for search results, documents, messages and transactions. There are two equivalent serialisations, XML and JSON, with published schemas and a mutual mapping. A Patient in JSON stays in the order of a few dozen lines:

{
  "resourceType": "Patient",
  "identifier": [{
    "system": "urn:oid:2.16.840.1.113883.2.9.4.3.2",
    "value": "RSSMRA50T25H501U"
  }],
  "name": [{ "use": "official", "family": ["Rossi"], "given": ["Mario"] }],
  "gender": { "coding": [{ "system": "http://hl7.org/fhir/v3/AdministrativeGender", "code": "M" }] },
  "birthDate": "1950-12-25"
}

Every resource also carries a text section with an XHTML narrative: the structured information rendered in human-readable form, a direct inheritance from CDA R2’s readability principle. This way a receiving system can display the content even when it cannot interpret every structured field.

Search goes through HTTP parameters. The request

GET [base]/Observation?subject=Patient/example&name=http://loinc.org|1558-6

returns a Bundle with the observations that match the criteria. Parameters allow modifiers (:exact, :missing), prefixes for numeric and date comparisons, and chained search over references; with _include the bundle also carries the referenced resources, resolving them in a single call.

The critical point

What deserves most attention is not the REST transport, but the way the standard handles what it does not cover. FHIR states that it models in the core the set of elements common to most implementations, and leaves the rest to a uniform system of Extension: any resource can carry additional attributes identified by a URL, without that breaking reading by a system that does not know them. This is the concrete difference from v2’s Z-segments, where the local extension is opaque and has no retrievable definition.

On top of this sits the Profile, serialised as a Profile resource: the formal definition of how the base resources are to be constrained, extended and bound for a given use context. A profile is read by a machine, so an instance’s conformance to a profile is verified automatically. This is the part where DSTU 1 is openly immature: the mechanism is there, but lightly exercised, and the example profiles themselves will change.

The Draft qualifier should be read literally. The specification’s DSTU status page warns that during the DSTU phase there is no commitment to backward or forward compatibility, and that changes may be structural — resources refactored, serialisation rules changed, data types added or removed. HL7 reckons on at least two DSTU releases, roughly a year apart, before part of the specification becomes Normative.

Implications

For an integrator in Italy, today, the practical fallout is limited. The regional EHR programmes rest on CDA R2, and the technical rules arriving with the implementing decree of article 12 of DL 179/2012 are drawn on documents, not on resource APIs. FHIR enters as an object of assessment within HL7 groups, particularly where a programmatic interface gives something the signed document does not: consulting a patient summary from an application, accessing a patient’s data from external tools, capturing data in clinical studies.

The licence lowers the threshold for experimentation: specification, schemas and examples come out as Creative Commons CC0, public domain, without the restrictions historically tied to HL7 International products. Open reference implementations to try the model already exist: HAPI FHIR, a Java library written by James Agnew at University Health Network as an extension of the HAPI ecosystem born for v2, and Spark, a .NET reference server written by Furore with the contribution of Ewout Kramer, also one of the standard’s authors.

Limits

DSTU 1 should be taken for what it states it is: a base for gathering feedback from early implementers, not a stable target. Anyone building on top of v0.0.82 must reckon that some resources and some rules will change in a non-backward-compatible way, starting from names like MedicationPrescription. Clinical coverage is partial, and terminology bindings to vocabularies (LOINC, SNOMED CT) are indicated but not everywhere binding. Exposing a resource over REST does not, on its own, solve patient identity, consent and access logging: these remain to be designed outside the data model.

https://www.hl7.org/fhir/DSTU1/ https://www.hl7.org/fhir/DSTU1/dstu.html https://www.hl7.org/fhir/DSTU1/patient.html https://www.hl7.org/fhir/DSTU1/medicationprescription.html https://www.hl7.org/fhir/DSTU1/http.html https://www.hl7.org/fhir/DSTU1/search.html https://hapifhir.io/ https://www.noze.it/en/insights/hl7-fhir-dstu1-nascita/

Cover image: Diagram of interlinked FHIR resources connected by references, each made of data elements describing a clinical concept — diagram by Tertius3, CC BY-SA 4.0 — https://commons.wikimedia.org/wiki/File:FHIR_resource_graph.png