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

From IHE Wiki
Jump to navigation Jump to search
 
(20 intermediate revisions by 3 users not shown)
Line 14: Line 14:
 
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.   
 
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.
+
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 requiring compliance with their own independent specification or developing their own viewer and requiring its use.  The work proposed here is similar to that done for the Mammography Image and NM Image profiles.
  
  
Line 24: Line 24:
 
:* the viewer does not successfully run
 
:* the viewer does not successfully run
 
:* the viewer does not successfully load the images
 
:* the viewer does not successfully load the images
 +
:* the viewer loads too slowly
 +
:* the view claims to be "not of diagnostic quality"
 
:* functions critical to review are missing from the viewer
 
:* 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 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 impact is delayed care, inaccessible information, repeat examination and irradiation, 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.
 
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==
 
==3. Key Use Case==
  
 
===Referring Clinician Review===
 
===Referring Clinician Review===
 +
 +
A referring clinician reviews an imaging study (DICOM images) on equipment other than a radiology reading station, such as whilst in their office, whilst making rounds at a hospital, or performing a consultation.
 +
 +
The referring clinician is often a primary care physician, but may also include neurosurgeons, cardiologists, orthopedic surgeons, oncologists, and other specialists.
 +
 +
The clinician should be able to perform all "basic image review" functions, including
 +
 +
:* image windowing, panning and zooming
 +
:* comparison of more than one series at a time (in current study)
 +
:* localization of currently displayed image on orthogonal image
 +
:* display of laterality of sagittal images (as distinct from orientation of image)
 +
 +
The availability and operation of those functions should be "readily apparent".
 +
 
Here is a link to the [[:Media:Final_statement_9_26_07_.doc | AMA requirements document]]
 
Here is a link to the [[:Media:Final_statement_9_26_07_.doc | AMA requirements document]]
  
 
===Patient Viewing===
 
===Patient Viewing===
  
 
+
As a secondary use case, also consider that patients may use the viewer, although this is less critical.
''<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==
  
 
Relevant Systems:
 
Relevant Systems:
 +
* Basic Image Review Applications
 
* Media Creators
 
* Media Creators
* Basic Image Review Applications
 
  
 
Relevant Standards:
 
Relevant Standards:
Line 58: Line 73:
  
  
 +
Once the profile is written, basic image display vendors can test and claim compliance. 
  
* Potentially the solution is a Basic Image Review Profile which places requirements on Media Creators and Image Display actors.
+
Users might require that:
 +
:* CD Burning systems incorporate a Basic Image Review compliant viewer on the disk.
 +
:* CD Burning systems permit multiple viewers on the disk, including a "standard" one.
 +
:* Web Review products from PACS vendors be compliant with Basic Image Review.
 +
:* PACS displays themselves, as a minimum, comply with Basic Image Review; and hopefully go far beyond.  
  
  
Line 65: Line 85:
 
===Existing actors===
 
===Existing actors===
 
* Image Display (definitely)
 
