HL7 vs FHIR: The Key Differences

Health information exchange (HIE) is crucial for improving healthcare quality, safety, efficiency, and reducing costs. Two major standards for exchanging healthcare information electronically are Health Level 7 (HL7) and Fast Healthcare Interoperability Resources (FHIR). Both play important roles in healthcare interoperability, but have key differences.

This article will provide an in-depth look at HL7 and FHIR, their history, features, similarities and differences, and future outlooks.

What is HL7?

HL7 stands for Health Level Seven, referring to the seventh level of the International Organization for Standardization’s (ISO) commun

ications model for Open Systems Interconnection (OSI). HL7 is a set of standards for exchanging electronic health information between software applications used by various healthcare organizations.

HL7 standards apply to the application layer, which is “Level 7” in the OSI model. The application layer interfaces directly to and performs common application services for the application processes. Application layer protocols include file transfer, email, and remote file access.

The first version of HL7 was published in 1987 by a group of large healthcare organizations who met at the University of Pennsylvania. The standard was created to exchange clinical data and integrate independent healthcare systems. HL7 quickly gained adoption for allowing healthcare providers to exchange patient clinical and administrative data electronically.

HL7 standards pertain to both the syntax (structure and format) and semantics (meaning) of messages exchanged between systems. An HL7 message has a series of segments in a defined sequence, each containing one or more composites which have data fields.

For example, a message may contain patient name, gender, birth date, and other information. HL7 specifies the order of segments, the structure of each segment, data types, and code systems to be used. HL7 v2.x is the most commonly used HL7 version today.

What is FHIR?

FHIR (Fast Healthcare Interoperability Resources) is the newest draft standard for exchanging electronic health records, published in 2014 by Health Level Seven International (HL7).

The purpose of FHIR is to define flexible, lightweight data formats and open application programming interfaces (APIs) for exchanging electronic medical records between different systems. The FHIR standard builds on previous HL7 standards, but is intended to be faster and easier to implement.

Some key features of FHIR include:

• Modular components called “Resources” that can be assembled into messages and documents
• Resources have common structures, behaviors, and APIs enabling reuse
• Support for JSON and XML data formats
• RESTful APIs using HTTP and REST principles
• Use of modern web standards and architecture principles

FHIR was created by HL7 and the open-source community to address limitations of older HL7 versions. It aims to simplify implementation, accelerate interoperability between systems, and enable innovation on top of the standard.

Brief History of HL7 and FHIR

HL7’s first standards were developed in the late 1980s to exchange clinical data between independent departmental systems. By the 1990s, HL7 v2.x messaging was established as the dominant standard for healthcare interfaces. However, implementing HL7 v2.x interfaces was complex and costly.

In the 2000s, the focus shifted to developing electronic health record (EHR) standards and promoting EHR adoption. HL7 v3 messaging was introduced in 2005 as the next-generation standard but failed to gain significant traction due to its complexity.

By 2010, the industry had rallied around the idea of simple web APIs for EHR interoperability. In 2014, HL7 published the FHIR standard based on web APIs and gained broad interest. FHIR is now quickly becoming the leading standard for healthcare interoperability.

HL7 v2.x is still widely used today, but FHIR adoption is rapidly accelerating as vendors modernize their offerings. FHIR combines the best lessons learned from previous standards while leveraging modern web technologies.

Key Similarities Between HL7 and FHIR

Although HL7 and FHIR were developed during different eras, they have some important similarities:

• Developed by Health Level Seven (HL7) as standards for exchanging electronic health information
• Allow encoding of healthcare data into standardized electronic messages that can be exchanged between health information systems
• Seek to allow healthcare systems to communicate and exchange data, promoting integration and interoperability
• Handle patient health information like laboratory tests, medical reports, diagnoses, medications, etc.
• Aim to improve efficiency, quality, and continuity of care across the health system
• Define both syntax (structure) and semantics (meaning) to facilitate data exchange
• Have extensible code systems to send and interpret coded data elements
• Are ANSI-accredited standards approved through a consensus process
• Widely adopted internationally for healthcare data integration and exchange

