What Is HL7? Standards, Versions, Use Cases, and Healthcare Interoperability (2026 Guide)

HL7 (Health Level Seven) is a family of healthcare data standards that defines how clinical systems exchange patient information, orders, results, and clinical documents. The Health Level Seven International standards organization, ANSI-accredited and founded in 1987, maintains four distinct standard families used across healthcare IT: HL7 V2 (the pipe-delimited messaging standard that has run hospital interoperability since the late 1980s), HL7 V3 (the XML-based standard largely superseded except for clinical documents), CDA (Clinical Document Architecture, the structured clinical document format), and HL7 FHIR (the modern REST API standard introduced in 2014).

Different healthcare workflows use different HL7 standards. Real-time messaging between hospital systems runs primarily on V2. Patient summary documents and continuity-of-care exchanges use CDA. Modern API integrations and patient portal data access use FHIR. In radiology specifically, HL7 V2 messages are the connective layer between the EHR, RIS, PACS, and modality — every imaging order, worklist entry, and report delivery depends on HL7 messages arriving with the correct segments, fields, and patient identifiers.

This guide covers what HL7 is, how each standard family works, where each fits within healthcare IT architecture, how HL7 connects to broader interoperability frameworks such as TEFCA and USCDI, and how organizations implementing HL7 should approach V2, FHIR, and the migration between them.

What is HL7? Origins, scope, and what the name actually means

HL7 stands for Health Level Seven International. It is an ANSI-accredited standards development organization founded in 1987, and it produces the messaging and interoperability standards most hospital IT infrastructure runs on.

The “Level Seven” in the name refers to the seventh layer of the OSI network model, the application layer. HL7 operates at that layer. It does not specify how data moves between systems (that is, TCP/IP and the layers below it). It specifies what the data means and how it must be structured upon arrival. Two systems can understand each other’s HL7 messages because they have both agreed on what the segments, fields, and values in those messages represent.

The HL7 International organization is a non-profit standards body with members across hospital systems, EHR vendors, medical device manufacturers, government agencies, and software developers globally. Standards are developed through working groups that publish draft standards for trial use, refine them based on implementer feedback, and eventually publish them as Normative or Informative standards through ANSI’s accreditation process. This open-standards process is one of the reasons HL7 has become the dominant healthcare messaging framework worldwide, rather than being replaced by proprietary vendor standards.

The organization produces several distinct standard families that solve different healthcare interoperability problems. The four that matter most in clinical practice are HL7 V2, HL7 V3, CDA (Clinical Document Architecture), and HL7 FHIR. Each was designed at a different time, for different use cases, with different architectural assumptions. Understanding when each applies, and how they coexist in modern healthcare environments, is the foundation of practical HL7 knowledge.

The HL7 standard family: V2, V3, FHIR, and CDA

HL7 is not a single standard. It is a family of related standards developed over four decades, each addressing different healthcare interoperability needs. The four most important members of the family are the ones healthcare IT teams encounter in real implementations.

HL7 V2 is the operational messaging backbone of hospital IT since the late 1980s. It uses pipe-delimited text messages sent between systems to communicate orders, results, patient registrations, and status updates. Despite being decades old, V2 remains the dominant messaging standard in hospital interoperability worldwide, with roughly 95 percent of US hospitals using V2 messaging in production.

HL7 V3 is the XML-based standard introduced in the early 2000s as a more rigorous successor to V2. The Reference Information Model (RIM) underlying V3 provided more semantic precision than V2, but the implementation complexity proved too high for widespread adoption. V3 messaging never displaced V2 in clinical workflows. The one V3-family standard that did achieve broad clinical adoption is CDA.

CDA (Clinical Document Architecture) is the V3 family member used for structured clinical documents. CDA defines a standard XML format for clinical narratives like discharge summaries, progress notes, consultation reports, and continuity-of-care documents. The most widely deployed CDA implementation is the Consolidated CDA (C-CDA), required by US Meaningful Use and ONC certification programs for exchanging patient summary information between healthcare organizations.

HL7 FHIR (Fast Healthcare Interoperability Resources) is the modern API-based standard introduced in 2014. FHIR uses REST, JSON, and web service patterns rather than the pipe-delimited text of V2 or the XML of V3 and CDA. It is the direction modern EHR and PACS architectures are moving, and the standard underlying patient portal APIs, third-party app integrations, and emerging healthcare data exchange platforms.

