A Guide to the HL7 File Format for Healthcare

Many healthcare teams sit in two worlds at once. Inside the EHR, data moves as structured HL7 messages. Outside that environment, staff still need to send readable documents to specialists, labs, payers, and offices that may not accept a live data feed. If you've ever heard someone say “the interface sent it” while another person asks for a faxed summary, you're already dealing with the HL7 file format whether you realize it or not.

If you're managing that mix of systems and document workflows, FaxZen offers a practical homepage starting point for moving healthcare documents online, and this related guide on healthcare document handling workflows adds useful context for teams working across digital and paper-like channels.

What Is the HL7 File Format

HL7 is not just a single file type. It is a standard for exchanging clinical and administrative data between healthcare systems. HL7 was established in 1987 as a not-for-profit organization, and HL7 Version 2 was formally accredited in 1994 by ANSI. That history matters because HL7 v2 became the long-running operational language behind hospital messaging before newer API styles became common.

One source reports that HL7 v2 is used in 95% of healthcare organizations in the USA and in 35 countries worldwide in high-volume workflows such as admissions, lab results, and patient demographics (RadSource overview of HL7 in healthcare). In plain terms, the HL7 file format is everywhere in healthcare operations, even if most clinicians never open one directly.

Think of HL7 as a shipping label for patient data. It tells one system where the information belongs and how another system should read it. The “file format” label is common because people often receive HL7 content as a text file, export, or interface payload, but the bigger idea is structured message exchange.

Practical rule: When someone says “send the HL7 file,” they usually mean “send the structured message data,” not a polished document a human wants to read.

Decoding the HL7 Message Structure

At first glance, an HL7 message looks like gibberish. After you know the grammar, it reads more like a form where each line has a job.

A standard HL7 v2 message is a plain-text record made of segments separated by carriage returns. There are over 120 HL7 segment types, but common ones such as MSH, PID, and PV1 appear in many messages and carry the header, patient, and visit details (Interfaceware explanation of HL7 message structure).

A simple way to read it

Think of an HL7 message like a tightly formatted business letter.

• The segment is the line type.
• The field is the slot on that line.
• The component is a smaller piece inside one slot.

So if you see PID, you know you're in the patient identification section. If you hear someone mention PID-3, they mean the third field within that patient segment. That positional logic is why HL7 can feel cryptic. Meaning comes from where the data sits, not from pretty labels on the screen.

Common HL7 delimiters

A second source describes HL7 v2 messages as plain-text, delimiter-based records that use carriage returns, |, ^, ~, and &, which keeps them compact and machine-parseable without XML or JSON overhead (Lifepoint overview of HL7 delimiters).

An HL7 message looks old because it is old. Its design came from a time when compact text mattered, and that efficiency still helps legacy systems today.

Key HL7 Versions and the Rise of FHIR

A common real-world scenario looks like this. A hospital registration system still sends HL7 v2 messages to the lab, while a patient-facing app asks for data through a FHIR API, and a referral packet may still travel as a scanned document over secure online fax. All three can be part of the same patient journey.

That mixed environment is why version history matters.

HL7 v2 is still the standard many hospitals, labs, and imaging centers rely on for day-to-day system messaging. It spread widely because it was light, practical, and good enough for getting admission, discharge, order, and result data from one system to another. Teams often describe it as familiar, even when the interfaces need careful maintenance.

HL7 v3 came later and aimed for tighter consistency through a more formal structure. The goal made sense, but many organizations found it harder to implement and less flexible in routine interface work. As a result, v3 never replaced v2 in the way many expected.

FHIR, short for Fast Healthcare Interoperability Resources, grew out of that history. It keeps the goal of structured exchange but presents data in a way that fits modern software better, especially web APIs, mobile apps, and cloud platforms. If your organization is comparing old interface methods with newer API-based exchange, this overview of healthcare interoperability solutions adds useful context.

A practical comparison

One way to picture the difference is this. HL7 v2 works like a long-running hospital phone tree. People know how to use it, but the path can vary by site. FHIR works more like a well-documented online service, where each request and response is easier for modern applications to process.

For healthcare operations, the practical lesson is simple. New standards rarely replace old ones all at once. A clinic may receive structured HL7 data from one partner, send a PDF summary by secure fax to another, and archive both because the legal record has to reflect the full communication trail. That is why healthcare teams often manage legacy HL7 formats and newer transport methods side by side, rather than choosing one and discarding the other.

Using and Transforming HL7 Data

A lab result arrives from an outside system at 2:07 p.m. The clinician expects to see it in the chart a few minutes later, in the right patient record, with the right test name, and without anyone retyping a thing. That quiet handoff is where HL7 transformation work happens.

Most clinical staff never read an HL7 message line by line. What matters to them is whether the message turns into something usable, trustworthy, and easy to act on. In practice, the workflow is usually receive, parse, validate, map, route, and store.

