HL7 Testing 101: What Integration Engineers Wish They Had
If you're new to healthcare integration or coming from a web development background, HL7 v2.x can feel like stepping into another world. Pipe delimiters instead of JSON. Segments instead of objects. Field positions instead of named keys.
This guide covers the fundamentals of HL7 testing and the workflows that experienced integration engineers use to ship reliable interfaces.
HL7 v2.x in 60 Seconds
An HL7 v2.x message is a series of segments separated by carriage returns. Each segment starts with a three-letter identifier and contains fields separated by pipe characters:
MSH|^~\&|SENDING_APP|SENDING_FACILITY|RECEIVING_APP|RECEIVING_FACILITY|20260222120000||ADT^A01|MSG001|P|2.3
EVN|A01|20260222120000
PID|1||MRN001^^^MPI||DOE^JANE||19850315|F
PV1|1|I|ICU^101^A
The MSH segment is the header — it tells you what kind of message this is. The PID segment identifies the patient. Everything else describes what happened.
What to Test
Experienced integration engineers test three things:
- Structure: Are required segments present? Are fields in the right positions? Are data types correct?
- Content: Are code sets valid? Do dates parse correctly? Are identifiers formatted properly for the receiving system?
- Scenarios: Does the receiving system handle ADT A01 (admit) followed by A02 (transfer) followed by A03 (discharge) in sequence?
The Testing Gap
Most teams test structure and maybe content. Few test scenarios systematically. That's where production issues hide — in the sequence of events, the edge cases, and the vendor-specific quirks that only show up when two systems talk to each other.
Post by Pidgeon Health generates realistic multi-message scenarios with the right clinical context. Validate against standards. Test against vendor profiles. Catch the issues before go-live.