What Is HL7 in Healthcare and Why Does Your Product Need It in 2026?

Interoperability has dogged healthcare for decades, and the price of getting it wrong is measurable. The 2025 CAQH Index found that US healthcare avoided roughly $258 billion in administrative costs through electronic transactions, with $21 billion still on the table wherever they stay manual. Health Level Seven International wrote the rules that let those systems read each other: HL7, and its newer standard, FHIR (Fast Healthcare Interoperability Resources). 

What changed lately is the stakes. Federal rules now name specific HL7 standards, attach dates to them, and penalize data that does not move. Here is what HL7 is, how the versions differ, and what your team needs to settle before anyone writes integration code.

So, What Exactly Is HL7?

HL7, or Health Level 7 (developed by Health Level Seven International), is an internationally accepted set of standards that serve as a medium to receive, exchange, manage, and retrieve digital information transferred between different software applications used by healthcare providers. In short, HL7 is a sophisticated framework that allows various healthcare software solutions to integrate and interpret it. The HL7 standards consist of a number of flexible guidelines and methodologies that various healthcare systems use to communicate with one another. These guidelines and messaging standards ensure that data exchange rules and common health data definitions relating to clinical documentation, EHR and personal health records, quality reporting, and prescription product labeling remain consistent across systems.

HL7 is a family of standards rather than a single specification, and the members of that family do very different jobs. HL7 v2 pushes operational messages between systems in near real time. Clinical Document Architecture carries structured clinical documents. HL7 FHIR exposes health data through a modern application programming interface. Most healthcare products end up touching at least two of the three.

In practical terms, the standards govern the integration, sharing, and retrieval of electronic health information across the systems healthcare providers use every day. Electronic health records sit at the center, but the same rules move patient data to and from a laboratory information system, imaging platforms, pharmacy software, and billing engines. Seamless data exchange between those information systems is a critical component of comprehensive care.

Those primary standards exist because healthcare providers store the same facts in incompatible ways. Two hospitals can run the same EHR product and still model an allergy differently. HL7 supplies the uniform data definitions that let different healthcare systems communicate effectively without a bespoke translator for every pair of endpoints.

The HL7 standards primarily focus on the application layer (layer 7) in the Open Systems Interconnection of the ISO seven-layer communications model. The application layer is a conceptual model that covers the communication function of a system with no regard to the internal structure or technology.

HL7 Primary Standards

There are certain HL7 standards (categories, versions, and concepts) that are predominantly used for HL7 system integration. The following is a list of where some of the primary HL7 standards belong:

1. Version 2.x/3 Messaging Standard: An interoperability specification for health and medical transactions
2. Clinical Document Architecture (CDA): An XML markup standard that specifies standards relating to encoding, structure, and the semantics of clinical documents that are to be exchanged
3. Continuity of Care Document: An XML markup standard that specifies the standards relating to encoding, structure, and the semantics of patient summary clinical documents to be exchanged
4. Structured Product Labeling: An XML-formatted standard that defines human prescription drug labeling content
5. Clinical Context Object Workgroup: A standard protocol that synchronizes disparate applications in real-time at the UI level
6. HL7 Version 2 Product Suite: Allows for data exchange between medical systems

So what is HL7, organizationally speaking? The standard is backed by 1,600 members from over 50 countries, with the main vision of providing users with flexible access to healthcare data whenever they need it. That membership includes more than 500 corporate members, and HL7 runs national affiliate organizations in over 30 countries, the first of which was founded in Germany in 1993.

These reference categories span messaging, document standards, and terminology, each with its own technical specifications. Standards development runs through open ballots, so related standards and their support documents move on a published schedule. Software and standards development advance in step, which is why an EHR vendor can plan a release around a ballot cycle.

Protocol HL7 variants

HL7 International has been improving its product constantly since the first version of HL7v1. So, several new versions saw the light of day: HL7v2, HL7v3, and the FHIR substandard. To understand how the product has improved over the years, let’s take a closer look at the versions:

