Data format

HL7 converter

An .hl7 file holds one or more HL7 version 2 messages: pipe-delimited healthcare interchange records made of segments — MSH for the header, PID for the patient, PV1 for the visit — each split into fields, components and subcomponents by a delimiter hierarchy declared in the message itself.

Private for supported formats — processed in your browser

Convert supported files

Runs on your device

Drop HL7 files here

Batch files can each use a different output. Nothing uploads for local conversions.

Working inputs include camera RAW, browser-local audio/video, PDF, CBZ/CBR comics, office documents, ebooks, markup, 3D models, structured text, images, and archives.

Where HL7 comes from

Health Level Seven International published HL7 v2.1 in 1988, and the standard has evolved through v2.9 while remaining broadly backward compatible. It is the most widely deployed healthcare messaging standard in the world — the overwhelming majority of hospital systems exchange v2 messages — and it persists despite HL7 having since produced v3 and FHIR, because replacing working clinical interfaces is expensive and risky.

How HL7 works

  • Segments are separated by CARRIAGE RETURNS, not newlines. This is the standard, not a Windows artefact, and readers that split on \n mis-parse real messages.
  • MSH-1 is the field separator and MSH-2 the encoding characters, conventionally |^~\& — the message declares its own delimiters before any parsing can begin.
  • The hierarchy is field, then component (^), then subcomponent (&), with ~ repeating a field.
  • Message type and trigger event (ADT^A01 for an admission, ORU^R01 for a result) determine which segments are expected.
  • The standard defines optionality loosely, so real-world messages are shaped as much by site-specific interface agreements as by the specification.

When to use HL7

  • Inspecting hospital interface traffic during integration work
  • Converting captured messages to JSON or CSV for analysis and debugging
  • Validating that an interface engine emits the segments a downstream system expects
  • Documenting an interface by turning sample messages into readable tables

Strengths and limitations

Strengths

  • Universally deployed across hospital systems — the safe assumption in healthcare integration
  • Compact and fast to parse compared with XML or JSON alternatives
  • Backward compatible across minor versions, so old interfaces keep working

Limitations

  • Extremely terse; a message is unreadable without a segment reference to hand
  • Site-specific customisation means conformance is a negotiation, not a check
  • Carriage-return separation and self-declared delimiters catch out naive readers

Compatibility

Mirth Connect, Rhapsody, Cloverleaf, HAPI and every hospital interface engine handle HL7 v2. Novus Convert parses segments and fields locally and converts to JSON, CSV and plain text without applying external profiles or code tables — the structure is exposed faithfully, and clinical interpretation is deliberately left to systems that hold the code tables. Files stay on the machine, which matters more here than for any other format on this site.

The MSH header — sending and receiving applications, timestamp, message type, control ID — is preserved in the JSON output.