Presentation of CAD/Annotations/Markups - Detailed Proposal: Difference between revisions

From IHE Wiki
Jump to navigation Jump to search
Mplanchart (talk | contribs)
New page: ==1. Proposed Workitem: == * Proposal Editor: Michael Planchart/Peter Maton * Domain: Radiology ==2. The Problem== Advanced image processing algorithms (e.g. Soft tissue or bone suppres...
 
Mplanchart (talk | contribs)
 
(96 intermediate revisions by 3 users not shown)
Line 1: Line 1:
==1. Proposed Workitem: ==
__NOTOC__
==1. Proposed Profile: Presentation of Chest X-Ray CAD/Annotations/Markups ==


* Proposal Editor: Michael Planchart/Peter Maton
* Proposal Editor: Michael Planchart / Peter Maton
* Profile Editor: Michael Planchart/Ellie Avraham (Mentor)
* Domain: Radiology
* Domain: Radiology


==2. The Problem==
===Summary===
Display of CAD/Annotations/Markups on images is unreliable, with potential for loss of information and disruption of workflow. 


Advanced image processing algorithms (e.g. Soft tissue or bone suppression, temporal subtraction) are being developed by various medical software companies.  These algorithms provide various outputs that enhance the source images obtained directly from the modalities.
A significant cause is that different products use different mechanisms when creating these graphics, and the PACS/display stations handle this inconsistency and variation poorly.  


As more post processing algorithms become available and more combination of outputs are possible the practicality of generating and storing all possible output images rapidly decreases.
DICOM has provided both general tools (GSPS, KIN, Overlays) and application-specific tools (Chest CAD SR, Colon CAD SR, etc.) for such purposes.


A more practical approach is to generate the required output on demand invoking only the required algorithms, or possibly using pre calculated intermediate results, and only creating the requested output combinations.
A Markup Profile could define which mechanisms should (and which should not) be used by Creators for different cases and types of markup and define which mechanisms and behaviors compliant displays must support.


==3. Key Use Cases==
Healthcare providers are showing continued interest in the use of CAD to improve the detection of cancer nodules and other abnormalities in Chest X-Rays.


*'''On-Demand Request of Advanced Processed Images:'''
==The Problem==


A radiologist reading a patient case would select additional computed information from a list of available processing options and parameter settings using GUI element definitions provided to the viewing workstation application by the computation server. This request would be processed via HTTP/HTTPS to the WADO sub-system of the Dynamically Computed Image Server. By means of a server side script the requested images would be fetched and/or processed according to the request and the resulting images and/or DICOM annotation/markup objects would be sent back to the PACS image viewing workstation.
CAD and clinical processing applications create processed images with annotations/markups. Different products are using different mechanisms for the markup, e.g.:


==4. Standards & Systems==
:*burned into the DICOM image,


*DICOM – Web Access to DICOM Persistent Objects (WADO)
:*encoded in the image overlay,
*DICOM – Hanging Protocols
*DICOM – Post-Processing Worklist
*HTTP and HTTPS


==5. Discussion==
:*encoded in separate presentation state graphics,


DICOM has defined a standard that could be leveraged for On-Demand services: Web Access to DICOM Persistent Objects (WADO).
:*encoded in a separate SR,


Since computation servers will provide different capabilities with various associated parameters a general mechanism is required for the server to specify the selection mechanisms including the types of GUI elements to be used by the workstation client.
:*rendered onto the image in a separate JPEG
 
With so many mechanisms, display systems support some of them poorly or not at all, so workflow is disrupted and key information may be inaccessible.
 
The variability also makes it very difficult to create robust hanging protocols.
 
 
==Key Use Case==
 
'''DR/CR Chest X-Ray Lung CAD'''
 
* DR/CR modality
** obtains AP/PA (frontal chest) X-Ray images
** stores images to Image Archive and CAD device
* CAD device
** processes the images to detect lung nodules or abnormalities
** identifies and marks the coordinates of such regions of interest (ROI).
** encodes the results as DICOM Chest CAD SR and stores to Image Archive.
* Image Display
** retrieves images and SR from Image Archive
** presents the images initially without CAD markup
** allows the overlaid markers to be toggled on-off (independant of other overlays)
 
==Standards and Systems==
 
* DICOM – Chest CAD SR SOP Class
* Existing IHE Actors and Transactions
 
==Technical Approach==
Create a Chest CAD Profile defining how Chest CAD SR should be created and displayed.
 
===Existing actors===
* Acquisition Modalities (e.g. CR,DR,DX)
** might need to require some specific image tags
* Evidence Creator (e.g. Chest CAD Device)
** to create Chest CAD SR
** may create an additional image that is derived from the source image and burning in the markups?
* Image Display (e.g. PACS Image Viewing Workstation)
* Image Archive (e.g. PACS)
 
===New actors===
* None proposed.
 
===Existing transactions===
 
* RAD-43: Evidence Documents Stored (add an option to require CAD SR?)
* RAD-44: Query Evidence Documents
* RAD-45: Retrieve Evidence Documents (add display behaviors?)
* RAD-10: Storage Commitment
* RAD-26: Query Reports
 
===New transactions (standards used)===
* None proposed.
 
===Impact on existing integration profiles===
* None anticipated.
 
===New integration profiles needed===
* Chest CAD Profile
 
or
 
* Consistent Presentation of Markup Profile
** A more generic approach might be preferable, but would need to deal with how to require support/display behaviors on recievers when DICOM defines new CAD objects.
 
===Breakdown of tasks that need to be accomplished===
 
* Validate the described use case as the "one-way" approach to integration of Chest CAD results with Image Displays,
* Determine from the collection of existing IHE transactions which could be leveraged,
* Create corresponding profile
 
==Support & Resources==
 
* CAD Providers:
** Riverain Medical
 
* Image Display Providers:
** ASPYRA
 
*During the discussions of promoting the brief proposals to detailed proposals most attendees seemed to be interested in the idea, among them:
** Agfa
** GE
** McKesson
** Toshiba
 
==Risks==
The authors of this detailed proposal have not been able to identify any risks.
 
Albeit there are many other approaches the industry wide consensus for the interoperability between CAD devices and Image Displays should be the DICOM SR.
 
==Open Issues==
 
*'''Should we address the Use Case where Results are not Stored in Image Archive (PACS):'''
 
Many radiologists do not want to store the CAD results in the PACS server citing various reasons (e.g. legal, network capacity).  CAD devices are not designed to store persistent objects and rarely have the Query/Retrieve SCP service capability, and if they did the image displays are not designed to poll other sources aside from the PACS server for images related to a patient and/or study under review.
 
IHE would have to decide whether or not a different profile would address this specific use case.
 
*'''Other Use Cases for CAD variations consideration:'''
 
Another consideration would be for the definition of a more generalized profile that would include more alternative CAD variations.  DICOM has addressed each SR separately albeit there are similarities between them since they are derived from the Mammo CAD SR SOP Class.
 
* '''Is this just a specialization of the Evidence Documents Profile?'''
 
==Tech Cmte Evaluation==
 
''<The technical committee will use this area to record details of the effort estimation, etc.>''
 
Effort Evaluation (as a % of Tech Cmte Bandwidth):
:* 35% for ...
 
Responses to Issues:
:''See italics in Risk and Open Issue sections''
 
Candidate Editor:
: TBA

Latest revision as of 15:49, 21 October 2009

1. Proposed Profile: Presentation of Chest X-Ray CAD/Annotations/Markups

  • Proposal Editor: Michael Planchart / Peter Maton
  • Profile Editor: Michael Planchart/Ellie Avraham (Mentor)
  • Domain: Radiology

Summary

Display of CAD/Annotations/Markups on images is unreliable, with potential for loss of information and disruption of workflow.

A significant cause is that different products use different mechanisms when creating these graphics, and the PACS/display stations handle this inconsistency and variation poorly.

DICOM has provided both general tools (GSPS, KIN, Overlays) and application-specific tools (Chest CAD SR, Colon CAD SR, etc.) for such purposes.

A Markup Profile could define which mechanisms should (and which should not) be used by Creators for different cases and types of markup and define which mechanisms and behaviors compliant displays must support.

Healthcare providers are showing continued interest in the use of CAD to improve the detection of cancer nodules and other abnormalities in Chest X-Rays.

The Problem

CAD and clinical processing applications create processed images with annotations/markups. Different products are using different mechanisms for the markup, e.g.:

  • burned into the DICOM image,
  • encoded in the image overlay,
  • encoded in separate presentation state graphics,
  • encoded in a separate SR,
  • rendered onto the image in a separate JPEG

With so many mechanisms, display systems support some of them poorly or not at all, so workflow is disrupted and key information may be inaccessible.

The variability also makes it very difficult to create robust hanging protocols.


Key Use Case

DR/CR Chest X-Ray Lung CAD

  • DR/CR modality
    • obtains AP/PA (frontal chest) X-Ray images
    • stores images to Image Archive and CAD device
  • CAD device
    • processes the images to detect lung nodules or abnormalities
    • identifies and marks the coordinates of such regions of interest (ROI).
    • encodes the results as DICOM Chest CAD SR and stores to Image Archive.
  • Image Display
    • retrieves images and SR from Image Archive
    • presents the images initially without CAD markup
    • allows the overlaid markers to be toggled on-off (independant of other overlays)

Standards and Systems

  • DICOM – Chest CAD SR SOP Class
  • Existing IHE Actors and Transactions

Technical Approach

Create a Chest CAD Profile defining how Chest CAD SR should be created and displayed.

Existing actors

  • Acquisition Modalities (e.g. CR,DR,DX)
    • might need to require some specific image tags
  • Evidence Creator (e.g. Chest CAD Device)
    • to create Chest CAD SR
    • may create an additional image that is derived from the source image and burning in the markups?
  • Image Display (e.g. PACS Image Viewing Workstation)
  • Image Archive (e.g. PACS)

New actors

  • None proposed.

Existing transactions

  • RAD-43: Evidence Documents Stored (add an option to require CAD SR?)
  • RAD-44: Query Evidence Documents
  • RAD-45: Retrieve Evidence Documents (add display behaviors?)
  • RAD-10: Storage Commitment
  • RAD-26: Query Reports

New transactions (standards used)

  • None proposed.

Impact on existing integration profiles

  • None anticipated.

New integration profiles needed

  • Chest CAD Profile

or

  • Consistent Presentation of Markup Profile
    • A more generic approach might be preferable, but would need to deal with how to require support/display behaviors on recievers when DICOM defines new CAD objects.

Breakdown of tasks that need to be accomplished

  • Validate the described use case as the "one-way" approach to integration of Chest CAD results with Image Displays,
  • Determine from the collection of existing IHE transactions which could be leveraged,
  • Create corresponding profile

Support & Resources

  • CAD Providers:
    • Riverain Medical
  • Image Display Providers:
    • ASPYRA
  • During the discussions of promoting the brief proposals to detailed proposals most attendees seemed to be interested in the idea, among them:
    • Agfa
    • GE
    • McKesson
    • Toshiba

Risks

The authors of this detailed proposal have not been able to identify any risks.

Albeit there are many other approaches the industry wide consensus for the interoperability between CAD devices and Image Displays should be the DICOM SR.

Open Issues

  • Should we address the Use Case where Results are not Stored in Image Archive (PACS):

Many radiologists do not want to store the CAD results in the PACS server citing various reasons (e.g. legal, network capacity). CAD devices are not designed to store persistent objects and rarely have the Query/Retrieve SCP service capability, and if they did the image displays are not designed to poll other sources aside from the PACS server for images related to a patient and/or study under review.

IHE would have to decide whether or not a different profile would address this specific use case.

  • Other Use Cases for CAD variations consideration:

Another consideration would be for the definition of a more generalized profile that would include more alternative CAD variations. DICOM has addressed each SR separately albeit there are similarities between them since they are derived from the Mammo CAD SR SOP Class.

  • Is this just a specialization of the Evidence Documents Profile?

Tech Cmte Evaluation

<The technical committee will use this area to record details of the effort estimation, etc.>

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

  • 35% for ...

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

TBA