Both standards serve the overall goal of integrating disconnected health systems to enable data exchange for improved healthcare delivery.

Key Differences Between HL7 and FHIR

While HL7 and FHIR share some high-level goals, they differ significantly in their technical approach:

• Messaging Structure — HL7 v2.x uses delimited segments and messages. FHIR uses resources with common formats, behaviors, and RESTful APIs. FHIR has greater flexibility.
• Ease of Use — HL7 v2.x has rigid specifications requiring custom integration. FHIR aims for simplicity using modern web standards and a modular framework.
• Implementation — HL7 v2.x requires specialized interfaces and custom code. FHIR uses modern RESTful APIs for rapid app development and system access.
• Tooling — HL7 v2.x has limited off-the-shelf software and tooling support. FHIR enables use of web dev tools, frameworks, and libraries.
• Data Formats — HL7 v2.x uses ER7 for encoding. FHIR uses XML, JSON, RDF for broader compatibility.
• Architecture — HL7 v2.x follows tightly coupled point-to-point messaging. FHIR emphasizes decentralized access and a loosely coupled publish-subscribe model.
• Maturity — HL7 v2.x is a mature standard with decades of implementations. As a newer standard, FHIR has less production experience but strong momentum.
• Focus — HL7 v2.x enables administrative, financial, and clinical data exchange. FHIR focuses mainly on the exchange of clinical content and patient data.
• Adoption — HL7 v2.x has near-universal adoption for legacy interfaces. FHIR adoption is rapidly growing for newer interoperability needs.

To summarize, FHIR offers major improvements in flexibility, ease of use, scalability, and developer experience compared to prior HL7 standards. Yet, HL7 v2 retains extensive legacy use. The two standards co-exist with FHIR addressing modern requirements.

FHIR Resources Explained

Resources are the basic building blocks of FHIR. Resources represent granular clinical or administrative concepts that can be assembled into messages or documents.

Some examples of FHIR resources:

• Patient — Demographics, contact info, relationships
• Observation — Clinical measurement, finding, assessment
• Procedure — Healthcare intervention/service provided
• Condition — Clinical diagnosis identified from observations
• Medication — Medicine or vaccine administered to a patient
• Questionnaire — A set of questions for gathering data
• Diagnostic Report — Interpretation of diagnostic tests and results

All resources share a common framework with set of features:

• JSON/XML representation
• Unique canonical URL for each resource
• Human-readable terminology for data elements
• Common metadata like id, version, lastUpdated
• References to link resources together
• APIs for CRUD operations

This consistent structure allows FHIR resources to be understood by different systems and enables modular resource reuse. Resources can be aggregated to represent complex clinical concepts or assembled into parcels of data called “bundles“.

The APIs allow resources to be created, retrieved, updated, deleted, searched, versioned and processed according to common patterns. Implementations can leverage off-the-shelf tooling and libraries instead of needing specialized interfaces.

Benefits of Modular Components

The modular approach used by FHIR provides a number of benefits:

• Simplifies understanding — Individual resources are smaller in scope and easier to understand than the large, monolithic messages used by HL7 v2.
• Promotes reuse — Resources have standard APIs, semantics, and bindings. This enables reuse across healthcare workflows and applications.
• Enables interoperability — Modular components with defined semantics are ideal for shareable data.
• Flexible assembly — Resources can be combined in different configurations to exchange data for various clinical use cases.
• Accelerates development — Common resource patterns reduce the learning curve for developers and decrease development time.
• Lightweight integration — Resources can be retrieved on demand versus using static messages with fixed payload. Reduces complexity.
• Scalability — Resources allow for more decentralized and cloud-based access models versus point-to-point message exchange.

Overall the resource-oriented paradigm used by FHIR, enables simpler yet more flexible and scalable interoperability compared to past approaches.

RESTful APIs

The FHIR standard is based on RESTful web APIs. This differs greatly from HL7 v2.x’s use of tightly-coupled, point-to-point messaging interfaces.

