Basic Image Review - Detailed Proposal

From IHE Wiki
Revision as of 10:17, 16 October 2008 by Jerold wallis (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

1. Proposed Workitem: Basic Image Review Profile

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


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

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


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.


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