The four standards are not competitors that replace each other sequentially. They are architecturally different approaches to interoperability that coexist in modern healthcare environments. Most US hospitals run V2 for real-time messaging, CDA for clinical document exchange, and FHIR for modern API integrations, all simultaneously.

Standard	Introduced	Format	Primary use case	Adoption status
HL7 V2	Late 1980s	Pipe-delimited text messages	Real-time event-driven messaging between hospital systems (orders, results, ADT)	Dominant in production hospital IT worldwide
HL7 V3	Early 2000s	XML based on Reference Information Model	Semantically rigorous messaging (designed but not widely adopted)	Largely superseded; CDA is the surviving V3-family standard
CDA	2005 (V3 family)	Structured XML clinical documents	Patient summaries, discharge documents, continuity of care exchange (C-CDA)	Required by ONC certification for US Meaningful Use
HL7 FHIR	2014	REST APIs with JSON or XML resources	API-based integrations, patient portals, third-party app access, modern cloud architectures	Growing rapidly; the direction of new healthcare IT builds

HL7 V2: the operational messaging backbone

HL7 V2 uses an event-driven messaging model. When something happens in a clinical system, a patient is registered, an order is placed, a result is ready, the system generates an HL7 message describing that event, and sends it to the systems that need to know.

Every V2 message has the same structural logic. The message is composed of segments, each on its own line, each identified by a three-letter code. Fields within a segment are separated by pipe characters. Subfields are separated by carets. Repeating values are separated by tildes.

An imaging order message — the ORM^O01 — looks like this in practice:

MSH|^~&|EPIC|HOSPITAL|RIS|RADIOLOGY|20250210143022||ORM^O01|987654|P|2.5
PID|1||MRN123456^^^HOSPITAL||SMITH^JOHN^A||19720315|M
ORC|NW|ORD-2025-4421||||||20250210143000
OBR|1|ORD-2025-4421||71046^CHEST XRAY 2 VIEWS^CPT|||20250210150000|||||||||DR JONES^REFERRING
ZDS|2.25.123456789|RIS|SCHEDULED

Breaking this down by segment:

MSH (Message Header) identifies the sending and receiving systems, the timestamp, the message type (ORM^O01 means Order Entry, New Order event), and the HL7 version.

PID (Patient Identification) carries the patient’s MRN, name, date of birth, and sex. This is the demographic data that must match exactly across RIS, PACS, and modality for images to auto-reconcile.

ORC (Common Order) carries the order control code (NW means New Order) and the order number.

OBR (Observation Request) includes the procedure code, accession number, requested exam time, and referring physician.

ZDS is a Z-segment, a custom segment defined locally by the vendor, used here to pass the DICOM Study Instance UID.

The caret notation in the message type field, ORM^O01, indicates the message type ORM (Order Entry) and event O01 (New Order). This notation is used to express HL7 message types throughout the radiology IT stack. When an interface engine log shows ADT^A08, it means the message type is ADT (Admit/Discharge/Transfer) and the event is A08 (Patient Update).

Understanding this structure matters for troubleshooting. A broken link between an image and its order is almost always a data mismatch between what the ORM message carried and what arrived at the PACS. The mismatch is in a specific field, usually PID-3 (Patient ID / MRN) or OBR-18 (Accession Number). Knowing the segment and field structure makes that diagnostic search tractable.

HL7 V2 message types in clinical workflows

Six message types recur throughout clinical workflows, particularly in the imaging workflow, where HL7 V2 connects EHR, RIS, PACS, and modality. Each maps to a specific event in the care delivery cycle.

ADT: Admit, Discharge, Transfer

ADT messages carry patient identity and registration data. They fire before orders are placed, when a patient is first registered in the HIS or EHR. The RIS receives ADT messages to identify a patient (MRN, full name, date of birth, insurance, encounter information) before any imaging order is created.

The two ADT events that matter most in imaging are ADT^A01 (Patient Admission, a new patient encounter is opened) and ADT^A08 (Patient Information Update, demographics are corrected). ADT^A08 is the update message that HL7 V2 architectures frequently fail to propagate correctly. A name correction in the EHR fires an A08, the RIS receives it and updates its record, but the PACS, if it has no bidirectional ADT feed, retains the original registration. The split record is born.

