Invoke Radiology Image Display Service - Detailed Proposal - 2012-2013

From IHE Wiki
Jump to navigation Jump to search

1. Proposed Workitem: Invoke Radiology Image Display Service

  • Proposal Editor: David Clunie
  • Editor: David Clunie
  • Date: N/A (Wiki keeps history)
  • Version: N/A (Wiki keeps history)
  • Domain: Radiology

Summary

The proposal is to create a Radiology profile that leverages the Cardiology Image Enabled Office Invoke Image Display Service transaction, which allows an EHR to request an IM/IA to display images of a study, and generalize it to support radiology use-cases that involve:

  • other actors invoking the service than only the IHE,
  • other means of selecting what to display than just the Study Instance UID, and
  • means of specifying with what fidelity and functionality to display the images

This is a task for IHE given that it involves integration of systems from different vendors and industries, and that it is based on an existing IHE transaction from another domain.

2. The Problem

There is a need to allow non-image-aware systems like EHRs to request the display of specific studies for a patient and have the display performed by an image-aware system like a PACS.

The IHE Cardiology Domain has addressed this issue in their Image Enabled Office Profile, which contains an Invoke Image Display Service transaction [CARD-15], between an EHR requesting the service and an Image Manager/Archive providing the service, in a manner that does not presume any particular technology used to deliver the images.

There is a need to generalize the cardiology transaction for radiology use, and allow for greater flexibility in what keys to use to specify the requested studies, and to specific with what degree of fidelity they should be displayed.

Standardization of the mechanism would significantly reduce the cost of implementing, testing and deploying multiple EHR-PACS custom integrations.

The proposal is timely since:

  • the ONC MU2 requirements specify a need to view images in the EHR, either in-line or via link, and whilst permitting that this is possible without standards, provides a strong incentive to implement this and a standard will increase accessibility and reduce complexity to the implementer and deployer (URL: ONC comment resolution and final rule)
  • the UK Imaging Informatics group has requested that this be considered as an IHE profile


3. Key Use Case

1. A nurse practitioner, physician assistant or physician not expert in imaging is using the EHR and wants to review key images on mobile device - clicks on "key image review" in a dated study entry for patient in EHR web portal, and the web browser tab switches to one that contains adequate but review (not diagnostic) quality key images rendered statically in the browser.

2. A physician or surgeon expert in imaging is called to consult on an emergency patient and is using EHR on PC workstation (with a high speed connection to the local network and with high quality displays) to review status and results, and wants to review diagnostic quality images for diagnostic and treatment decision making - clicks on "diagnostic image review" in a dated study entry for patient in EHR web portal, and new web browser page executing a zero footprint viewer of a complete set of diagnostic quality images appears loaded with selected study.

3. The same situation as 2, but clicking on "diagnostic image review" instead opens a transient popup page that triggers startup of local PACS viewing application and commands that application to load the entire study selected from PACS for display.

4. Standards and Systems

Services like WADO have provided a means to render single images server-side and return then to a web browser in a consumer format, but do not address the need to organize and navigate a set of images that constitute a study. Any form of interaction like zooming or panning or windowing or scrolling needs to be implemented in logic on the client side or embedded in additional web pages from the server. This unnecessarily burdens non-image-aware clients like an EHR.

A web interface to a PACS may implement this logic easily, but this begs the question of how the EHR is linked to this PACS web portal in the first place, and implies the need for n:m combinations of custom interfaces, where n is the number of EHR vendors and software versions and m is the number of PACS vendors and software versions, possibly multiplied by further customizations required by individual sites.

A single definition of a family of request types or resources would suffice to eliminate the need for the n:m permutations of customization by addressing the single issue of requesting viewing of a specific study (or perhaps set of studies), leaving aside the issue of what browser or platform is necessary to actually execute the viewer software, or to control the access (which then become a matter of local IT infrastructure configuration rather than customization of software, or even configuration of software other than the browser +/- consumer plugins).

The IHE Cardiology Domain has addressed this issue in their Image Enabled Office Profile, which contains an Invoke Image Display Service transaction [CARD-15], between an EHR requesting the service and an Image Manager/Archive providing the service, in a manner that does not presume any particular technology used to deliver the images.

5. Technical Approach

Existing actors

  • Image Manager/Image Archive
  • EHR-S (from Cardiology)

New actors

  • what ever might invoke a viewer (not necessarily just the EHR-S, as in the Cardiology IEO profile)

Existing transactions

The CARD-15 supports the request to display a single study identified by its Study Instance UID. This presumes sufficiently tight integration that the requesting EHR is aware of the Study Instance UID. It is proposed that in the case of radiology images there is a need to be able to specify both more than one study (since multiple studies may have been performed on the same day, or there is a need to compare with priors) and to be able to specify using more general keys, such as Accession Number, or Study Date, or Modality.

New transactions (standards used)