• HL7v1: First release of the protocol, already considered outdated and practically unused in the medical field
• HL7v2: Test standard, characterized by ease of implementation and use, and the most widespread in the healthcare environment. HL7v2 has a slight problem with security, since it predates much of today’s malware, though its structure has room to address that. The version provides 80% of the basic interface and 20% for adjustment, meaning you can integrate your own solutions
• HL7v3: Characterized by flexible and diverse semantics, which makes it difficult to understand and use. Development was based on RIM (Reference Information Model), which allows interaction formats to be reapplied and harmonized. V3 messaging never displaced v2 in clinical workflows, because the modeling skills it demanded outstripped what most hospital IT teams could staff. The one v3-family standard that did land broadly is CDA
• FHIR: The newest HL7 protocol, which combines the valuable features of previous versions. Release 4 is the version US regulation points at, and R6 is currently in ballot. We’ll talk about it in more detail later

In order to ensure everyone’s voice is heard, HL7 International develops its standards via a balloting system. This democratic system allows members to vote and comment during successive balloting rounds until there are no negative comments left and draft standards are agreed upon.

Why HL7 and FHIR Are Now a Regulatory Requirement in the US

For most of its history, HL7 spread because vendors found it convenient. Four overlapping US policy tracks now name HL7 standards directly, and three carry dates that have already passed or land inside the next eighteen months. These rules shape your integration roadmap whether or not you sell to the government.

The 21st Century Cures Act and certified FHIR APIs

The 21st Century Cures Act, signed in 2016, instructed the industry to adopt standardized APIs so individuals could pull their records into an app of their choosing. ONC turned that instruction into a certification criterion. Under §170.315(g)(10), certified health IT must support HL7’s FHIR US Core Implementation Guide built on FHIR Release 4, the FHIR Bulk Data Access IG, and the HL7 SMART Application Launch Framework, delivered to customers by December 31, 2022. So if your customers run certified electronic health records in the US, a FHIR R4 endpoint is already waiting for you.

Information blocking and what counts as interference

The same rulemaking made information blocking a defined offense. Any practice likely to interfere with the access, exchange, or use of electronic health information can qualify, and since October 6, 2022 the scope covers a patient’s full designated record set. Providers, developers of certified health IT, and health information networks all sit inside the definition. ONC maintains the current exception list and claim process.

TEFCA and nationwide exchange through QHINs

TEFCA, the Trusted Exchange Framework and Common Agreement, came out of the same Cures Act and went live in December 2023, giving the country one legal and technical foundation for exchanging health data across organizations. Networks that finish onboarding become Qualified Health Information Networks, or QHINs, and everyone else joins as a Participant or Subparticipant underneath one. Eleven designated QHINs were listed as of mid-2026, among them CommonWell, eHealth Exchange, Epic Nexus, Health Gorilla, Oracle Health Information Network, and Surescripts. As of November 2025, more than 10,600 organizations were live on TEFCA, representing over 60,000 connections to clinicians, hospitals, public health authorities, and post-acute facilities.

The framework exists to make seamless exchange the default rather than a per-partner project. Participation stays voluntary, but procurement conversations now ask which QHIN you exchange through, what transactions you support, and how you resolve patient identity. Weak patient matching becomes visible the moment records arrive from outside your own ecosystem.

CMS Interoperability and Patient Access, plus the 2027 prior authorization deadline

CMS applied pressure on the payer side. The Interoperability and Patient Access final rule (CMS-9115-F) required impacted payers to stand up a FHIR-based Patient Access API and a Provider Directory API. CMS-0057-F, the Interoperability and Prior Authorization final rule published in 2024, went considerably further. Impacted payers, meaning Medicare Advantage organizations, state Medicaid and CHIP programs, and QHP issuers on the federally facilitated exchanges, have until January 1, 2027 to run four production FHIR APIs: Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization.

The operational half of that rule landed a year earlier. Since January 1, 2026, impacted payers must decide expedited prior authorization requests within 72 hours and standard ones within seven calendar days, with a specific reason for every denial. CMS estimates roughly $15 billion in savings over ten years. For payer-facing or revenue cycle software, the Da Vinci IGs (PAS, CRD, DTR, PDex, CARIN Blue Button) are now part of the requirements document.

Here is how the four tracks line up:

What Is an HL7 Interface?

While the HL7 protocol enables data sharing and exchange, the HL7 interface is an interconnection that allows for information transmission between different system endpoints.