ORM: Order Entry

ORM^O01 is the message that initiates the radiology workflow. When a physician places an imaging order in the EHR or CPOE, the ordering system generates an ORM^O01 and sends it to the RIS. This is Step 1 of the IHE Scheduled Workflow (SWF) transaction sequence.

The ORM carries everything the RIS needs to create a Scheduled Procedure Step and make it available on the Modality Worklist: patient demographics, accession number, procedure code, ordered exam time, ordering physician, and priority. The accession number generated at this point serves as the linking key that will follow the study through the entire workflow, from MWL response to DICOM image tags to MPPS completion signal to the final report.

ORM also carries order status updates beyond new orders. ORM^O01 with ORC order control code CA (Cancel Order) cancels a scheduled exam. XO (Change Order) modifies it. These update messages are where many legacy integrations break: the original order arrives fine, but cancellation or modification messages use different ORC control codes that the receiving system was never configured to handle.

ORU: Observation Result

ORU^R01 carries the imaging result, the radiology report, back to the ordering system. When the radiologist signs the final report in the RIS or reporting system, an ORU^R01 fires to the referring physician’s EHR, the patient’s primary HIS, and any other registered result recipients.

The ORU message either carries the report text directly (in OBX segments, one per observation) or references the report document stored elsewhere. In modern deployments, the report itself may be a DICOM Structured Report or a PDF attached to the FHIR DiagnosticReport resource, but the notification that a result exists and where to find it still often travels as ORU^R01 in V2 environments.

ORU failure is the most visible integration failure in the workflow from the clinician’s perspective. The radiologist signed the report, the study was completed in PACS, but the referring physician never received the result. The study is also not billed because the billing trigger depends on the ORU reaching the billing system and on the order status being set to Finalized.

ACK: Acknowledgment

ACK messages are the receiving system’s response to any inbound HL7 message. An AA acknowledgment code (Application Accept) indicates that the receiving system has successfully processed the message. An AE (Application Error) or AR (Application Reject) means it did not.

The ACK is also where V2’s fundamental limitation becomes visible. An AA acknowledgment confirms that the receiving system’s message parser accepted the message, not that the system acted on it correctly. The interface engine can log a clean ACK while the RIS silently discards the order because the procedure code was unrecognized. This is why HL7 interface monitoring requires watching application logs, not just ACK codes.

Message	Direction	What it carries	Where it appears in the workflow
ADT A01	HIS to RIS	New patient registration / encounter open	Establishes patient identity in RIS before any order is placed
ADT A08	HIS to RIS / PACS	Patient information update	Propagates name corrections; often not received by PACS, causing split records
ORM O01	EHR to RIS	New imaging order with accession number	Step 1 of IHE SWF sequence; triggers Scheduled Procedure Step creation and Modality Worklist entry
ORM O01 (CA/XO)	EHR to RIS	Order cancellation or modification	Common failure point: legacy RIS/PACS often configured to receive O01 new orders but not cancel or modify events
ORU R01	RIS to EHR / HIS	Finalized radiology report	Closes the clinical loop; triggers referring physician notification and billing status update
ACK	Receiver to Sender	Message receipt acknowledgement	AA means accepted; AE means error; AR means rejected. Confirms parse success, not application action

What breaks when HL7 messages fail

HL7 V2 failures in clinical workflows produce a recognizable set of downstream symptoms. Understanding the failure pattern speeds diagnosis.

The lost order

An imaging order is placed in the EHR. The ORM^O01 fires. The interface engine logs an AA acknowledgment. The modality queries the MWL and finds nothing. The technologist manually enters the patient data.

The ORM arrived at the interface engine and was acknowledged, but the RIS never processed it because the procedure code in OBR-4 was not in the RIS procedure dictionary. Some interface engine configurations return AA on receipt rather than waiting for the downstream system to confirm processing. The result is a clean HL7 log and a missing worklist entry.

Fixing this requires monitoring application-level processing logs in the RIS, not just the interface engine’s ACK log. It also requires a defined exception workflow: what happens when the interface engine accepts a message that the RIS silently discards.

The split record

