EDI, X12 and HL7: Reading the Formats That Run Behind the Scenes
Purchase orders, invoices and clinical messages travel in formats designed in the 1980s and still moving trillions of dollars. How to look inside one without specialist software.
There is a category of file most people never see and almost everyone depends on. EDI and X12 carry purchase orders, invoices and shipping notices between companies. HL7 carries clinical messages between hospital systems. They were designed when bandwidth was expensive, they look like line noise, and they are still in daily use at enormous scale.
If one lands on your desk, the immediate problem is simply reading it.
Why they look like that#
These formats are positional and delimiter-separated. Segments are separated by one character, elements within a segment by another, and the meaning of each position is defined by a specification rather than by anything in the file. There are no field names. A segment reading ST*850*0001 is a transaction header for a purchase order, and nothing in the file says so.
Converting to JSON gives the structure names and nesting, which turns an opaque line into something you can read and search. Convert X12 to JSON, convert EDI to JSON, or convert HL7 to JSON.
What conversion does and does not give you#
That is usually fine, because the question is generally which fields are present and what they contain. Reading the structure answers that. Acting on it needs the specification open beside you.
HL7 deserves particular care#
An HL7 message is, in almost every real case, about a patient. Name, date of birth, identifiers, diagnoses, results. It is health information in the regulatory sense, and the rules about where it may be sent are not advisory.
Uploading one to an online converter to see what is inside would be, in most jurisdictions, a disclosure. This conversion runs in your browser, so the message is never transmitted, and that difference is the entire reason this paragraph exists.
Practical notes#
- Delimiters vary by sender and are declared in the header. A file that parses oddly is often using different separators rather than being malformed.
- Segment terminators differ between systems, and a file that came through a Windows mail gateway may carry different line endings from one that did not.
- Envelope segments wrap the actual content. The interesting data is usually several levels in.
- Version matters. X12 and HL7 both have versions that changed field meanings, and the version is in the header.
Once it is JSON, the ordinary data guides apply: see CSV, JSON and Excel conversions for getting it into a spreadsheet.
Troubleshooting
Delimiters differ between senders and are declared in the header segment. Check what the file actually declares rather than assuming the common defaults.
Field meanings changed between versions of both standards. Check the version in the header against the specification you are reading.
Envelope segments wrap the content. The transaction you want usually sits several levels inside the interchange and functional group.
Segment terminators vary between systems and a file routed through a mail gateway may have been rewritten. Normalise them before parsing.
Frequently asked questions
What is X12?
The North American standard for electronic business documents: purchase orders, invoices, shipping notices and many more. Each transaction type has a number, such as 850 for a purchase order.
Will converting tell me what the fields mean?
No. It exposes the structure: segments, elements and positions. What element 03 of a given segment means comes from the specification and your trading partner agreement, not from the file.
Is it safe to convert an HL7 message?
Here, yes, because it runs in your browser and nothing is transmitted. Uploading one to an online converter would in most jurisdictions be a disclosure of health information.
Why do these formats look so cryptic?
They were designed when bandwidth was expensive, so meaning is carried by position rather than by field names. The tradeoff was deliberate and the formats long outlived the constraint.
Can I convert JSON back into X12?
Not here. Producing a valid outbound transaction requires the specification and the trading partner agreement, and generating one that looks right but is not would be worse than refusing.
