Health Level 7 is a standard language that lets hospital computers talk to each other

Health Level 7 (HL7) is a set of rules that tells medical software how to format and send patient information between different systems. When your doctor's office sends your test results to a hospital, or a pharmacy receives a prescription from a clinic, HL7 is usually the language those computers use to understand each other. Without it, each hospital system would need custom translation software for every other system it connects to — which would be expensive and error-prone.

HL7 exists because hospitals and clinics use dozens of different software programs made by different companies. A patient's electronic health record (EHR) might run on one vendor's system, the lab equipment on another's, and the pharmacy on a third's. HL7 gives all of them a common way to say "this patient's name is" or "this test result is" so the information flows correctly without manual re-entry.

The standard is maintained by Health Level Seven International, a nonprofit organization that updates the rules as medical technology changes. The most common versions in use today are HL7 version 2 (released in 1989 and still dominant) and HL7 version 3 and FHIR (newer standards that are gradually replacing it).

Key Takeaways

  • HL7 is a standard format that lets different hospital and clinic computer systems exchange patient data without manual re-entry.
  • HL7 version 2 has been the industry standard since 1989 and still handles most medical data transfers today.
  • Newer standards like FHIR are designed to be simpler and work better with modern web-based systems, but HL7 v2 remains widespread.
  • Without HL7, hospitals would need separate custom software to translate data between each pair of systems they use.

How HL7 messages work in practice

An HL7 message is a text file with a specific structure. Each message contains segments — chunks of information separated by special characters — that describe what is being sent. A typical message might start with an MSH segment (message header) that identifies the sending system, receiving system, and timestamp. Then it includes segments for patient demographics (PID), orders (ORC), and results (OBX).

When a lab machine finishes a blood test, it creates an HL7 message saying "Patient John Smith, medical record 12345, had a glucose test at 2:15 PM, result 105 mg/dL." The hospital's EHR system reads this message, parses each segment, and automatically enters the result into Smith's chart. The doctor sees it without anyone typing it twice.

HL7 v2 messages are human-readable if you know the format — you can open one in a text editor and see the actual data. This makes it easier to troubleshoot when something goes wrong. Newer versions like FHIR use a different approach based on web standards, which some systems find easier to build but others find less transparent.

Why hospitals need a standard like this

A large hospital system might use an EHR from Epic, a lab system from Cerner, a pharmacy system from Omnicell, and imaging software from GE Healthcare. Each one stores data in its own format. Without HL7, the hospital would need to hire programmers to write custom code that translates Epic's format into Cerner's format, and Cerner's into Omnicell's, and so on. That is expensive, takes months, and breaks every time a vendor updates their software.

HL7 lets vendors build one translator: "convert our data to HL7 format, and any other system that understands HL7 can read it." The hospital still needs to configure each connection, but the underlying work is standardized. This also means a hospital can switch vendors more easily — the new vendor's system already knows how to read HL7, so the data migration is simpler.

For patients, the benefit is that their information moves between providers without gaps or re-entry errors. A cardiologist at one hospital can see the blood work a primary care doctor ordered at another hospital, because both systems speak HL7.

HL7 version 2 versus newer standards

HL7 version 2 has dominated healthcare IT for over 30 years. It is flexible, widely supported, and hospitals have invested heavily in systems that use it. However, it has quirks that made sense in 1989 but feel clunky now. The format is text-based and uses special characters as delimiters, which can cause problems if patient data itself contains those characters. Vendors sometimes interpret the standard slightly differently, leading to compatibility headaches.

HL7 version 3 was designed to fix these problems but turned out to be so complex that few systems actually use it. FHIR (Fast Healthcare Interoperability Resources), released in 2014, takes a different approach. It uses modern web standards (JSON and REST APIs) that developers already know, making it faster to build and easier to integrate with non-medical software. The U.S. government has pushed hospitals to adopt FHIR for better data sharing.

In practice, most hospitals today use HL7 v2 for their core systems and are gradually adding FHIR connections for newer applications and patient-facing tools. A hospital might use HL7 v2 to send lab results between departments but use FHIR to let patients download their records through a mobile app.

What happens when HL7 messages fail

When an HL7 message does not reach its destination or arrives corrupted, the result can range from a minor inconvenience to a patient safety issue. A missing lab result might delay a diagnosis. A pharmacy order that does not transmit could mean a patient does not get their medication. Most hospitals have monitoring systems that alert staff when a message fails, but the alert only works if someone is watching.

Common failure points include network outages, mismatched HL7 configurations between systems, and data that does not fit the expected format. If a patient's name contains a character that HL7 v2 uses as a delimiter, the message might break. If a lab machine is set to send results in one format but the EHR expects a different one, the data will not import correctly.

Hospital IT teams spend significant time testing HL7 connections and troubleshooting failures. This is one reason why switching to FHIR is appealing — the newer standard is designed to handle edge cases more gracefully.

HL7 and patient privacy

HL7 itself is just a format — it does not encrypt data or control who sees it. Patient information in an HL7 message is as sensitive as any other patient data. Hospitals must secure HL7 connections using encryption (usually TLS) and access controls to make sure only authorized systems receive the messages. A message traveling between a lab and an EHR should be encrypted in transit and only readable by those two systems.

When hospitals share data with outside providers, they use HL7 over secure connections and often strip out unnecessary details to follow privacy rules. A specialist might receive an HL7 message with only the information relevant to their specialty, not the patient's entire medical history.

Frequently Asked Questions

Do patients need to know about HL7?

No. HL7 is infrastructure that works behind the scenes. You will never see an HL7 message or interact with it directly. It matters to hospital IT staff and software vendors, but from a patient's perspective, the benefit is simply that your information moves between providers smoothly and accurately.

Is HL7 the same everywhere?

The standard is the same, but implementations vary. Different hospitals configure HL7 slightly differently based on their needs and systems. This is why data sharing between hospitals sometimes requires custom setup work, even though both use HL7.

Will HL7 v2 go away soon?

Not in the near future. HL7 v2 is so deeply embedded in hospital systems that replacing it entirely would take decades and cost billions. Most hospitals will run both HL7 v2 and FHIR in parallel for many years as they gradually migrate to newer standards.

Can I see my HL7 data?

Not directly — HL7 messages are meant for computer-to-computer communication. However, the data inside HL7 messages is your medical record, which you have the right to request from your provider. They will give it to you in a human-readable format, not as raw HL7.