HL7 ORM to DICOM Modality Worklist: The Order-to-Report Chain

Before any order flows, the imaging systems need to know who the patient is. That comes from the ADT feed, typically A04 for an outpatient registration, A01 for an admission, A08 for a demographic update and A40 for a patient merge. Teams building a radiology interface tend to treat ADT as plumbing already handled by someone else, and then spend months chasing symptoms whose root cause is that A08 updates were never subscribed to by the RIS.

The merge message deserves specific attention. When your registration desk discovers that Mr Sharma has been registered twice and merges the records, the HMS resolves it cleanly. Whether the RIS and PACS resolve it depends entirely on whether they receive and act on A40, and on whether the PACS supports patient reconciliation on already-archived studies. A hospital that has never tested this typically has a slowly growing population of studies filed under retired identifiers, discoverable only when a clinician cannot find a prior.

Decide and document your identifier strategy at the start. Which field carries the hospital UHID, whether the visit number travels separately, and what the assigning authority string is. Where ABDM linkage is in play, the ABHA Number is an additional patient-level identifier and not a replacement for your internal one, so keep them in separate fields with separate meanings. Interfaces built without that decision written down end up with three teams each assuming a different field is authoritative.

An ORM order message is mostly two segments that matter. ORC carries the order control code, which says whether this is a new order, a cancellation, a change or a hold, plus the ordering provider and the entering facility. OBR carries the clinical content: the service being requested, the placer and filler order numbers, the priority, the reason for the study and the scheduled date and time. Everything the technologist and the radiologist need to do their job correctly is either in OBR or missing from it.

Two fields cause disproportionate trouble. The first is the service identifier, because the code your HMS uses for a service is meaningless to a modality unless it maps to a DICOM-recognisable procedure and modality type. That mapping table, from your hospital service catalogue to procedure code and modality, is real work and it is never finished, because the department adds services. The second is the accession number, which is the join key for the entire chain and must be unique, stable and generated by exactly one system.

The clinical indication field is the one clinicians ignore and radiologists depend on. An order that arrives with the indication blank, or filled with the referring department's shorthand, forces the radiologist to interpret an image without knowing the question being asked. If your order screen makes indication optional, your reports will be worse, and no amount of integration quality compensates for that. Make it mandatory and make the field long enough to hold a sentence.

DICOM Modality Worklist is a query. The scanner acts as a service class user, sends a C-FIND to the worklist provider, and receives back the scheduled procedure steps that match its query keys. Those keys are usually the scheduled station AE title, the modality type and a date range. The technologist then selects a row, and the patient name, identifier, accession number, procedure description and study instance UID are populated into the study without a keystroke.

The failure that produces the most downstream damage is a worklist that returns nothing, because the technologist's response is entirely rational: they type the patient details in by hand and carry on scanning. The study is acquired, the patient is cared for, and an object now exists in the archive with a hand-typed name, possibly no accession number, and no link to any order. This is where unmatched studies come from, and every one of them is manual reconciliation work for somebody later.

Configuration mismatches cause most empty worklists. The AE title configured on the scanner does not match the scheduled station in the order, the date range is narrow and the order was placed for tomorrow, or the modality code sent by the scanner is CR while the order was scheduled as DX. None of these are difficult to fix once identified, and all of them are invisible from the HMS side, which is why the ability to run a worklist query from a test tool is a capability your team should have in-house.

Accession number mismatch is the classic. The HMS generates one, the RIS generates its own for internal use, and the number written into the DICOM header is the RIS one while the number on the bill and the report request is the HMS one. Reports then cannot be matched to studies automatically and someone reconciles by patient name and date, which works until two patients with the same common name are scanned on the same morning. Fix it by choosing one generator and making every other system carry that value as a reference, not as a second identity.

Patient identifier drift is the second. A patient registered in emergency without a full identity is scanned as an unknown, then properly registered an hour later. Now there are two identities and one study. Every hospital has this case and it is not a defect, it is emergency medicine. What matters is whether you have a defined reconciliation procedure, whether the PACS supports updating the study, and whether anybody is measuring how many such studies are outstanding.

The third is silent interface failure. A message queue stops, or the receiving system accepts messages and discards them because a mandatory field is absent, and nobody notices for six hours because the department is busy and the technologists have fallen back to manual entry. Interfaces should be noisy when they fail. A queue depth alert and a daily count reconciliation catch this in minutes rather than at the end of the month when billing does not tie out.

The signed report returns as an HL7 ORU message, carrying the same accession number, the result status, the observation text and the identity of the radiologist who signed it. Result status is the field most often implemented badly. A preliminary report, a final report and an addendum are three different things clinically, and if all three arrive with the same status code, the receiving system will either overwrite the earlier one or append a duplicate, and neither behaviour is safe.

Decide explicitly how amendments behave. When a radiologist issues an addendum after a report has been released to a patient portal, the correct behaviour is almost always to keep both versions visible, with the amendment clearly marked and dated, rather than silently replacing the text a clinician may already have acted on. This has a records dimension as well as a clinical one: a medico-legal enquiry will want the report as it stood at the time of the treatment decision.

Critical findings need a route that does not depend on the message. An unexpected finding requiring immediate action should trigger a call or an escalation with acknowledgement, not simply a report status change that a busy ward may not open for hours. Build the electronic path, and keep the human path documented alongside it, with a log of who was informed and when. HealUDoc activity logs can hold that acknowledgement against the same encounter, so the clinical trail and the interface trail sit together.

Build a single daily reconciliation that counts, for the previous day, orders placed, worklist entries created, studies received in the archive and reports returned, broken down by modality. Four numbers that should be nearly equal. Any divergence larger than a defined tolerance raises a ticket with a named owner. This is unglamorous and it catches the great majority of interface problems before a clinician does.

Add two live measures. Queue depth on each interface, alerted when it exceeds a threshold, and the age of the oldest unprocessed message. A queue that is growing tells you something is failing right now, which is far more actionable than a report telling you something failed yesterday. Where your integration runs through a broker, these are usually available out of the box and simply never configured.

Finally, keep a test patient and a documented smoke test that any duty engineer can run in ten minutes: place an order, confirm it appears on the worklist at a named station, acquire or simulate a study, confirm it lands in the archive with the right accession, and confirm the report returns. Run it after every change to any of the three systems. The trade-off is a small standing cost in discipline; the return is that you find out about a broken chain from your own test rather than from a technologist at two in the morning.