Images arrive in PACS from a CT scanner. The PACS cannot automatically reconcile them with the correct patient. They land in an unassigned folder. The images carry the correct DICOM tags (pulled from MWL). The MWL was populated correctly from the ORM. But the patient in the PACS was registered from an ADT^A01 that spelled the patient’s name differently than the ORM.

The accession number matches. The name does not. The PACS reconciliation logic requires both to match, but it fails. A technologist manually moves the study. The manual action creates a second event in the audit log, a billing delay, and a risk that the study is attached to the wrong patient record if the name difference is due to a different patient rather than a typo.

This is the most common identity integrity failure in radiology IT. The RIS-PACS Integration guide covers the mechanism in detail. The root cause at the HL7 level is that ADT and ORM messages for the same patient were generated from different source records across different systems, with no MPI (Master Patient Index) to enforce consistent identity.

The frozen status

The radiologist signs the report. The PACS shows the study as reported. The referring physician’s EHR never receives the result. The RIS shows the order as pending. Billing shows no claim.

The ORU^R01 fired but never arrived at the receiving system. In a push-only V2 architecture, the sender has no mechanism to detect this beyond a failed ACK, and ACK failures require the sender to retry and ultimately alert. If the retry logic is misconfigured, or if the failure was silent (the message arrived at the interface engine but the EHR discarded it), the ORU is lost, and no automatic recovery occurs.

Monitoring for ORU delivery failures requires tracking not just whether the message was sent, but also whether the downstream system’s order status changed to reflect receipt. In many legacy environments, this monitoring does not exist.

The uncancelled order

A patient cancels their appointment. The receptionist marks the order as canceled in the RIS. The cancellation ORM (ORC control code CA) fires to the PACS. The PACS was not configured to handle CA events. It was set up years ago to receive only new orders. The order remains active in PACS. When the patient reschedules and the study is acquired, two Scheduled Procedure Step records exist for the same accession number.

This is a configuration failure, not a protocol failure. HL7 defines the cancel message correctly. But it is representative of how legacy integrations accumulate technical debt: each order event type (new, cancel, modify, reschedule) requires explicit configuration in both the sending and receiving systems, and departments often configure only the happy path.

HL7 V3 and CDA: structured clinical documents

HL7 V3 emerged in the early 2000s as a more semantically rigorous successor to V2. The Reference Information Model (RIM) underlying V3 defined precise relationships between clinical concepts that V2’s pipe-delimited messages could express only loosely. V3 messaging promised better interoperability through stronger typing and more formal information modeling.

V3 messaging did not achieve widespread clinical adoption. The implementation complexity proved too high for hospital IT departments and EHR vendors who had already invested heavily in V2 infrastructure. The semantic rigor V3 required turned out to require expert-level information modeling skills that most healthcare IT teams lacked. Most V3 messaging implementations remained in research or pilot environments rather than production hospital workflows.

The one V3-family standard that did achieve broad clinical adoption is CDA (Clinical Document Architecture). CDA was introduced in 2005 as the V3 family’s structured clinical document standard, defining a standard XML format for clinical narratives. CDA documents have three layers: a structured header carrying patient identity, document type, and metadata; a structured body containing the clinical narrative in machine-readable form; and human-readable rendering data that displays the document like a traditional clinical note.

The most widely deployed CDA implementation is the Consolidated CDA (C-CDA), required by the US Meaningful Use program and the ONC Health IT Certification Program. C-CDA defines specific document templates for common clinical exchanges: Continuity of Care Document (CCD) for patient summary exchange between providers; Discharge Summary for hospital discharge documentation; Progress Note for outpatient encounter documentation; Consultation Note for specialist referrals; and Operative Note for surgical procedures. EHR systems certified for Meaningful Use must be able to generate and consume C-CDA documents in these templates.

C-CDA remains the dominant standard for clinical document exchange in US healthcare, particularly for use cases such as primary care-to-specialty referrals, hospital discharge transitions, and patient summary exchanges through health information exchanges (HIEs). FHIR Documents are emerging as the API-based successor to C-CDA, but C-CDA’s installed base in EHR systems means it will remain operationally important for years to come.

HL7 FHIR: the modern API-based standard

