IRA Content - Proposal

1. Proposed Workitem: IRA Content

• Proposal Contributors: Kevin O’Donnell, Kinson? Tarik? Michael?
• Workitem Editor: Kevin O’Donnell
• Domain: Radiology

2. The Problem

Integrating Reporting Applications (IRA) profiled FHIRcast and patient/study context switching for reporting and associated processing. Mechanisms for sharing content between subscribed applications were identified but the content itself was largely undefined.

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)
• RadElement/CDE (Clinical Data Elements) Sets
• SNOMED, LOINC, etc

5. Technical Approach

Actors

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

Transactions

• Probably no new transactions

Profile

Packaging Choices:

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

New Work:

• New Use Case section for finding exchange (eg between finding tool and report creator)
• Concept sections as needed
• More specific examples

Decisions/Topics/Uncertainties

• Reference Content Definition sections introduced by IDR?
• Profile some specific Finding Sets (eg Lung Nodule)?
• Review/discuss CDE schema revisions

6. Support & Resources

Members of the RSNA CDE activity expected.

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

8. Tech Cmte Evaluation

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

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

Editor:

Kevin O'Donnell

SME/Champion:

TBA <typically with a technical editor, the Subject Matter Expert will bring clinical expertise; in the (unusual) case of a clinical editor, the SME will bring technical expertise>