# From Order to Report: How Integration Engineers Keep Radiology and Lab Workflows Running

> A deep dive into the clinical workflows that integration engineers support — the radiology order-to-report cycle, laboratory result routing, billing charge capture, and the HL7 message choreography that makes it all work.

Author: Ala Ben Aicha

Canonical page: https://alabenaicha.me/insights/radiology-lab-workflow-integration

Updated: 2026-10-05

## Direct answer

Radiology and lab integration is the order-to-report loop: an ORM (or equivalent FHIR ServiceRequest) carries the accession, the modality or analyser produces results, and an ORU / DiagnosticReport returns them without losing identifiers. DICOM is the image store; HL7/FHIR carry the order and the report. Failures usually come from accession, patient, and filler-order ID mismatches — not from the video codec.

## Questions this page answers

**What messages carry radiology and lab orders and results?**
ORM (or FHIR ServiceRequest) for the order; ORU (or DiagnosticReport + Observation) for the result. DICOM stores images; it is not the order/result bus.

**Why do reports attach to the wrong study?**
Accession, placer/filler order ids, and patient ids diverged. Test amendments and cancels, not only the happy-path ORU.

**Where is the integration service?**
[/services/hl7-fhir-integration](https://alabenaicha.me/services/hl7-fhir-integration) and [/services/ehr-emr-integration](https://alabenaicha.me/services/ehr-emr-integration).

## The short version

A reliable order-to-report integration preserves the patient, encounter, order and specimen or study identifiers from request through corrected result. Transport success alone does not show that the right clinical record received the right report. Test cancellations, duplicate messages, amendments and critical-result acknowledgements as separate workflows.

In FHIR R4, [DiagnosticReport](https://hl7.org/fhir/R4/diagnosticreport.html) provides report context and can reference individual Observation results. Imaging exchange uses DICOM services; a report link and an image transfer are distinct integration concerns.

See the [patient identity guide](https://alabenaicha.me/insights/master-patient-index-identity-management) before defining matching rules, and the [HL7 migration strategy](https://alabenaicha.me/insights/hl7v2-to-fhir-migration-strategy) for coexistence planning.

## Integration Is Not About Messages — It Is About Clinical Workflows

Most articles about healthcare integration focus on the protocols — HL7 v2 syntax, FHIR resource structures, transport mechanisms. That is important, but it misses the point. The reason these messages exist is to support **clinical workflows** — the sequence of events that starts when a doctor makes a clinical decision and ends when the result of that decision reaches the right person at the right time.

As a Technical Lead who builds integration pipelines, I have found that the difference between a working integration and a failed one is almost never the protocol. It is whether the engineer understands the clinical workflow the messages support. A perfectly parsed HL7 message that arrives at the wrong system, at the wrong time, or with the wrong linking identifier is worse than no message at all.

This article walks through two of the most critical clinical workflows that integration engineers support: the **radiology order-to-report cycle** and the **laboratory result pipeline** — plus the **billing integration** that captures revenue from both.

## The Radiology Workflow

Radiology integration is one of the most complex workflows in healthcare IT because it spans three different technology worlds: HL7 (clinical messaging), DICOM (medical imaging), and often FHIR (modern applications). The **accession number** is the key that holds all of it together.

### The Complete Cycle

```
Step 1: Order                    Step 2: Schedule
┌──────────────┐                ┌──────────────┐
│     EHR      │── ORM^O01 ──► │     RIS      │
│  (Clinician  │                │  (Radiology  │
│   orders CT) │                │   assigns    │
│              │                │   Accession  │
│              │                │   Number)    │
└──────────────┘                └──────┬───────┘
                                       │
Step 4: Report                   Step 3: Image
┌──────────────┐                ┌──────┴───────┐
│     EHR      │◄─ ORU^R01 ──  │   Modality   │
│  (Clinician  │                │  (CT Scanner) │
│   reads      │                │   acquires   │
│   report)    │                │   images,    │
│              │                │   tags with  │
│              │                │   Accession  │
│              │                │   Number)    │
└──────────────┘                └──────┬───────┘
                                       │
                                ┌──────▼───────┐
                                │    PACS      │
                                │  (stores     │
                                │   images)    │
                                └──────────────┘
```

### Step 1: The Order (ORM^O01)

A clinician in the EHR decides a patient needs a CT scan. The EHR generates an ORM^O01 message containing:

* **MSH segment** — message header with sending/receiving system identifiers
* **PID segment** — patient demographics (name, MRN, DOB)
* **PV1 segment** — visit information (attending physician, location)
* **ORC segment** — common order details (order number, order status, ordering provider)
* **OBR segment** — the actual order (universal service ID, requested procedure, clinical indication)

The OBR-4 field (Universal Service ID) contains the procedure code — for example, `71260^CT CHEST W CONTRAST^CPT4`. This tells the radiology department exactly what imaging study to perform.

### Step 2: The Accession Number

When the RIS receives the order, it generates an **accession number** — a unique identifier that will follow this specific imaging study through its entire lifecycle. This is the most critical identifier in radiology integration.

The accession number links:

* The HL7 order (ORM) in the RIS
* The DICOM images on the modality and in PACS
* The HL7 report (ORU) sent back to the EHR
* The billing charge (DFT) in the financial system

If the accession number is lost, duplicated, or mismatched at any point in this chain, the consequences cascade: images cannot be linked to orders, reports go to wrong patients, and billing claims are rejected.

### Step 3: Image Acquisition and DICOM

The RIS presents the order to the imaging modality (CT scanner, MRI machine, X-ray unit) via a **DICOM Modality Worklist (MWL)**. The MWL provides the technologist with the patient's demographics, the ordered procedure, and — critically — the accession number.

When the technologist acquires the images, the modality automatically tags every DICOM image with the accession number. The images are then sent to the PACS (Picture Archiving and Communication System) for storage and viewing.

The integration engineer must ensure that the accession number flows correctly from the RIS (HL7 world) through the MWL (DICOM world) and back. Any mismatch means images are orphaned — stored in PACS but not linked to the patient's order in the EHR.

### Step 4: The Report (ORU^R01)

After the radiologist reads the images and dictates a report, the RIS generates an ORU^R01 message containing:

* **OBR segment** — references the original order, includes the accession number
* **OBX segments** — the actual report content:
  * OBX with value type `TX` (text) — narrative report text
  * OBX with value type `ED` (encapsulated data) — PDF or RTF version of the signed report
* **Status** — preliminary or final (the OBR-25 field indicates whether the report is still pending radiologist review)

The EHR receives this ORU, matches it to the original order using the accession number, and displays the report in the patient's chart. The ordering clinician is notified that results are available.

### What I Build in Mirth Connect

For a typical radiology integration, I configure the following channels:

1. **ORM Router** — receives the order from the EHR, transforms it if needed (e.g., mapping procedure codes between systems), and routes it to the RIS
2. **ORU Router** — receives the report from the RIS, enriches it with any missing patient demographics (by querying the MPI if needed), and delivers it to the EHR
3. **Accession Number Tracker** — a monitoring channel that verifies accession number consistency across all messages. If an ORU references an accession number that does not match any known ORM, an alert is triggered immediately
4. **Status Update Handler** — handles order status changes (cancelled, modified, held) and ensures both systems stay synchronized

## The Laboratory Workflow

Laboratory integration follows a similar order-result pattern but with higher message volumes and more granular data.

### The Lab Cycle

```
EHR                    LIS                    Analyzer
┌──────────┐          ┌──────────┐          ┌──────────┐
│ Clinician│─ORM^O01─►│ Lab      │─Orders──►│ Chemistry│
│ orders   │          │ receives │          │ Analyzer │
│ CBC,     │          │ order,   │          │ runs     │
│ BMP      │          │ assigns  │          │ tests    │
│          │◄─ORU^R01─│ specimen │◄─Results─│          │
│ (sees    │          │ ID       │          │          │
│  results)│          │          │          │          │
└──────────┘          └──────────┘          └──────────┘
```

### Order Message (ORM^O01) for Lab

The lab order is similar to radiology but with lab-specific details:

* **OBR-4** contains the test order code (e.g., `CBC^COMPLETE BLOOD COUNT^L`)
* **OBR-15** specifies the specimen source (e.g., `BLD^Blood^HL70070`)
* **OBR-27** contains the collection priority (STAT, ROUTINE, ASAP)

A single order can request multiple tests — the ORM may contain multiple OBR segments, one per panel ordered.

### Result Message (ORU^R01) for Lab

Lab results are where the OBX segment becomes critical. Each individual test value is its own OBX:

```
OBR|1||LAB-123456|CBC^Complete Blood Count^L|||20260215140000
OBX|1|NM|6690-2^WBC^LN||7.5|10*3/uL|4.5-11.0|N|||F
OBX|2|NM|789-8^RBC^LN||4.8|10*6/uL|4.0-5.5|N|||F
OBX|3|NM|718-7^Hemoglobin^LN||14.2|g/dL|12.0-17.5|N|||F
OBX|4|NM|4544-3^Hematocrit^LN||42.1|%|36.0-46.0|N|||F
OBX|5|NM|787-2^Platelet Count^LN||250|10*3/uL|150-400|N|||F
```

Key OBX fields:

* **OBX-2** — value type (NM = numeric, ST = string, TX = text, CE = coded entry)
* **OBX-3** — observation identifier (ideally LOINC-coded for semantic interoperability)
* **OBX-5** — the actual result value
* **OBX-6** — units of measurement (ideally UCUM-coded)
* **OBX-7** — reference range
* **OBX-8** — abnormal flag (N = normal, H = high, L = low, HH = critically high, LL = critically low)
* **OBX-11** — observation result status (P = preliminary, F = final, C = corrected)

### Critical vs Routine Results

Lab results with abnormal flags of HH (critically high) or LL (critically low) require **immediate** clinician notification. In my integration pipelines, I build a filter that detects critical values and triggers an urgent notification channel — separate from the standard result routing — to ensure critical results reach the ordering clinician within minutes.

This is not just a nice feature. Regulatory requirements in many European countries mandate maximum turnaround times for critical value notification. A well-designed integration engine makes this auditable and reliable.

## Billing and Revenue Cycle Integration

Every clinical event — an admission, a procedure, a lab test, a radiology study — is also a financial event. The integration engine must capture these charges accurately and route them to the billing system.

### Charge Capture with DFT Messages

When a clinical procedure is performed, the system generates a DFT^P03 (Detailed Financial Transaction) message. The critical segment is **FT1 (Financial Transaction)**:

* **FT1-4** — transaction date
* **FT1-6** — transaction type (charge, credit, adjustment)
* **FT1-7** — transaction code (CPT, HCPCS, or local procedure code)
* **FT1-10** — transaction quantity
* **FT1-11** — transaction amount
* **FT1-20** — procedure code (links to clinical activity)

### The Automation ROI

Manual charge capture — where billing staff review clinical charts to determine what procedures were performed — is error-prone and slow. Common problems:

* **Missed charges** — procedures performed but never billed
* **Incorrect codes** — wrong procedure code leads to claim denial or underpayment
* **Delayed billing** — manual review adds days to the billing cycle, affecting cash flow

Automated charge capture through the integration engine eliminates these issues. When the RIS sends an ORU (indicating a radiology study was completed), the integration engine simultaneously generates a DFT to the billing system with the correct procedure code, ensuring that every completed study is billed accurately and immediately.

## Error Handling and Reliability

### ACK/NACK Management

Every HL7 v2 message must be acknowledged. The integration engine must handle three scenarios:

| Response                    | Meaning                                          | Action                                 |
| --------------------------- | ------------------------------------------------ | -------------------------------------- |
| **AA** (Application Accept) | Message processed successfully                   | Log success, move to next message      |
| **AE** (Application Error)  | Business-level rejection (e.g., unknown patient) | Route to error queue for investigation |
| **AR** (Application Reject) | Technical rejection (e.g., malformed message)    | Log error, attempt auto-fix, retry     |

For messages that fail persistently, the integration engine must:

1. Queue the message in a dead letter queue (never discard it)
2. Alert the support team with the failure reason
3. Provide a mechanism for manual reprocessing after the issue is resolved

### Monitoring and Alerting

In production, I configure Mirth Connect dashboards that track:

* **Message throughput** — messages per minute by channel (sudden drops indicate connectivity issues)
* **Error rate** — percentage of messages receiving NACK or failing transformation
* **Processing latency** — time from message receipt to destination delivery (critical result latency must be under 60 seconds)
* **Queue depth** — messages waiting to be processed (growing queues indicate downstream system problems)

## The Integration Engineer's Value

The clinical workflows described in this article — radiology order-to-report, laboratory result routing, billing charge capture — are the bread and butter of healthcare IT. They run 24/7, process thousands of messages per hour, and directly affect patient care and hospital revenue.

Building these integrations well requires understanding not just the HL7 message syntax, but the clinical context: why the accession number matters, what happens when a critical lab value is delayed, how a missing charge code affects revenue. This combination of technical depth and clinical workflow knowledge is what separates a message parser from an integration engineer.

I build and maintain these integration pipelines using Mirth Connect, HL7 v2, FHIR, and DICOM — connecting EHRs, RIS, LIS, PACS, and billing systems into workflows that clinicians can rely on. If your organization needs integration expertise for clinical workflows, I would be glad to discuss your requirements.