HL7 FHIR (Fast Healthcare Interoperability Resources) is the modern healthcare interoperability standard introduced in 2014 and rapidly becoming the dominant approach for new healthcare IT integrations. FHIR represents a fundamental architectural shift from the messaging patterns of V2 and the document patterns of CDA toward RESTful API patterns familiar to modern web developers.

The core architectural concepts of FHIR are simpler than V2 or V3. FHIR defines “resources” representing common healthcare data elements: Patient (demographic information), Observation (lab results, vital signs, clinical measurements), Encounter (clinical visit context), MedicationRequest (prescriptions), DiagnosticReport (lab and imaging results), ServiceRequest (orders for services), ImagingStudy (medical imaging metadata), and dozens of others. Each resource has a defined schema with required and optional fields, and each resource type has its own REST endpoint that supports standard HTTP operations (GET, POST, PUT, DELETE).

A FHIR API call for retrieving a patient’s recent observations looks like a standard REST call: GET /Observation?patient=12345&date=ge2026-01-01. The response is a JSON document containing FHIR Observation resources matching the query. This is the same pattern that any modern web developer uses for any REST API, by design. FHIR’s adoption strategy explicitly targeted developers outside the traditional healthcare IT world by using familiar web technology.

The drivers behind FHIR adoption include three structural forces. First, regulatory pressure: the 21st Century Cures Act and its information blocking provisions require certified EHR systems to expose patient data through standard APIs, and the FHIR specification defines those APIs. Second, patient empowerment: patient portals, third-party health apps, and personal health records all need API-based access to clinical data that V2 push messaging cannot easily provide. Third, modern cloud architectures: new healthcare IT systems built in the cloud expect REST APIs as the default for integration, not pipe-delimited text messages over TCP sockets.

FHIR adoption has been particularly strong in three use cases. EHR API access for third-party applications (clinicians launching apps from within EHR workflows that retrieve patient data via FHIR), patient portals and personal health records (patients accessing their own clinical data through standardized APIs), and cloud-based imaging integration (modern PACS and imaging platforms expose imaging metadata via FHIR ImagingStudy resources alongside DICOMweb for the imaging pixel data). Medicai’s cloud imaging platform implements FHIR resources alongside V2 message processing, generating FHIR ServiceRequest and DiagnosticReport resources from inbound V2 messages so the imaging workflow operates on V2 while modern integrations consume FHIR resources.

For deeper coverage of FHIR architecture and its relationship to V2 in practical implementations, see HL7 FHIR vs HL7 V2.

HL7 V2 and FHIR: coexistence in modern architectures

Most healthcare environments in 2026 run HL7 V2 for operational messaging and are adding FHIR at the edges, for EHR integration APIs, patient portal access to imaging results, and cross-enterprise data sharing. It is not an either/or transition in practice. It is a layered architecture in which V2 handles real-time ordering and results workflows, while FHIR handles broader interoperability use cases that V2 was never designed for.

The architectural reason for this split is fundamental. V2 is a push model: systems send messages to other systems that are waiting for them. FHIR is a pull model: systems expose resources via RESTful APIs that other systems can query on demand. Push models are simpler to implement in tightly coupled point-to-point workflows, such as ordering and results. Pull models are better suited to use cases where the querying system does not know in advance when data will be available or needs to query across multiple sources.

In a Medicai cloud-native environment, FHIR resources coexist with V2 message processing. An ORM^O01 from a legacy EHR enters the platform, is processed to create the Scheduled Procedure Step and MWL entry, and also creates or updates a FHIR ServiceRequest resource. The FHIR resource can then be queried by any system with API access: a referring physician’s portal, a cross-enterprise imaging exchange, a population health analytics platform, without requiring those systems to receive V2 push messages. The imaging workflow itself still runs on V2; the interoperability layer runs on FHIR.

The HL7 FHIR vs V2 guide covers the full architectural comparison, including the specific FHIR resources corresponding to each V2 message type and a practical migration path for departments moving from pure V2 to a hybrid or FHIR-first architecture.

HL7 in healthcare interoperability: TEFCA, USCDI, and the Cures Act

HL7 standards do not exist in isolation. They operate within broader federal interoperability frameworks that mandate specific data-exchange capabilities and define which standards qualify for those exchanges. Three frameworks in particular shape how HL7 standards get deployed in US healthcare.

