IHE: profiles as workflow recipes
Tonight · ~20 min · read · energy: low · setup: none
IHE sounds like a standards body that issues checklists to memorise. It is not. IHE profiles are tested recipes for interoperable workflows, built from combinations of DICOM, HL7 and friends. This lesson teaches you to read them as solutions to the problems of lessons 5–6, not as material to memorise.
The anchor: recipes, not new standards
IHE (Integrating the Healthcare Enterprise) does not create new standards — it profiles combinations of DICOM, HL7, etc. to solve specific integration problems. Think “IHE Profile = a tested recipe for an interoperable workflow”. Read profiles as solutions to problems, not material to memorise. When a paper claims “deployed AI”, ask which IHE profiles it conforms to — often none.
The AI-relevant Radiology profiles
All three are VERIFIED at profiles.ihe.net; all
currently Trial Implementation, not Final Text — cite them as evolving
specifications.
- AIW-I — AI Workflow for Imaging (Rev 1.1, TI 2020). Manages the AI inference workflow: requesting, performing, monitoring inference on acquired images. It is built on DICOM UPS — specifically the RESTful UPS-RS workitem/worklist service (lesson 4) — for task dispatch and state tracking, using DICOMweb/DIMSE for input retrieval and output distribution. This is the recipe for the retrieve→infer→return loop of lesson 5.
- AIR — AI Results (Rev 1.3, TI 2025; incl. 2022 AIR+ extensions). The communication, storage, retrieval, and display of structured AI results (SEG/SR, measurements, result trees), associated with the source study so any DICOM-aware viewer can render them — instead of proprietary formats. This is the recipe for making a correct result visible (lesson 6).
- AIRA — AI Result Assessment for Imaging (Public Comment → Trial Implementation, 2025 cycle). It is not “AI Report Appendices”. It concerns the assessment of and feedback about AI results — quality assurance, human assessment/acceptance of AI outputs, monitoring, post-deployment performance surveillance, and drift detection. It is the profile most relevant to the post-market lifecycle of Chapter 9.
Mapping profiles to the failure modes
Each profile addresses specific failures from lesson 6:
| Failure mode | Profile that addresses it |
|---|---|
| Wrong study retrieved / task dispatch chaos | AIW-I (UPS-RS workitem workflow) |
| Result not retrievable / not displayable | AIR (structured results + viewer rendering) |
| Lost provenance | AIR (result trees tied to source) + AIW-I task state |
| No post-deployment monitoring / drift | AIRA (assessment, feedback, surveillance) |
This is why the profiles matter: they are pre-built, tested answers to the exact informatics failures that make correct models clinically useless. A system that conforms to AIW-I + AIR has solved dispatch, retrieval and display at the standards level; one that conforms to none is reinventing (and mis-implementing) the same problems.
HL7 / FHIR bridge (just enough)
DICOM handles images and imaging objects; HL7 handles everything else (orders, results, admissions, demographics). The bridge:
- Order flows RIS→modality (via MWL) and RIS↔EHR (via HL7).
- Report/result flows reporting→RIS→EHR (via HL7; increasingly FHIR, HL7’s modern REST/JSON/API-friendly standard).
- FHIR matters to imaging because discrete measurements and AI findings
increasingly need to land in the EHR as structured resources (e.g.
Observation), not just as PDF in a note.
You do not need HL7/FHIR depth for radiomics. You need the model: imaging is one subsystem in the hospital’s HL7/FHIR fabric; results must cross that bridge to affect care.
Stop and think — then reveal
A vendor says their AI is “fully deployed and integrated”. You ask which IHE profiles it conforms to and they cannot answer. Why is that a red flag, and which two profiles would most directly address “the result reaches and influences the reader”?
It is a red flag because “deployed” without profile conformance usually means the vendor solved dispatch, retrieval, display and provenance with bespoke (and often fragile) glue — exactly the failure modes of lesson 6. AIW-I addresses whether the right study is dispatched and tracked to the right inference task; AIR addresses whether the structured result is stored, retrievable and renderable by any DICOM-aware viewer, tied to the source study. Together they cover “the result reaches the reader”; AIRA then covers “we can monitor whether it is still right” (Ch. 9). No profile conformance ⇒ no standardised answer to those questions.
What to retain
- IHE profiles are tested recipes combining DICOM/HL7 to solve integration problems — not new standards, not checklists to memorise.
- AIW-I (inference workflow, on UPS-RS), AIR (structured results storage/retrieval/ display), AIRA (assessment/feedback/monitoring) — all Trial Implementation.
- Each maps to a lesson 6 failure mode; ask which profiles a “deployed AI” conforms to.
- Imaging is one subsystem in the hospital’s HL7/FHIR fabric; results must cross that bridge (increasingly as FHIR resources) to affect care.
You have finished Chapter 5. For the DIMSE/DICOMweb verb tables, profile versions, HL7/FHIR bridge detail and the full failure-mode catalogue, see the informatics reference. Continue to Chapter 6 — Medical imaging AI.