Overview - FHIR v5.0.0 (2024)

This page is part of the FHIR Specification (v5.0.0: R5 - STU). This is the current published version. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

2.1.15 FHIR Overview

FHIR Infrastructure Work Group

Maturity Level: N/A

Standards Status: Informative

Welcome to the FHIR (Fast Healthcare Interoperability Resources) Specification, which is a standard for exchanging healthcare information electronically.This page provides an overview of the standard, and serves as a road map for first-time readers of the specification to help find your way around FHIR quickly.

2.1.15.1 Background

Healthcare records are increasingly becoming digitized. As patients move around thehealthcare ecosystem, their electronic health records must be available, discoverable,and understandable. Further, to support automated clinical decision support and othermachine-based processing, the data must also be structured and standardized. (See Coming digital challenges in healthcare)

HL7 has been addressing these challenges by producinghealthcare data exchange and information modeling standards for over 20 years. FHIRis a new specification based on emerging industry approaches, but informed by yearsof lessons around requirements, successes and challenges gained through defining andimplementing HL7 V2 , HL7 v3 and the RIM, and CDA . FHIR can be used as a stand-alone dataexchange standard, but can and will also be used in partnership with existing widelyused standards. (See Comparing FHIR to other HL7 standards)

FHIR aims to simplify implementation without sacrificing information integrity. Itleverages existing logical and theoretical models to provide a consistent, easy toimplement, and rigorous mechanism for exchanging data between healthcare applications.FHIR has built-in mechanisms for traceability to the HL7 RIM and other important contentmodels. This ensures alignment to HL7's previously defined patterns and best practiceswithout requiring the implementer to have intimate knowledge of the RIM or any HL7 v3 derivations. (See Comparing FHIRto other HL7 standards)

2.1.15.2 Components

The basic building block in FHIR is a Resource. All exchangeable content is defined as a resource. Resources all share the following set of characteristics:

A common way to define and represent them, building them from datatypes that define common reusable patterns of elements
A common set of metadata
A human readable part

2.1.15.3 Approach

2.1.15.3.1 Approach to information modeling

The philosophy behind FHIR is to build a base set of resources that,either by themselves or when combined, satisfy the majority of commonuse cases. FHIR resources aim to define the information contents andstructure for the core information set that is shared by most implementations.There is a built-in extension mechanism tocover the remaining content as needed.

FHIR modeling uses a composition approach. In comparison, HL7 v3 modeling isbased on "model by constraint" (see Comparing FHIRto other HL7 standards). With FHIR, specific use cases are usually implementedby combining resources together through the use of resource references.Although a single resource might be useful by itself for a given use case, itis more common that resources will be combined and tailored to meet usecase specific requirements. Two special kinds of resources are used to describe how resources are defined and used:

2.1.15.4 The Specification

Broadly, the FHIR specification is broken up into a set of modules:

Foundation: The basic definitional infrastructure on which the rest of the specification is built
Implementer Support: Services to help implementers make use of the specification
: Documentation and services to create and maintain security, integrity and privacy
Conformance: How to test conformance to the specification, and define implementation guides
Terminology: Use and support of terminologies and related artifacts
Linked Data: Defined methods of exchange for resources
Administration: Basic resources for tracking patients, practitioners, organizations, devices, substances, etc.
Clinical: Core clinical content such as problems, allergies, and the care process (care plans, referrals) + more
Medications: Medication management and immunization tracking
Diagnostics: Observations, Diagnostic reports and requests + related content
Workflow: Managing the process of care, and technical artifacts to do with obligation management
Financial: Billing and Claiming support
Clinical Reasoning: Clinical Decision Support and Quality Measures
Medication Definition: Detailed medication definitions, for regulatory and drug dictionary use

Resources have a wide range of uses, from pure clinical content such as care plans and diagnostic reports to pure infrastructuresuch as Message Header and Capability Statements. They all share common technical characteristics (see below for a more formal definition),but they are used in totally different fashions. Note that you do not have to use REST to make use of resources.

2.1.15.5 Where to Start

The best place to start is to quickly read the Resources list to get a sense of what resources exist and then look atthe Patient resource definition to see what resource definitions look like, and then read these background pages:

Resource Definitions - basic background to how resources are defined
About Resources: the Narrative they all contain, and how Resources refer to each other
Formats: XML and JSON
About Extensibility: a key way that the specification is kept simple
If you are coming to FHIR with a background in another HL7 standard (HL7 V2 , HL7 v3 or CDA ), The Relationship between FHIR and other HL7 Standards may also be useful

2.1.15.5.1 Header Tabs

These header tabs found through-out the specification are important, and many readers miss them:

Resources and the datatypes that they use are presented in a concise easy to read XML-like format,but they also have detailed descriptions of their contents. In addition, most resources are mapped to severaldifferent formats, including HL7 V2 , the HL7 v3 RIM, CDA , DICOM, and others. Also, all resources come with at least one example (sometimesmany more) and, where appropriate, with profiles that describe their use in specific circ*mstances. Finally, some resources includenotes that help implementers understand the design rationale underlying them.

2.1.15.6 Finding Additional Information and Providing Feedback

While intended to be consumable by a variety of audiences, the FHIR specification is targeted to the implementation community - those who will actuallywrite the software that uses the specification. To help meet the needs of the implementation community, the editors have strived to keep the specificationconcise to reduce the amount of reading that must be done before writing useful code. For this reason, information that is not essential to the implementation process, suchas considered alternatives, points of contention, future plans, etc. have been excluded from this specification. As well, it is likely thatfrom time-to-time, implementers will encounter situations where the specification is unclear or incomplete. Finally, there may be circ*mstances wherethe specification is broken or where a change could allow it to better meet implementer needs.

HL7 has therefore provided a number of mechanisms through which additional information about FHIR can be sought and maintained and through which supportand requests for change can be made.

2.1.15.6.1 The FHIR Confluence Pages

The FHIR project team also maintains a set of Confluence pages wheredevelopment processes, methodology and design decisions are documented. Implementers and others can also contribute to Confluence to provide additional guidanceand supplemental information not found in the specification. Note that Confluence content is not authoritative and is not relevant for determining conformance tothe FHIR specification. As well, some Confluence content might not be up to date with the most recent version of the FHIR specification.

Pages defined include FHIR methodology ,use of the FHIR design tools , etc. Toexplore the FHIR Confluence pages, you can start at the root page

2.1.15.6.2 Formal Change requests

Formal requests for change can be submitted here .(There's a link at the bottom of each page as well.) These will be reviewed by the appropriate work group and a decision made on their incorporation into thespecification, including which release (if any) they will be part of.

2.1.15.6.3 Additional Information sources/Engagement Mechanisms

In addition to the above mechanisms, HL7 provides a Stack Overflow tag, list servers and online chat system to provide various levels of implementer supportand engagement. Instructions for accessing these other mechanisms (and instructions for how best to make use of them) can be foundat the Support Links .