IRA Content - Proposal

1. Proposed Workitem: IRA Content

• Proposal Contributors: Kevin O’Donnell, Tarik Alkasab, Michael Hood, Seth Berkowitz
• Workitem Editor: Kevin O’Donnell
• Domain: Radiology

Summary

IRA (Integrated Reporting Applications) profiled FHIRcast-based patient/study context switching, but content sharing between subscribed applications was generalized. It didn't get down to the level of detail likely needed for robustly interoperable content sharing.

This proposal will profile medical image finding sharing (including CDE finding sets) between systems such as AI tools and Report Creators. The work will leverage the finding profiles of FHIR Observation and BodyStructure in IDR Phase II.

The result will be packaged either as a named option on the existing IRA Profile or as an updated IRA.b Profile.

RSNA CDE participants and DICOM WG-20 members will be involved in review and possibly development.

This work builds on useful synergies between existing IHE Profiles.

2. The Problem

Integrated Reporting Applications (IRA) profiled FHIRcast and patient/study context switching for reporting and associated processing. General mechanisms were identified for sharing content between subscribed applications but the content itself was largely undefined. For example, an AI application trying to provide a candidate finding to a Report Creator has little guidance beyond "try using a FHIR Observation in some way".

Systems providing and consuming such content depend on having a standard/shared understanding of how that content is encoded. This is particularly needed when multiple applications from multiple vendors are trying to collaborate. Otherwise the effort, configuration, and out-of-band information needed becomes excessive.

Imaging Diagnostic Report (IDR) (especially in Phase II) has now worked out a lot of relevant specification for coding findings and conclusions (Key content for reporting) into FHIR resources and sets of resources. This could be leveraged to fill some content standardization gaps in IRA.

3. Key Use Case

Generated Findings

The most basic content sharing includes tools and apps (conventional image/clinical analysis or AI-based) that generate candidate observations/findings for study images.

A source tool/app might create/share an individual measurement / segmentation / classification, or it might share a full set of such things, like a CDE Set, or it might add one or more such things to an existing Set.

A display app (which might be part of the report creator or the image display or something else) can present those findings to the radiologist. The report creator app can incorporate those findings into the evolving report content. Based on interactions between the radiologist and these results, an app might create AIRA assessment objects.

Early in this process, another app might correlate / match newly generated findings with existing / prior findings.

For most / all of this, the content definitions would build on the Findings and Conclusions encodings in IDR Phase I & II.

Imaging “Problem List”

The IPL concept is continuing to be refined and developed under the leadership of Tarik Alkasab & Michael Hood. It could also be a good candidate for an IRA content definition since it forms a framework for information/collaboration between apps supporting the interpretation process.

The content definitions would leverage the IDR Findings and Conclusions, but might also need organizing resources.

EHR Patient Summary

(This might be designated as a stretch goal)

An application might populate the FHIRcast hub with “relevant” content extracted from the EHR for this patient. Discuss whether these should be summary copies of EHR resources or newly constructed resources on the hub that do not persist.

Collaborative Report Composition

An assumption so far is that there is a single application responsible for the Report content and that application pulls / mediates content from the FHIRcast session into the report.

One could also imagine the Report itself existing in the FHIRcast hub in some form where multiple applications could read / write the content until it is finalized and published as the final report. However, while potentially powerful, multiple applications might introduce more variability / unexpected behaviors or other risks than implementations are willing to consider today.

Possible functions a coded “problem list” might facilitate include:

• supporting protocoling of the current exam (views, scan range, contrast, technique) to )facilitate effective follow-up of pertinent “problem list” items
• preparing a concise summary of the patients imaging history for the imaging clinician
• highlighting topics the imaging clinician has not commented on (completeness)
• identifying and/or automatically performing current measurements to mirror prior measurements
• plotting/presenting trends over time for certain details

Other simpler use cases also exist but are likely addressed by the tools for this one.

4. Standards and Systems

• IHE IRA Profile
• IHE IDR Profile (Phase II)
• FHIR (Observation, ImagingStudy, ImagingSelection, ServiceRequest, Procedure, etc)
• FHIRcast [1]
• SNOMED, LOINC, etc
• RadElement/CDE (Clinical Data Elements) Sets -
• Open Imaging Data Model (OIDM) - information model for data involved in the medical imaging reporting process

5. Technical Approach

Actors

• No new actors anticipated. Would use actors in IRA.

Transactions

• Probably no new transactions
• Might need to revisit existing Content Transactions
  • FHIRCast is considering having the Hub pair with a FHIR Resource Server then the Hub only hosts references. Temporary/working content instances are hosted on the FHIR Resource Server

Profile

Packaging Choices:

• Add “Finding Content” Named Option to IRA?
• Publish IRA.b?

New Work:

• New Use Case section for finding exchange (eg between finding tool and report creator)
• Concept sections as needed (Hub/Server Models, Intention/Workflow alignment between clients)
• More specific examples (AI Finding for review/incorporation, ...)

Decisions/Topics/Uncertainties

• Incorporate Content Definitions by referencing sections introduced by IDR?
• Select some specific Finding Sets for Profiling/Examples (eg Lung Nodule)?
• Review/discuss CDE schema revisions (underway at RSNA)

6. Support & Resources

Members of the RSNA CDE activity expected.

DICOM WG-20 experience in FHIRcast (Jonathan, Isaac)

It would be good to recruit some reporting vendors (as both creators and in the case of the Priors use case, as consumers)

7. Risks

• Getting engagement from 3rd party reporting tool vendors and report creator vendors

8. Tech Cmte Evaluation

Effort Evaluation (as a % of Tech Cmte Bandwidth):

• xx% for MUE
• yy% for MUE + optional

Editor:

Kevin O'Donnell

SME/Champions:

Dr. Tarik Alkasab, Dr. Michael Hood