Interoperability profiles as workflow recipes

Knowing the names of DICOM and HL7 services does not by itself explain how a complete workflow is assembled. A system can support an image-storage service and still leave the work item, result association, display, and monitoring steps ambiguous. IHE profiles address this kind of integration problem by specifying how existing standards are combined for a defined workflow.

Profiles combine standards; they do not replace them

IHE profiles are best read as workflow recipes. They may select actors, transactions, options, and sequences from DICOM, HL7, and related specifications so that an integration problem has a more explicit shape. They do not create a replacement for the underlying standards, and a profile name is not a guarantee that two particular products will work without configuration and testing.

This is a useful way to interrogate a deployment claim. Instead of asking only whether a vendor supports DICOM, ask which workflow is claimed, which actors are implemented, which transactions are used, and which options or limitations apply. The current official profile document remains the authority for those details; profile revisions and implementation status belong in maintained reference material rather than in the chapter’s durable mental model.

Three AI workflow roles

Several IHE Radiology profiles provide a useful orientation to the AI result path. Their exact actors and transactions must be read from the current profile documents, but their roles can be stated without depending on a particular revision.

• AIW-I (AI Workflow for Imaging) concerns the inference work item: requesting or dispatching an inference task, identifying its input, tracking execution, and coordinating the resulting workflow. The Unified Procedure Step model and its RESTful interaction are part of the mental bridge to the work-item services described earlier in the chapter.
• AIR (AI Results) concerns the communication, storage, retrieval, and display of structured AI results associated with their source imaging context. It is the profile role most directly related to the problem of a result that exists but is not visible or usable in a DICOM-aware reading workflow.
• AIRA (AI Result Assessment for Imaging) concerns structures and transactions for documenting and communicating assessment and feedback around AI results. Those records may contribute to filtering, metrics, quality assurance, post-market surveillance, or drift analysis, but AIRA does not define assessment criteria, establish whether a rating is correct, or supply a complete operational monitoring and rechecking process. It connects the informatics path to the longer lifecycle considered in the clinical deployment chapter.

These descriptions are orientation, not conformance verdicts. A profile can make a workflow contract more explicit, but it does not establish that a particular implementation selected the correct input, preserved every required relationship, or achieved clinical performance.

Use profiles to locate the failure boundary

The profiles are also a diagnostic lens. A dispatch or work-item problem points towards the inference workflow. A structured result that is stored but not retrievable or displayable points towards the AI-results path. A missing record of what happened points towards the interaction between work-item state, result provenance, and local audit mechanisms. A question about performance after deployment belongs to assessment and lifecycle evidence rather than to transport alone.

Question	Profile role that helps frame it
Was the intended study assigned to the intended inference task?	AIW-I and its work-item transactions.
Can the returned structured result be stored, retrieved, associated, and shown?	AIR and its result workflow.
Can the site represent and communicate feedback, metrics, and post-deployment assessments?	AIRA and the surrounding monitoring process.

This mapping does not mean that conformance has solved the failure. It tells the reviewer where to look for the declared contract and which end-to-end tests are still needed. The evidence remains the behavior of the configured system with the objects, identities, permissions, and viewer involved in the intended workflow.

The HL7 and FHIR bridge

Imaging is one subsystem in a wider hospital information fabric. DICOM describes imaging objects and their services; HL7 v2 and FHIR can carry broader workflow, administrative, and result information. An order may be represented through an HL7 interface or a FHIR request, while the acquired study remains a DICOM study. A report or measurement may then need to be related to both the imaging study and the clinical record.

FHIR makes some of those relationships explicit with resources such as ServiceRequest, ImagingStudy, DiagnosticReport, and Observation, but it is not a requirement that every integration represent every imaging detail in one of those resources. Nor does a rendered PDF have no role simply because a structured resource is available. The design question is what the receiving workflow needs: human-readable interpretation, queryable measurements, source linkage, or some combination. As with the DICOM-to-FHIR bridge earlier, the names are a conceptual map, not a mechanical translation table.

The profile perspective leads naturally to a more basic procurement and testing question. Even when two products claim DICOM support and an IHE workflow is named, what exact capabilities can each side accept, and who is responsible for the objects after the transfer? That question requires reading conformance statements and separating acceptance from custody.