The AI results checklist we hold our viewer to
Most AI in radiology still reaches the radiologist as a screenshot. The algorithm draws a box on the image, saves it as a new DICOM Secondary Capture, and sends it to the PACS. The radiologist gets one more series to scroll, with the annotation burned in and no way to switch it off. The advantage of this method is that every PACS can display it; the disadvantage is that nothing else can use it, and the radiologist pays for it in clicks.
There is a better way, and it is already written down. Herman Oosterwijk, who has trained a generation of PACS administrators on DICOM and HL7, laid it out in Using the IHE AI-Results profile for AI deployment. I read his posts as they come out, and this one became our internal checklist. So, let's go over what the profile asks of a viewer, how we check our own viewer against it, and why it matters for Indian centres in particular.
What the IHE AIR profile asks of a viewer
First, a few words about IHE. DICOM and HL7 define the data and the messages; IHE profiles define how to use them together for a real workflow, with named "actors" (a modality, a PACS, a display) and the transactions between them. The AI Results (AIR) profile covers how AI output is created, stored and shown. In AIR terms, the algorithm is an Evidence Creator, the PACS is the Image Manager/Archive, and the viewer is the Image Display.
How IHE AIR moves AI results from the algorithm through the archive to viewer and report.
The part that matters most for a radiologist is the display transaction, RAD-136. A display that conforms must open four DICOM object types: Key Object Selection, Comprehensive 3D SR, Segmentation and Parametric Map. (If those names are unfamiliar, our DICOM explainer covers the basics.) On top of that, the display must do the following.
| Requirement | What it means at the workstation |
|---|---|
| Notify | Tell the radiologist that AI results exist for this study |
| Show the source | Show the algorithm name, version and manufacturer for every result |
| Pick what shows | Switch each finding, measurement or region on and off on its own |
| Point to the image | Make clear which image or frame a result belongs to |
| Regions | Show segmentations as shaded areas or contours, binary or fractional, several at once |
| Measurements | Show values on the image they belong to |
| Parametric maps | Show a colour map alone or blended over the source image, with blending control |
| Tracking IDs | Show the ID that follows a lesion across studies |
| Low effort | Do all of this without excessive interaction from the radiologist |
That last row is the one early adopters complain about most. Herman puts it as fitting into the workflow without excessive user interaction. In practice, a result that takes six clicks to find does not get looked at.
How we check SOMATIQ against it
We built the SOMATIQ viewer and archive ourselves, from the ground up, rather than on open-source projects such as DCM4CHEE, OHIF or Orthanc. Owning both keeps us close to the standards: DICOM objects reach the viewer as they were stored, not as pictures of themselves. It is also why we describe the platform as AI-native rather than AI added on; the AI result is a first-class object in the archive, not an attachment.
How we check the viewer: the basics are in, the metadata-dependent rows are hardest.
We go through the table above before each viewer release. The basics are in: AI output arrives as data, overlays switch on and off, and segmentations render as contours over the source series. Other posts in this series take the main object types one at a time: Presentation States, Structured Reports and, in a later post, Segmentation.
The rows we find hardest are not the rendering ones. They are "Show the source" and "Tracking IDs", because they depend on the algorithm filling in its metadata properly. A viewer can only display the algorithm version if the Evidence Creator wrote it. That is a useful question to put to any AI vendor before you sign.
Why this matters in India
Most Indian centres run a mix of modalities, PACS and AI vendors. Every non-standard AI integration becomes a custom project, and a multi-centre network can end up maintaining one integration per algorithm per site. Standards like AIR are how a network adds a new algorithm without a new integration each time. They also keep the radiologist in charge: the AI result is a layer the radiologist can inspect and switch off, which fits the view we argued in Radiology did not fail AI that the problem has usually been the workflow around the algorithm, not the radiologist.
With a standard, a new algorithm does not need a new integration at each site.
In conclusion, the IHE AIR profile is less about new technology than about agreeing where AI output goes and how it is shown. For a centre choosing a viewer or an AI product, the table above is a ready-made checklist: ask the vendor to show each row on a real study, and count the clicks.
Related reading
- Stop burning AI into the image — DICOM Presentation States as the first step away from screenshots.
- DICOM SR: AI findings a report can read — the AIR object that carries coded findings.
FAQ
What is the IHE AIR profile?
An IHE integration profile that defines how AI results are created, stored in the PACS and shown in the viewer, using DICOM and DICOMweb.
Is Secondary Capture wrong?
It works, but the annotation is burned into a new image. You cannot switch it off, and software cannot read the finding.
Which DICOM objects carry AI results?
Structured Reports for findings and measurements, Segmentation for regions, Parametric Maps for heat maps, and Key Object Selection for key images.
What should I ask an AI vendor about AIR?
Which of the four object types it produces, whether it fills in algorithm name and version, and whether it uses tracking IDs for lesions followed across studies.
Ready to see your workflow on one platform?
We will walk you through the whole workflow, from registration to signed report.