Lab results, cleanly: automating HL7 result feeds (ORU) into the systems that need them

HL7 ORU messages, almost always the ORU^R01 trigger event, carry lab results from a laboratory information system to every downstream consumer that needs them: the EPR, the ordering clinician's system, sometimes a GP system or an alerting workflow. The feed looks simple and behaves like anything but, because volume is high, timing matters clinically, and the message structure (an OBR carrying order context, a stack of OBX segments carrying individual result values) has enough variation across lab systems to punish naive parsing. A reliable pattern receives the message, parses it into structured values, validates units and reference ranges before anything downstream sees it, routes to every consumer that needs it, and confirms delivery, treating the feed with the same rigour as any other clinically significant integration rather than as background plumbing.

ORU traffic rarely gets the attention its stakes deserve, mostly because it works most of the time and integration attention gravitates toward what's currently broken. But the failure modes here are directly clinical in a way that, say, a rostering feed's failure modes aren't: a delayed or lost result can mean a delayed diagnosis or a missed deterioration. Volume compounds the risk, because a Trust's pathology output is one of its highest-frequency message types, which means even a small percentage failure rate translates into a meaningful number of results going astray every single day.

The honest starting point for this piece is that lab result delivery deserves the same engineering seriousness as any patient-safety-relevant system, not the "it's just an old interface, it's fine" treatment it often gets.

An ORU^R01 message is built around a simple structure carrying real complexity underneath. The OBR segment carries the order context: which test, ordered by whom, on which specimen, at what point the specimen was collected and the result produced. Beneath it, a stack of OBX segments each carry one individual result value: the specific analyte, its value, its units, its reference range, and a result status indicating whether it's preliminary, final, or corrected.

That status field deserves particular attention, because a corrected result replacing an earlier preliminary one is exactly the kind of detail a naive integration can silently mishandle, either by failing to update the earlier value or by creating a duplicate that leaves both the wrong and right result visible side by side.

A handful of failure patterns account for most of the pain in real ORU integrations. Units and reference ranges getting lost or mismatched in transformation, so a numerically correct value displays without the context a clinician needs to interpret it safely. Corrected results not properly superseding prior ones, leaving stale or duplicate values visible downstream. Timing mismatches between specimen collection and result production, where a naive integration uses the wrong timestamp for either the trend view or the urgency calculation. And silent partial delivery, where a batch of results mostly routes correctly but a handful fail quietly, the same pattern that makes so many high-volume NHS feeds dangerous: the failures are rare enough to go unnoticed and important enough to matter when they happen.

A lab results pipeline that holds up in production has five deliberate stages:

1. Receive. Take the message over whatever transport the lab system uses, typically MLLP for a live pathology interface.
2. Parse. Turn the message into structured values, treating OBR and OBX as first-class structures rather than string-splitting them, and explicitly capture the result status field.
3. Validate. Check the data before anything downstream sees it: units present and sensible, reference ranges populated, and a corrected result correctly linked to whatever it supersedes.
4. Route. Send the result to every consumer that needs it: the EPR, the ordering clinician's system, any GP-facing feed, and potentially an alerting workflow for critical values. A single result often needs to reach more than one destination simultaneously.
5. Confirm. Acknowledge delivery to each consumer, so a silent partial failure becomes a visible exception rather than a result that simply never arrived anywhere it should have.

This is precisely the discipline WeHub Studio's HL7 Operation is built to support: parsing and producing v2 messages as structured operations rather than treating a pathology feed as an interface to be scripted once and left alone.

A production-grade ORU pipeline needs explicit handling for the cases that don't fit the simple story. Preliminary results followed by a corrected final need to be linked, not treated as two unrelated messages, so the receiving system shows the current, correct value rather than both. Critical or abnormal flags need a faster or additional routing path where clinical policy requires immediate notification, rather than travelling through exactly the same queue as routine results. And free-text microbiology or narrative results, common in pathology, need a defined handling approach, since forcing free text into a structured field it doesn't fit is its own quiet source of data loss.

ORU feeds are treated as solved because they mostly work, and that's exactly the wrong reason to leave them unexamined, given what's actually at stake when they don't. The fix isn't a new standard or a rebuild; it's applying the same discipline, parse properly, validate before delivery, route to every consumer, confirm receipt, that any clinically significant integration deserves. Pick your Trust's highest-volume pathology feed this month and ask one question: does anything validate units, reference ranges and correction status before a result reaches a downstream system? If the honest answer is no, that's the gap worth closing before the next audit finds it for you.