HL7 FHIR: An Overview of the Standard and How It Works

Healthcare organizations rarely operate within a single system. Patient demographics and clinical records may be stored in an electronic health record, laboratory results in a separate platform, and research or population health data in purpose-built applications. Because these systems use different data structures, vocabularies, and interfaces, exchanging information between them can require significant custom development.

HL7 Fast Healthcare Interoperability Resources, better known as FHIR, provides a standardized framework for representing and exchanging healthcare information electronically. It combines healthcare-specific data models with technologies familiar to modern software teams. FHIR is now used in EHR integrations, patient and clinician applications, research platforms, analytics, and cross-organizational data exchange.

What Is HL7 FHIR?

FHIR is a healthcare data exchange standard published by Health Level Seven International, or HL7. Its name stands for Fast Healthcare Interoperability Resources.

The word “resources” is central to the standard. Instead of representing a medical record as one large structure, FHIR divides healthcare information into standardized building blocks. Each resource describes a particular clinical or administrative concept, such as a patient, appointment, observation, medication request, or diagnostic report.

Resources can reference one another, allowing systems to preserve the relationships between different information sets. For example, an application retrieving a patient’s blood pressure may work with:

• a Patient resource containing demographic and administrative information;
• an Observation resource containing the measurement;
• an Encounter resource providing the context in which it was recorded.

The application can retrieve these resources through a FHIR API without requesting the patient’s entire medical record. FHIR APIs commonly use HTTP and exchange information in JSON or XML. Depending on the server’s capabilities and the application’s permissions, a client may be able to search for, create, retrieve, or update particular resources.

FHIR also supports exchange patterns beyond REST APIs. These include documents, messages, subscriptions, and bulk data exports. An organization can therefore select an approach based on the workflow, data volume, timing, and reliability requirements.

The application can retrieve these resources through a FHIR API without requesting the patient’s entire medical record. FHIR APIs commonly use HTTP and exchange information in JSON or XML. Depending on the server’s capabilities and the application’s permissions, a client may be able to search for, create, retrieve, or update particular resources.

FHIR also supports exchange patterns beyond REST APIs. These include documents, messages, subscriptions, and bulk data exports. An organization can therefore select an approach based on the workflow, data volume, timing, and reliability requirements.

From Base Resources to Implementation

Base FHIR resources are intentionally flexible because they need to work across different countries, healthcare systems, and use cases. Practical implementations use several additional components to turn this general framework into a more precise set of requirements:

• Profiles specify how a resource should be used in a particular context. A profile may require certain elements, restrict permitted values, or define which terminology should be used.
• Extensions provide a structured way to represent information that is not included in the base resource.
• Implementation Guides combine profiles, extensions, terminology requirements, examples, and other rules for a particular jurisdiction or business problem.
• CapabilityStatements describe which resources, search parameters, operations, and interactions a particular server supports.

Consider the previous blood pressure example. A profile may define which fields, codes, and units must be included in the Observation. An Implementation Guide may establish broader rules for exchanging clinical measurements, while the server’s CapabilityStatement indicates whether the required resource and search operation are supported.

FHIR also relies on clinical terminology to ensure that systems exchange meaning, not only structure. Depending on the use case, resources may contain codes from systems such as SNOMED CT, LOINC, ICD, or RxNorm. If a source system uses local codes, those values may need to be mapped to a recognized terminology before the receiving system can interpret them reliably.

How FHIR Fits into the HL7 Ecosystem

FHIR exists alongside earlier healthcare interoperability standards rather than simply replacing them. HL7 v2 remains widely used for event-driven exchanges such as admissions, discharges, transfers, orders, and results. CDA and C-CDA are used for structured clinical documents, while many organizations also rely on proprietary formats and internal data models.

FHIR takes a more modular approach. Instead of organizing every exchange around a complete message or document, it allows applications to work with individual resources that can be queried, updated, combined, and reused.

In practice, these standards often coexist within the same architecture. An organization may receive HL7 v2 messages, preserve C-CDA documents, transform selected data into FHIR resources, and make that information available to other applications through a FHIR API. Transformation between FHIR and existing formats is therefore a common part of healthcare integration work.

Common FHIR Use Cases

FHIR can be applied wherever an application or organization needs structured access to healthcare information. Common scenarios include:

• connecting patient-facing or clinician-facing applications to EHR data;
• exchanging clinical information between healthcare organizations;
• supporting applications that launch within an EHR;
• migrating and consolidating data from legacy systems or multiple EMRs;
• building research cohorts and population health datasets;
• enabling clinical decision support, reporting, and analytics;
• coordinating scheduling, referrals, questionnaires, and remote patient monitoring.

The same resource can support different workflows. An Observation, for example, may represent a laboratory result, vital sign, assessment score, or device measurement. For this reason, a FHIR implementation should begin with the clinical or business purpose rather than a list of available resources.

FHIR also supports incremental adoption. An organization can begin with a focused workflow, such as retrieving patient demographics and selected observations, rather than redesigning every existing interface. Shared resources, profiles, and terminology can then be reused as additional applications and workflows are introduced.

FHIR Versions

FHIR continues to evolve. R5 is the current published version of the core specification, while R4 and R4B remain relevant to existing products, Implementation Guides, and production integrations.

The newest release is not automatically the right choice for every project. Version selection depends on the systems involved, the applicable Implementation Guide, and the maturity of the resources required for the workflow. An EHR may expose an R4 API even when newer versions of the standard are available.

Conversion between FHIR versions may also involve more than renaming fields. Resource structures, data types, required elements, and terminology bindings can change between releases. The version used by each participating system should therefore be confirmed and documented early in the project.

Why FHIR Implementations Are Still Complex

FHIR gives healthcare organizations a common foundation, but it does not make every integration plug-and-play. Several areas usually require additional analysis and coordination:

• Differences between implementations: Two systems may support different resources, profiles, search parameters, or operations. Optional elements may also be interpreted differently.
• Source data quality: A structurally valid resource can still contain an incorrect identifier, inconsistent unit, incomplete historical record, or ambiguous local code.
• Mapping between formats: Information stored in HL7 v2 messages, CDA documents, or custom models may not have a direct equivalent in FHIR. The team must decide how to transform it without losing important context.
• Security and access: FHIR is not a security protocol. Production integrations need appropriate authentication, authorization, transport security, audit controls, monitoring, and data protection.
• Environment differences: Sandbox data and functionality may not fully reflect the production environment. Production access may also require additional onboarding and security review.
• Workflow validation: A technically valid resource does not guarantee that the complete workflow works as intended. User context, timing, permissions, and downstream system behavior must also be tested.

SMART App Launch addresses one part of this challenge by providing OAuth 2.0-based patterns for applications that need authorized access to FHIR data. It can support applications launched from an EHR as well as standalone applications. However, each healthcare organization still defines which users and applications can access particular information and under which conditions.

A Practical FHIR Implementation Approach

A FHIR project should start with a specific clinical, operational, or data problem. Before selecting resources or endpoints, the team should understand who will use the integration, what information they need, where that information currently resides, and what should happen after it is exchanged.

A practical implementation process usually includes the following steps:

1. Define the use case and workflow. Identify the users, systems, required data, timing, and expected outcome.
2. Assess the participating systems. Confirm the supported FHIR versions, resources, profiles, search parameters, operations, terminology requirements, and authorization mechanisms.
3. Review the source data. Examine identifiers, codes, units, timestamps, missing values, historical records, and information that may not map cleanly to the target model.
4. Design the exchange. Select the appropriate combination of REST APIs, messages, documents, subscriptions, or bulk exports. Define how data will be mapped, validated, and protected.
5. Test the complete workflow. Testing should cover data accuracy, authorization, expected and unexpected inputs, performance, error handling, and differences between staging and production environments.
6. Prepare for production support. Establish monitoring, support ownership, release coordination, and a process for responding to changes in source systems, vendor APIs, and FHIR requirements.

This approach keeps the implementation focused on the intended outcome. FHIR resources and APIs become tools for supporting the workflow rather than the starting point of the project.

How Clinovera Supports FHIR Initiatives

Clinovera supports healthcare organizations across the FHIR implementation lifecycle, from initial assessment and proof of concept to production rollout and ongoing maintenance. Engagements may involve advisory consulting, full-cycle delivery, or additional specialists working alongside an existing team.

Our interoperability work includes bidirectional exchange and transformation across FHIR R4 and R5, HL7 v2 and v3, CDA and C-CDA, XML, and custom data models. We also support FHIR readiness and data quality profiling, terminology and ontology work, migration, integration engine implementation, cohort development, testing, and scalable production processing.

A FHIR project should ultimately solve a specific clinical, operational, or data challenge. Our role is to help clients identify the right implementation approach and build an integration that works within their existing systems, workflows, and technical constraints.

August 2026