The 21st Century Cures Act (passed in 2016, with information blocking provisions effective from 2020) requires certified EHR systems to make patient data available through standardized APIs without “information blocking” practices that restrict legitimate access. The Cures Act information blocking provisions effectively mandate access to FHIR APIs in certified EHRs. Healthcare organizations that block legitimate FHIR API requests face penalties from the Office of Inspector General. This regulatory pressure has been the dominant driver of FHIR adoption since 2020.

USCDI (United States Core Data for Interoperability) is the minimum data set that certified EHRs must support for interoperability. USCDI is published by the Office of the National Coordinator for Health Information Technology (ONC) and updated annually, with each version expanding the required data elements. USCDI v4 (the version current as of 2026) includes patient demographics, clinical notes, medications, allergies, lab results, vital signs, immunizations, problems, procedures, and increasingly granular elements like social determinants of health, sexual orientation and gender identity, and patient-reported outcomes. EHR systems must support the exchange of USCDI data through certified FHIR APIs.

TEFCA (Trusted Exchange Framework and Common Agreement) is the national framework for health information exchange established by the 21st Century Cures Act and operationalized by ONC starting in 2022. TEFCA defines how Qualified Health Information Networks (QHINs) connect to each other to enable nationwide data exchange, the legal agreements governing those exchanges, and the technical standards required for participation. TEFCA’s technical foundation is FHIR-based, with QHINs exchanging data through FHIR APIs and supporting USCDI-defined data elements. As of 2026, multiple QHINs are operational and interconnected, with continued expansion expected as more healthcare organizations join the network.

These three frameworks together drive the FHIR transition in US healthcare. The Cures Act creates the regulatory mandate, USCDI defines what data must flow, and TEFCA defines the national exchange infrastructure. Healthcare organizations that need to participate in this ecosystem must implement FHIR APIs supporting USCDI data, with TEFCA participation increasingly expected for cross-organizational data exchange. HL7 V2 remains operationally important for internal workflows, but the cross-organizational interoperability layer is built on FHIR.

HL7 implementation considerations for healthcare organizations

Healthcare organizations implementing or maintaining HL7 integrations face four practical considerations that affect operational success.

Interface engines are the middleware that handle HL7 message routing, transformation, and monitoring between hospital systems. Established interface engines include Rhapsody Integration Engine, Corepoint Integration Engine, Lyniate Rhapsody, Iguana from iNTERFACEWARE, Mirth Connect (the open-source option, now NextGen Mirth Connect), and Cloverleaf. The choice of interface engine affects long-term operational costs, monitoring capabilities, and skill requirements for the integration team. Most large hospital systems run one of these engines; smaller practices may rely on integrations directly within their EHR or RIS systems.

Integration patterns vary by use case. Point-to-point integrations connect two systems directly via HL7 messaging, which is simple to set up but creates a maintenance burden as the number of connections grows (with N systems, point-to-point requires N×(N-1)/2 connections). Hub-and-spoke architectures route all messages through a central interface engine, reducing the number of connections but creating a critical dependency on the hub. Modern cloud-based integration platforms (iPaaS) treat healthcare integration as a managed service, abstracting the interface engine complexity behind APIs.

Monitoring and reliability require more than just ACK code logging. Effective HL7 monitoring tracks application-level processing (did the receiving system actually use the message), end-to-end latency (how long from order to MWL entry), failure rates by message type, and downstream effects (did the order create a billable encounter). Many legacy environments monitor only at the interface engine level, missing silent failures in which messages are acknowledged but not processed correctly.

Governance and change management matter because HL7 interfaces accumulate technical debt as healthcare organizations grow, replace systems, and add new clinical workflows. Each integration is a small contract between sending and receiving systems, often documented inconsistently or not at all. Organizations with mature HL7 governance maintain interface specifications that document which message types each interface supports, which fields are required, and which business rules apply. Organizations without governance discover their integration assumptions only when systems fail.

For organizations evaluating cloud-native imaging architecture that handles HL7 messaging alongside FHIR APIs, see Medicai’s cloud PACS platform and the medical imaging EHR integration patterns we support.

Frequently asked questions about HL7

What is HL7?

