A History of HL7: From Terminals to APIs
A journey through 30 years of healthcare interoperability from costly 1980s interfaces to modern FHIR APIs following HL7's evolution to web-friendly resources.
HL7 (Health Level Seven International) is a not-for-profit standards development organization (SDO) founded in 1987 that creates frameworks and standards for the exchange, integration, sharing, and retrieval of electronic health information. Its standards act as a common language that lets separate healthcare systems - Electronic Health Records (EHRs), labs, pharmacies, and billing platforms - pass data to each other accurately and reliably. The HL7 family includes HL7 v2, HL7 v3, the Clinical Document Architecture (CDA), and FHIR.
Introduction
HL7, or Health Level Seven, is the standards organization that has been trying to fix healthcare’s data communication problem since 1987. Over the past four decades, it has produced the messaging standards that most hospitals, labs, pharmacies, and health IT vendors run on. From the pipe-delimited HL7 v2 messages that still flow through nearly every US hospital today, to the modern FHIR APIs now mandated by federal regulation, HL7 standards are the foundation of clinical data exchange.
Definition and Organizational Overview
The Full Name: Health Level Seven International
It is a set of technical standards for health information exchange between software applications which are produced by HL7 International, an international standards organization, and are adopted by other standards-issuing bodies such as the American National Standards Institute (ANSI) and International Organization for Standardization.
When a hospital’s lab system sends a test result to a physician’s EHR, it is HL7 standards that define how that message is structured, what each data field means, and how the receiving system should interpret it.
HL7’s Role as a Standards Development Organization
The core mission of HL7 International is to ensure that accurate health data is accessible to healthcare providers in a timely and secure way. It received accreditation from the American National Standards Institute (ANSI) in 1994, cementing its role in the health IT landscape.
HL7 standards go through a multi-year collaborative development process with input from its broad membership base. That membership includes over 1,600 corporate members spanning more than 50 countries, covering EHR vendors, health systems, government agencies, academic institutions, and technology companies. Every major standard HL7 publishes goes through this process, which is why the standards carry broad industry buy-in.
The “Level Seven” in HL7 - What Does It Means?
The “seven” in HL7 is a direct reference to the OSI (Open Systems Interconnection) model, a conceptual framework that describes how data moves across a network in seven layers. Layer 7 is the application layer, the topmost layer where software applications actually exchange meaningful data.
HL7 standards operate at this application layer. They are not concerned with how bytes travel across a wire or how packets are routed. They focus entirely on the content and meaning of the data being exchanged: what a patient record looks like, how a lab result is structured, how an admission event triggers a notification across systems.
The HL7 Standards Family - v2, v3, CDA, and FHIR
HL7 is not a single standard. It is a family of related standards, each designed for different purposes and eras of healthcare technology. Understanding the differences between them is essential for anyone working in health IT.
-
HL7 v2 (Version 2)
The most widely used healthcare messaging standard. It enables the exchange of clinical and administrative data (e.g., admissions, lab results, patient information) between healthcare systems using simple text-based messages. It is flexible and easy to implement but can lead to variations between organizations.
-
HL7 v3 (Version 3)
Developed to provide a more consistent and structured approach than v2. It uses a formal information model called the Reference Information Model (RIM) and relies on XML-based messaging. While more rigorous, it is also more complex and saw limited adoption compared to v2.
-
CDA (Clinical Document Architecture)
An HL7 v3-based standard for exchanging clinical documents such as discharge summaries, progress notes, and care plans. CDA documents are human-readable and machine-processable, making them useful for document sharing and health information exchange.
-
FHIR (Fast Healthcare Interoperability Resources)
HL7’s modern interoperability standard. FHIR uses web technologies such as REST APIs, JSON, and XML, making it easier for developers to build healthcare applications. Data is organized into reusable “resources” (e.g., Patient, Observation, Medication). FHIR is currently the fastest-growing and most widely adopted HL7 standard for new healthcare systems.
You can have a look at their detailed comparison here - https://medblocks.com/blog/what-is-fhir#fhir-vs-hl7-v2-vs-v3-at-a-glance
HL7 Version 2 (v2) - The Workhorse of Healthcare IT
The organizations that are actively building FHIR APIs, the internal messaging backbone almost always runs on v2. It was first released in 1987 and has gone through incremental updates like v2.1, v2.2, all the way up to v2.9. Because v2 is backward compatible, applications can correctly receive and appropriately handle different versions in the v2 family. That backward compatibility is one major reason it has survived for nearly four decades. Read more https://medblocks.com/blog/what-is-fhir#hl7-v2-brought-pipe-delimited-messaging
A HIMSS survey found that more than 95 percent of large hospitals rely on HL7 v2 for internal integration. That is a remarkable figure for a standard built before the modern web existed.
HL7 v2 Interfaces - How Hospitals Use Them Today
In a typical hospital, HL7 v2 messages flow through an interface engine, a software that sits in the middle, receives incoming messages, transforms them as needed, and routes them to the right destination systems. Common interface engines include Mirth Connect (open source), Rhapsody, Iguana, and Azure Health Data Services.
The Challenge of HL7 v2 Variations and Non-Standard Implementations
Here is the dirty secret of HL7 v2 adoption: the standard is flexible to the point of being inconsistent. HL7 v2 allows many optional segments and custom Z segments. Vendors and even individual health systems often define local variations. Two ADT feeds from two hospitals rarely look identical, even when both claim HL7 v2 compliance. This variation increases interface mapping and testing work.
Epic, Cerner, and other major EMR vendors implement HL7 standards with proprietary extensions and variations. These differences require custom interface mapping and specialized integration tools costing organizations $500,000 to $2 million annually for interface engine licensing and support.
HL7 CDA (Clinical Document Architecture) - Documents in Healthcare
The Clinical Document Architecture (CDA) is an HL7 v3-based standard for clinical documents, such as discharge summaries or consult notes. The Consolidated CDA (C-CDA) format, required under Meaningful Use and now the Cures Act, defines standard templates for summary of care documents.
The most common use of CDA in the US is the Continuity of Care Document (CCD), which packages a patient’s summary, diagnoses, medications, allergies, labs into a structured XML document that can travel between providers. ONC reported that by 2021, about 70 percent of US hospitals could electronically send summary of care records to external organizations, often using C-CDA over transport protocols such as Direct.
HL7 Version 3 - The Ambitious Standard That Struggled
Development of version 3 started around 1995, resulting in an initial standard publication in 2005. The v3 standard, as opposed to version 2, is based on a formal methodology and object-oriented principles.
The idea behind v3 was noble: create a fully rigorous, model-driven standard that eliminated the ambiguity plaguing v2. The Reference Information Model (RIM) is the cornerstone of the HL7 Version 3 development process. RIM expresses the data content needed in a specific clinical or administrative context and provides an explicit representation of the semantic and lexical connections that exist between the information. Read More - https://medblocks.com/blog/what-is-fhir#hl7-v3-tried-to-fix-things-with-a-single-model
The problem? Adoption of the RIM in HL7 v3 introduced uniformity but overextended in achieving its goal of standardization and turned out to be too inflexible for practical use. In particular, HL7 v3 required application users to understand the RIM to effectively use the tools for data exchange. The regulatory changes required to implement the standard and training programs to educate users made the adoption of HL7 v3 complex and expensive. This proved to be antithetical to the goal of the HL7 organization, which was to develop cheap and simple solutions for healthcare information exchange.
HL7 v3 also lacked backward compatibility with v2, which meant any system adopting it had to make a clean break from existing infrastructure. Most hospitals were not willing to do that. So v3 became a standard that exists in the spec sheets but rarely in production hospital environments.
HL7 FHIR - The Modern Standard Built for APIs
The shortcomings of HL7 v2 and v3 motivated the development of the latest HL7 standard: FHIR. In 2014, HL7 introduced FHIR as an important alternative to HL7 V2 and V3 standards. FHIR, which was first drafted in 2011, is an open standard that enables new apps and legacy systems to more easily exchange data. It was developed to not only improve interoperability and enhance efficiency of communication but also streamline implementation compared with previous standards, providing easily understood specifications and enabling developers to capitalize on common web technologies.
As you can see in the images above, FHIR uses RESTful APIs, JSON, and HTTP - the same building blocks developers already use for web and mobile applications. Instead of sending a monolithic pipe-delimited message, FHIR exchanges granular “resources” like Patient, Observation, Condition, and MedicationRequest. Each resource is a self-contained JSON object that developers can work with using standard tools.
Have a look at the detailed article on HL7 FHIR - https://medblocks.com/blog/what-is-fhir#a-fresh-look-at-interoperability-and-the-birth-of-fhir
HL7 and EHR Integration - What Developers and Architects Need to Know
Understanding HL7 at the conceptual level is one thing. Making it work inside a real hospital environment is another. Here is what matters on the ground.
HL7 Interfaces in Epic, Cerner, and Other Major EHRs
Every major EHR platform supports HL7 v2 which is a basic requirement. Epic uses its own interface engine internally and exposes HL7 v2 feeds via its “Chronicles” backend for integration with third-party systems. Cerner (now Oracle Health) similarly exposes HL7 v2 for lab results, ADT messages, and orders through its Millennium platform.
ONC notes that about 87 percent of certified health IT developers support FHIR-based APIs, and support among large EHR vendors is nearly universal. Epic’s FHIR API (MyChart and their Interconnect service) is widely used for patient-facing apps. Cerner’s HealtheIntent platform similarly exposes FHIR R4 endpoints.
But even at hospitals running the latest Epic or Oracle Health builds, HL7 v2 still carries the bulk of internal operational messaging. ADT feeds to bed management, lab results back to ordering providers, orders from CPOE to the pharmacy. These all run on v2 in most environments today.
The choice of interface engine matters. Mid-size hospitals typically spend $500,000 to $1.2 million annually on interface engine licensing, maintenance, and technical support. Large health systems may invest $2-5 million yearly in HL7 infrastructure, including software licensing, specialized staff, monitoring tools, and vendor support services.
Interface Engines - Mirth Connect, Rhapsody, and Azure Health Data Services
An interface engine is the translation layer that sits between sending and receiving systems. It receives an HL7 message, applies transformation logic (mapping fields, filtering events, reformatting data), and routes the message to its destination.
Common interface engines include:
- Mirth Connect: Open-source, widely used in smaller health systems and by integration teams building custom workflows. Free to use, with commercial support available from NextGen.
- Rhapsody (now part of Lyniate): A commercial-grade engine used by large health systems and HIEs for high-volume, mission-critical interfaces.
- Azure Health Data Services: Microsoft’s cloud-native integration platform that supports both HL7 v2 and FHIR, ideal for organizations building on Azure infrastructure.
- Google Cloud Healthcare API: Similar cloud-native offering from Google, supporting HL7 v2, FHIR, and DICOM.
Migrating from HL7 v2 to FHIR - A Practical Roadmap
Migrating from HL7 v2 to FHIR is not a rip-and-replace exercise. It is a gradual transition that most organizations complete over multiple years. Here is a practical roadmap:
Phase 1: Inventory and Assessment Catalog all existing HL7 v2 interfaces. Document the message types, volumes, sending/receiving systems, and custom Z-segments in use. Identify which interfaces are mission-critical versus low-priority.
Phase 2: Identify FHIR-Ready Use Cases Not all HL7 v2 workflows are equally ready for FHIR. Patient-facing apps, external partner integrations, and analytics pipelines are good starting points. Internal real-time ADT and order messaging can come later.
Phase 3: Stand Up a FHIR Server Deploy a FHIR R4 server (either through your EHR vendor or a standalone solution like the Medblocks FHIR platform). Validate that it supports the USCDI data elements required for ONC certification.
Phase 4: Using ETL Pipelines to Transform HL7 v2 to FHIR
ETL (Extract, Transform, Load) pipelines can parse incoming HL7 v2 messages, map them to corresponding FHIR resources, and load the results into a FHIR server. For example, an ADT^A01 message maps to a FHIR Encounter resource (plus a Patient resource, a Location resource, and potentially a Practitioner resource). A lab ORU message maps to a FHIR Observation resource referencing a DiagnosticReport.
Phase 5: Validate, Monitor, and Retire Legacy Feeds Once FHIR flows are validated and stable, legacy v2 interfaces for those workflows can be decommissioned. Monitor error rates and data quality continuously. Retire v2 feeds methodically, not all at once.
Migration strategies typically involve hybrid environments where FHIR applications coexist with legacy HL7 v2 systems. This minimizes disruption while enabling modern capabilities for emerging use cases like patient-facing apps and AI integration.
This layout demonstrates that healthcare modernization is not about choosing between traditional interface engines or cloud repositories, rather it is about utilizing both to build a continuous, future-proof data pipeline.
The Reality of Hybrid Interoperability: Connecting the Old World to the New
In theory, migrating to modern healthcare data standards looks like a clean, one-time swap. In the reality of live hospital operations, it is a multi-generational architectural balancing act. Millions of dollars of functioning, on-premise clinical hardware cannot be replaced overnight, meaning legacy formats must seamlessly coexist with modern cloud APIs.
Achieving this balance requires shifting from isolated, “point-to-point” plumbing to a modern, centralized data ecosystem.
The flowchart below illustrates this real-world hybrid topology in action during a standard patient encounter:
- The Legacy Pipeline Layer: When a clinical event occurs, legacy systems stream standard real-time messages (such as HL7 v2). An interface engine like Mirth or Rhapsody sits at the center, functioning as the primary translator booth. It ensures traditional on-premise systems receive the old-school feeds they require to operate without modification.
- The Cloud-Native Data Platform Layer: Simultaneously, the interface engine normalizes and converts that live legacy data stream into a modern, standardized JSON format on the fly, feeding it directly into a centralized reservoir like Azure Health Data Services.
- The Consumer & Analytics Layer: By decoupling the data store from the legacy hardware, the cloud reservoir acts as a permanent, searchable single source of truth. Modern applications, AI diagnostic engines, and mobile tools can query it instantly via secure REST web APIs, while compliance engines can bundle historical timelines into structured XML clinical documents for external health exchanges.
HL7 and Clinical Terminology Standards - SNOMED, LOINC, and ICD
An HL7 message defines structure: where the data lives, how the segments are ordered, what each field position represents. But structure alone does not guarantee that two systems will interpret the same data the same way. That is where clinical terminology standards come in.
Understanding the Blueprint: Why Structure Needs Meaning
A common pitfall in healthcare interoperability is assuming that an HL7 standard alone is enough to share patient data successfully.
In practice, data exchange requires two distinct layers:
- The Structural Layer (The Envelope): Standards like HL7 v2, CDA, and FHIR define where data lives, how segments are ordered, and how messages are packaged. They ensure System A can mechanically open a message sent by System B.
- The Semantic Layer (The Language): Clinical terminology standards define what the data actually means. They translate raw clinical text into universal, unalterable mathematical codes.
Without semantic coding, one system might log Type 2 Diabetes as “DM2”, another as “E11”, and a third as “44054006”. While structurally sound, the receiving system’s analytics and clinical decision support engines will fail to identify them as the same disease.
The diagram below maps how the three pillars of clinical terminology LOINC, SNOMED CT, and ICD-10 integrate directly into legacy HL7 v2 workflows and modern FHIR data structures to achieve true semantic interoperability.
The critical point here is that HL7, LOINC, SNOMED, and ICD work as a system. HL7 provides the envelope. Terminology standards provide the content. You need both to achieve true semantic interoperability, the kind where two completely different systems can exchange data and both understand what it means at a clinical level, not just a structural one.
HL7 Certification and Compliance in 2025
For healthcare compliance teams and administrators, HL7 is no longer just a technical concern. It is a regulatory requirement.
ONC Certification and HL7 FHIR Requirements
The API certification criterion requires the use of HL7 FHIR Release 4 and references several standards and implementation specifications to support standardization and interoperability. This certification criterion aligns industry efforts around FHIR Release 4 and advances interoperability of API-enabled “read” services for single and multiple patients.
In practical terms: any EHR vendor seeking ONC certification must now support FHIR R4 APIs. This is not optional. About 87 percent of certified health IT developers support FHIR-based APIs, and support among large EHR vendors is nearly universal.
The ONC HTI-1 final rule includes revised certification criteria for “decision support interventions,” “patient demographics and observations,” and “electronic case reporting,” as well as a new baseline version of the United States Core Data for Interoperability (USCDI) standard updated to Version 3.
The 21st Century Cures Act’s Impact on HL7 Standards
The 21st Century Cures Act, signed into law in 2016, is the single biggest regulatory driver of FHIR adoption in the United States. The ONC Interoperability and Information Blocking Final Regulation implements key provisions of the 21st Century Cures Act focused on advancing interoperability and supporting the access, exchange, and use of electronic health information. ONC’s regulation establishes API requirements using the FHIR standard, including for patients to use APIs to electronically access all of their EHI, structured and/or unstructured, at no cost.
FHIR adoption is accelerating due to regulatory requirements. The 21st Century Cures Act and CMS Interoperability Rule mandate FHIR API availability for certain use cases, driving organizational adoption.
The information blocking provisions of the Cures Act are equally significant. Health IT developers, health information networks, and healthcare providers are prohibited from taking actions that unreasonably interfere with the access, exchange, or use of electronic health information. Health IT developers and HIEs face civil monetary penalties up to $1,000,000 per violation, enforced by the HHS Office of Inspector General.
TEFCA and HL7 FHIR as the Interoperability Backbone
TEFCA (Trusted Exchange Framework and Common Agreement) is the ONC’s framework for establishing a nationwide health information network. The Cures Act laid out a vision for a rich health IT ecosystem of standards-based APIs and nationwide health information networks to securely open up electronically accessible information to patients themselves and to healthcare professionals supporting their care. Progress on nationwide network integration via TEFCA continues as all actors covered by the information blocking provisions of the Cures Act are required to make available the full scope of electronic health information to other authorized parties.
FHIR is the technical backbone of TEFCA. Qualified Health Information Networks (QHINs) operating under TEFCA use FHIR R4 for data exchange. CMS-0057-F mandates four FHIR-based APIs: Patient Access API, Provider Access API, Payer-to-Payer API, and Prior Authorization API. All four must be operational by January 1, 2027, built on HL7 FHIR R4.0.1 with USCDI data standards.
The compliance landscape is moving fast. Organizations that treat FHIR as a future consideration rather than a current priority are falling behind both technically and regulatorily.
HL7 in Action: Real-World Use Cases
Here are four scenarios where HL7 standards make a direct clinical and operational difference.
Use Case 1: Patient Admission Notification When a patient is admitted to a hospital, the admissions system fires an ADT^A01 message. That single message simultaneously notifies the pharmacy (so it can prepare medication reconciliation), the lab (so it knows who is in-house), the billing system (to open a new account), and infection control (to check for isolation flags). Without that HL7 message flowing reliably, each of those downstream systems operates blind.
Use Case 2: Lab Result Routing A physician orders a blood culture in the EHR. An ORM message carries that order to the lab information system (LIS). When results are ready, the LIS sends an ORU^R01 message back to the EHR including the LOINC code for the organism identified and the antibiotic sensitivity results in structured OBX segments. The physician sees the result in real time without anyone having to manually enter data.
Use Case 3: Medication Dispensing An ORM message from the EHR reaches the pharmacy system with the drug name, dose, route, and frequency. The pharmacy system verifies and dispenses, then sends back an acknowledgment. All of this happens without a phone call or paper form.
Use Case 4: Care Transitions via C-CDA When a patient is discharged from a hospital and transferred to a skilled nursing facility, a C-CDA document (built on HL7 CDA) containing the discharge summary, medication list, problem list, and allergies is transmitted via Direct secure messaging. The receiving facility’s EHR imports the document, reducing the risk that critical information gets lost in the handoff.
Conclusion - HL7 Is the Foundation; FHIR Is the Future
HL7 spent the last four decades building the infrastructure that clinical data exchange runs on. HL7 v2 is imperfect as its flexibility creates inconsistency, and its age shows in every pipe-delimited segment. But it works. And it will continue to work inside hospital walls for years to come.
The direction, though, is unmistakable. FHIR is the standard that regulators have mandated, that EHR vendors have adopted, and that health IT developers are building toward. 78% of US hospitals now use FHIR-based APIs for clinical data exchange, often alongside traditional HL7 v2 systems, creating hybrid environments requiring sophisticated integration platforms to manage multiple standards simultaneously.
If you work in health IT whether as a developer, architect, informatics professional, or administrator, you need to understand both sides of this picture. HL7 v2 because it is the operational reality in most hospitals right now. FHIR because it is the foundation everything new is being built on.
The Medblocks FHIR Bootcamp gives you exactly this: practical, hands-on training in both HL7 standards and FHIR development, structured for people who need to build real things in real healthcare environments. Whether you are debugging a broken ADT feed or designing a FHIR-based clinical app, the Bootcamp gives you the skills to work with confidence.
Explore the Medblocks FHIR Bootcamp and start building the interoperability skills that health IT teams genuinely need right now.
Key Takeaways
- HL7 is a family, not a single standard. It includes HL7 v2, HL7 v3, CDA, and FHIR where each of them serves different purposes and eras of healthcare IT.
- HL7 v2 is deeply embedded. It has been adopted by more than 35 countries, with greater than 95% coverage in healthcare organizations in the United States.
- HL7 v3 is largely a cautionary tale. The regulatory changes required to implement v3 and the training needed to educate users made adoption complex and expensive, proving antithetical to the goal of developing cheap and simple solutions.
- FHIR is the regulatory mandate. The ONC Cures Act Final Rule requires the use of HL7 FHIR Release 4 for API certification, aligning industry efforts around FHIR R4.
- The “standard” is not always standard. HL7 v2 allows many optional segments and custom Z segments. Vendors and health systems often define local variations. Two ADT feeds from two hospitals rarely look identical, even when both claim HL7 v2 compliance.
- Interface failures have real costs. HL7 interface failures cost hospitals an average of $8,000 per site in operational disruption and can delay lab results, prevent medication orders from reaching pharmacies, and disrupt billing processes.
- Terminology standards complete the picture. HL7 defines structure; LOINC, SNOMED CT, and ICD-10 define meaning. You need both for true interoperability.
- Migration is gradual, not overnight. Migration strategies typically involve hybrid environments where FHIR applications coexist with legacy HL7 v2 systems, minimizing disruption while enabling modern capabilities.
- Compliance pressure is real and growing. CMS mandates four FHIR-based APIs which are Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization, all being operational by January 1, 2027, built on HL7 FHIR R4.0.1 with USCDI data standards.
- Medblocks build directly on these standards. Whether through openFHIR or the FHIR Bootcamp, Medblocks equips health IT teams to work confidently at every layer of the HL7 and FHIR stack.
Frequently asked questions
What is HL7 used for?
HL7 is used to standardize the exchange of clinical and administrative data between different healthcare software systems. In practice, this means routing lab results from a lab information system to an EHR, sending patient admission notifications to downstream systems, transmitting medication orders to a pharmacy, and packaging patient summaries for care transitions. It provides a common language that lets systems from different vendors talk to each other without requiring custom, one-off data formats.
What is the difference between HL7 and FHIR?
FHIR is a member of the HL7 family which was developed and maintained by HL7 International. The distinction most people are drawing when they contrast “HL7 and FHIR” is between HL7 v2 (the legacy pipe-delimited messaging standard) and FHIR (the modern RESTful API standard). HL7 v2 is event-driven and uses flat text messages. FHIR relies on RESTful web services and open web technologies, such as JSON and RDF data formats. FHIR is designed for web and mobile applications; HL7 v2 was designed for point-to-point hospital messaging. Most organizations today use both.
Is HL7 v2 still used?
Yes, and extensively. HL7 v2 remains the dominant standard, used by 95% of healthcare organizations for system-to-system messaging. Despite being nearly 40 years old, its longevity comes from the massive investment healthcare organizations have made in v2-based interfaces, its backward compatibility, and the sheer number of legacy systems that depend on it. FHIR is growing rapidly, but it has not replaced v2 but runs alongside it. A HIMSS survey found that more than 95 percent of large hospitals rely on HL7 v2 for internal integration. That persistence explains why you still need HL7 expertise even as FHIR adoption grows.
What is an HL7 message?
An HL7 message is a structured text file that carries clinical or administrative data from one system to another. In HL7 v2, a message consists of a series of segments, each on its own line and identified by a three-letter code (MSH, PID, OBR, etc.), with fields separated by pipe characters. Each message type corresponds to a real-world event: a patient admission, a lab result, a medication order. The receiving system parses the message, extracts the relevant data, and updates its own records accordingly.
What does HL7 stand for?
HL7 stands for Health Level Seven. The “seven” refers to the seventh layer of the OSI (Open Systems Interconnection) networking model, which is the application layer. This signals that HL7 standards operate at the application level as they define the content, structure, and meaning of health data being exchanged, not the network transport mechanics below it.
What is HL7 CDA?
HL7 CDA stands for Clinical Document Architecture. It is an HL7 v3-based standard for structuring clinical documents in XML format. CDA is used primarily for documents like discharge summaries, progress notes, referral letters, and patient care summaries. The most commonly used CDA format in the US is the Consolidated CDA (C-CDA), which defines specific templates for documents like the Continuity of Care Document (CCD). C-CDA was required under Meaningful Use and remains part of the USCDI requirements under the 21st Century Cures Act.
Who maintains HL7 standards?
HL7 standards are maintained by HL7 International, a not-for-profit standards development organization. HL7 International operates through technical committees and working groups made up of member organizations consisting of EHR vendors, healthcare providers, government agencies, academic institutions, and technology companies. It has over 1,600 corporate members across more than 50 countries. HL7 International is accredited by the American National Standards Institute (ANSI) and works in coordination with the International Organization for Standardization (ISO).
How does FHIR relate to HL7 v2?
FHIR was built by HL7 International to address the limitations of HL7 v2 and v3. FHIR builds on previous standards, including HL7 v2, HL7 v3, and CDA. Rather than replacing v2 overnight, FHIR exists alongside it. The current strategy most health systems follow is to use HL7 v2 for internal real-time operational messaging and FHIR APIs for external integrations, patient-facing apps, and regulatory compliance. Over time, as FHIR tooling matures and implementation costs drop, this balance is expected to shift.
What are the most common HL7 v2 message types?
The most common HL7 v2 message types are ADT (Admit, Discharge, Transfer), ORU (Observation Result Unsolicited, for lab results), ORM (Order Message, for placing orders), and MDM (Medical Document Management, for transcribed or scanned documents). ADT messages are particularly pervasive: in a 2023 national survey of HIEs, more than 90% of HIEs reported that they routinely or sometimes received and sent CDAs, and most HIEs routinely received and sent HL7 v2 messages. 96% of HIEs reported receiving HL7 v2 ADT messages.
What is the USCDI and how does it relate to HL7?
USCDI (United States Core Data for Interoperability) is a standardized set of health data elements defined by ONC that certified health IT systems must be able to exchange. It defines what data is required for, like patient demographics, medications, allergies, lab results, and clinical notes. HL7 FHIR is the primary transport mechanism for USCDI data under ONC certification requirements. ONC’s HTI-1 final rule established a new baseline version of the United States Core Data for Interoperability (USCDI) standard updated to Version 3. In short, USCDI tells you what to share; FHIR defines how to share it.
Related articles
View all
What is FHIR? The Complete Guide to Healthcare Interoperability
The complete guide to FHIR (Fast Healthcare Interoperability Resources). Learn FHIR resources, R4, Profiles and Implementation Guides, SMART on FHIR, HL7 history, and how to start.
CDS Hooks Matter More Than You Think
CDS Hooks are more than alerts: they’re real-time EHR webhooks that can surface a card and launch a SMART on FHIR app, letting you run workflows outside the EHR. The key is relevance + low latency, and rising adoption.
