IHE Radiology: how imaging systems are made to work together

The gap standards leave

A hospital buys a new CT scanner. The vendor's DICOM conformance statement is impeccable. The RIS vendor's is equally impeccable. Both products have been sold into hundreds of sites. Neither is defective in any way a court would recognise.

On go-live, the scanner's worklist comes up empty for half the day's patients. When images do arrive, the PACS files a third of them under a study the radiologist cannot find from the report. The technologists start typing patient names by hand. Six weeks and one integration consultant later, the department discovers that the RIS was populating the accession number in a field the modality was not reading, and that nobody had agreed which system generates the Study Instance UID.

Nothing in that story violates DICOM. Nothing in it violates HL7. Both standards did exactly what they promise: they defined the syntax and semantics of individual messages. Neither says which messages must be sent, in what order, by which system, carrying which values, or what to do when a patient arrives unconscious with no name.

If DICOM and HL7 define the characters, words and grammar, an IHE integration profile is a complete scripted conversation: who speaks, in what order, using which words, and what happens when the conversation goes off-script.

IHE writes no standards

IHE began in 1998, when HIMSS and the Radiological Society of North America concluded that cooperative effort could raise interoperability between imaging and information systems further than either standards development or procurement pressure alone. Both remain sponsors.

The critical thing to understand is what IHE does not do. It does not write standards. It writes implementation specifications that constrain existing ones, among them DICOM, HL7 v2, CDA, FHIR, IETF protocols, SNOMED, LOINC and RadLex, into interoperable combinations. Adopting a profile is not adopting a new protocol. It is adopting a set of decisions about how to use protocols you already have.

A profile names abstract actors rather than products. It numbers the transactions between them. It pins the field-level mapping, down to which HL7 field carries which DICOM attribute. It assigns ownership of every identifier. It names the exception cases. And then IHE runs an annual monitored event at which vendors prove the result actually interoperates.

Scheduled Workflow.b, and why the letter matters

Scheduled Workflow integrates ordering, scheduling, acquisition, storage and viewing for a radiology exam. It is the backbone of the domain and the profile against which almost every RIS, modality and PACS on the market is sold. It defines nine actors, none of which is a product: a single RIS typically implements three, and a PACS three or four.

SWF and SWF.b are both Final Text and both currently published. They are siblings, not successors, and IHE states the relationship as a formula: SWF.b equals SWF plus PIR plus HL7 v2.5.1, minus HL7 v2.3.1.

SWF.b makes v2.5.1 mandatory for the HL7-based transactions, drops v2.3.1 entirely, and absorbs the Patient Information Reconciliation transactions into the base profile rather than leaving them as a separate claim. It reached Final Text in September 2020, so a presentation given that year may well predate its promotion. For anything new, SWF.b is the profile to specify.

One concrete benefit is worth checking in a vendor’s interface specification. In the classic order message the Study Instance UID travels in a ZDS segment, a non-standard Z segment, because HL7 v2 has no native field for it. The v2.5.1 OMI^O23 message used by RAD-4 introduces the standard IPC segment, which carries the accession identifier, requested procedure ID, Study Instance UID and scheduled procedure step ID in properly defined fields.

The identifier chain is the whole profile

Strip away the transaction numbers and Scheduled Workflow is one idea: a small set of identifiers is generated exactly once, by exactly one system, and every other system copies rather than invents them. Everything else in the profile exists to move those identifiers to the systems that need them, before they need them. Almost every workflow defect in a radiology department is a violation of that sentence.

Note what is absent from that table. In the scheduled case the modality generates none of these; it receives them and copies them. IHE is unambiguous about it: worklist return values, where available as a source, shall be used by the acquisition modality in filling the corresponding attributes of both composite instances and MPPS instances.

The identifiers reach the two systems that need them by different routes, and the timing is the point. RAD-4 Procedure Scheduled carries the full set from the RIS to the Image Manager while the patient is still in the waiting room, which is what pre-registers the study and lets a well-integrated PACS show a scheduled but not yet acquired exam. RAD-5 Query Modality Worklist delivers them to the scanner, at the scanner. Everything the scanner then produces carries them back out, in the Request Attributes Sequence for images and the Scheduled Step Attributes Sequence for procedure step messages.

