HL7 Message Parser

Parse HL7 v2.x healthcare messages (ADT, ORU, ORM) into readable structure. Decode pipe-delimited segments into patient info, visit details, observations. Export to CSV or JSON.

1.0.0
Version
Auth
Batch

About HL7 Message Parser

HL7 v2 is the lingua franca of every hospital integration engine, and also a 30-year-old pipe-delimited format with positional fields, recursive composites and a custom separator character per message. Reading one in a text editor is like reading a CSV that decided to escape with both |, ^, ~, \ and &. The desktop options (HL7Soup, 7edit, Mirth Connect) are full integration engines built around long-running interfaces — overkill for "what's actually in this one ADT message".

This HL7 message parser takes a paste-in or uploaded message and renders it three ways. A segment-by-segment view shows every MSH, PID, PV1, OBX and friend with field numbers and decoded composite components (patient name parts, address fields, location triple). A summary block at the top pulls out the high-value fields — patient ID and name, visit number, sending and receiving application, message type and event — so you can sanity-check the message in two seconds without scrolling. CSV (one row per segment.field) and JSON (nested structure) downloads come out alongside. Custom separator characters (non-standard delimiters that some vendor interfaces ship) are detected from MSH-1 and MSH-2 automatically, so the parser doesn't choke when the integration engine you're debugging uses something other than the canonical |^~\&.

Use it to triage a malformed ADT before it breaks the interface again, compare two ORU results from different LIMS systems, learn what fields a vendor actually populates in their SIU schedule messages, audit what PHI sits in a message before pasting into a ticket, or just open one .hl7 file someone emailed without spinning up a full integration engine.

HL7 Message Parser Use Cases

  • Integration engineers triaging a malformed ADT before it breaks an HL7 interface
  • Lab informatics teams comparing ORU result messages from different LIMS vendors
  • Auditing what PHI sits in a sample message before pasting into a support ticket
  • Learning what optional fields a vendor populates in SIU schedule or VXU vaccination messages
  • Quick decode of an ACK response when an interface engine is rejecting messages
  • Healthcare developers prototyping a new HL7 inbound consumer without Mirth Connect
  • Support teams forwarding a clean CSV or JSON summary instead of the raw pipe-delimited blob

HL7 Message Parser Features

  • Parses all common HL7 v2.x message types — ADT, ORU, ORM, SIU, VXU, ACK, MDM, DFT and more
  • Decodes composite fields (PID-5 name parts, PID-11 address, PV1-3 location) into named components rather than ^-glued strings
  • Auto-detects non-standard separators from MSH-1 and MSH-2 — works on vendor interfaces that ship custom delimiters
  • Summary block surfaces high-value fields — patient ID, name, visit number, sending/receiving app, message type and event
  • CSV export with one row per segment.field for spreadsheet diffing; JSON export with nested structure for programmatic use
  • Accepts file upload (.hl7, .txt, .msg) or pasted text — handy when a teammate dropped the message in chat
  • Files up to 5 MB processed in a stateless serverless function and discarded immediately after the response

How to Use HL7 Message Parser

Upload or paste your HL7 message

Drop a .hl7, .txt or .msg file onto the upload zone (up to 5 MB), or paste the message text directly into the textarea — handy when a colleague pasted it into Slack and you just want to grok it. Both single messages and batched files work.

Click Parse

The parser reads MSH-1 and MSH-2 to pick up the field, component, repetition, escape and subcomponent separators (canonical |^~\& or custom), then walks the segments and decodes the composite fields into named components.

Read the summary

The summary panel at the top shows patient ID and name, visit number, sending and receiving application, message type and event (e.g. ADT^A01 for admit, ORU^R01 for results). Sanity-check that the message header matches what you expected to receive.

Inspect segments and fields

The full segment list shows every line — MSH, EVN, PID, PV1, OBR, OBX, NK1, IN1 and so on — with field numbers and decoded composites. Long fields are wrapped; the JSON download has the un-truncated tree if you need it for scripting.

Download CSV or JSON

Click Download CSV for a one-row-per-field spreadsheet (segment, field, component, value) that's easy to diff with another message, or Download JSON for a nested structure ready to feed into Python's hl7apy, R, or any JavaScript pipeline.

