FHIR for AI results

An AI result that never reaches the report is mostly wasted. The radiologist sees a measurement on screen, retypes it into the report, maybe gets one digit wrong, and the structured value the model produced is gone.

Earlier in this series we covered DICOM SR: AI findings a report can read, which is the DICOM way of packaging findings and measurements. This post is about the other half of the journey: how those results get into the reporting application while the radiologist is working. The answer the industry is converging on is FHIR, and specifically the IHE Integrated Reporting Applications (IRA) profile. Herman Oosterwijk wrote a very good explainer, Using FHIR in the AI imaging ecosystem (IHE IRA), in June. What follows is our reading of it, with our own opinions from building reporting and viewing on one platform.

The problem IRA solves: context

Reading a study involves several applications at once. A PACS viewer, a reporting screen, sometimes a dictation tool, sometimes an AI app, sometimes the hospital's EMR. Each needs to agree on one thing at every moment: which patient, which study, which report.

When they disagree, bad things happen. Herman describes a case where he served as an expert witness. A reporting system and a PACS viewer fell out of sync, a report got linked to the wrong study, and it was caught only because the referring doctor noticed the chest X-ray was of a man while her patient was a woman. Nobody was physically harmed. It could easily have gone the other way.

(Inside a hospital, the same "which patient, which study" question runs through the HL7 messages between the HIS and radiology, which we covered in Connecting radiology to the HIS.)

The old answer to this was CCOW, a context-sharing standard that never got wide, reliable adoption. The new answer is FHIRcast, and IRA builds on it.

How FHIRcast works, in plain terms

There is one central Hub. Applications subscribe to a session on the Hub. One application drives the workflow, say the worklist or the reporting system, and when the radiologist opens a study it publishes an event. The Hub tells every subscriber, and they all switch to the same patient and study.

FHIRcast keeps every application on the same patient and study.

Events are small JSON messages wrapping FHIR resources. The ones that matter for reporting include Patient open/close, ImagingStudy open/close and DiagnosticReport open/close/update/select. In the IRA profile, these become transactions such as [RAD-146] Subscribe to Reporting Session, [RAD-148] Open Report Context, [RAD-150] Update Report Content and [RAD-151] Select Report Content.

IRA adds the idea of content on top of context. Any application can share what it has created into the current report context. An AI tool can post a measurement while the report is open. The reporting application receives it and, after the radiologist reviews it, places it in the report.

How AI results map to FHIR

A DICOM SR measurement maps to FHIR resources that a reporting system can use directly.

The IRA profile is clear about which FHIR resource carries what:

That last row is typical of FHIR. An Observation does not repeat the patient name and study details. It points to the Patient and ImagingStudy resources. Herman shows in his AIR article how the DICOM SR measurement template (TID 1500) maps onto Observations in exactly this way, which is why SR and FHIR are complementary rather than competing. SR is the durable record in the archive. FHIR is the live feed into the report.

Why reporting systems prefer FHIR to DICOM

This is a practical question, not a philosophical one.

Reporting teams are web teams. People who build reporting applications work in JSON and REST every day. A DICOM SR is a deeply nested hierarchical tree of content items with coded concept names. Parsing it correctly is real work, and many reporting tools simply do not have a DICOM stack. Herman notes in his AIR article that many reporting systems lack DICOM connectivity, and that FHIR is a much better interface than inventing another semi-proprietary API.

FHIR resources are small and specific. A reporting template wants "the aortic diameter value and its unit". With FHIR that is one Observation. With SR it is a walk through the tree to find the right container.

Timing. DICOM SR is usually stored to the archive and fetched later. FHIRcast pushes content into the open session as it happens, which is what the radiologist actually needs while dictating.

India adds a second reason. Our national health stack, ABDM, uses FHIR R4 profiles published by NRCeS for health records, including imaging reports. Teams here are going to learn FHIR anyway. The catch is versioning: ABDM work is R4, IRA is R5. A system that does both has to be careful about which version it speaks where.

How we think about it

Where IRA matters is at the edges. A hospital that wants its own dictation software next to our viewer. An external AI tool that wants to drop a measurement into the open report. A centre that uses a standalone reporting tool, like the Trinity Reporting Engine by SOMATIQ, alongside someone else's PACS. Each of these is an integration where context could slip, and each is a place where a standard beats a one-off connector.

At each edge, a standard replaces a one-off connector.

What we look for when we think about AI results in reporting:

1. The radiologist accepts every value. AI content should arrive as a suggestion the radiologist confirms, never as text that silently appears in a signed report. IRA's model, where the report creator retrieves content after review, fits this.
2. Every value keeps its source. Which algorithm, which version, which images. Observation plus ImagingSelection carries this, and it should stay attached after the value lands in the report.
3. Codes, not just strings. A measurement with a proper code can feed follow-up tracking and registries later. A sentence cannot.
4. SR in the archive, FHIR in the session. Keep both. They solve different problems. (For what the viewer should do with SR and the other AI objects, see The AI results checklist we hold our viewer to.)

AI content reaches the report only after the radiologist has reviewed it.

The practical upshot is that DICOM SR and FHIR are not rivals. SR keeps the AI result with the images, where it can be audited and retrieved years later; FHIR gets the same result into the report while the radiologist is still looking at the study. The advantage of IRA is that it gives this second step a standard shape; its disadvantage, for now, is that it is young and built on FHIR R5, so support will be uneven for a while. That is why I suggest asking every reporting and PACS vendor two questions: can you store and display SR, and what is your plan for IRA?

Keep both: SR in the archive, FHIR in the session.

Related reading

• DICOM SR: AI findings a report can read — the archive side of the same AI result.
• Connecting radiology to the HIS — HL7 v2 messages and where FHIR fits beside them.
• The AI results checklist we hold our viewer to — IHE AIR, the display counterpart to IRA.

FAQ

What is the IHE IRA profile?

IRA (Integrated Reporting Applications) is an IHE Radiology profile, built on FHIRcast, that lets a viewer, reporting system, EMR and AI tools share the current patient, study and report context, and share content such as AI measurements, in real time.

Which FHIR resources carry AI results?

Findings and measurements go in Observation, image and region references in ImagingSelection, and the report itself in DiagnosticReport. Patient and study are referenced through Patient and ImagingStudy.

Why do reporting systems prefer FHIR over DICOM SR?

FHIR is JSON over web APIs, which reporting developers already use, and each resource is small and specific. Many reporting systems have no DICOM stack, and SR trees are harder to parse.

Does FHIR replace DICOM SR for AI results?

No. SR remains the durable record stored with the images in the PACS. FHIR, through IRA, is how results reach the report while the radiologist is working.