In order to allow this exchange to occur, healthcare companies need to integrate and enable their internal systems with the proper means of communication.

HL7 Integration Process in the System

Integrating hospital services into the system is a meticulous task, but the right mix of IT skills and technology stack keeps it to roughly 1 to 3 months.

Interaction between systems is the key point. Correct planning optimizes staff work, displays information from other sources accurately, and lets you avoid duplication while achieving compatibility between apps.

The most common interfaces are distinguished:

• ADT: Human resources operations
• DFT: Financial operations
• ORU: Examination results
• ORM: Order management
• MDM: Collection and storage of medical records
• MFN: Key file message service
• SIU: Work on schedules
• BAR: System for payment account records

Interface engineers build the connection between user and system, working to this plan:

• Creating: The necessary ports in an app, pulling in the required content
• Configuring: The interface and the workspace in the system, in line with the institution’s specifications
• Checking: The optimal connection options, which help detect errors or failures in HL7 information exchange along the “source-recipient” chain

Testing of the created interface is the final stage of HL7 implementation. At this step, technical specialists work alongside experts in the field the application serves, so the system’s appearance, usage algorithm, and content all get a full review.

There are two types of testing:

• Modular testing: Analyzes the flow of content, its accuracy, and veracity, and reveals errors and gaps missed during the first stage of testing
• Integrated validation: Looks at information crossing different system levels through the HL7 interface, with experts familiar with medical records taking part

One addition worth budgeting for in 2026: conformance testing against the published IGs, not only against your own interface spec. If a payer API has to satisfy CMS-0057-F, validate against the relevant Da Vinci reference implementations before you commit to a go-live date. Discovering a profile mismatch during customer onboarding costs far more than catching it in a Connectathon. ONC publishes conformance test tools for the certification criteria.

Why Is HL7 Used in Healthcare?

Proper data sharing and interchangeability play a crucial role across healthcare organizations. As medical institutions adopt more software and devices, it is crucial to ensure smooth integration between all systems and disparate sources. HL7 is used mainly by hospitals, private clinics, governmental healthcare institutions, healthcare software providers, laboratories, and pharmaceutical companies.

Achieving interoperability matters most at the point of care delivery. When a patient moves from an emergency department to an inpatient ward, patient admission details, medication lists, and clinical information all have to travel with them. HL7 standards let various healthcare providers share data across organizational boundaries, so clinicians can make informed decisions from a complete record.

Who uses the HL7 standards?

After settling the definition, let’s look at who actually uses the global standard.

Roughly 95% of US healthcare organizations run HL7 v2 in their information systems, and the standard has been adopted to varying degrees in more than 35 other countries. Nearly four decades after its first publication in 1987, v2 messages still carry the majority of real-time traffic between EHRs, lab systems, radiology, and pharmacy.

That footprint covers clinical practice and back-office work alike. Hospitals run interfaces for patient admissions and discharge, laboratories return results through them, and payers pull patient information to adjudicate claims. Software vendors build against the same key standards so a product connects to different healthcare systems without a rewrite for every customer.

Three further groups of professionals work with HL7 directly:

• Clinical interface developers: They transfer and aggregate records, create clinical programs and provide technical support, and build the mechanisms that move information between applications and healthcare providers
• Specialists working in health informatics: They study how clinical knowledge is created, then use available technologies to organize medical knowledge, dictionaries, and work processes
• Government and political structures: Their interest comes from a desire to share data with different organizations and to move information to all parts of the world. Several older exchange systems are now irrelevant, so these users adopt HL7 to work outside an outdated interface

Integration with other systems

The modern healthcare industry operates multiple systems and devices to sustain its essential day-to-day operations. All of these software solutions and applications are built differently, with different functionality and capabilities. Some organizations run large, complex infrastructures while other healthcare institutions deploy simpler software. The purpose of the HL7 standard is to provide a universal protocol so that any organization with permission can access and retrieve information from other healthcare software systems or applications. The point is a common protocol that lets different systems trade records on equal terms, so healthcare providers can share data with a partner clinic as easily as with a department down the hall. Seamless exchange of patient data across those boundaries is what interoperability means in daily use. We unpack the wider picture in our guide to interoperability in healthcare.

Workflow automation

