Most radiology IT problems trace back to a handful of poorly configured HL7 messages. We've seen integrations that took six months to stabilize, and in the vast majority of cases, the root cause wasn't hardware, network, or even the PACS itself. It was a mismatch in how ADT events fed the worklist, or an ORU delivery gap that left the RIS out of sync. This primer walks through the core message types, the accession-number pipeline, and the interface engine patterns that matter for anyone building or maintaining a PACS integration today.
The Three Message Flows You Actually Need to Understand
HL7 v2.x is a messaging standard from the late 1980s that somehow became the backbone of modern hospital interoperability. That's not a compliment. It's flexible to the point of being ambiguous, and two vendors can both claim "HL7 v2.5 compliant" while producing messages that fail silently on each other. That said, if you can nail three message flows, you'll cover roughly 90% of a standard radiology workflow.
ADT messages (Admit/Discharge/Transfer) are the first feed into PACS. The A01 event fires when a patient is admitted, A04 for outpatient registration, A08 for patient information updates. These messages carry the MRN, patient name, date of birth, and visiting information. Your PACS and RIS need this data before any imaging order can be placed. Miss an A08 update, and the worklist shows the patient's maiden name from a registration twelve years ago.
ORM O01 messages carry the imaging orders. When a clinician orders a chest X-ray in the EMR, an ORM O01 fires toward the RIS. The RIS creates an accession number, then forwards a modified ORM to the PACS. This two-hop journey is where accession collisions happen. If the RIS assigns accession numbers using a sequence that doesn't account for system clock skew across HL7 brokers, you can end up with two separate orders carrying identical accession numbers. In our tracking, this happens in roughly 3-8% of fresh integrations before tuning.
ORU R01 messages carry results back. When the radiologist signs a report in the PACS reading station, the result fires as an ORU R01 toward the ordering system, the EMR, and sometimes a results notification service. ORU delivery gaps, where the message never arrives or arrives malformed, are the most common complaint from ordering physicians. They dictate, sign, wait. Nothing shows up. The HL7 feed is usually the culprit.
The Accession Number Pipeline
Accession numbers are the thread that ties an imaging order to the DICOM study to the final report. Get this wrong and your worklist becomes untrustworthy. Quickly.
The pipeline typically looks like this:
- EMR sends ORM O01 to the interface engine (no accession number yet)
- Interface engine routes to RIS, which assigns an accession number in the ORC-3 field
- RIS sends a modified ORM to the modality via the DICOM Modality Worklist (MWL) query
- Technologist performs the study; modality stores DICOM images using the accession number from the MWL response
- PACS receives the DICOM study and associates it to the RIS order via that accession number
- Radiologist signs the report; ORU R01 fires back with the accession number in OBR-18
Any break in this chain produces orphaned studies, which are DICOM images sitting in the PACS with no linked order. Orphaned studies don't appear on the worklist. Radiologists don't see them. That's a patient safety problem.
Modality Worklist: Where DICOM Meets HL7
Most radiologists interact with the Modality Worklist (MWL) without knowing it. When a CT scanner displays the patient name and accession number pre-populated before the scan, that data came from an MWL query. The modality sends a DICOM C-FIND request to the MWL server (usually part of the RIS or a standalone broker), which returns the scheduled procedure step. This is the handoff point between the HL7 world of the RIS and the DICOM world of imaging equipment.
The MWL query uses four or five matching keys: patient ID, scheduled date, modality type, and sometimes the accession number. Loose matching keys can return too many results. Overly strict keys return nothing. We've found that most community hospitals default their MWL servers to "any date, any modality" just to avoid zero-result queries, which defeats the purpose of the worklist filtering entirely. The right configuration matches on scheduled date plus modality type, with a 48-hour lookahead window.
Interface Engines: Rhapsody, Mirth, Corepoint, Cloverleaf
The interface engine is the traffic cop sitting between every system. It receives HL7 messages, applies transformation rules, routes them to destinations, and logs every transaction. Four products dominate this space:
| Engine | Ownership | Common Use Case | Pricing Model |
|---|---|---|---|
| Rhapsody | Rhapsody (Orion Health spin-off) | Large academic medical centers, complex routing | Connection-based license |
| Mirth Connect | NextGen Healthcare | Community hospitals, open-source core | Free OSS + paid support |
| Corepoint | Rhapsody (acquired 2017) | Mid-size hospitals, visual workflow builder | Connection-based license |
| Cloverleaf | Infor (Cloverleaf) | Legacy enterprise, mainframe environments | Enterprise contract |
For radiology integrations specifically, Mirth Connect is the most common choice in community hospital settings because the open-source license removes the per-connection cost model. The tradeoff: support is community-driven, and complex transformation logic requires JavaScript or Rhino scripting knowledge that not every IT team has in-house. Rhapsody and Corepoint both offer graphical transformation tools that reduce scripting, but at significantly higher total cost.
The Most Common Pitfalls
In our experience, most PACS integration failures fall into three categories. Not network outages, not vendor bugs. Configuration and data quality.
MRN mismatch. Every source system has its own patient identifier scheme. The EMR uses a 7-digit MRN. The RIS uses a legacy 10-digit number with a site prefix. The PACS uses the EMR MRN. Unless the interface engine normalizes identifiers before routing, the same patient will exist as three separate people across systems. This breaks the accession pipeline completely because the DICOM study can't link back to the HL7 order.
Accession collision. This happens when the RIS and the PACS both generate accession numbers independently, or when the RIS sequence generator isn't synchronized across redundant RIS nodes. A study comes in with accession number 2024003847, but another study already occupies that slot. One study gets bumped to an "orphaned" state. The radiologist sees an incomplete worklist. Nobody knows why until someone runs a PACS audit report.
ORU delivery gaps. ORU R01 messages are supposed to travel from the PACS to the EMR after report sign-off. But the routing rule in the interface engine might only fire for FINAL status, not for ADDENDUM. A radiologist adds a critical finding addendum two hours after initial sign-off. The interface engine ignores the addendum message. The ordering physician never sees it. This is a compliance issue under most state critical results notification regulations, not just a workflow annoyance.
Practical note: Always configure ORU routing rules to handle PRELIMINARY, FINAL, CORRECTED, and ADDENDUM statuses explicitly. A catch-all "any status" rule looks safer but often masks delivery failures in logging dashboards.
Building It Right the First Time
There's no magic here. Just discipline.
Before go-live, map every message flow end-to-end on paper. Identify every field transformation the interface engine applies. Validate that MRNs are normalized to a single master patient index before any message leaves the broker. Run a 72-hour parallel processing test where both the old and new systems receive every HL7 message, and audit the outputs for discrepancies.
Post go-live, set up automated monitoring on ORU delivery. Track the time between report sign-off and EMR receipt. Anything over five minutes warrants investigation. Set up daily orphaned study reports from the PACS. A count above zero means something in the accession pipeline is broken.
AI-powered tools that sit on top of PACS, like automated triage, anomaly flagging, or worklist prioritization, are only as good as the data flowing into them. If the HL7 feeds are clean, the AI has something to work with. If the worklist has orphaned studies, mismatched MRNs, and delivery gaps, the AI sees incomplete context and produces unreliable outputs. Getting the integration right isn't just a technical checkbox. It's the foundation everything else depends on.
Questions about your specific PACS configuration? Reach out to the Pacslens team. We work with community hospitals at every stage of integration maturity.
