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

From IHE Wiki
Jump to navigation Jump to search
← Older edit
Mplanchart (talk | contribs)
150 edits
No edit summary
Mplanchart (talk | contribs)
150 edits
 
(93 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.
 
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.:
CAD and clinical processing applications create processed images with annotations/markups. Different products are using different mechanisms for the markup, e.g.:
Line 19: Line 32:


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.  
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.  
The variability also makes it very difficult to create robust hanging protocols.  


Of all the methods available the DICOM Structured Report (SR) is the preferred one and by industry-wide consensus, to contain the encoded markups.


==3. Key Use Cases==
==Key Use Case==
 
'''DR/CR Chest X-Ray Lung CAD'''


*'''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)


Chest X-Ray Lung CAD devices process the digital images of AP/PA projections (frontal chest) obtained from the DR/CR modalities in order to detect nodules or abnormalities and to identify and mark the coordinates of the regions of interest (ROI).
==Standards and Systems==


The CAD processed output shall be delivered as a DICOM Chest CAD SR SOP Class to the PACS server.
* DICOM – Chest CAD SR SOP Class
* Existing IHE Actors and Transactions


The PACS image viewing workstation shall provide the means of toggling on off the markers atop the source image.  The markers should be off by default on the PACS viewing workstation.  The SR should be independently toggled from other overlays.
==Technical Approach==
Create a Chest CAD Profile defining how Chest CAD SR should be created and displayed.


==4. Standards & Systems==
===Existing actors===
*DICOM – Chest CAD SR SOP Class
* 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)


===Summary===
===New actors===
''<Summarize in a few lines the existing problem . E.g. "It is difficult to monitor radiation dose for individual patients and almost impossible to assemble and compare such statistics for a site or a population.">''
* 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.


''<Demonstrate in a line or two that the key integration features are available in existing standards. E.g. "DICOM has an SR format for radiation dose events and a protocol for exchanging them.">''
===New integration profiles needed===
* Chest CAD Profile


''<Summarize in a few lines how the problem could be solved.  E.g. "A Radiation Dose profile could require compliant radiating devices to produce such reports and could define transactions to actors that collect, analyze and present such information.">''
or


''<Summarize in a line or two market interest & available resources.  E.g. "Euratom and ACR have published guidelines requiring/encouraging dose tracking.  Individuals from SFR are willing to participate in Profile development.">''
* 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.


''<Summarize in a line or two why IHE would be a good venue to solve the problem.  E.g. "The main challenges are dealing with the chicken-and-egg problem and avoiding inconsistent implementations.">''
===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


==5. Technical Approach==
==Support & Resources==
''<This section can be very short but include as much detail as you like.  The Technical Committee will flesh it out when doing the effort estimation.>''


''<Outline how the standards could be used/refined to solve the problems in the Use Cases.  The Technical Committee will be responsible for the full design and may choose to take a different approach, but a sample design is a good indication of feasibility.>''
* CAD Providers:
** Riverain Medical


''<If a phased approach would make sense indicate some logical phases.  This may be because standards are evolving, because the problem is too big to solve at once, or because there are unknowns that won’t be resolved soon.>''
* Image Display Providers:
** ASPYRA


===Existing actors===
*During the discussions of promoting the brief proposals to detailed proposals most attendees seemed to be interested in the idea, among them:
''<Indicate what existing actors could be used or might be affected by the profile.>''
** Agfa
** GE
** McKesson
** Toshiba


===New actors===
==Risks==
''<List possible new actors>''
The authors of this detailed proposal have not been able to identify any risks.


===Existing transactions===
Albeit there are many other approaches the industry wide consensus for the interoperability between CAD devices and Image Displays should be the DICOM SR.
''<Indicate how existing transactions might be used or might need to be extended.>''


===New transactions (standards used)===
==Open Issues==
''<Describe possible new transactions (indicating what standards would likely be used for each.  Transaction diagrams are very helpful here.  Feel free to go into as much detail as seems useful.>''


===Impact on existing integration profiles===
*'''Should we address the Use Case where Results are not Stored in Image Archive (PACS):'''
''<Indicate how existing profiles might need to be modified.>''


===New integration profiles needed===
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.
''<Indicate what new profile(s) might need to be created.>''


===Breakdown of tasks that need to be accomplished===
IHE would have to decide whether or not a different profile would address this specific use case.
''<A list of tasks would be helpful for the technical committee who will have to estimate the effort required to design, review and implement the profile.>''


==6. Support & Resources==
*'''Other Use Cases for CAD variations consideration:'''
''<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>''  


==7. Risks==
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.
''<List technical or political risks that will need to be considered to successfully field the profile.>''


==8. Open Issues==
* '''Is this just a specialization of the Evidence Documents Profile?'''
''<Point out any key issues or design problems.  This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>''


==9. Tech Cmte Evaluation==
==Tech Cmte Evaluation==


''<The technical committee will use this area to record details of the effort estimation, etc.>''
''<The technical committee will use this area to record details of the effort estimation, etc.>''
Line 96: Line 144:


Candidate Editor:
Candidate Editor:
: TBA  
: TBA
 
 
''<Delete this Category Templates line since your specific Profile Proposal page is no longer a template.>'' [[Category:Templates]]
 
==10. Discussion==
 
IHE has proven to succesfully develop profiles that harmonize the DICOM and HL7 standards to solve many integration problems where vendors were using disparate approaches.
 
A profile based on this proposal would allow vendors to implement the same functionality accross the board.
 
The profile would be tested during Connectathons to validate DICOM compliance.

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
Retrieved from "http://wiki.ihe.net/index.php?title=Presentation_of_CAD/Annotations/Markups_-_Detailed_Proposal&oldid=37766"