HL7 Message Parser FAQ

It does upload — HL7 parsing with vendor-edge-case handling is easier as a server-side Python pass than as in-browser JavaScript. The message is processed in a stateless serverless function and discarded immediately after the response is sent; nothing is logged to durable storage. That said, for messages containing live PHI on a regulated workflow, prefer a desktop tool (Mirth Connect, HL7Soup) or a fully in-browser parser like Parse Hog or MajeDynamics.

All common HL7 v2.x types: ADT (admission, discharge, transfer — A01–A45), ORU (observation result, R01/R30/R31), ORM (order, O01), SIU (scheduling, S12–S26), VXU (vaccination, V04), ACK (acknowledgement, A01–A45), MDM (document), DFT (financial transaction) and others. The parser is structure-driven rather than type-specific, so uncommon trigger events still decode correctly even if they're not in this list.

Yes. The HL7 spec lets MSH-1 declare any character as the field separator and MSH-2 declare component, repetition, escape and subcomponent separators. The parser reads them from the message header before walking the body, so vendor interfaces that ship |^~\& replacements or use unusual characters (some Asian-locale interfaces do) parse correctly without configuration.

CSV is flat — one row per segment.field with columns for segment name, field number, component, subcomponent and value. Great for diffing two messages side by side in Excel. JSON preserves the nested structure: segments contain fields, fields contain components, components contain subcomponents. Use JSON when feeding the parsed message into hl7apy, an HL7 FHIR mapper or a downstream validator.

Those are full integration platforms — built for long-running interfaces with persistent message stores, retry logic and transformation pipelines. This is a focused parser for the one message in front of you: read it, summarise it, export it, move on. Best paired with a real interface engine for production traffic; useful on its own for troubleshooting, learning a vendor's schema, or auditing a sample.

5 MB per upload, which covers a single message of any realistic size and small batches concatenated together (HL7 messages are typically 1–10 KB each). For larger batches — for example a day's worth of ORU traffic — split the file into chunks or use hl7apy in a local script.

Yes. The parser accepts any well-formed HL7 fragment that starts with a recognisable segment header (MSH, PID, OBR, etc.) and skips lines that don't match. Pasting just PID and PV1 for a quick patient/visit decode works — the summary block degrades gracefully when MSH is missing.

Upload .hl7 / .txt / .msg file

Max 5MB

Requires login • 1 credit

HL7 Message Parser Tutorial

What is HL7?

HL7 (Health Level Seven) is the messaging standard that powers most of healthcare IT. When a patient is admitted, a lab result comes back, or an order is placed, a pipe-delimited HL7 v2 message flies between EHR systems like this:

MSH|^~\&|APP|FAC|REC|RECFAC|20260420120000||ADT^A01|MSG001|P|2.5
PID|1||PATID1234||DOE^JOHN||19610615|M
PV1|1|I|2000^2012^01||||DOC123

Each line is a segment (MSH, PID, PV1...), fields split by |, components by ^. Unreadable raw, but it's the lifeblood of hospital interop.

What Gets Extracted

  • Message type (ADT^A01 → "Admit/Visit Notification")
  • Patient: ID, name, DOB, sex, address
  • Visit: class (inpatient/outpatient), location, attending doctor, admit time
  • Source/destination systems: sending and receiving apps/facilities
  • All segments: every field broken out to CSV

Supported Segments

Built-in names for: MSH, EVN, PID, PD1, NK1, PV1, PV2, OBX, OBR, ORC, DG1, AL1, IN1, GT1, NTE, MSA, ERR, FT1, SCH, and more. Unknown segments still parse — just without a friendly name.

Custom Separators

Some systems use non-standard delimiters. The tool reads them from the MSH header automatically:

  • Field separator (position 4 of MSH)
  • Component separator (position 5)
  • Repeat separator
  • Escape character
  • Subcomponent separator

Privacy

HL7 messages often contain PHI. Everything is parsed in memory and discarded after the response. Nothing is stored or logged beyond anonymized hit counts. For serious PHI work, consider running this locally.