Difference between revisions of "Basic Image Review - Detailed Proposal"

From IHE Wiki
Jump to navigation Jump to search
Line 10: Line 10:
 
Functionality gaps, poor interfaces and excessive variability between basic image viewers is frustrating clinicians and obstructing patient care.
 
Functionality gaps, poor interfaces and excessive variability between basic image viewers is frustrating clinicians and obstructing patient care.
  
''<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.">''
+
A Basic Image Review profile could require compliant image displays to support certain display behaviors and control capabilities.
  
''<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.">''
+
AMA/ACR/ACC/AANS/AAOS have formally expressed their frustration and patient safety concerns on this issue to the imaging vendors represented by NEMA/MITA and went to the extent of developing a draft viewer specification.
  
''<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.">''
+
The above physician groups agreed to adopt IHE PDI as the preferred solution for image media compatibility, and are ready to participate in the IHE process as an alternative to pushing their own specification.  The work proposed here is similar to that done for the Mammography Image profile.
 
 
''<Summarize in a line or two why IHE would be a good venue to solve the problemE.g. "The main challenges are dealing with the chicken-and-egg problem and avoiding inconsistent implementations.">''
 
  
  
Line 42: Line 40:
  
 
''<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.>''
 +
  
 
==4. Standards & Systems==
 
==4. Standards & Systems==
Line 54: Line 53:
  
  
==5. Discussion==
+
==5. Technical Approach==
 +
 
 +
Broadly, a new Basic Image Review Profile would require Image Display actors to support certain display behaviors similar to what was done in the Mammography Image Profile.
 +
 
 +
 
 +
 
 +
* Potentially the solution is a Basic Image Review Profile which places requirements on Media Creators and Image Display actors.
 +
 
 +
 
 +
 
 +
===Existing actors===
 +
* Image Display (definitely)
 +
* Media Creator (possibly)
 +
 
 +
===New actors===
 +
None
 +
 
 +
 
 +
===Existing transactions===
 +
One approach would be to add behaviors to the Image Stored transaction which would be required for Image Display actors claiming to support the Basic Image Review profile. 
 +
 
 +
===New transactions (standards used)===
 +
An possibly better approach would be to introduce a new Display Image transaction (arguably between the display and the user) with the required behaviors could be created.
 +
 
 +
The advantage would be that it could be used regardless of whether the image was pushed, pulled, acquired, imported from a CD or loaded from a local drive.
 +
 
 +
 
 +
===Impact on existing integration profiles===
 +
None required.  Display oriented profiles might consider adopting the extra Image Stored behaviors as optional behaviors, or the Display Image transaction as an optional transaction.
 +
 
 +
===New integration profiles needed===
 +
One new profile proposed.  See Technical Approach summary above.
 +
 
  
 +
===Breakdown of tasks that need to be accomplished===
 +
''<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==
 
* The AMA, ACR, ACC, AANS, DRG, and RANZCR have all specifically identified this as a significant issue for them
 
* The AMA, ACR, ACC, AANS, DRG, and RANZCR have all specifically identified this as a significant issue for them
 
** Several members of those organizations have expressed interest or been identified to participate in the meetings where the profile is developed
 
** Several members of those organizations have expressed interest or been identified to participate in the meetings where the profile is developed
Line 63: Line 99:
 
*** Dr. Gaby Weissman
 
*** Dr. Gaby Weissman
  
** AMA, ACR, ACC and AANS are preparing to declare IHE PDI as being the Standard of Care and look forward to further productive work with IHE
+
** AMA, ACR, ACC and AANS are preparing to declare IHE PDI as being the Standard of Care for distributing images on media and look forward to further productive work with IHE
  
* In some ways the work would be similar to what was done in Mammography Image to specify basic display behaviors and control
+
===Demonstrations===
 +
Two venues have already been proposed for promotion/demonstration:
 +
:* AANS 2009 -  April 30-May 2 San Diego - 8000 physicians
 +
