Skip to content

HL7 to DICOM: The Imaging Order Round Trip

An imaging order is the most common place a healthcare interface has to cross standards. The order is written in HL7 v2, the exam is performed and stored in DICOM, and the report comes back in HL7 v2 again. Nothing translates between them automatically. This page follows one order across both seams.

Two standards, one order. The first two hops and the last are HL7 v2; everything between them is DICOM. Most imaging interface work happens at those two seams, not inside either standard.

The handoff is not a conversion step. The RIS receives an HL7 order and, some time later, a modality asks a DICOM service for a worklist. Those are two separate transactions against the same underlying order, and the only thing tying them together is the data the RIS copied from one into the other.

That copy is where imaging interfaces break. If it never happens, the modality queries an empty worklist. If it happens with the wrong values, the study arrives at the PACS carrying identifiers the order system does not recognise.

The ordering system sends an ORM message naming the patient, the procedure and the accession number. The ORM message reference covers the order control codes and the full lifecycle; what matters here is which fields the worklist will be built from.

An ED physician orders a CT of the abdomen and pelvis with IV contrast to evaluate acute right lower quadrant pain.

ORM^O01 6 segments HL7 v2.5.1

What the worklist is built from. Each ORM field lands in a specific DICOM attribute, and the accession number is the one both sides have to agree on: it is what lets the finished study find its order again.

The accession number is the join. It is assigned by the order system, carried in OBR-18, written into the worklist entry as DICOM Accession Number, and returned in the completed study. Every later step that has to associate images with an order resolves through it.

The modality asks a worklist provider what it is scheduled to do, using the DICOM query services rather than anything HL7. The DICOM service classes page covers how those queries are structured; the operationally interesting part is what happens when one comes back empty.

The failure everyone meets first. A query that returns nothing does not stop the exam, it just moves the data entry to the console, which is how a study ends up with an accession number the RIS has never seen.

A technologist who gets nothing from the worklist will key the demographics in by hand and scan the patient anyway, because the alternative is sending the patient away. The exam is now correct and the metadata is not, and the study will not reconcile against its order without manual repair.

While the exam runs, the modality reports progress with MPPS, and on completion sends the images to the archive. The archive now holds a study; the order system still has an open order. The loop closes when the reading radiologist signs a report and the RIS sends it back as an ORU message.

A radiologist finalizes a 2-view chest X-ray report, returning the narrative findings and impression to the ordering EHR.

ORU^R01 7 segments HL7 v2.5.1

That ORU carries the same accession number the order started with, which is how the report lands against the right order in the chart rather than becoming an orphaned document.

What to check when a study will not reconcile

Section titled “What to check when a study will not reconcile”
  • The accession number does not match. The most common cause, and the easiest to prove: compare OBR-18 on the order against Accession Number in the stored study.
  • The patient identifier does not match. The worklist entry was built from a stale PID, or the modality overwrote it during manual entry.
  • The order never reached the worklist provider. Check the ORM was delivered and acknowledged before looking anywhere downstream.
  • The study was performed outside the scheduled window. Worklist queries are usually date-scoped, so a rescheduled exam can be invisible to the modality without anything having failed.

For the wider EMR-and-PACS picture beyond a single order, see EHR and PACS integration.