HL7 FHIR
"As a technology community, we believe that a forward-thinking API strategy … will advance the ability for all organizations to build and deploy novel applications to the benefit of patients, care providers, and administrators alike." [1]
— Amazon, Google, IBM, Microsoft, Oracle and Salesforce
FHIR supports this vision by providing a standardized, web-based approach for exchanging electronic healthcare information.
Clinical Applications of FHIR [2]
Note: This section summarizes and adapts information from the official HL7 FHIR Clinical Overview [2]
FHIR supports the exchange of clinical, healthcare-administrative, public-health, and research data. It can be applied in both human and veterinary medicine and used in numerous contexts, including inpatient, ambulatory, acute, long-term, community, and allied healthcare settings.
Resources
FHIR organizes healthcare information into modular components called resources. A resource can be compared to a generic form template representing a specific type of clinical or administrative information. For example, separate resources exist for allergies, prescriptions, referrals, patients, practitioners, and organizations.
A completed form is called a resource instance. Resource instances can describe patient-related information, such as demographics and health conditions, as well as administrative information, such as healthcare practitioners, organizations, and locations. EHRs, pharmacy systems, and hospital information systems may store or exchange these resources. A collection of connected resources can form a more complete clinical record.
Profiles and Extensions
Because healthcare requirements vary across countries, organizations, specialties, and clinical settings, FHIR resources can be adapted for different contexts.
Extensions: add information that is not included in the base resource.
Profiles: establish constraints and rules for how a resource should be used in a particular context.
These mechanisms allow implementers to add requirements or restrictions while maintaining the shared structure of the underlying resource.
Computer-Readable and Human-Readable Information
FHIR supports the exchange of discrete data, meaning separately defined data elements that computers can process. This allows the information to be used for activities such as searching, decision support, and trend analysis.
FHIR resources can also include a human-readable view. This helps clinicians understand the information even when a receiving system cannot interpret every discrete element.
FHIR Exchange Mechanism
FHIR supports four primary mechanisms for exchanging information: REST, documents, messaging, and services.
REST
A FHIR REST server can be compared to a room containing filing cabinets. Each cabinet contains one type of resource, such as Patient, Encounter, or Medication. Each folder represents a particular resource instance, such as one patient or encounter. The pages within a folder represent different versions of that resource.
When information is updated, a new version is added to the folder. Through the FHIR API, systems can perform actions such as:
Search: Find resources matching specified criteria
Read: Retrieve the current version of a resource
Create: Add a new resource
Update: Add a new version of an existing resource
Delete: Remove or deactivate a resource
History: Review previous versions
Transaction: Perform several related actions together
Operation: Request a specialized function, such as producing a summary
Documents
FHIR documents combine multiple related resources into a persistent collection. A compostion resource acts like a document’s cover page by identifying information such as its title, author, date, patient, and contents.
The composition and related resources are assembled into a complete document that can be stored or exchanged. Discharge summaries and laboratory reports are examples of information that may be exchanged as documents.
Messaging
FHIR messaging sends information from one system to another in response to an event, such as a patient admission, transfer, laboratory order, or medication administration. A message notifies the receiving system of the event and provides relevant information.
Like a document, a message groups related resources. However, it uses a MessageHeader to identify the event and expected response. Unlike a document, the receiving system is not necessarily expected to preserve the message exactly as received.
Services
Services allow one system to request a particular function from another. They are especially useful for clinical decision support.
For example, a system might ask:
Is prescribing this medication appropriate for this patient?
What care plan is recommended for a patient with these conditions?
References
Health Level Seven International. Cloud Providers Unite for Healthcare Interoperability. The Standard: The Official Blog of Health Level Seven International. Published July 30, 2019. Accessed August 19, 2026.
Health Level Seven International. FHIR Overview—Clinicians. FHIR Specification, Version 5.0.0 (R5). Published March 26, 2023. Accessed August 19, 2026.
Last updated