HL7 for lab and pathology results

Lab results are easy to parse and surprisingly easy to misfile.

Most lab and pathology interfaces are built around ORU_R01, with the report header in OBR and each result line in OBX. That sounds simple until the same message carries a panel, a corrected result, a microbiology culture, a reflex test, and a narrative comment.

The first rule is not to flatten the report too early. OBR-4 says what was ordered or reported as a service; OBX-3 says what a single observation is; OBX-5 carries the value; and status fields tell you whether the result is preliminary, final, corrected, or cancelled. The HL7 Chapter 7 observation model is built for repeated observations, so your receiver should be too.

Open the sample in HL7 Soup Web and look at the relationship between the OBR and its repeated OBX segments. If your mapping cannot preserve that parent-child shape, it is not yet a safe lab-result mapping.

MSH|^~\&|LIS|CITYLAB|EHR|CITYHOSP|20260715113000||ORU^R01^ORU_R01|LAB000501|P|2.5.1 PID|1||123456^^^CITYHOSP^MR||Smith^Jane^Anne^^Ms^^L||19800314|F PV1|1|O|OPD^12^1^CITYHOSP||||12345^Careful^Clara^^^^^^NPI ORC|RE|ORD4488^EHR|FILL7788^LIS||CM||||20260715101500|||12345^Careful^Clara^^^^^^NPI OBR|1|ORD4488^EHR|FILL7788^LIS|24323-8^Comprehensive metabolic panel^LN|||20260715100000|||||||||12345^Careful^Clara^^^^^^NPI||||||20260715112500|||F SPM|1|SPEC7788^LIS||SER^Serum^HL70487|||||||P||||||20260715100500|20260715102500 OBX|1|NM|2951-2^Sodium^LN||140|mmol/L|135-145|N|||F|||20260715110000 OBX|2|NM|2823-3^Potassium^LN||5.7|mmol/L|3.5-5.1|H|||F|||20260715110000 OBX|3|ST|5778-6^Color of Urine^LN||Yellow|||||F|||20260715110000 NTE|1|L|Repeat potassium if clinically indicated.

This is synthetic sample data for learning and testing. Open it in HL7 Soup Web before mapping it so the segment groups, repeated fields, and coded values are visible.

Message Shape To Respect

A result feed usually starts with MSH, patient context in PID, optional visit context in PV1, order context in ORC, report context in OBR, specimen context in SPM when the sender supports it, then one or more OBX observations. Comments commonly appear in NTE.

Do not assume one message equals one test. Panels produce multiple OBX values. Microbiology and anatomic pathology may use narrative OBX values, repeated OBR groups, parent-child relationships, or local profile rules. If you need CSV output, the correct grain is often one row per OBX, not one row per message.

SQL And Repeating Results

If the destination is SQL, decide the row grain before writing the mapping: one row per message, per OBR, per OBX, or per document payload. In many lab feeds, patient and order fields are copied into every output row while the observation code, value, units, abnormal flag, and status change inside the repeat. That is the same shape as the Integration Soup repeating OBX tutorial, even when the final target is a database instead of CSV.

In Integration Soup, keep patient, visit, order, and accession context outside the loop, then loop over the repeated OBR or OBX group when inserting observations, writing CSV rows, or building JSON. If you use a code activity for SQL, make the loop follow the repeated clinical object rather than the whole message, and store message control ID plus placer/filler identifiers so each inserted row can be traced back to the raw HL7.

Pathology And Narrative Results

Pathology results often mix coded facts with narrative interpretation. A receiving system that only expects numeric OBX values can make a blood test look fine and then silently lose the diagnosis paragraph. For surgical pathology, cytology, and cancer reporting, the message profile matters more than the base message name.

Cancer registry reporting is even more constrained; NAACCR publishes pathology laboratory electronic reporting guidance, and that is the sort of profile you should follow rather than inventing a local layout because it still starts with ORU_R01.

A Practical Integration Soup Workflow

In Integration Soup, I would keep the OBR group and each OBX visible in the workflow. Start with a receiver or Directory Scanner, add a realistic ORU sample as the message template, then map patient ID, visit number, accession, service code, observation code, value, units, abnormal flag, and status into the destination.

The repeating OBX to CSV tutorial is the exact pattern to borrow when one ORU should become multiple output rows. If you are writing files, also use the file-processing tutorial habits: archive source files, use unique output names, and write completed files in a way that downstream systems cannot pick up half-written content.

The Test Pack I Would Ask For

Ask for a normal panel, an abnormal value, a corrected result, a cancelled result, a result with comments, a report with multiple OBR groups, a specimen-heavy result, and a narrative pathology report. If public health reporting is involved, ask for the exact local implementation guide and test against that, not just generic ORU syntax.