A grouping requirement that explains MPPS

IHE specifies not only which actors exist but which must be implemented together. SWF.b requires the Performed Procedure Step Manager to be grouped with the DSS/Order Filler and with the Image Manager.

This is the single most useful structural fact in the profile. One message from the scanner reaches both the RIS and the PACS because the relaying actor is specified to live inside both. Group it into only the RIS, a very common deployment shortcut, and the PACS never learns that an exam completed. That is the fix for studies which show as finished on the reading worklist and permanently in progress in the archive, and it is a grouping problem rather than a modality problem.

When reality intrudes

The happy path is one of thirteen documented use cases. The other twelve are where the profile earns its reputation, because they cover the situations that actually generate support tickets: the patient arrives unconscious, the exam is done before anyone writes an order, the technologist performs something other than what was requested.

The scheduled and unscheduled cases are deliberately asymmetric. Scheduled, the modality copies the accession number, Study Instance UID, requested procedure ID and scheduled step ID straight from the worklist. Unscheduled, there is nothing to query: the Study Instance UID is generated locally, because the objects must be storable at all, and the accession number is left at zero length.

IHE recommends that the Accession Number rather contains no value than an unreliable value.

This is the design principle most often violated in the field, usually by a well-meaning modality configured to generate a temporary accession number so the field is not blank. A null is recoverable. A plausible wrong value is not: it will match something, eventually, and quietly.

When the real identity is established, RAD-12 Patient Update propagates the correction to the Order Placer, the RIS and the Image Manager, with RAD-13 Procedure Update following if the procedure details changed too. What matters architecturally is that the correction is a transaction, not a database migration. Every system in the chain is specified to accept an identity update after the fact, which is precisely why the trauma case does not require someone to log into the PACS and edit records by hand.

The reconciliation profiles nobody specifies

Scheduled Workflow assumes things go roughly right. Four sibling profiles handle the cases where they did not, and a radiology project that specifies SWF.b without at least considering these has left the hard half unspecified.

• PIR, Patient Information Reconciliation. Coordinates reconciliation when images were acquired for unidentified or misidentified patients. Its content is built into SWF.b, but it remains separately published, so a vendor claiming only plain SWF must claim PIR as well to get the same behaviour.
• IOCM, Imaging Object Change Management. How one system tells the others that stored objects should be rejected, corrected or withdrawn. This is the answer to forty images landing under the wrong patient: a rejection note, not a database edit.
• IRWF, Import Reconciliation Workflow. Bringing outside studies into the local identity domain without corrupting either. IRWF.b has been in Trial Implementation since 2016.
• PGP, Presentation of Grouped Procedures. One acquisition covering several separately ordered procedures, each readable and reportable on its own, without a second exposure.

The distinction worth making at procurement is simple. SWF.b tells you what a correct exam looks like; IOCM and IRWF tell you what happens to an incorrect one. Vendors compete hard on the first and are often quiet about the second, and the second is where clinical risk actually lives. An image filed under the wrong patient is a patient safety event, not a data quality issue.

What changed since 2020

Three streams have opened that change what you should be specifying.

• An AI profile family that did not exist. AIW-I, from 2020, governs how inference is requested and dispatched, built on DICOM UPS-RS rather than modality worklist, with pull, triggered pull and push models. AIR, from 2022, constrains the output: Comprehensive 3D SR on template TID 1500 as the primary encoding, plus Segmentation and Parametric Maps, and it explicitly excludes Secondary Capture. AIRA, from 2025, covers assessment of AI results: clinical validation, post-market surveillance and data drift detection. Every profile in the family is still Trial Implementation, which is a reason to read the status line before writing one into a contract rather than a reason to ignore them.
• A web-native access layer. WIA covers RESTful retrieval and viewing, WIC covers capture from lightweight devices, and BIR specifies the baseline functions a non-radiologist viewer must offer. IID is the small and unglamorous one: a URL-based hand-off that lets an EHR open a study in a viewer without either system knowing anything about the other. MADO, still Trial Implementation, adds selective retrieval from a manifest with both DICOM and FHIR encodings and a mapping between them.
• Operational visibility. SOLE defines exchange of business activity events, not audit events, so departmental operations can be measured with standard methods rather than by scraping logs. If anyone in your organisation is building radiology operational dashboards from bespoke log parsing, this is the profile that ought to replace it.