Parsing breaks the raw message into recognizable parts, much like sorting a mailed packet into labeled folders. Validation checks whether the message is complete and internally consistent. If a patient identifier is missing or a date is in the wrong place, the system can catch that before bad data lands in the chart.

Mapping is the step that often causes confusion. It means translating one system's label or layout into another system's expected format. One EHR might store a provider name in one field, while another expects separate first and last name fields. HL7 carries the information, but the receiving system still needs rules for where each piece belongs.

Transformation can also support secondary uses. An organization may remove identifying details from HL7 v2 messages before sending data to an analytics team or a research project. This IHE de-identification example for HL7 shows the kind of field-level changes involved. The practical point is simple. Reusing data safely requires more than forwarding the original message.

For a quick visual walkthrough, this video gives a useful overview before teams start planning workflows.

What transformation often looks like

One practical reality in healthcare is that the target is not always another HL7 interface. Sometimes the destination is a chart update. Sometimes it is a PDF in a document management system. Sometimes it is information sent outside the EHR through secure document sharing for healthcare workflows. That is why teams often maintain both interface rules and document delivery processes. HL7 handles the structured message, while the surrounding workflow makes that message useful for care, operations, and records management.

Sending and Archiving Healthcare Documents

A care coordinator sends a referral in minutes, but the specialist's office cannot use the raw HL7 message sitting behind it. What they need is a document a person can open, read, attach to the chart, and act on without extra technical work.

HL7 is good at moving structured facts between systems. Daily operations often depend on something more familiar. Referral packets, release-of-information requests, legal disclosures, prior authorization attachments, and follow-up summaries usually need a readable file such as a PDF or scanned image.

That conversion step matters because software exchange and document exchange serve different jobs. HL7 carries data in a machine-friendly shape. Staff outside the originating workflow often need the same information repackaged as a document with headings, signatures, page order, and context. A lab result that fits neatly into an interface feed may still need to become a report for a physician inbox, an outside practice, or a records request.

Raw HL7 works for software. Outside recipients usually need a document they can read, file, and use right away.

The practical workflow is usually: extract the needed data, generate a human-readable document, send it through an approved channel, and keep a retrievable copy with transmission history. That last part is easy to overlook. If a clinic later needs to prove what was sent, when it was sent, and to whom, the archive matters as much as the original message.

This is also where older and newer methods meet. An organization may receive HL7 from an EHR, create a document from that data, then deliver it by direct messaging, portal upload, or secure online fax when the recipient cannot accept structured data directly. Teams that handle both interoperability feeds and outward-facing document delivery usually benefit from clear retention rules and a documented filing process. If you are comparing storage and workflow options, this guide to healthcare document management systems gives a useful operational view.

HL7 File Format FAQ

Can I open an HL7 file in a text editor

Yes. An HL7 v2 file is usually plain text, so a basic text editor can display it.

Reading it correctly is a significant challenge. The message is organized into segments and fields separated by special characters, much like a spreadsheet exported without visible columns. You can see the content, but the meaning depends on knowing what each line and separator represents.

Does an HL7 file always have one specific extension

No single file extension defines HL7. One organization might save it as .hl7 or .txt, while another sends the same content through an interface engine and never treats it as a user-facing file at all.

For day-to-day operations, the safer question is not "What is the extension?" but "Does this content follow HL7 message rules?"

Is HL7 the same thing as a PDF medical record

HL7 and PDF serve different jobs. HL7 carries structured data that software can sort into the right fields. A PDF presents information in a layout that a person can read, print, sign, or file.

A helpful way to separate them is this: HL7 works like the data behind the chart, while a PDF works like the page someone reviews. In many clinics, both are needed. The system may receive HL7 from an EHR, then staff generate a readable document for referral, records release, or outside delivery.

Why does HL7 still matter if FHIR exists

HL7 v2 still runs a large share of everyday healthcare messaging. Orders, admissions, discharges, transfers, and results often move through long-established interfaces that organizations rely on every day.

FHIR matters because it makes modern application and API workflows easier. But replacing older interfaces takes time, budget, testing, and agreement across many systems. For many healthcare teams, the practical reality is mixed. HL7 v2 handles internal system-to-system traffic, while newer tools support patient apps, portals, and other modern use cases.

Where does online fax fit in

Online fax usually comes into play after HL7 data has been turned into a human-readable document. That matters when the receiving office cannot accept structured messages directly, or when the workflow calls for a document someone can review and file immediately.

A common example is a referral office receiving a summary, lab report, or discharge note derived from EHR data. In that setting, secure faxing is less about replacing HL7 and more about bridging the last mile between structured data and document delivery. If your team manages both interface feeds and outbound paperwork, this guide to HIPAA-compliant online fax for healthcare workflows explains that document transport side clearly.

Related articles

• Healthcare interoperability solutions
• Secure document sharing
• Healthcare document management systems
• Online fax for healthcare workflows
• Healthcare document handling workflows

If you need a simple way to send healthcare documents derived from EHR or HL7-based workflows, FaxZen gives teams a straightforward online fax option without requiring a fax machine.