What is HL7 FHIR, and when should you use it?
Understand FHIR resources, APIs, profiles, and how to choose between FHIR, HL7 v2 messaging, and clinical documents for a healthcare integration.
Published Updated
What is HL7 FHIR?
HL7 FHIR (Fast Healthcare Interoperability Resources) is a standard for exchanging healthcare information using defined resources such as Patient and Observation. It specifies data formats and an optional RESTful API, among other exchange approaches. A real deployment still needs agreed profiles, terminology, permissions, and tests so that both parties interpret the data consistently.
The basic model
HL7 defines FHIR as a standard for healthcare data exchange. Its building blocks are resources: for example, Patient represents demographic and identifying information, Encounter a care interaction, and Observation a measurement or assertion. A resource has a defined structure and can refer to other resources. The resource model is separate from the transport: the FHIR specification's developer overview describes REST interactions as well as other ways to exchange FHIR content.
A client might request a patient's observations from a FHIR server, but the endpoint alone does not answer which observations are available, who may read them, or which codes the recipient understands. Those details come from the implementation context.
FHIR, HL7 v2, and CDA serve different needs
| Approach | Common exchange pattern | What to check first |
|---|---|---|
| HL7 v2 | Event-driven messages between established systems | Local message variants, triggers, acknowledgements |
| CDA | Structured clinical documents | Document templates, sections, coded entries |
| FHIR | Resource-based APIs and other resource exchanges | Release, supported interactions, profiles, authorization |
This is not a ranking. An existing v2 feed for admission events may be the right choice to retain, while a new application retrieving selected patient data might use FHIR. A document-sharing workflow may need a complete clinical document rather than a series of isolated resource requests. Replacing a working interface simply to adopt a newer standard creates migration work without necessarily improving the workflow.
Where implementers need to make decisions
Choose the FHIR release and implementation guide. Servers and clients need to agree on a compatible version and on the rules for their jurisdiction or programme. HL7's implementation-guide specification describes how related conformance rules and examples are published together.
Constrain the data. Base resources permit many variations. Profiles can make elements required, bind terminology, and specify how references are used. Agree on patient identity, code systems, units, absent data, and updates before testing.
Define access and failure behaviour. Document who can call an API, how authorization is obtained, how missing or rejected requests are handled, and what must be logged. The standard is not a substitute for local security policy.
Test the workflow, not only the payload. Validate sample resources against the applicable profiles, then test actual exchanges with partner systems, including errors and mismatched data. A syntactically valid resource is not proof that a clinical workflow is safe.
A decision checklist
Before adopting FHIR, ask: What information needs to move, and at what point in care? Is an API, event message, or document the appropriate exchange? Which guide and release must participating systems support? Who owns terminology, identity matching, and access decisions? What evidence will demonstrate that the receiving system uses the information correctly? Answering these questions makes the standards choice testable.