HL7 vs FHIR: The Key Differences

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.