* Image Display (definitely)
* Media Creator (possibly)
+
* Media Creator (possibly
 +
* Acquisition Modality (possibly)
  
 
===New actors===
 
===New actors===
 
None
 
None
 
  
 
===Existing transactions===
 
===Existing transactions===
Line 75: Line 95:
  
 
===New transactions (standards used)===
 
===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.
+
A 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.
 
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===
 
===Impact on existing integration profiles===
Line 88: Line 107:
  
 
===Breakdown of tasks that need to be accomplished===
 
===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.>''
 
  
 +
:* Engage and schedule time with various clinician groups (may need a remote Tech Cmte Mtg)
 +
:* Settle on scope in terms of types of modality and specialty functions
 +
:* Agree on what constitutes "basic image review" functions
 +
:* Document those functions
 +
:* Agree on what constitutes a "readily apparent" user interface
 +
:* Document appropriate guidance (both in terms of implementation and testing)
 +
:* Decide which transaction to package it in
 +
:* Decide how to package the profile (PDI Extension, vs Standalone, etc)
 +
:* Decide whether additional Acquisition Modality requirements on attributes need on images are needed
  
 
==6. Support & Resources==
 
==6. Support & Resources==
Line 99: Line 126:
 
*** Dr. Gaby Weissman
 
*** 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
+
* 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
 +
 
 +
* The Mammo Image profile demonstrated the value of having several clinicians involved in profile development. In this case, clinicians (not engineers or radiologists) are required to evaluate compliance based on clinical utility.
 +
 
  
 
===Demonstrations===
 
===Demonstrations===
Line 109: Line 139:
 
of how close we are.  A demo of Connectathon tested products could be done the following year.
 
of how close we are.  A demo of Connectathon tested products could be done the following year.
  
 +
We should strongly pursue display vendors and encourage them to pull together a prototype for these shows.
  
 
==7. Risks==
 
==7. Risks==
''<List technical or political risks that will need to be considered to successfully field the profile.>''
+
 
 +
Risk: Balancing GUI requirements may be challenging
 +
* Too detailed and they could restrict innovation
 +
* Too broad and they could fail to achieve "usable" interfaces
 +
 
 +
Risk: While most of the requirements are very straight forward, one or two functions may be difficult to implement
 +
* i.e. laterality display
 +
 
 +
Risk: If it is too hard to implement, no vendors may choose to implement it
 +
* Be prepared for some tough decisions
 +
 
 +
Risk: Will we be able to get enough attention on this for vendors to implement
 +
* Use AMA, AANS, RSNA to bring attention
 +
* Pull in ACR and RIC and DRG and RANZCR
 +
* Engage Japanese groups (Identify which one)
 +
* Encourage the AMA group to continue coordinating the user coalition
 +
* Directly contact our participant base (work with MITA)
 +
* Find and contact the small display vendors
 +
 
 +
Risk: We might not get the clinicians to show up
 +
* Make it convenient for them to participate
 +
* Be prepared to produce "user speak" documents
 +
* Focus their effort on requirements and we'll do the tech docs.
  
 
==8. Open Issues==
 
==8. Open Issues==
  
 +
Issue: Where to put the display and control behaviors
 
* Put the requirements in Image Stored, or in a new Display Image, or somewhere else?
 
* 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
 
* Others would like to specify broad behaviors and things like "must be readily apparent"
 
* Others would like to specify broad behaviors and things like "must be readily apparent"
** Problem: May requires human evaluation which may be subjective  
+
** Problem: May require human evaluation of compliance which may be subjective  
 
* There is some interest in ACR to be involved in the evaluation of systems implementing the profile
 
* There is some interest in ACR to be involved in the evaluation of systems implementing the profile
 +
* AMA might also like to review/certify
 +
* Mammo got domain experts to do the evaluations and it worked
 
* AMA prepared the document linked in the use cases as a starting point
 
* AMA prepared the document linked in the use cases as a starting point
  
  
Issue: Should we address office review ''workflow''
+
Issue: Should the profile address office review ''workflow''
 
* E.g. provide recommendations to set up your own viewer and have office staff pre-load images from patients
 
* 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
 
* Offices which do not think about this find CDs painful because of the loading time of the application and data
 +
* Many of the use cases do not involve an "office workflow" at all, e.g., rounding in one of many hospitals where a specialist is credentialed and consults.
  
  
 
Issue: Report Review
 
Issue: Report Review
 
* the reviewer is often also interested in the accompanying Radiology Report (if any)
 
* the reviewer is often also interested in the accompanying Radiology Report (if any)
 +
* delaying media creation until report creation may delay care
 +
* any report on the media may be obsolete (was preliminary not final, or has been amended)
 +
* lack of deployment of standards for report format adds risk to profile compliance if required
 +
* not expressed as key to solving the primary concern of physicians
 
* 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
 
* 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
 
* DRPT documents PDF-based reports
 
* PDI allows for reports on the CD
 
* PDI allows for reports on the CD
 
* Basic Image Review is intended to be complementary to PDI
 
* Basic Image Review is intended to be complementary to PDI
 +
 +
* Close issue by declaring detailed specification of how reports are encoded and displayed to be out of scope of this profile
 +
 +
 +
Issue: Inclusion of NM features within scope
 +
* Of the 20+ pages of items in the NM profile, the single NM feature being proposed for inclusion here is "include controls for upper and lower level window adjustments"
 +
* If this is not acceptable, a dumbed-down simpler version would be to by default lock the lower level to zero for NM and PET images (ie, the lock could be turned off by some setting or other in the user interface).  Thus, no matter how one adjusted the window using whatever controls available of any type at all, the lower level would be fixed at zero.  This is the setting that 98% of viewers would want. Since this could be turned off by the user, it would keep everyone happy.
 +
*  If even this is not acceptable, an even dumber-downed version would be to ALWAYS lock the lower level to zero for NM and PET images, (ie without the abitiliy to turn this feature off).  This would be a single line of code, with NO change in GUI controls.  I cannot imagine that this would be too hard for developers.
 +
 +
 +
 +
Issue: Inclusion of Image Fusion profile features within scope?
 +
* Of all the items in the Image Fusion profile, the two that should be strongly considered for the Basic image review are:
 +
1) Ability to window PET studies using upper and lower level controls (see above comments regarding NM images). <p>
 +