REST (Representational State Transfer) is an architectural style for web services. RESTful systems aim to expose data on the web as addressable resources that can be identified using URLs.

REST uses standard HTTP methods to perform operations on resources like GET, POST, PUT, DELETE. For example, HTTP GET retrieves a resource, POST creates a new resource, PUT updates a resource, and DELETE removes it.

In FHIR, resources are accessed by sending HTTP requests to defined FHIR servers:

• GET {serverURL}/Patient/{id} — Retrieve a patient by ID
• POST {serverURL}/Observation — Create new observation resource
• PUT {serverURL}/Procedure/{id} — Update existing procedure resource

This RESTful API model has numerous benefits:

• Simplicity — Uses widely adopted web technologies and protocols
• Developer experience — Leverages existing tooling, libraries, skills
• Scalability — Enables decentralized, internet-scale architecture
• Flexibility — Resources accessed on demand, not predefined messages
• Security — Built-in authentication, authorization, encryption
• Ecosystem — Broad ecosystem of infrastructure, cloud platforms, and vendors

The RESTful APIs make it much easier to exchange healthcare data between disparate systems. They promote simpler point-to-point data access rather than complex, tightly-coupled interfaces.

Comparing Message Exchange Patterns

HL7 v2.x uses a message exchange pattern that is transactional, point-to-point, synchronous, and server-driven. Systems send request messages and receive response messages over direct interfaces.

This messaging pattern has some limitations:

• Tight coupling — Dedicated interfaces between each system
• Fixed messaging — Rigid message structures
• Batch transactions — Data exchange done in batches
• Centralized — Single server controls transactions

In contrast, FHIR follows a web-based exchange pattern that is resource-focused, ad hoc, asynchronous, and client-driven:

• Decentralized — APIs provide access to data anywhere
• On-demand — Data accessed when needed
• Stateless — No transaction tracking needed
• Mobile — Works across multiple device types
• Cached — Enables data to be cached locally

The RESTful exchange pattern used by FHIR provides greater scalability and flexibility compared to previous approaches. It aligns better with internet-scale access to healthcare information.

Security

Both HL7 and FHIR require comprehensive security to protect sensitive patient health information being exchanged.

HL7 v2.x security relied mainly on point-to-point security controls like VPNs and firewalls.

FHIR incorporates modern internet-based security:

• Transport encryption via HTTPS
• OAuth 2.0 authentication using access tokens
• Access control using user roles and permissions
• Audit logging to track data access
• Anonymization to hide personal identifiers
• Digital signatures on resources
• TLS and HTTPS for end-to-end security

FHIR’s web-based security model aligns with modern application security techniques and can leverage a wide range of tools and libraries.

Clinical Terminologies

Both standards need codified clinical terminologies to represent concepts like diagnoses, procedures, medications, lab results, etc.

HL7 v2.x uses keyed codes with some standard code systems like LOINC, SNOMED CT, and RxNorm but allows many custom codes.

FHIR emphasizes the use of standard clinical terminologies and ontologies through its “CodeSystem” resource and bindings to global standards:

• SNOMED CT, LOINC, RxNorm, ICD-10 for clinical codes
• UCUM for units of measure
• HL7 v3 data types
• PROV for provenance metadata

The use of common global terminologies improves semantic interoperability between systems using FHIR.

Converting Between HL7 v2 and FHIR

Many healthcare organizations have legacy systems using HL7 v2, yet want to adopt FHIR for new applications and interfaces. This requires converting data between the two standards.

The structured nature of HL7 v2 and FHIR make automated conversion possible, but it requires mapping between the models:

• Segments and delimiters vs. resource data elements
• V2 fields and datatypes to FHIR elements
• Embedding v2 messages in FHIR bundles
• Mapping v2 codes to FHIR terminologies
• Converting v2 Send/Receive interfaces to FHIR APIs

Lossless roundtrip conversion between v2 and FHIR may not always be feasible due to differences in expressivity. Some implementation-specific details may not fully map.

Tooling is emerging to assist with HL7 v2 and FHIR conversion including middleware, integration engines, and mapping tools. But quality transformers still require human understanding of the data models.

