The Hospital Communication Problem Nobody Talks About
Every day, a typical hospital generates over 50,000 data transactions — patient registrations, lab orders, test results, prescriptions, billing charges, and discharge summaries. Each of these transactions needs to flow between systems that were never designed to talk to each other.
Without a universal standard, a lab system stores a patient's name as "Smith, John" while the EHR stores it as "John Smith" and the billing system stores it as "SMITH, JOHN A." Multiply this by thousands of data fields across dozens of systems, and you begin to see why healthcare has historically been one of the most data-fragmented industries on the planet.
That's exactly the problem HL7 was created to solve. And understanding it — whether you're evaluating integration vendors, planning a system migration, or simply trying to understand why your hospital's systems don't talk to each other — starts here.
What is HL7? The Universal Translator for Healthcare Systems
HL7 stands for Health Level Seven — a set of international standards for the transfer of clinical and administrative health data between software applications. The "Level Seven" refers to the seventh layer (application layer) of the OSI communication model, meaning HL7 operates at the highest level of system-to-system communication.
Think of HL7 as the universal translator for healthcare IT. Just as a translator enables a Spanish speaker and a Japanese speaker to have a conversation, HL7 enables an EHR system and a lab system — built by completely different vendors, in different programming languages, with different data structures — to exchange patient information reliably.
Without HL7, a hospital with just 6 major systems (EHR, Lab, Pharmacy, Radiology, Billing, Registration) would need 15 custom point-to-point interfaces. Add a seventh system, and that jumps to 21. HL7 replaces this chaos with a single standard that every system speaks.
The Evolution: From HL7 v2 to FHIR
HL7 isn't a single standard — it's a family of standards that has evolved over nearly four decades. Understanding this evolution is critical because different versions coexist in production today, and the version your organization uses determines your integration strategy, cost, and future readiness.
HL7 Version 2 (1987–present)
HL7 v2 is the workhorse of healthcare IT. First released in 1987, it remains the most widely deployed healthcare messaging standard in the world. Over 95% of US healthcare organizations use HL7 v2 in some form. It uses a pipe-delimited text format (fields separated by | characters) and communicates over TCP connections using a protocol called MLLP (Minimum Lower Layer Protocol).
HL7 v2 is battle-tested and universally supported, but it has limitations: the standard is loosely defined, allowing vendors to implement it differently, which creates integration headaches.
HL7 Version 3 and CDA (2005)
HL7 v3 attempted to fix v2's ambiguity with a rigorous data model based on XML. While it produced the valuable Clinical Document Architecture (CDA) — still used for sharing clinical summaries — v3 itself was too complex for widespread adoption. Most organizations skipped it entirely.
FHIR (2014–present)
FHIR (Fast Healthcare Interoperability Resources) is the modern standard that combines the best of v2's simplicity with web-era technology. FHIR uses JSON and REST APIs — the same technology that powers every modern web and mobile application. This means any developer with web experience can build FHIR integrations, dramatically reducing the talent barrier.
FHIR R4 (released 2019) is the current normative standard, and CMS has mandated its adoption for Medicare and Medicaid participating organizations.
HL7 v2 vs FHIR: Which One Matters for Your Organization?
This is the most common question healthcare leaders ask, and the answer is nuanced: you almost certainly need both. Here's why.
HL7 v2 isn't going away. Your lab systems, pharmacy systems, and most in-hospital integrations will continue to use v2 for years — possibly decades. FHIR is where all new development is happening, especially for patient-facing applications, mobile health, and cross-organizational data exchange.
The practical strategy: Maintain your existing v2 interfaces, build all new integrations in FHIR, and use an integration engine that can bridge between both. This is not an either-or decision.
Inside an HL7 Message: Decoded for Humans
You don't need to read HL7 messages to make strategic decisions, but understanding their structure helps you ask the right questions during vendor evaluations and troubleshoot integration issues.
Every HL7 v2 message is built from segments — each segment is a single line that starts with a three-letter code. Think of segments as rows in a spreadsheet, where each row contains a specific category of information.
The three most important segments you'll encounter:
- MSH (Message Header) — Who sent this message, when, and what type of message is it. Every HL7 message starts with MSH.
- PID (Patient Identification) — The patient's demographic information: name, date of birth, medical record number, address, phone number.
- PV1 (Patient Visit) — Where the patient is: which department, which bed, which attending physician, admission date.
When an integration fails, it's almost always a problem in one of these three segments — a missing field, a mismatched format, or an unexpected value.
Where HL7 Runs: The Complete Patient Visit
The best way to understand HL7 is to follow a patient through a typical hospital visit and see which messages fire at each step. This is the data flow that keeps a hospital running.
Step 1: Registration. The patient checks in at the front desk. The registration system sends an ADT^A01 (Admit) message to every system that needs to know a new patient has arrived — the EHR, lab, pharmacy, and billing.
Step 2: Doctor's Orders. The physician examines the patient and orders a blood test. The EHR sends an ORM^O01 (Order) message to the lab information system with the specific tests requested.
Step 3: Lab Results. The lab completes the blood work and sends back an ORU^R01 (Result) message containing the test values, reference ranges, and any abnormal flags.
Step 4: Prescription. Based on the results, the doctor prescribes medication. An RDE^O11 (Pharmacy Encode) message goes to the pharmacy system with the drug, dosage, and frequency.
Step 5: Billing. Throughout the visit, charges accumulate. A DFT^P03 (Detail Financial Transaction) message sends each charge to the billing system — the office visit, lab work, and medication.
Step 6: Discharge. The patient is discharged. An ADT^A03 (Discharge) message notifies all systems that the patient encounter is complete.
This entire flow — six message types across six systems — happens thousands of times per day in a busy hospital. HL7 is the invisible infrastructure that makes it work.
The 4 Levels of Interoperability
HL7 addresses a specific layer of a bigger challenge: healthcare interoperability. The Healthcare Information and Management Systems Society (HIMSS) defines four levels, and understanding where your organization sits reveals where your real problems are.
Level 1 — Foundational: Systems can send data to each other. This is just network connectivity — TCP/IP, VPN tunnels. Almost every organization has this.
Level 2 — Structural: Systems agree on a message format. This is where HL7 v2 lives. The sender and receiver both know that field 5 of the PID segment contains the patient's name. Most hospitals are at this level.
Level 3 — Semantic: Systems share the same meaning. When Lab A sends a glucose result coded as LOINC 2345-7, Lab B knows exactly what that means. This requires shared terminology standards like SNOMED CT, LOINC, and ICD-10. This is where most organizations struggle — and it's where the real value of interoperability lives.
Level 4 — Organizational: Governance, consent, and trust frameworks enable data exchange across organizational boundaries. This includes business associate agreements, patient consent management, and data use policies. FHIR and frameworks like TEFCA (Trusted Exchange Framework and Common Agreement) are pushing the industry toward this level.
FHIR Resources Mapped to Hospital Departments
If your organization is evaluating FHIR adoption, it helps to understand which FHIR resources each department will use. FHIR organizes healthcare data into Resources — discrete, well-defined data objects that map to real clinical concepts.
This mapping is valuable for scoping a FHIR implementation. If you're starting with the emergency department, you know you need to support Patient, Encounter, Condition, and AllergyIntolerance resources. If pharmacy is next, add MedicationRequest and MedicationDispense. This lets you prioritize implementation by department rather than trying to boil the ocean.
CMS Compliance: What's Mandatory in 2026
The Centers for Medicare and Medicaid Services (CMS) has moved healthcare interoperability from "nice to have" to "mandatory." If your organization participates in Medicare or Medicaid programs, you are subject to these requirements.
The key regulations driving compliance:
- CMS Interoperability and Patient Access Rule (CMS-9115-F): Requires payers to provide Patient Access APIs using FHIR R4.
- CMS Prior Authorization Rule (CMS-0057-F): Mandates electronic prior authorization via FHIR APIs, with implementation deadlines in 2026.
- Information Blocking provisions (21st Century Cures Act): Penalties of up to $1 million per violation for healthcare organizations that unreasonably restrict electronic health information exchange.
What this means for your organization: If you haven't started FHIR adoption, you're already behind. The good news is that modern integration engines support both HL7 v2 and FHIR, so you can bridge your existing infrastructure while building toward compliance.
What Should You Do Next?
Whether you're a hospital CIO planning a system migration, a healthtech product manager building integrations, or a compliance officer evaluating your organization's readiness, the path forward follows a clear sequence:
- Audit your current state. How many HL7 v2 interfaces do you have? Which systems are they connecting? Document everything.
- Assess your FHIR readiness. Does your EHR vendor support FHIR R4? Which FHIR resources do you need for your priority use cases?
- Evaluate your integration engine. Can your current middleware handle both v2 and FHIR? If not, it's time to evaluate options.
- Build a roadmap. Prioritize by business impact and compliance deadlines. Start with the interfaces that cause the most pain or carry the most regulatory risk.
For a detailed guide on how to plan and execute an HL7 integration project — including message types, vendor selection, and a step-by-step implementation playbook — read our companion guide: HL7 Integration: How It Works, Key Message Types, and Implementation Playbook.
If you need hands-on help with HL7 or FHIR integration — from assessment to go-live — talk to our healthcare integration team. We've helped healthcare organizations across the US build and scale interoperable systems.
