Internet-Ready SWF - Proposal

From IHE Wiki
Jump to: navigation, search


1. Proposed Workitem: Image Viewing and Upload over the Web (IVUW)

  • Proposal Editor: Kinson Ho
  • Editor: Kinson Ho / Brad Genereaux
  • Date: N/A (Wiki keeps history)
  • Version: N/A (Wiki keeps history)
  • Domain: Radiology

Summary

With the increasing popularity of using web based image viewers, it is most often a proprietary implementation such that the web based image viewer can only work with the Image Manager from the same vendor. A common workaround is for the web based image viewer vendor to retrieve a copy of the studies from the Image Manager, which is suboptimal, increases integration complexity and resource consumption.

Furthermore, with the increasing use of mobile devices such as smartphone, tablet, smart watches / glasses, there is no easy way for these devices to upload captured images directly to the Image Manager, whether the images are new or appending to an existing study.

A 3rd problem is that many emerging enterprise imaging departments are creating lots of clinical images but they are not yet well integrated to the existing SWF infrastruture. Some of these departments are not using DICOM. In many cases, these enterprise imaging departments use a much simpler on-demand based workflow (e.g. no scheduled order).

DICOM WG27 has developed DICOMweb which currently includes QIDO-RS for study query, WADO-RS for study retrieve as well as STOW-RS for study store. This enables web based image viewer to directly interact with the Image Manager using HTTP protocols.

For image viewing, a web based Image Viewer DICOMweb to query and retrieve imaging studies from an Image Manager and present to the user.

For image upload, a mobile device uses the built-in camera to capture images and then upload to the Image Manager directly using DICOMweb. This can create a new study or expand an existing study. No scheduled order is necessary.

A healthcare enterprise often would like to integrate non-image viewing client like EMR with imaging studies. Meaningful Use Stage 3 includes imaging studies. Also this does not apply to only Radiology department but also other emerging enterprise imaging such as wound care, ophathmology, etc.

Many health information exchange network currently copy studies from Site A to Site B in order to facilitate exchange. Using a viewing-only based approach and only import if necessary can reduce the complexity and improve efficiency.

SIIM is also a strong promoter of enterprise imaging, which is the theme for SIIM 2014 and it will continue in SIIM 2015.

Collaboration with SIIM is possible.

DICOMweb defines the standard for common image study management. IHE is a good venue to create a profile specifying how DICOMweb can be used to address image viewing and upload over the web in a vendor neutral interoperable manner.

2. The Problem

Internet has become the standard of interconnecting different devices / systems to form a highly connected system. To participate in the age of Internet of Things (IoT), devices / systems usually communicate with the commonly known protocol such as HTTP, JSON / XML instead of any domain specific protocols. DICOM WG-27 has developed a number of Internet friendly API to query/retrieve/store imaging studies. This allows image viewers to query/retrieve and upload images from an Image Manager over the web in a stanardized manner.

Furthermore, there are many emerging enterprise imaging departments are creating lots of clinical images but they are not yet well integrated to the existing SWF infrastruture. Some of these departments are not using DICOM. In many cases, these enterprise imaging departments use a much simpler on-demand based workflow (e.g. no scheduled order). DICOMweb provides a simple mechanism for these departments to integrate with existing infrastructure using a simplified workflow (e.g. unscheduled)

3. Key Use Case

  1. Web based Image Viewing
  • A user, using an Internet browser, launched an web based Image Viewer.
    • The viewer can also be launched indirectly. E.g. In an EMR, a user finds the episode of a patient and launch an embedded web imaging viewer
    • The imaging viewer using QIDO-RS and WADO-RS to query and retrieving the imaging study from the Image Manager (may be a local PACS or a foreign PACS not directly connected to the EMR (e.g. discovered via XDS))
    • The image viewer presented the study to the user
  1. Enterprise Imaging Upload over the web
  • A user uses the camera on the mobile device to capture new images. Then the Image Viewer / EMR uses STOW-RS to upload the images to the Image Manager
    • The images can belong to a new study (e.g. photo for dermatology), or can be associated to an existing study (upload evidence documents or new captured images)
    • Most commonly the image upload is on-demand (i.e. unscheduled)
  1. Secure image transfer over the web
  • When a site wants to transfer a study to another non-affiliated site and there is no existing VPN between the two sites, the Sending Site uses STOW-RS over https to push a study to the Receiving Site in an encrypted form.
    • The Sending Site can also use FHIR to push the clinical context to the Receiving Site
  • DICOMweb complements some of the existing profiles such as XDR-I when the need is just to share imaging studies between two sites.

4. Standards and Systems

Existing standards: DICOM QIDO-RS, STOW-RS, WADO-RS, FHIR, MHD / MHD-I, IID

Existing systems: Image Manager / Image Archive, Image Display, Imaging Document Source / Consumer / Provider / Recipient.


5. Technical Approach

Existing actors

Image Display to query / retrieve images over the web

Image Manager to accept images and query/retrieve request using DICOMweb

Evidence Creator / Importer using DICOMweb to upload images to the Image Manager over the web securely

New actors

No new actor required

Existing transactions

No existing transactions

New transactions (standards used)

  1. Web Query Images (... and other Query transactions for other object type)
  2. Web Retrieve Images (... and other Retrieve transactions for other object type)
  3. Web Store Images (... and other Store transactions for other object type)

Impact on existing integration profiles

Can be integrated with MHD-I to disocver images from the XDS Document Registry

New integration profiles needed

Image Viewing and Upload over the Web (IVUW)

Breakdown of tasks that need to be accomplished

  • Create a profile
  • Define web equivalent for the existing store/query/retrieve transactions using DICOMweb


6. Support & Resources

At SIIM 2014 Hackathon, there were four DICOMweb API vendors (Agfa, Vital Imaging, McKesson, GE), FHIR API as well as numerous participants showcasing the basic interoperability of these APIs. There are lots of interest in this API-oriented direction of healthcare.

Agfa is willing to lead the development of this profile.

7. Risks

  • May be viewed as competing to XDR-I and XCA-I but not really.
    • XDR-I is a push based protocol. DICOMweb supports query/retrieve.
    • XCA-I supports query/retrieve. There is no storage to cross community. Also it requires a gateway, which is not required by DICOMweb.

8. Open Issues

  • Questions about whether this is focussed on a full workflow, or primarily capture and retrieval/display over the web.
    • Will likely focus on unscheduled use case initially given that workflow related web API are still in development in DICOM WG27.
  • Patient identities management. PIX / PDQ Web API is still in development in ITI. How to handle different patient ID domains
  • What is the impact to IID?
    • IID targets the integration of a viewer to a non-image viewing environment
    • IVUW targets the integration of image viewing / importer over the web
  • What is the impact to MHD-I?


9. Tech Cmte Evaluation

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

  • 25% Mobile Upload extention to MHD-I
  • 20% additional for whitepaper

Responses to Issues:

  • Primary new introduction is the upload (STOW-RS)
  • Query/Retrieve is somewhat available in MHD-I, and MHD-I has a more XDS focus with web manifest
  • Profile is a collection of transactions to create a solution
  • Potential to consolidate multiple similar existing profiles like IID, MHD-I, XDR-I
  • May need to retire some of them
  • Potentially a whitepaper

Candidate Editor:

TBA