Fast Healthcare Interoperability Resources (FHIR – pronounced “fire”) is a relatively new standard from HL7 that aims to solve many of the problems associated with previous HL7 standards such as HL7 v2 messages and HL7 v3. The FHIR standard describes data formats, components (resources – the ‘R’ in FHIR) and the FHIR application programming interface (API). FHIR is designed to be easy to develop for and implement to encourage adoption from software vendors who may be put off by highly complex standards. Unlike other standards, the FHIR standard is also free to use (open) without restrictions on how or where it can be used. FHIR can work with existing HL7 standards such as v2 messages and the HL7 clinical document architecture (CDA) standard but is itself based on web standards such as XML, JSON, HTTP, OAUTH and REST. Aside from its technical features, the group behind FHIR, including the founder, Graham Grieve, have developed a set of implementation libraries and extensive documentation that enables developers to get up and running quickly.
The FHIR standard originated out of a “Fresh Look” task force that HL7 established in 2011 in order to review how HL7 could move on from the HL7 v3 standard to create standards that were easier and more affordable to adopt. Although v3 had achieved considerable success in large national programmes, particularly with the Clinical Document Architecture (CDA) standard, using v3 standards had become complex and difficult, particularly for smaller software vendors and cash-strapped hospital systems.
FHIR uses a technology called “REST” which stands for “Representational State Transfer” to share data between digital health systems. Most of the modern web services we all use today use RESTful application programming interfaces (APIs) to share data. APIs have a long history but, ever since the rise of the internet, they are increasingly used to help different systems communicate and share data of networks. REST is a set of principles that governs how these APIs should work. To be a RESTful API, it should use a uniform interface by using unique URLs (web addresses) to identify individual resources (often these are XML or JSON formatted documents) which can then be accessed or manipulated using the hyperlink system built into the web. Another principle of RESTful APIs is that all the information for a request to a service is contained within the URL, headers and body of the request rather than stored on the server. This is called “stateless interactions”. The other principles include being “cacheable” (using copies of commonly accessed data rather than re-accessing the original repeatedly); separation of the “client” and “server” systems which separates the data from the user interface; and RESTful APIs should be “layered systems”, whereby intermediaries between the client and server can help stabilise the communication and ensure security.
FHIR is a “RESTful” interface – it adopts the core principle of REST described above although the FHIR specification is broader than most RESTful services (which are not designed to be “standards” but just services provided by a company or organisation). FHIR also works with lots of other types of exchange services that are not RESTful APIs.
The FHIR specification is built around a core “repository” which is a list of FHIR resources, each represented by a FHIR URL such as http://server.example.com/fhir/Patient/1234.
The URL has 3 components:
FHIR uses records for exchanging data with client systems telling the FHIR server what contents of the record it needs – the server provides these contents using CRUD services (Create, Read, Update and Delete).
FHIR defines a set of resource types. There are currently 145 resource types in release 4 of FHIR. Resources in FHIR are grouped into five categories: Foundation, Base, Clinical, Financial and Specialised.
Each resource type defines the scope of the resource type, the data content and a common set of data types, terminology and content rules, common search parameters to find resources of the type and that can be used to join them, mappings to other types and any additional services required by the resource type. The FHIR resources are supported by a defined infrastructure including the FHIR RESTful API, an ontology layer that provides narrative descriptions and computable definitions of the resource content, a conformance framework, and an additional set of resources for managing workflows.
References can refer to other resources such as the Patient resource for clinical resources. A set of references can be wrapped in a Composition. In this way, resources form a network of interlinked digital information. As resources are referred to through their URL, references can be relative (assumed to be on the same FHIR server and so the service information is omitted) or absolute (include the server information in the reference, so could also refer other FHIR servers). If a FHIR server is changed, relative references will continue to work but ‘hard-coded’ absolute references will stop working. FHIR servers can insist that references are valid.
The FHIR standard continues to grow in use internationally, with many governments now adopting the standard for national systems. Most of the larger digital health software vendors now support the use of HL7 FHIR for interoperability with other systems.
Paton, C (2024). Textbook of Digital Health.