HL7 test data that behaves like a sending system
An HL7 sample file tells you your parser runs. It does not tell you what happens when the messages arrive in the wrong order, when the ACK comes back AE, when the same result is sent twice, or when the connection drops half way through a run. MediFlow sends the messages the way a hospital sends them, and reads back what your system said in reply.
Messages in clinical order, not in file order
A real feed is a sequence with meaning. The registration precedes the order; the order precedes the result; the discharge summary refers to an encounter that exists. MediFlow builds an encounter and emits its messages in that order, so your interface is tested against the dependencies it will actually meet:
- ADT for registration, admission, transfer, discharge and the cancellations that follow them.
- ORU for results, including the panels a given diagnosis would really trigger.
- ORM, RDE and RAS across the order and medication lifecycle.
- MDM for documents, DFT for charges, VXU for immunisations, SIU for scheduling.
A single patient run produces a couple of dozen messages across those types, which is a far better test of a channel than a thousand copies of one ADT.
Delivery, acknowledgement, and the failures in between
Messages go out over MLLP on a TCP port, or over HTTPS to an endpoint, whichever matches the system under test. Each acknowledgement is read back and scored, so an AE or an AR is a reported failure rather than a silence. That makes the awkward cases testable on purpose:
| Case | What it exposes |
|---|---|
| Duplicate message | Whether your engine deduplicates or creates a second result |
| Out-of-order arrival | Whether a transfer processed before its admission corrupts the encounter |
| Rejected message | Whether an AE is surfaced to a human or swallowed by the channel |
| Connection loss mid-run | Whether the sender retries, and whether the retry duplicates |
| Unknown or local code | Whether the value lands in a mapped field or quietly becomes an orphan |
Real codes, or an honest local one
Interface testing goes wrong when the test data carries codes the receiving system would reject anyway. Every LOINC, ICD-10-CM, RxNorm and CVX code MediFlow sends is checked against the published release before it ships, and the build fails on a code that is not current. Where no standard code exists for a concept, MediFlow sends a local code explicitly marked as local, which is correct HL7 behaviour and keeps the distinction visible to whatever is mapping on the far side.
Messages that know which facility they came from
Most test feeds arrive as one anonymous sender, which means per-facility routing, per-facility metrics and per-facility mapping coverage cannot be tested at all. MediFlow carries a registry of facilities, each with its own identifier and NPI in the message header, and a patient keeps the same facility for its whole history. For an HIE, a regional platform or any multi-site integration, that is the difference between a feed you can rehearse against and a feed that only proves one channel works.
Tell us what you need to trust
Describe the workflow, interface or release you are validating. We define the synthetic patients, the interface profile, the expected outcomes and the evidence you get back. Reply within one business day.