IHE and FHIR, honestly

IHE's two most relevant domains have moved at very different speeds, and conflating them will mislead you.

IT Infrastructure has largely completed a FHIR transition. Its profiles are published as versioned FHIR Implementation Guides: MHD for document access, PIXm and PDQm for patient identity, IUA for authorization, mCSD for service discovery, BALP for audit. If your architecture needs identity, sharing or security services, the FHIR-based answer already exists and is maintained.

IHE Radiology has not, and deliberately so. SWF.b runs on modality worklist and HL7 v2.5.1, and AIW-I runs on DICOM UPS-RS. FHIR is entering Radiology selectively and from the top, at the report layer and the manifest layer, rather than displacing the acquisition workflow. A useful way to hold it: FHIR is winning where the consumer is a clinical application or another enterprise, and DICOM is holding where the consumer is a device or an archive.

What the testing actually proves

Once a year in each of three regions, vendors bring their products to a hall and test every transaction of every profile they claim against multiple other vendors, under monitored conditions. The Connectathon is the single most effective interoperability mechanism healthcare has produced, and it is the reason IHE profiles work in practice rather than only on paper.

An IHE Integration Statement is a different thing. Its structure is prescribed; its contents are not verified. In IHE’s own words, vendors are solely responsible for the accuracy and validity of their integration statements. Treat one exactly as you would a DICOM conformance statement, as a structured claim to be checked. The check is straightforward: take the profile, actor and option list from the statement, and look that vendor up in the public Connectathon results database to see what was actually tested, against whom, and in which year.

Writing it into a real project

1. Name profiles, actors and options, not "IHE compliance." "Must be IHE compliant" is unenforceable. "Must support Scheduled Workflow.b as Acquisition Modality, including the Broad Worklist Query, Modality Group Case and PPS Exception Management options" is a specification you can test against. A product can support a profile as one actor and not another.
2. Ask for the integration statement, then verify it. Request it for the exact product version being quoted, not the product line, and check the Connectathon record for it.
3. Check the status line of every profile you cite. Final Text and Trial Implementation are very different commitments. A profile that has been in Trial Implementation since 2006 is not a foundation.
4. Specify the exception paths, not just the happy path. Unscheduled exams, unidentified patients, changed procedures and objects stored in error are where the cost lands. Name PIR behaviour, the exception-management option, IOCM, and IRWF if outside studies will arrive.
5. Settle identifier ownership in writing, before build. Who mints the accession number, who mints the Study Instance UID, and whether the Enterprise Identity option is in scope. It is a half-page decision that prevents a six-month problem, and it is almost never written down.
6. Pin the HL7 mapping. Which segment and field carries the accession number and the requested procedure ID, and whether the Study Instance UID travels in a Z segment or the standard IPC segment. Get both vendors’ interface specifications side by side and confirm they agree before anyone writes code.
7. Plan for the AI actors now, even if the model comes later. Specifying AIW-I dispatch and AIR result encoding at PACS procurement is enormously cheaper than negotiating it as a change request against a deployed archive two years later.

One option deserves pulling out of that list, because nobody implements it until it is too late. Enterprise Identity qualifies Patient IDs and Accession Numbers with the institution that issued them. Every hospital merger, every regional PACS consolidation and every shared VNA eventually runs into two sites that independently issued accession number A-88213. Requiring it at procurement costs almost nothing; retrofitting it after the archives have been merged does not.

Part 1 of this series covers the standard underneath everything described here. The full 29-page paper walks all twenty transactions, the twelve named options, both canonical process flows, and nine failure modes IHE documents against its own flagship profile.