Although electronic health record (EHR) systems are the most common solutions for workflow automation, communicating between various EHRs and other sources, including lab services, stays difficult. HL7 standards enhance interoperability and transmit records whether the systems use older communication paradigms or modern APIs, and can automate workflows where no comprehensive EHR exists. The protocol structures and shares records in a clear way, thus simplifying the information exchange process across healthcare systems.

Removing manual data entry is where most healthcare organizations see the first return. Every rekeyed lab value invites a transcription error, and every hour spent retyping is an hour not spent on patient care. HL7 interfaces feed automated workflows instead: results post themselves, follow-up appointments schedule off a discharge message, and administrative processes that once needed a phone call complete in the background. That cuts administrative burden on both sides of the house.

Collaboration

HL7 is a powerful tool for storing and exchanging healthcare data, which gives it global reach. Collaboration between established governmental institutions, the fast-growing health tech sector, and private practice has long been a sticking point. HL7 standards create a unified guideline for all healthcare market players, from private clinics and state hospitals to laboratories and software providers. That coordination shows up most clearly in public health reporting, where case notifications, lab results, and immunization records have to reach state and federal agencies in a form they can process without manual rework. TEFCA added public health as a named exchange purpose, which gives agencies a route to that data without negotiating an agreement with every hospital individually. Because HL7 outputs are recognized as international standards, the same approach carries across borders, letting health services in different countries connect their healthcare information systems on a comprehensive framework instead of one-off bridges.

What Are the Benefits of an HL7 Interface for Hospital Services?

The value of an HL7 interface shows up in three places: what clinicians see, what administrators stop retyping, and what your engineering team can build next. Each one compounds the others. 

Improved clinical efficiency

The goal states plainly enough: improve patient care by putting better information in front of clinicians sooner. Breaking down data silos between departments means a physician sees medical information from radiology, the laboratory, and the pharmacy in a single view. Feeding that same stream into clinical decision support turns raw patient information into prompts a clinician can act on during the visit.

Improved communication between medical organizations accumulates more valuable information, which allows clinicians to receive up-to-date records and a wider clinical perspective.

Elimination of administrative errors

Through HL7, clinicians can access relevant information from multiple sources and can be sure that everything is synchronized and relevant. With less manual requesting and form-filling, HL7 standards save time and raise accuracy in patient records.

Cleaner records improve patient care in ways you can measure: fewer duplicate tests, faster triage, and fewer medication errors traced back to a stale allergy list.

Opportunities for new technology

Apart from seamless transmission between existing systems used by particular medical institutions, the HL7 protocol also opens more opportunities to experiment with other software solutions. This creates a wider pool to choose from and enables flexibility in terms of tech solutions for healthcare companies. Emerging technologies depend on this directly. A model that reads structured FHIR data types from a certified endpoint can ship in weeks. The same model waiting on a custom flat-file export negotiated per customer takes quarters. Seamless integration is what turns a promising prototype into a product that scales across accounts.

Are There Flaws in the HL7 Standard?

Oddly enough, the main weakness of HL7 is its key characteristic: flexibility. The same adaptability that lets different workspaces “communicate” with each other complicates transfers between unrelated structures, and each release of updates improves and complicates the standard at once.

Different medical institutions run different apps with their own quirks, which all have to be accounted for so the protocols work smoothly.

Different vendors built their programming structures around different assumptions, which is why two v2 feeds claiming the same version rarely behave identically in production.

Version fragmentation is the practical form this takes. A single hospital may run v2 feeds for lab and ADT, exchange CDA documents with referral partners, and expose FHIR R4 to patient apps, all at once. Budget for translation between them rather than assuming one standard will cover the estate.

FHIR vs. HL7: What Is the FHIR Specification?

FHIR is a specification from HL7 International that can be used as a stand-alone data exchange standard. The FHIR specification delivers simplified implementation by leveraging existing logical and theoretical models.

Put simply, FHIR is the most up-to-date framework for healthcare data exchange, designed specifically for digital interactions. FHIR uses a modern clinical decision model that gives healthcare providers and individuals real-time information access and connects systems, applications, and devices. The main aim is to deliver resources that support most use cases, either on their own or when combined.