HL7 (Health Level Seven) is a family of healthcare data standards developed by Health Level Seven International, an ANSI-accredited standards organization founded in 1987. The HL7 family includes HL7 V2 (pipe-delimited messaging used for real-time clinical events), HL7 V3 (XML-based messaging, largely superseded), CDA (Clinical Document Architecture for structured clinical documents), and HL7 FHIR (the modern REST API standard). HL7 standards define how clinical systems exchange patient information, orders, results, and clinical documents across healthcare IT infrastructure worldwide.

What does HL7 stand for?

HL7 stands for Health Level Seven International. The “Level Seven” refers to the seventh layer of the OSI network model, the application layer. HL7 operates at that layer by defining the structure and meaning of healthcare data exchanged between systems, rather than the network transport mechanisms that move the data between systems. The HL7 International organization develops and maintains the HL7 family of standards through working groups composed of healthcare IT professionals globally.

What is HL7 V2?

HL7 V2 is the original HL7 messaging standard, introduced in the late 1980s and still the dominant operational messaging standard in hospital interoperability worldwide. V2 uses pipe-delimited text messages with structured segments to communicate events between clinical systems: patient registrations (ADT messages), orders (ORM messages), results (ORU messages), and acknowledgements (ACK messages). Approximately 95 percent of US hospitals run V2 messaging in production for real-time clinical workflows including EHR-to-RIS-to-PACS integration.

What is HL7 FHIR?

HL7 FHIR (Fast Healthcare Interoperability Resources) is the modern API-based healthcare interoperability standard introduced in 2014. FHIR uses REST APIs with JSON resources rather than V2’s pipe-delimited messaging or V3’s XML. FHIR defines resources for common healthcare data elements (Patient, Observation, Encounter, DiagnosticReport, ImagingStudy, and others) with REST endpoints for each. FHIR is the standard mandated by the 21st Century Cures Act for certified EHR API access and is the technical foundation of TEFCA’s national health information exchange network.

What is the difference between HL7 V2 and FHIR?

HL7 V2 is a push-based messaging standard where systems send pipe-delimited messages to other systems on clinical events. FHIR is a pull-based REST API standard where systems expose resources that other systems query on demand. V2 is operationally dominant for real-time hospital workflows. FHIR is dominant for new API integrations, patient portals, and cross-organizational data exchange. Most healthcare environments in 2026 run both: V2 for internal messaging, FHIR for external APIs. See HL7 FHIR vs HL7 V2 for the architectural comparison.

What is CDA in HL7?

CDA (Clinical Document Architecture) is the HL7 V3-family standard for structured clinical documents, introduced in 2005. CDA defines XML format for clinical narratives like discharge summaries, progress notes, and patient summaries. The Consolidated CDA (C-CDA) is the most widely deployed CDA implementation, required by US Meaningful Use and ONC certification programs. C-CDA defines standard document templates including Continuity of Care Document (CCD), Discharge Summary, Progress Note, and Consultation Note, enabling structured clinical document exchange between healthcare organizations.

What are HL7 message types in radiology?

The HL7 V2 message types in radiology workflow are ADT (Admit/Discharge/Transfer for patient registration), ORM O01 (Order Entry for new imaging orders, with control codes for cancellations and modifications), ORU R01 (Observation Result for finalized radiology reports), and ACK (Acknowledgement for message receipt confirmation). These message types connect the EHR, RIS, PACS, and imaging modalities in the radiology workflow. ORM O01 specifically initiates the IHE Scheduled Workflow sequence that populates the Modality Worklist.

How does HL7 work with DICOM?

HL7 and DICOM are complementary standards that work together in radiology workflow. HL7 handles the clinical messaging (orders, demographics, results) between EHR, RIS, PACS, and other clinical systems. DICOM handles the imaging data itself (the medical images, structured reports, and imaging metadata). The accession number and patient identifiers in HL7 ORM messages must match the DICOM tags in acquired images for the PACS to auto-reconcile studies to their orders. See What Is DICOM for the imaging standard’s full scope.

What is TEFCA in healthcare interoperability?

TEFCA (Trusted Exchange Framework and Common Agreement) is the national framework for health information exchange in the United States, established by the 21st Century Cures Act and operationalized by ONC starting in 2022. TEFCA defines how Qualified Health Information Networks (QHINs) connect to enable nationwide healthcare data exchange. TEFCA’s technical foundation is FHIR-based, with QHINs exchanging data through FHIR APIs and supporting USCDI-defined data elements. Multiple QHINs are operational as of 2026, with continued network expansion expected.

