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

From IHE Wiki
Jump to navigation Jump to search
m
Line 8: Line 8:
  
 
===Summary===
 
===Summary===
Functionality gaps, poor interfances and excessive variability between basic image viewers is 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.">''
 
''<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.">''

Revision as of 19:28, 29 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.

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

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

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

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


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 CD has Yet Another Viewer in which the operation of basic functions is non-obvious

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

Some argue that while the first customer in the chain (the radiologist) is satisfied, the second customer in the chain (the clinician) has not yet been well served by digital image distribution.

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

  • 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 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
  • Potentially the solution is a Basic Image Review Profile which places requirements on Media Creators and Image Display actors.

Issues:

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

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


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