Difference between revisions of "AIR Datasets and Root Results - Proposal"

From IHE Wiki
Jump to navigation Jump to search
Line 21: Line 21:
  
 
So:
 
So:
* The Image Display needs a simple way to access & leverage the hierarchy/structure
+
* The '''Image Display needs a simple way to access & leverage the hierarchy/structure'''
* The Creator likely knows that structure but needs a way to communicate it
+
* The '''Creator likely knows that structure but needs a way to communicate it'''
 
:* Advanced “data organizing” software could also create summaries and structure for results from multiple algorithms
 
:* Advanced “data organizing” software could also create summaries and structure for results from multiple algorithms
  

Revision as of 20:32, 11 August 2021

1. Proposed Workitem: AIR Datasets and Root Results

  • Proposal Editor: Kevin O’Donnell
  • Editor: Kevin O’Donnell
  • Domain: Radiology

2. The Problem

The AIR Profile specifies predictable encoding of image analysis results for reliable receipt, parsing and display by consumers (Image Displays).

First, while the profile includes some text examples at the end of Annex A, it can be challenging for implementers (per comments from Lynn Felhofer and Herman Oosterwijk) to understand how the specification applies in their case and to correctly create conformant objects without a fuller set of examples as digital datasets.

Second, broad adoption of image analysis AI poses the next problem for Image Displays, which is how to navigate large result datasets:

  • Expanded use of AI algorithms may produce very large collections of results for a given study
  • Image Displays need to present that information to radiologists/clinicians
  • Large result sets have logical structure/hierarchy that would help clinicians navigate and review the data
  • Where to start; “Root”/“Summary” findings
  • “Summary” findings are supported/derived from sub-sets of “sub-findings” (“drill-down”, “next layer”)
  • The open-ended nature of results being provided for display mean image displays will be hard pressed to organize it themselves
  • Without such organization, navigating large result sets will be labor intensive for radiologists, leading them to either waste time or ignore information.

So:

  • The Image Display needs a simple way to access & leverage the hierarchy/structure
  • The Creator likely knows that structure but needs a way to communicate it
  • Advanced “data organizing” software could also create summaries and structure for results from multiple algorithms

3. Key Use Case

CT Lung Screening Example:

  • An AI analysis package detects 8 nodules
  • For each detected nodule,
  • a segmentation algorithm generates a segmentation
  • a third algorithm estimates the size, the solidity, the margin, and the LungRADS assessment
  • it also generates an overall LungRADS™ score.
  • another algorithm (outside the LungRADS package) generates a result that pneumonia is present
  • and stores an associated saliency map

These roughly 40+ results are stored to the study ( consisting of location, size, solidity, margin, and LungRADS for each of 8 nodules, an overall LungRADS score, the pneumonia finding, and the pneumonia saliency map reference. The cardiac calcification and other screening were not run on this study.

The Lung Screening package stores a Root Result object with a root finding of (LungRADS = Category 3), with links to the next layer findings (the 8 nodules and their LungRADS values) which in turn are linked to locations, segmentations, and assessments of the size, solidity, and margin of each detected nodule.

The Pneumonia application stores a Root Result object with a summary finding of (“pneumonia present”), and a link/reference to the saliency map instance.

The Image Display first filters for Root Results instances and presents the two root findings to the radiologist. (that have a document title of (Newcode0,99IHE,”Analysis Root Result”) allowing consumers like Image Displays to identify them in a study. Root result instances then contain subordinate results (e.g., measurements and locations) and/or reference other instances that contain subordinate results.

In the case of the two examples above, an Image Display might initially present the two root results and (Pneumonia present) followed by “drill down <Feel free to add a second use case scenario demonstrating how it “should” work. Try to indicate the people/systems, the tasks they are doing, the information they need, and hopefully where the information should come from.> How to filter, how to start from “top level” details, how to step through, how to drill down,

It seems likely that displays might leverage component hierarchy by first presenting a summary “root” result or key value to an imaging clinician and offer the ability to explore additional layers of detail as needed, for example to next review the segmentation that underlies a volume measurement, or initially display a LungRADS score, and allow the imaging clinician to choose to expose the nodule evaluations it was based on. This exploration might be done to gain greater confidence in the summary result, or to comprehend more details and nuances of the finding(s).

Work will continue to explore the use of some kind of Key Object Selection type of instance that summarizes/organizes/serves as an entry point for a set of results in the study. These objects should be readily filterable/findable by a simple display that can use the top level to communicate the summary finding to a user and then let the user choose to display additional lower levels within the “tree” that would likely contain supporting details.

The expectation is that there could be multiple “root results” in a study. It would not make sense to mandate that a single result catalog object index all the results in the study, since that would require continually revising the catalog object each time one of many algorithms stored new results to the study. It would be challenging, not to mention handling competing updates by when multiple algorithms happen to complete at the same time.

with information to help them organize and prioritize the result “entries” listed/communicated to the operator at one time, this profile introduces Root Results that communicate a basic hierarchy for a set of related results.

The Root Results described in Section X.4.1.2a allow a display to use a mechanical filter (on Document Title) to get a first-order set of summary findings. The references in each of those Root Results provides a logical next layer of detail. Ideally, some displays will develop much more sophisticated analysis and logic, or more advanced configurations, and more advanced navigation and display, while the Root Results provide a first simple step up from the flat list of findings.

Might be interesting for the result to include a confidence and potential significance as well to assist in filtering/layering/progressive disclosure

4. Standards and Systems

DICOM SR analogous to Key Object Selection seems like a valid approach.

5. Discussion

This problem was identified during development of the AIR Profile and a “Root result” object was proposed.

  • Some public comments supported the need and value
  • Others comments challenged that the proposed mechanism had not been fully thought through or the potential complexities mapped out

Some form of DICOM SR object seemed like a valid approach, but TODO

One piece of proposed work will be to create example datasets.

A second piece of proposed work will be to assess how to make dataset organization tractable for relatively simple Image Displays. An organizing object will be evaluated. If it seems workable, creating and using said object could be added as a Named Option in the AIR Profile for the Evidence Creator and Image Display actors.

<This is the brief proposal. Try to keep it to 1 or at most 2 pages>