The design borrows from the ordinary web rather than from healthcare messaging: resources addressed over a RESTful API and serialized as JSON or XML. The number of FHIR Resources has grown from 49 in the first draft to 145 today. Any developer who has consumed a REST API can read a FHIR Patient resource without training, which is part of why adoption moved so fast.

Learn more about FHIR vs HL7 v2: Key Difference in Healthcare Data Exchange Standards.

Which FHIR version to build on: R4, R5, and R6

HL7 FHIR organizes clinical facts into standard resources and data types, which is why different systems can parse the same payload without negotiating a format in advance. Choosing a release is the one decision that shapes everything downstream.

R4, published in 2019, is the version regulation points at. US Core profiles, the ONC certification criteria, and every CMS API mandate reference R4, and it remains the primary version for most implementers worldwide. R5 arrived in 2023 with new resources and stronger public health support, but it brought breaking changes and no US regulatory backing, so adoption sits in the single digits.

R6 is the one to watch. The first normative ballot opened in January 2026, aiming to move most core clinical and administrative resources to normative status, which would freeze the core API surface. Publication is expected in late 2026 or 2027, and HL7 has signalled an R4 sunset window measured in years.

For anything shipping now, the recommendation is unambiguous: build on R4, keep profiles and terminology bindings clean enough to migrate, and use cross-version extensions if you need an R5 element early.

SMART on FHIR and how apps launch inside an EHR

FHIR defines the data. SMART on FHIR defines how an outside application earns permission to read it, layering OAuth 2.0 and OpenID Connect on top so a clinician can open your app from inside Epic or Oracle Health with the patient context loaded and scopes limited to what the app needs.

ONC named the HL7 SMART Application Launch Framework in the (g)(10) criterion, which is why every certified EHR in the US supports it. For a clinician-facing product that makes it the default distribution route; for bulk back-end work, the Bulk Data Access IG fits better. Implementation details are in our separate guide to SMART on FHIR.

How Is the Data Protected During System Installation?

Medical data are among those that fall under the category of “confidential”. Doctor-patient confidentiality prohibits specialists from sharing patient information with third parties. Because of this, systems for transferring records between institutions and specialists need strong protection.

During verification of the installed interface, test records from the working environment are needed. That information then settles on the laptops of technicians, so this stage needs the protection of patients’ personal details as much as production does.

To avoid attacks on confidential records, specialists resort to anonymizing test information. So, pseudonyms are used, birthdates are generalized, and direct data (names, social security numbers, addresses) are deleted.

Communications and information exchange in the HL7 system can be protected by various security programs, from encryption to SSH tunneling. HTTPS, SFTP, FTPS, and SMIME protocols are also used for transfer. Because HL7 is a two-way exchange, the transfer layer and the client app both have to be secured, not just your own end.

One caution specific to FHIR. Exposing an API widens the attack surface in ways a point-to-point v2 feed does not. Scope your SMART tokens narrowly, expire and rotate refresh tokens, log every access against the requesting app and user, and confirm that patient matching cannot be abused to enumerate records. TEFCA participation raises the same question at network scale, because exchange there assumes you can prove who is asking, on whose behalf, and for which permitted purpose. Our HIPAA Compliance Quick-Start covers the controls auditors ask about first.

Build Your HL7 and FHIR Integration with Glorium Technologies

HL7 will remain a central standard for healthcare software development. With the CMS API deadline landing on January 1, 2027, and R6 moving through ballot, the next two years will decide which products exchange data cleanly and which ones renegotiate custom feeds one customer at a time. Getting it right shows up as seamless communication between healthcare systems and, downstream, as improved care delivery.

The teams that come through this well treat integration as product architecture, not a task for the final sprint. Decide early which standard carries which workflow, build on R4, and find out what your customers’ EHRs already expose before anyone designs something custom.

Glorium Technologies has spent more than 15 years building software for healthcare organizations, with HL7 and FHIR integration at the center of that work. Our teams ship EHR and EMR integrations, patient portals, remote monitoring platforms, and clinical apps connected to Epic, Oracle Health, and Athenahealth, under ISO 27001, ISO 13485, and SOC 2 certification. Browse the healthcare case studies to see how those projects came together.

Tell us what you need to connect and where your deadlines sit. Learn more about our HL7 integration services or book a call with our team today.

FAQ