2) Ability to scroll through two registered data sets synchronously with side-by-side display and linked cursors (ie point to a feature on one image and also see the cursor on the second image). 
 +
* While other features are nice (MPR generation of coronal images, MIP generation, image fusion overlays, use of stored presentation states, etc), the two features above are the minimal features that would be extremely helpful in viewing the many PET-CT CDs that flow through our department.
 +
 +
  
  
  
 
==9. Tech Cmte Evaluation==
 
==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):
 
Effort Evaluation (as a % of Tech Cmte Bandwidth):
:* 35% for ...
+
:* 40% (i.e. 2 days of each 5 day meeting)
  
 
Responses to Issues:
 
Responses to Issues:

Latest revision as of 11:17, 16 October 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 requiring compliance with their own independent specification or developing their own viewer and requiring its use. The work proposed here is similar to that done for the Mammography Image and NM Image profiles.


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
  • the viewer loads too slowly
  • the view claims to be "not of diagnostic quality"
  • 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, repeat examination and irradiation, 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

A referring clinician reviews an imaging study (DICOM images) on equipment other than a radiology reading station, such as whilst in their office, whilst making rounds at a hospital, or performing a consultation.

The referring clinician is often a primary care physician, but may also include neurosurgeons, cardiologists, orthopedic surgeons, oncologists, and other specialists.

The clinician should be able to perform all "basic image review" functions, including

  • image windowing, panning and zooming
  • comparison of more than one series at a time (in current study)
  • localization of currently displayed image on orthogonal image
  • display of laterality of sagittal images (as distinct from orientation of image)

The availability and operation of those functions should be "readily apparent".

Here is a link to the AMA requirements document

Patient Viewing

As a secondary use case, also consider that patients may use the viewer, although this is less critical.

4. Standards & Systems

Relevant Systems:

  • Basic Image Review Applications
  • Media Creators

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.


Once the profile is written, basic image display vendors can test and claim compliance.

Users might require that:

  • CD Burning systems incorporate a Basic Image Review compliant viewer on the disk.
  • CD Burning systems permit multiple viewers on the disk, including a "standard" one.
  • Web Review products from PACS vendors be compliant with Basic Image Review.
  • PACS displays themselves, as a minimum, comply with Basic Image Review; and hopefully go far beyond.


