Overview of FHIR and FHIR resources (optional)
Note
This unit is optional. If you're familiar with the FHIR® standards, you can skip this unit.
Fast Healthcare Interoperability Resources (FHIR®, pronounced "fire") is an industry standard created by Health Level Seven International (HL7®), a global nonprofit health data organization. It specifies a universal structure for health data. FHIR facilitates interoperability between legacy health data systems so that organizations, providers, and patients can share health data across traditional obstacles and boundaries. As a result, organizations can share data more easily between different organizations and health data systems.
FHIR resources
FHIR differs from traditional document-based data storage by structuring healthcare data around the people, places, and other entities that connect with real-world healthcare interactions. These people, places, and other entities are referred to as resources in FHIR. Therefore, a FHIR resource is a discrete piece of data that represents an entity. For example, in FHIR, a healthcare data entity is structured as:
A web of connections to a Patient resource (for a specific patient).
A Practitioner resource (for a specific provider).
An Encounter resource (to store information about a care visit).
A DiagnosticReport resource.
Additionally, FHIR resources structure information as generated in real-world healthcare settings.
FHIR resources offer extensive coverage of the entities that connect with the healthcare process, including resources for devices, insurance plans, scheduling, survey questions, and other items that relate to healthcare. HL7 continuously adds more resources in FHIR because FHIR is an evolving standard.
All FHIR resource types have:
A canonical URL, where the structure of the resource type is defined (for example,
http://hl7.org/fhir/StructureDefinition/Patient).Four data elements: ID, metadata, implicitRules, and language.
Elements within metadata, including versionId, lastUpdated, source, profile, security, and tag.
An extensibility framework to support evolving methods in healthcare.
The common resource types (such as Patient, Practitioner, Encounter, and Observation) have a set of defined data elements that are specific to the real-world domain of the resource (such as the gender element for the Patient resource), and they differ for each resource type.
FHIR resource instances (on a FHIR server) have a unique, server-wide resource ID (such as 123) with a resource instance URL (for example, {{fhirurl}}/Patient/123).
FHIR resources classification
Generally, you can classify resources in the context of the following five categories: Types, Elements, Structure, Hierarchy, and Identity.
Types - HL7 defines these categories to help distinguish the function of resources, including:
Clinical
Financial
Specialized
Elements - Attributes that distinguish every resource instance.
ID - The server-wide resource ID that’s unique to each resource instance on a FHIR server.
Metadata - For storing information, such as the profile on which the resource is based.
implicitRules - For indicating special restrictions on a resource instance.
Language - The human language that you use to record information (such as English or Spanish).
The domain-specific elements for the common resources (such as the gender element for the Patient resource).
Structure - For defining the schema of each resource type, including its data types, extensions, and constraints.
Narratives - XHTML-formatted information about a resource for display in a user interface.
Extensions - A framework for adding new structure and/or elements to extend a resource definition.
Contained resources - A framework for storing a resource's data within an enclosing resource.
Hierarchy - For establishing how resources inherit their attributes from the foundational base resource class in FHIR.
DomainResource class - Inherits from the base resource class, which is parent to the common resource types, such as Patient or Practitioner.
Bundle, Binary, and Parameters - Three resource types in FHIR that inherit directly from the foundational base resource class.
Identity - How and where to track and locate resource instances.
Location URL - The location of the URL, such as
{{fhirurl}}/Patient/123.Location identifiers - Codes that you use in addition to the resource ID for identifying a resource instance.
Example - Patient resource
This example provides a high-level review of a patient resource. Patient is a normalized resource in the HL7 FHIR® specification, meaning that it's universally received and standardized around the world. The FHIR service associates a set of definitive data elements with a patient, and it associates a unique URL with each patient resource instance. A FHIR client can use that URL to interact with the patient resource that the hosting FHIR server manages.
FHIR resources contain data items, which the definition of the resource type describes. The patient resource includes demographics and other administrative information about an individual who’s receiving health-related services. The US Core Implementation Guide (IG) defines how to implement FHIR in the US. To define the standard Patient resource structure, the IG requires data elements for a Patient resource. A patient resource must include elements that store the patient name, an identifier, and the patient's gender. An identifier can include the patient's Medical Record Number (MRN) or Social Security number (SSN).
The following screenshot shows a partial example of a patient resource. You can view the full example at HL7® FHIR® Example Instance.
Connections between resources in FHIR
The following graphic is only one example of the various resources that you might use for an event, such as a patient procedure. The shown resources are Patient, DiagnosticReport, Condition, Procedure, Encounter, and Practitioner, all of which are connected through the subject, report, performer, encounter, and related elements that the Procedure resource stores. These elements in the Procedure resource hold references to the other resources, which illustrate how the references between resources form a web of health information in FHIR. While not shown here, you could reference other resources, including for administrative functions in the financials category for billing (such as the Invoice, Claim, and ClaimResponse resources).
Often, the system includes resources together when it retrieves them in a FHIR search. For example, a patient could have an annual physical (Encounter) with their physician (Practitioner) on August 1, 2021. In that scenario, the physician reviews the patient’s family history (FamilyMemberHistory) and decides to order a mammogram (Procedure). When someone conducts a search for information about that particular encounter, the system could return these resources within a Bundle resource, with references between the different resources.
FHIR key tenets
The FHIR key tenets are:
An extensible data model for healthcare that serves to normalize health data. For example, with FHIR, the canonical data model for a patient always follows the same structure so that patient data is transferable from one system to another.
An API specification for exchanging health data between systems. The specification provides a framework for sending and receiving FHIR data over the internet by using a common data transfer protocol.
A set of profiles and implementation guides for putting the FHIR standard into use in real-world healthcare operations. FHIR conformance guidelines are available on the HL7 website.
A community of implementers that supports the standards. The global health and life sciences community uses the FHIR data model and API to promote health data interoperability.
FHIR normalizes the structure and exchange of health information, which allows payors, providers, researchers, and patients move health data electronically wherever the data is needed, across different healthcare scenarios, systems, and organizations.
FHIR is a next-generation standards framework that allows for health data interoperability. FHIR is built on previous data format standards, such as HL7v2. However, it expands on these older standards by incorporating modern, web-based technologies, including:
An HTTP RESTful protocol.
XHTML and Cascading Style Sheets (CSS) for user interface integration.
A choice of JSON, XML, or RDF for data representation.
Because FHIR is implemented on top of HL7 and the HTTPS (HTTP Secure) protocol, applications that listen for "events" in FHIR (that is, specific changes in FHIR data) parse the messages. In this frame, healthcare organizations can gather near real-time data from FHIR resources as they're created or updated. Then, the system processes data with custom business logic to trigger preset actions and workflows. Potential use cases include epidemic tracking, adverse drug interaction warnings, care team notifications, and more.
FHIR principles
FHIR aligns to the following architectural principles:
Reuse and composability - The FHIR data model is built with the 80/20 rule as its guiding principle. Prioritize the 20 percent of requirements that allow for 80 percent of interoperability scenarios.
Scalability - Transactions are stateless to reduce memory usage and support horizontal scalability.
Performance - Suitable for rapid exchange across networks.
Usability - FHIR resources are human-readable and viewable in text editors/browsers.
Data fidelity - FHIR has strict data typing built in, with support for clinical terminology coding systems and a mechanism for performing data validation against standard profiles. Ways to extend profile definitions with custom business logic for rules-based validation are available.
Implementable - FHIR is ready to implement by using industry standards and by developing SMART on FHIR® applications that can connect to a FHIR server from mobile and web-based applications.
The United States mandates FHIR standards, and other countries and/or regions around the world are adopting them as well. Additionally, FHIR standards have a foundation in web standards, are human readable, and allow for straightforward adoption through shared profiles.