Fast Healthcare Interoperability Resources (FHIR - pronounced "fire") is an HL7 standard that aims to solve many of the problems associated with earlier 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, in order to encourage adoption from software vendors put off by the complexity of earlier standards. Unlike most other HL7 standards, FHIR is free to use without restrictions on how or where it can be used. FHIR can interoperate with the existing v2 messaging and CDA standards, but the FHIR specification itself is built on web standards: XML, JSON, HTTP, OAuth and REST. The group behind FHIR - including its founder Grahame Grieve - also ship a set of implementation libraries and extensive documentation that lets developers get up and running quickly.
Origins
FHIR originated in a "Fresh Look" task force that HL7 established in 2011 to review how to move on from HL7 v3 toward 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 - v3 had become complex and difficult to use, especially for smaller software vendors and cash-strapped hospital systems.
REST and the Resource model
FHIR uses REST (Representational State Transfer) to share data between digital health systems. Most modern web services use RESTful APIs. The principles of REST are:
- Uniform interface - unique URLs identify individual Resources (usually XML or JSON documents) accessed via the standard web verbs.
- Stateless interactions - all the information for a request is contained in the URL, headers and body, not on the server.
- Cacheable - common responses can be re-used.
- Client-server separation - the data layer is decoupled from the user interface.
- Layered system - intermediaries between client and server can stabilise communication and add security.
FHIR adopts these REST principles, though it is broader than most RESTful services (which are not designed as standards). FHIR also supports non-RESTful exchange patterns.
The FHIR specification is built around a core repository - a list of FHIR
Resources, each identified by a URL such as
http://server.example.com/fhir/Patient/1234. The URL has three parts:
- Base address - the server providing the FHIR service
(
http://server.example.com/fhir). - Type - the FHIR Type service for a particular Resource type
(
Patient). - Id - the Instance service identifying one specific Resource
(
1234).
FHIR clients tell the server which parts of a record they need; the server provides them via CRUD operations (Create, Read, Update, Delete).
Resources
Release 4 of FHIR defines 145 Resource types, grouped into five categories: Foundation, Base, Clinical, Financial and Specialised. Each Resource type defines its scope, data content, common data types, terminology and content rules, search parameters, mappings to other types, and any additional services needed.
Resources reference each other (for example, clinical Resources usually
reference the Patient Resource). A set of references can be wrapped in a
Composition. References can be relative (assumed to be on the same FHIR
server) or absolute (carrying the full server URL). Relative references
survive a server move; hard-coded absolute references do not. FHIR
servers can require that references resolve.
Adoption
FHIR continues to grow internationally, with many governments adopting it for national systems. Most of the larger digital health software vendors now support FHIR for interoperability with other systems.
Video
Discussed in