Existing actors

  • Image Display (definitely)
  • Media Creator (possibly
  • Acquisition Modality (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)

A 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

  • Engage and schedule time with various clinician groups (may need a remote Tech Cmte Mtg)
  • Settle on scope in terms of types of modality and specialty functions
  • Agree on what constitutes "basic image review" functions
  • Document those functions
  • Agree on what constitutes a "readily apparent" user interface
  • Document appropriate guidance (both in terms of implementation and testing)
  • Decide which transaction to package it in
  • Decide how to package the profile (PDI Extension, vs Standalone, etc)
  • Decide whether additional Acquisition Modality requirements on attributes need on images are needed

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
  • The Mammo Image profile demonstrated the value of having several clinicians involved in profile development. In this case, clinicians (not engineers or radiologists) are required to evaluate compliance based on clinical utility.


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.

We should strongly pursue display vendors and encourage them to pull together a prototype for these shows.

7. Risks

Risk: Balancing GUI requirements may be challenging

  • Too detailed and they could restrict innovation
  • Too broad and they could fail to achieve "usable" interfaces

Risk: While most of the requirements are very straight forward, one or two functions may be difficult to implement

  • i.e. laterality display

Risk: If it is too hard to implement, no vendors may choose to implement it

  • Be prepared for some tough decisions

Risk: Will we be able to get enough attention on this for vendors to implement

  • Use AMA, AANS, RSNA to bring attention
  • Pull in ACR and RIC and DRG and RANZCR
  • Engage Japanese groups (Identify which one)
  • Encourage the AMA group to continue coordinating the user coalition
  • Directly contact our participant base (work with MITA)
  • Find and contact the small display vendors

Risk: We might not get the clinicians to show up

  • Make it convenient for them to participate
  • Be prepared to produce "user speak" documents
  • Focus their effort on requirements and we'll do the tech docs.

8. Open Issues

Issue: Where to put the display and control behaviors

  • 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 require human evaluation of compliance which may be subjective
  • There is some interest in ACR to be involved in the evaluation of systems implementing the profile
  • AMA might also like to review/certify
  • Mammo got domain experts to do the evaluations and it worked
  • AMA prepared the document linked in the use cases as a starting point


Issue: Should the profile 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
  • Many of the use cases do not involve an "office workflow" at all, e.g., rounding in one of many hospitals where a specialist is credentialed and consults.


Issue: Report Review

  • the reviewer is often also interested in the accompanying Radiology Report (if any)
  • delaying media creation until report creation may delay care
  • any report on the media may be obsolete (was preliminary not final, or has been amended)
  • lack of deployment of standards for report format adds risk to profile compliance if required
  • not expressed as key to solving the primary concern of physicians
  • 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
  • Close issue by declaring detailed specification of how reports are encoded and displayed to be out of scope of this profile


Issue: Inclusion of NM features within scope

  • Of the 20+ pages of items in the NM profile, the single NM feature being proposed for inclusion here is "include controls for upper and lower level window adjustments"
  • If this is not acceptable, a dumbed-down simpler version would be to by default lock the lower level to zero for NM and PET images (ie, the lock could be turned off by some setting or other in the user interface). Thus, no matter how one adjusted the window using whatever controls available of any type at all, the lower level would be fixed at zero. This is the setting that 98% of viewers would want. Since this could be turned off by the user, it would keep everyone happy.
  • If even this is not acceptable, an even dumber-downed version would be to ALWAYS lock the lower level to zero for NM and PET images, (ie without the abitiliy to turn this feature off). This would be a single line of code, with NO change in GUI controls. I cannot imagine that this would be too hard for developers.


Issue: Inclusion of Image Fusion profile features within scope?

  • Of all the items in the Image Fusion profile, the two that should be strongly considered for the Basic image review are:

1) Ability to window PET studies using upper and lower level controls (see above comments regarding NM images).

2) Ability to scroll through two registered data sets synchronously with side-by-side display and linked cursors (ie point to a feature on one image and also see the cursor on the second image).

  • While other features are nice (MPR generation of coronal images, MIP generation, image fusion overlays, use of stored presentation states, etc), the two features above are the minimal features that would be extremely helpful in viewing the many PET-CT CDs that flow through our department.

9. Tech Cmte Evaluation

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

  • 40% (i.e. 2 days of each 5 day meeting)

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

David Clunie