FHIR, pronounced fire, stands for Fast Healthcare Interoperability Resources. It is a standard published by Health Level Seven International (HL7) for exchanging healthcare information electronically. Unlike its predecessors, it was designed around modern web technology: RESTful APIs, JSON and XML payloads, and OAuth 2.0 for authorisation.
Its predecessors remain in wide use. HL7 version 2 messaging still carries an enormous volume of hospital traffic, and HL7 version 3 and CDA documents are embedded in many systems. FHIR was created in response to the complexity of version 3, aiming for something implementers could adopt quickly using familiar tools.
The core building block is the resource, a modular unit representing a discrete clinical or administrative concept. Patient, Observation, Condition, MedicationRequest, Encounter, Appointment and DiagnosticReport are among the most used. Each has a defined structure, a set of standard elements and an extension mechanism for local needs, so systems can exchange a single observation or a full clinical document using the same model.
The base specification is deliberately general, which means two conformant systems can still fail to interoperate. Profiles constrain resources for a particular context: which elements are mandatory, which value sets and terminologies must be used, and which extensions apply. Implementation guides bundle profiles with narrative rules for a specific use case or jurisdiction, and it is at this level that real interoperability is achieved.
NHS England maintains UK Core FHIR profiles and a range of national APIs built on FHIR, covering areas such as the Personal Demographics Service, electronic prescribing and shared care records. Alignment with these standards is one of the interoperability criteria assessed within DTAC, so for suppliers selling into the NHS, FHIR conformance is a commercial requirement as much as a technical choice. Terminology matters too: NHS data generally expects SNOMED CT for clinical concepts and dm+d for medicines.