Presentation of Processed Images - Brief Proposal: Difference between revisions

From IHE Wiki
Jump to navigation Jump to search
← Older editNewer edit →
Lindop (talk | contribs)
Bureaucrats, editor
854 edits
Kevino (talk | contribs)
editor
4,951 edits
No edit summary
Line 1: Line 1:
==1. Proposed Workitem: ''Presentation of Processed Images''==
{{TOCright}}
==1. Proposed Workitem: Presentation of Processed Images Profile==


* Proposal Editor: Michael Planchart
* Proposal Editor: Michael Planchart (GE?)
* Editor: ''<Name of candidate Lead Editor for the Profile, if known>''  
* Editor: ''<Name of candidate Lead Editor for the Profile, if known>''  
* Date:    N/A (Wiki keeps history)
* Domain: Radiology and Cardiology
* Version: N/A (Wiki keeps history)
* Domain: Radiology


==2. The Problem==
==2. The Problem==


''<Summarize the integration problem. What doesn’t work, or what needs to work.>''
Systems produce a variety of Processed images:
The challenge is having the 2-dimensional processed images (e.g. Computer Aided Detection (CAD) results, Soft tissue or bone subtraction images, Residual or Temporal Subtraction images, etc.), to be consumed and displayed by the various PACS viewing workstations in a way that compliments the viewing experience and workflow of the radiologist.
:* Computer Aided Detection (CAD) results
:* Soft tissue or bone subtraction images
:* Residual or Temporal Subtraction images


It is very important that the processed images should not be a cause of disruption of their workflow nor be obtrusive to their viewing experience.
These images (especially CAD) may have Region of Interest (ROI) coordinates provided as series 6000 overlay tags, GSPS annotations, or SR data.


In the case of CAD results processed images may be provided with series 6000 overlay tags populated, GSPS, or optionally produce a DICOM Structured Report (SR) that contains the coordinates of the Regions of Interest(ROI) for the CAD results.
However,
:* Some hospitals do not want to store them in PACS, claiming liability issues or limited resources (e.g. memory, bandwidth, etc.),
:* Some PACS viewers can't display the Regions of Interest (ROI) either by toggling on/off series 6000 overlay tags or by using the coordinates contained in the SR
:* Some PACS viewers can't do "hanging protocols" unobtrusively in the workflow


==3. Key Use Case==
==3. Key Use Case==
Line 22: Line 26:
''<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.>''
''<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.>''


Today, there are a myriad of obstacles each representing an individual use case and the most common are:
Images should be consumed and displayed by PACS viewing workstations in a way that compliments the viewing experience and workflow of the radiologist.
 
 
-        Some hospitals do not want to store the resulting images in
their PACS server claiming potential liability issues or taking up resources that are already limited (e.g. memory, bandwidth, etc.),
 
-        Some PACS viewers do not have the feature of displaying the
Regions of Interest (ROI) by toggling on/off series 6000 overlay tags or by using the coordinates contained in the SR,
 
-        Some PACS viewers do not have the feature of implementing a
"hanging protocol" that is non-obtrusive to their workflow,
 
 
 




Line 54: Line 43:
:''<What are some of the risks or open issues to be addressed?>''
:''<What are some of the risks or open issues to be addressed?>''


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

Revision as of 16:05, 26 August 2009

1. Proposed Workitem: Presentation of Processed Images Profile

  • Proposal Editor: Michael Planchart (GE?)
  • Editor: <Name of candidate Lead Editor for the Profile, if known>
  • Domain: Radiology and Cardiology

2. The Problem

Systems produce a variety of Processed images:

  • Computer Aided Detection (CAD) results
  • Soft tissue or bone subtraction images
  • Residual or Temporal Subtraction images

These images (especially CAD) may have Region of Interest (ROI) coordinates provided as series 6000 overlay tags, GSPS annotations, or SR data.

However,

  • Some hospitals do not want to store them in PACS, claiming liability issues or limited resources (e.g. memory, bandwidth, etc.),
  • Some PACS viewers can't display the Regions of Interest (ROI) either by toggling on/off series 6000 overlay tags or by using the coordinates contained in the SR
  • Some PACS viewers can't do "hanging protocols" unobtrusively in the workflow

3. Key Use Case

<Describe a short use case scenario from the user perspective. The use case should demonstrate the integration/workflow problem.>

<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.>

Images should be consumed and displayed by PACS viewing workstations in a way that compliments the viewing experience and workflow of the radiologist.


4. Standards & Systems

<List existing systems that are/could be involved in the problem/solution.>

<If known, list standards which might be relevant to the solution>


5. Discussion

<Include additional discussion or consider a few details which might be useful for the detailed proposal>

<Why IHE would be a good venue to solve the problem and what you think IHE should do to solve it.>
<What might the IHE technical approach be? Existing Actors? New Transactions? Additional Profiles?>
<What are some of the risks or open issues to be addressed?>

IHE should ...

Retrieved from "http://wiki.ihe.net/index.php?title=Presentation_of_Processed_Images_-_Brief_Proposal&oldid=36019"