:* AMA 2009 - late June - 1200 delegates - could sponsor a demo and provide feedback
 +
Most likely these events would involve promoting the draft specification and perhaps doing a product survey/pre-test
 +
of existing products (as has been done for NucMed, Mammo and some others) to give vendors a heads up and to get a sense
 +
of how close we are.  A demo of Connectathon tested products could be done the following year.
  
* Potentially the solution is a Basic Image Review Profile which places requirements on Media Creators and Image Display actors.
 
  
===Issues:===
+
==7. Risks==
 +
''<List technical or political risks that will need to be considered to successfully field the profile.>''
 +
 
 +
==8. Open Issues==
 +
 
 +
* Put the requirements in Image Stored, or in a new Display Image, or somewhere else?
  
Issue: Specifying what to achieve VERSUS how to do it
+
* Issue: Specifying what to achieve VERSUS how to do it
 
* Some would like to specify icons and GUI elements
 
* Some would like to specify icons and GUI elements
 
** Problem: May unnecessarily disallow valid implementations, which might be better
 
** Problem: May unnecessarily disallow valid implementations, which might be better
Line 92: Line 138:
 
* Basic Image Review is intended to be complementary to PDI
 
* Basic Image Review is intended to be complementary to PDI
  
===Resources:===
 
See above.
 
 
 
===Demonstrations===
 
Two venues proposed for promotion/demonstration:
 
:* AANS 2009 -  April 30-May 2 San Diego - 8000 physicians
 
:* AMA 2009 - late June - 1200 delegates - could sponsor a demo and provide feedback
 
It may be that these events involve promoting the draft specification and doing a survey/pre-test
 
of existing products to get a sense of how close we are.
 
 
* Paste this text into a copy of your Brief Proposal
 
* Move the Summary section to the end of Section 1
 
* Expand details in the Use Case Section
 
* Distribute material in the Discussion Section into the other bottom sections.
 
----
 
 
 
 
 
==5. Technical Approach==
 
''<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.>''
 
 
''<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.>''
 
 
===Existing actors===
 
''<Indicate what existing actors could be used or might be affected by the profile.>''
 
 
===New actors===
 
''<List possible new actors>''
 
 
===Existing transactions===
 
''<Indicate how existing transactions might be used or might need to be extended.>''
 
 
===New transactions (standards used)===
 
''<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===
 
''<Indicate how existing profiles might need to be modified.>''
 
 
===New integration profiles needed===
 
''<Indicate what new profile(s) might need to be created.>''
 
 
===Breakdown of tasks that need to be accomplished===
 
''<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==
 
''<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>''
 
 
==7. Risks==
 
''<List technical or political risks that will need to be considered to successfully field the profile.>''
 
 
==8. Open Issues==
 
''<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.>''
 
  
  

Revision as of 22:44, 30 September 2008


1. Proposed Workitem: Basic Image Review Profile

  • Proposal Editor: Kevin O'Donnell
  • Editor: David Clunie
  • Domain: Radiology (incl. all image viewing subspecialties)

Summary

Functionality gaps, poor interfaces and excessive variability between basic image viewers is frustrating clinicians and obstructing patient care.

A Basic Image Review profile could require compliant image displays to support certain display behaviors and control capabilities.

AMA/ACR/ACC/AANS/AAOS have formally expressed their frustration and patient safety concerns on this issue to the imaging vendors represented by NEMA/MITA and went to the extent of developing a draft viewer specification.

The above physician groups agreed to adopt IHE PDI as the preferred solution for image media compatibility, and are ready to participate in the IHE process as an alternative to pushing their own specification. The work proposed here is similar to that done for the Mammography Image profile.


2. The Problem

It is common practice for imaging facilities to distribute images on CDs and for receiving physicians to review those images with the viewer often bundled onto the CD.

Physicians have increasingly been expressing frustration that all too often:

  • the viewer does not successfully run
  • the viewer does not successfully load the images
  • functions critical to review are missing from the viewer
  • the viewer on the CD has Yet Another GUI in which the operation of basic functions is non-obvious

