HL7 ORU messages vs PDF lab reports is a choice between data and a document. An ORU message sends each lab result as coded fields a system can file without retyping. PDF lab reports show the same results as a page a person reads. Choose ORU messages for steady volume from one lab, and PDF extraction for occasional outside labs.
What an HL7 ORU message carries for each lab result
An HL7 ORU message is the version 2 message a lab system sends to report results, and for each result it carries an order segment and one or more observation segments. The OBR segment describes the test that was ordered. Each OBX segment holds one result, with its code, value, units, reference range, flag and status.
HL7 version 2 messages are built from segments, which are lines that each start with a three-letter name. The HL7 map of the ORU_R01 message to FHIR lists the segments a result message can hold, including MSH for the message header, PID for the patient, ORC and OBR for the order, OBX for each observation, NTE for notes and SPM for the specimen.
What the OBR segment holds
The OBR segment names the test or panel and ties the results to an order. The HL7 map of the OBR segment to a FHIR DiagnosticReport gives the fields most offices care about:
- OBR-2 Placer Order Number, the order number assigned by whoever placed the order.
- OBR-3 Filler Order Number, the number the lab assigned.
- OBR-4 Universal Service Identifier, the code and name of the test or panel ordered.
- OBR-7 Observation Date/Time, which the HL7 map files as the time the results apply to.
- OBR-22 Results Rpt/Status Chng - Date/Time, when the report was issued or changed.
- OBR-25 Result Status, the status of the report as a whole.
What the OBX segment holds
Each OBX segment carries one result. The HL7 map of the OBX segment to a FHIR Observation names the fields, and this fictional potassium result shows them filled in. Every value, including the local test code EX-K, is made up for the example. In this example, vertical bars separate the fields and carets separate the parts of one field.
OBX|1|NM|EX-K^Potassium^L||5.6|mmol/L|3.5-5.1|H|||F|||20261012083000
| Field | HL7 name | Example value |
|---|---|---|
| OBX-1 | Set ID - OBX | 1 |
| OBX-2 | Value Type | NM |
| OBX-3 | Observation Identifier | EX-K^Potassium^L |
| OBX-4 | Observation Sub-ID | (empty) |
| OBX-5 | Observation Value | 5.6 |
| OBX-6 | Units | mmol/L |
| OBX-7 | References Range | 3.5-5.1 |
| OBX-8 | Interpretation Codes | H |
| OBX-11 | Observation Result Status | F |
| OBX-14 | Date/Time of the Observation | 20261012083000 |
The codes in the example come from published HL7 tables. In the HL7 data types code system, NM means "Numeric". In the HL7 observation interpretation code system, H means "High". In the HL7 observation result status table, F means "Final results". These are labels the lab sends. This post covers how they are stored, not what any result means.
The same result as printed on a PDF report
A PDF report from the same fictional lab would show the result as one row on a page:
| Test | Result | Flag | Units | Reference range |
|---|---|---|---|---|
| Potassium | 5.6 | H | mmol/L | 3.5-5.1 |
The row carries the same five facts as OBX-3, OBX-5, OBX-8, OBX-6 and OBX-7. What it lacks is the code in OBX-3 and the status in OBX-11, unless the lab prints them. A person can read the row at a glance. A system needs the row turned back into fields first.
What does a PDF lab report show that an ORU message leaves out?
A PDF lab report shows how the lab chose to present the results: their order on the page, the headers and footers, footnotes, comments placed beside a result, and the look of the signature block. An ORU message can carry most of these facts as fields or notes, but a given feed may leave some of those fields empty.
The CLIA rules set a floor for what the report must contain, including the name and address of the lab location that ran the test; the guide to lab report header fields and the CLIA report elements lists every item. A printed report shows them all on one page.
A printed report almost always shows the performing lab's name and address in its header. In an ORU message, the matching facts sit in OBX-23 Performing Organization Name and OBX-24 Performing Organization Address, according to the HL7 OBX map. If your feed does not fill those fields, the message alone may not tell a reader which lab location ran the test.
Comments are the other common gap. Lab reports often print a note such as "specimen hemolyzed" or "result confirmed by repeat analysis" beside the affected row. In a message, the HL7 ORU map places notes in the NTE segment under the observation. A system that files OBX values and ignores NTE segments loses the comment. A person reading the PDF sees it.
Layout itself carries meaning that a message does not. A PDF groups results under panel headings, places a flag in a particular column, and may show earlier results in a history column. Those visual cues help a reader, and they are exactly what has to be rebuilt when a PDF is turned into data.
HL7 ORU vs PDF lab report: a comparison by field
HL7 ORU and PDF lab reports line up field by field: each fact on the printed row has a place in the OBR or OBX segment. The difference is that the message gives every fact its own labelled slot, while the PDF gives it a position on a page. This table pairs the common report items with their ORU fields.
| Report item | Where it sits in an ORU message | Where it sits on a PDF report |
|---|---|---|
| Patient name | PID-5 Patient Name | Report header |
| Patient identifier | PID-3 Patient Identifier List | Report header, often labelled MRN or patient ID |
| Date of birth | PID-7 Date/Time of Birth | Report header |
| Test or panel ordered | OBR-4 Universal Service Identifier | Panel heading |
| Lab order number | OBR-3 Filler Order Number | Header, often labelled accession number |
| Observation date and time | OBR-7 Observation Date/Time | Header, next to the other dates |
| Report time | OBR-22 Results Rpt/Status Chng - Date/Time | Header, often labelled reported |
| Test name and code | OBX-3 Observation Identifier | Test column, usually the name only |
| Result value | OBX-5 Observation Value | Result column |
| Units | OBX-6 Units | Units column |
| Reference range | OBX-7 References Range | Range column |
| Flag | OBX-8 Interpretation Codes | Flag column or a mark beside the value |
| Result status | OBX-11 Observation Result Status | A word such as final, preliminary or corrected, if printed |
| Performing lab | OBX-23 and OBX-24 | Header or footer |
| Comments | NTE segment | Footnote or text beside the row |
The PID field names come from the HL7 map of the PID segment to a FHIR Patient. The test code in OBX-3 is often a LOINC code. The National Library of Medicine's LOINC overview describes LOINC as "a clinical terminology important for laboratory test orders and results" and says it was identified as a preferred code set for laboratory test names in transactions between health care facilities.
Status deserves attention. The HL7 result status table includes codes for preliminary results, final results, and a correction that replaces a final result. A PDF may print the same status as a word in the header, in a footer or nowhere at all. When a corrected report arrives as a PDF, someone has to notice the word "corrected" and replace the earlier values. In a message, the status code tells the receiving system.
When is a lab interface not worth building for an outside lab?
A lab interface is not worth building for an outside lab when the lab sends only a few reports a month, when the relationship is short or one-off, or when the lab cannot send messages your system accepts. In those cases, extracting the results from PDF reports and checking them costs less than building and testing a connection.
A lab interface is a standing connection that moves ORU messages from the lab's system into yours. Setting one up usually involves agreeing on which segments and fields the lab will fill, mapping the lab's test codes to the codes your system uses, testing with sample messages, and watching the feed after go-live. Each of those steps takes time from both sides, and someone has to maintain the mapping when the lab adds a test.
Here is example arithmetic, with made-up figures, to show how volume changes the answer. Suppose an outside lab sends 12 reports a month and each takes a staff member about 6 minutes to enter and check. That is 72 minutes a month. If the interface project would take 40 hours of staff time across both offices, it would need more than 33 months of saved entry time to pay back that effort, before counting upkeep. The same project for a lab sending 600 reports a month pays back far sooner.
PDF extraction is the better choice in these situations:
- Low volume. A specialty lab that sends a handful of reports a month.
- Variable sources. Results that arrive from many different labs, each with its own layout.
- Patient-supplied reports. Results a patient brings from a lab you have no relationship with.
- Historical records. Older reports from before any interface existed.
Who should do the PDF entry is its own decision. The comparison of outsourcing lab result data entry or automating it covers that choice.
Mapping extracted PDF lab fields onto ORU segments
Mapping extracted PDF lab fields onto ORU segments means placing each value read from the page into the slot it would occupy in a message: the header into PID and OBR, and each result row into one OBX. Doing this mapping, even on paper, makes the extracted data easier to compare with interfaced results and to check for gaps.
Start with the header. The patient name, identifier and date of birth fill the PID fields. The accession number, the panel heading and the observation date and time fill OBR-3, OBR-4 and OBR-7. The report date and any printed status fill OBR-22 and OBR-25.
Then take each result row in order and give it one OBX. Set OBX-1 to the row's position, put the printed test name into OBX-3, the value into OBX-5, the units into OBX-6, the range into OBX-7 and the flag into OBX-8. Decide OBX-2 from the value: a plain number is numeric, while text such as "negative" is not. Keep comments beside the row they belong to, as a note on that result.
Three gaps appear when you do this:
- No test code. Most PDFs print only a name. The OBX-3 slot needs a code your system recognizes, which means mapping each printed name to a code, often a LOINC code.
- No result status per row. A PDF usually prints status once for the report, if at all. Copy it to every row, and flag rows from a report marked preliminary.
- No machine timestamps. Printed dates and times need converting into one consistent format before they can fill OBR-7 or OBX-14.
This mapping is a way to organize fields, and Schema Care does not produce HL7 messages. What it does is read the test names, results, units, ranges and flags from a lab report page, score each field, and hold the doubtful ones for a person, as the human review steps describe.
Once results are in fields, they still need filing against the right patient and order. The guide to entering outside lab results into an EHR covers matching and filing. HL7 version 2, FHIR and other integration standards in general are covered in the developer integration category.