What is USCDI?

USCDI (United States Core Data for Interoperability) is the minimum data set that certified EHRs must support for interoperability. Published by the Office of the National Coordinator for Health Information Technology (ONC) and updated annually, USCDI defines required data elements including patient demographics, clinical notes, medications, allergies, lab results, vital signs, immunizations, problems, procedures, and increasingly granular elements like social determinants of health. EHR systems must support exchange of USCDI data through certified FHIR APIs as part of meeting ONC certification requirements.

HL7 and the broader imaging standards

HL7 is the connective tissue between PACS, RIS, EHR, and modality in healthcare IT architecture. Every post in the imaging interoperability cluster touches HL7 at some point. This guide is the vocabulary anchor for those references.

Modality Worklist (MWL): The MWL transaction is Step 4 in the IHE Scheduled Workflow sequence. Step 1, the ORM O01, is an HL7 message. Understanding what the ORM carries and how it populates the Scheduled Procedure Step explains why MWL query results look the way they do and why the accession number in the DICOM tag must match the ORM exactly. See Modality Worklist Implementation for the full transaction sequence.

RIS-PACS Integration: The RIS-PACS integration depends on the ORM and ORU message flow and on a consistent patient identity across systems. This guide provides the structural foundation (segment definitions, field semantics) that makes integration failure analysis actionable. See RIS-PACS Integration for operational coverage.

IHE Integration Profiles: The IHE Scheduled Workflow profile defines how HL7 ORM and ORU messages fit into the full eight-step transaction sequence linking ordering systems, RIS, modality, and PACS. See PACS Interoperability and IHE Profiles for the profile-level treatment.

PACS Migration: Identity mismatches that accumulate during a PACS migration are almost always rooted in HL7 data inconsistency. ADT records that differ between source and destination, ORM messages that use non-standard field population, and historical data loaded without a corresponding HL7 context all create migration risk. See PACS Migration for the operational consequences.

HL7 FHIR vs HL7 V2: That guide assumes the reader already understands V2 mechanics and explores the architectural differences with FHIR in detail. This guide is the prerequisite. Readers new to HL7 should read this one first, then move to the FHIR vs V2 comparison.

Healthcare Interoperability Concepts: The broader concepts of functional and semantic interoperability in healthcare provide the framework within which HL7 standards operate. See Functional Interoperability in Healthcare and Benefits and Challenges of Interoperability in Healthcare (after the planned rewrite) for that broader context.

DICOM Standard: HL7 carries clinical messaging; DICOM carries imaging data. The two standards are complementary, with the accession number serving as the linking key between HL7 ORM messages and DICOM image tags. See What Is DICOM for the imaging standard’s full scope.

The future of HL7 in healthcare interoperability

HL7 standards will continue to evolve through the next several years along three predictable directions.

FHIR adoption will continue accelerating across new healthcare IT implementations. The combination of regulatory mandates (Cures Act information blocking, ONC certification requirements), expanding TEFCA network participation, and cloud-native architecture preferences makes FHIR the default standard for new builds. V2 will not disappear (the installed base is too large, and operational workflows depend on it), but new integrations will increasingly be FHIR-first, with V2 supported through translation layers.

USCDI expansion will continue annually, with each version adding required data elements that EHR systems must support. The trajectory expands USCDI beyond basic demographics and clinical data to include more specialized elements: social determinants of health, patient-reported outcomes, genomic data, and behavioral health information. Healthcare organizations and EHR vendors face ongoing implementation work to keep pace with USCDI updates.

Cross-organizational interoperability through TEFCA will expand as more QHINs come online and existing QHINs add participants. The practical effect is that healthcare data exchange across organizational boundaries becomes more feasible, supporting use cases like patient transitions between providers, public health reporting, and clinical research that draws on multiple data sources.

For healthcare organizations planning an HL7 strategy, the practical implications include continuing V2 investment for operational workflows (V2 will not be replaced quickly), expanding FHIR capability for API integrations and external data exchange, and treating HL7 implementation as an ongoing operational capability rather than a one-time project. The standards will continue to evolve, and the integrations will continue to require maintenance, monitoring, and governance.