Clinical Data Analytics Using FHIR

The web-based nature of FHIR makes it feasible to leverage cloud platforms, big data technologies, and clinical data analytics using FHIR data:

• Cloud deployment of FHIR servers and data storage
• Big data pipelines to ingest, transform and consolidate FHIR resource data
• Analytics using BI tools, data science, and machine learning on FHIR data
• Visualization and dashboards powered by FHIR data APIs
• Clinical decision support based on analysis of patient data trends
• Population health management analyzing patient cohorts
• Precision medicine correlating genomic data with clinical data
• Clinical trials gathering patient-reported outcomes
• Public health monitoring based on analysis of healthcare trends

The transition to FHIR enables entirely new uses of healthcare data that were impractical with previous standards and legacy interfaces.

FHIR Development Tools and Libraries

One driver of FHIR adoption is the availability of open-source libraries, tools, and plugins that accelerate development:

• Sample server and API implementations
• Code generation tools to speed creation of models
• Interface engines to quick start integration
• Testing tools and sample data for implementations
• Mapping tools to/from other standards
• Terminology services for code lookup and translation
• Mobile libraries on iOS, Android, React Native
• SDKs for various languages — Java, .NET, Python, JavaScript, Go
• ORM libraries to persist FHIR models in databases
• Support for FHIR in leading healthcare interoperability platforms
• FHIR extensions for healthcare-related web protocols like OAuth 2.0
• Plug-ins for EHR systems and healthcare middleware

The tooling and support for FHIR will continue maturing to reduce barriers to adoption. But HL7 v2 still has richer legacy tooling support currently.

Limitations of FHIR

While FHIR is gaining momentum, it is not without limitations:

• Newer standard with less production experience than HL7 v2.x
• Key specifications like terminology services still evolving
• Limited support for financial, administrative, and supply chain workflows
• Concerns over bandwidth and caching needed for extensive resource querying
• Immaturity of tools for aggregating resource data into clinical artifacts
• Standards governance and versioning processes still developing
• Gaps in representing complex clinical concepts like genomics
• Need for “gold-standard” reference implementations
• Change management from legacy interfaces to FHIR-based infrastructure

Despite its limitations, FHIR adoption is accelerating because its overall approach addresses fundamental needs for simpler, web-based healthcare data exchange.

Future Outlook for FHIR Adoption

FHIR adoption is expected to rapidly grow over the next 5–10 years across healthcare organizations, EHR systems, consumer apps, medical devices, analytics platforms, and other health IT:

• U.S. CMS and ONC have mandated access to patient data via FHIR APIs
• Leading EHR vendors committed to exposing data via FHIR APIs
• Health systems rolling out enterprise FHIR capabilities
• Major growth in FHIR-enabled healthcare apps and digital health tools
• Emerging support in medical devices like imaging systems, wearables, and IoMT
• Increased use of FHIR for public health data exchange and analytics
• Growth of FHIR in clinical research and patient-centered outcomes
• HL7 standards under international review to incorporate latest FHIR features
• Expanded FHIR capabilities in integration engines and health data platforms
• Potential consolidation and deprecation of overlapping standards

Despite its current limitations, FHIR solves real healthcare interoperability needs and has too much momentum to stop. Patient and provider demand for seamless healthcare data access will only accelerate FHIR adoption. It will eventually subsume and consolidate overlapping standards. FHIR aims to finally deliver on the promise of standards-based healthcare interoperability.

Conclusion

HL7 and FHIR both facilitate healthcare interoperability, but take fundamentally different technical approaches. While earlier HL7 standards paved the way, FHIR represents a major evolution in how healthcare data is modeled, accessed, and exchanged.

FHIR provides a simpler, modular, web-based model for exchanging patient health data that better aligns with modern software best practices. Adoption is accelerating to replace dated interfaces. FHIR capabilities will eventually become a baseline requirement for health IT systems.

Despite its current limitations as a relatively new standard, FHIR represents the future of healthcare interoperability.