Difference between revisions of "Internet-Ready SWF - Proposal"

From IHE Wiki
Jump to navigation Jump to search
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
  
==1. Proposed Workitem: Internet-Ready SWF==
+
==1. Proposed Workitem: Image Viewing and Upload over the Web (IVUW)==
  
 
* Proposal Editor: Kinson Ho
 
* Proposal Editor: Kinson Ho
Line 8: Line 8:
 
* Version: N/A (Wiki keeps history)
 
* Version: N/A (Wiki keeps history)
 
* Domain: Radiology
 
* 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==
 
==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. It would be beneficial to extend the successful IHE SWF profile to be Internet ready so that other devices such as mobile phone, tablet, smart wearable devices, or systems connected via the Internet can share imaging studies without a steep learning curve.
+
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==
 
==3. Key Use Case==
  
* A user, using an Internet browser, launched the EMR
+
# Web based Image Viewing
** Find the episode of a patient and launch an imaging viewer
+
 
** The imaging viewer using QIDO-RS and WADO-RS to query and retrieving the imaging study from the PACS (may be a foreign PACS not directly connected to the EMR)
+
* A user, using an Internet browser, launched an web based Image Viewer.
** The user can upload additional evidence documents or using the camera on the mobile device to capture new images. Then the EMR uses STOW-RS to upload the images.
+
** 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
* When a site wants to transfer a study to another non-affiliated site without a VPN, the Sending Site uses STOW-RS to push a study to the Receiving Site.
+
** 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
 +
 
 +
# 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)
 +
 
 +
# 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
 
** 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==
 
==4. Standards and Systems==
Line 28: Line 66:
 
Existing systems: Image Manager / Image Archive, Image Display, Imaging Document Source / Consumer / Provider / Recipient.
 
Existing systems: Image Manager / Image Archive, Image Display, Imaging Document Source / Consumer / Provider / Recipient.
  
==5. Discussion==
 
  
At SIIM 2014 Hackathon, there were three DICOMweb API vendors (Agfa, Vital Imaging, McKesson), 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.
+
==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)===
 +
# Web Query Images (... and other Query transactions for other object type)
 +
# Web Retrieve Images (... and other Retrieve transactions for other object type)
 +
# 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
  
DICOMweb complements some of the existing profiles such as XDR-I when the need is just to share imaging studies between two sites.
+
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
  
Questions about whether this is focussed on a full workflow, or primarily capture and retrieval/display over the web.
+
:* 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
  
Capture might be initial primary capture (e.g. photos for dermatology), or append cases (retrieve data, and make new data).  For demographics, need to get demographics but there might not be a scheduled task giving you a worklist item to query.  Might be analagous to the IRWF.
+
Candidate Editor:
 +
: TBA

Latest revision as of 13:26, 27 October 2014


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