The impact is delayed care, inaccessible information, and poor use of valuable clinician time.

The radiologist may seldom, if ever, use the viewer on the CDs created by their institution and may be unaware of the pain suffered by the clinicians. So the ultimate user of the CDs has problems, while the purchaser the CD burner is satisfied, meaning the critical feedback is not effectively communicated to the vendor of the system.

3. Key Use Case

Referring Clinician Review

Here is a link to the AMA requirements document

Patient Viewing

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


4. Standards & Systems

Relevant Systems:

  • Media Creators
  • Basic Image Review Applications

Relevant Standards:

  • DICOM Media
  • IHE PDI


5. Technical Approach

Broadly, a new Basic Image Review Profile would require Image Display actors to support certain display behaviors similar to what was done in the Mammography Image Profile.


  • Potentially the solution is a Basic Image Review Profile which places requirements on Media Creators and Image Display actors.


Existing actors

  • Image Display (definitely)
  • Media Creator (possibly)

New actors

None


Existing transactions

One approach would be to add behaviors to the Image Stored transaction which would be required for Image Display actors claiming to support the Basic Image Review profile.

New transactions (standards used)

An possibly better approach would be to introduce a new Display Image transaction (arguably between the display and the user) with the required behaviors could be created.

The advantage would be that it could be used regardless of whether the image was pushed, pulled, acquired, imported from a CD or loaded from a local drive.


Impact on existing integration profiles

None required. Display oriented profiles might consider adopting the extra Image Stored behaviors as optional behaviors, or the Display Image transaction as an optional transaction.

New integration profiles needed

One new profile proposed. See Technical Approach summary above.


Breakdown of tasks that need to be accomplished

<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

  • The AMA, ACR, ACC, AANS, DRG, and RANZCR have all specifically identified this as a significant issue for them
    • Several members of those organizations have expressed interest or been identified to participate in the meetings where the profile is developed
      • Dr. Katarzyna Macura
      • Dr. Peter Carmel
      • Dr. Charles Rosen
      • Dr. Gaby Weissman
    • AMA, ACR, ACC and AANS are preparing to declare IHE PDI as being the Standard of Care for distributing images on media and look forward to further productive work with IHE

Demonstrations

Two venues have already been proposed for promotion/demonstration:

  • AANS 2009 - April 30-May 2 San Diego - 8000 physicians
  • AMA 2009 - late June - 1200 delegates - could sponsor a demo and provide feedback

Most likely these events would involve promoting the draft specification and perhaps doing a product survey/pre-test of existing products (as has been done for NucMed, Mammo and some others) to give vendors a heads up and to get a sense of how close we are. A demo of Connectathon tested products could be done the following year.


7. Risks

<List technical or political risks that will need to be considered to successfully field the profile.>

8. Open Issues

  • Put the requirements in Image Stored, or in a new Display Image, or somewhere else?
  • Issue: Specifying what to achieve VERSUS how to do it
  • Some would like to specify icons and GUI elements
    • Problem: May unnecessarily disallow valid implementations, which might be better
  • Others would like to specify broad behaviors and things like "must be readily apparent"
    • Problem: May requires human evaluation which may be subjective
  • There is some interest in ACR to be involved in the evaluation of systems implementing the profile
  • AMA prepared the document linked in the use cases as a starting point


Issue: Should we address office review workflow

  • E.g. provide recommendations to set up your own viewer and have office staff pre-load images from patients
  • Offices which do not think about this find CDs painful because of the loading time of the application and data


Issue: Report Review

  • the reviewer is often also interested in the accompanying Radiology Report (if any)
  • the Profile work should include reviewing what is covered in IHE Displayable Reports and IHE Portable Data for Imaging and decide if some guidance and/or additional specification would be appropriate
  • DRPT documents PDF-based reports
  • PDI allows for reports on the CD
  • Basic Image Review is intended to be complementary to PDI


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

David Clunie