Some extension of the CARD-15 transaction, perhaps using parameters from the related Retrieve Specific Information for Display [ITI-11] transaction is needed.

Though other approaches than an http request type URL could be used, such as to specify RESTful resources or to specify SOAP-based web services, the existing precedent of CARD-15 and ITI-11 would seem to be sufficient.

There is no conflict (but also no overlap) with the current work of DICOM WG 27, which is defining web services for the transport of images, not services for invoking the display of such images; such existing and new DICOM services might well be appropriate for the implementation of the viewer, but are not a pre-requisite and are outside the scope of this proposal.

In brief, the expected behavior is "make available all images in the study to be viewed interactively"; the following text quoted from the Cardiology IEO Profile describes the expected behavior for the CARD-15 transaction in this respect:

4.15.4.3 Interactive Access to DICOM Study

Following successful parsing of a web service request and identification of the study(ies) to be displayed, the Image Manager/ Image Archive shall provide a web-based client interaction to one or more windows on the EHR-S actor.

Any necessary plug-ins shall be automatically dowloaded from the Image Manager/ Image Archive, if not already installed on the EHR-S client.

Note: The area of web interaction technologies is rapidly evolving, and the producers of Image Manage/Image Archive products with web interfaces are very cognizant of the need to display properly on the variety of platforms that are used for EHR systems. The IHE Cardiology Technical Committee has decided that over-specification of this interaction would be counter-productive to innovation in implementation of effective user interfaces. This transaction therefore specifies only the initial web service invocation, and the functional requirement for display of all study information objects. During Trial Implementation, the committee will monitor whether this approach is achieving the requisite level of interoperability.

Management of change of patient context is out of scope of this profile. Note: The EHR-S Actor may implement the ITI Patient Synchronized Applications (PSA) Profile based on the HL7 CCOW standard.

The Image Manager/ Image Archive shall provide web-based access and display of all DICOM objects for which it claims compliance in any IHE Content or Workflow Profile. This includes images (single frame and multi-frame), DICOM SR (including Evidence Documents and Key Image Notes), and Presentation State objects with their referenced images.

Note: The Image Manager/ Image Archive documentation should indicate under what conditions or circumstances the displayed images may be considered to be diagnostic quality when rendered by the EHR-S Actor.

As an example, the provider of the service may provide an HTML page that does whatever is necessary, including, but not limited to, such methods as:

  • HTML5/Canvas zero footprint viewer
  • traditional HTML +/- Javascript JPEG viewer or plugin (Flash, Silverlight) embedded (in-browser) viewer
  • Java WebStart or ActiveX viewer
  • triggers proprietary installed plugin to feed or launch local viewer application
  • static layer of pre-formatted images

What viewer technology is used is outside the scope, the value is in standardizing the "call".

The cardiology transaction presumes that for every use case "interactivity" in viewing is actually necessary, and this might instead need to be a parameter for radiology use-cases.

This and other possible parameters might include:

  • interactiveViewing=[yes|no] - default is no (not required); if yes, assumes viewer is interactive not static (e.g., allows navigation, windowing, etc.)
  • diagnosticQuality=[yes|no] - default is no (not required); if yes, assumes satisfactory diagnostic display environment
  • imageQuality=integer - permitted if diagnosticQuality=no (not required); definition from WADO
  • keyImagesOnly=[yes|no] - default is no (all images required); if yes, assumes key images were specified (server knows; not supplied by client)
  • anonymize=[yes|no] - default is no
  • viewerComplexity=[simple|basic|advanced], perhaps with basic defined to be IHE BIR Profile functionality

Impact on existing integration profiles

There would be no impact on existing profiles

New integration profiles needed

A new profile to define the behavior of the new transaction and to bring the cardiology profile actors into radiology would need to be defined, tentatively called the "Invoke Radiology Image Display Service (IRIDS) Integration Profile"

Breakdown of tasks that need to be accomplished

  • define scope, including use-cases and options
    • during effort evaluation, it was noted that the following would be out of scope
      • profiling the use of WADO-* to deliver the requested images
      • specifying capabilities associated with simple/basic/advanced viewer complexity (other than perhaps simply pointing at BIR)
  • review cardiology transaction is a good basis and decide how it should be modified
  • define and name service invoking actors
  • define the request options and how to define them
  • profile text drafting, cutting and pasting from cardiology as needed

6. Support & Resources

  • David Clunie
  • UK Imaging Informatics group will review and consult

7. Risks

  • lack of consensus on approach
  • lack of agreement that actual viewer technology definition can remain out of scope
  • lack of consensus on which viewing options are necessary and how to define them (e.g., what is "diagnostic")

8. Open Issues

  • whether or not to reference Basic Image Review (BIR) profile
  • whether or not and how to include reports

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%

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

David Clunie
Retrieved from "http://wiki.ihe.net/index.php?title=Invoke_Radiology_Image_Display_Service_-_Detailed_Proposal_-_2012-2013&oldid=64091"