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

From IHE Wiki
Jump to navigation Jump to search
(Created page with "__NOTOC__ ==1. Proposed Workitem: Internet-Ready SWF== * Proposal Editor: Kinson Ho * Editor: Kinson Ho / Brad Genereaux * Date: N/A (Wiki keeps history) * Version: N/A (Wik...")
 
Line 33: Line 33:
  
 
DICOMweb complements some of the existing profiles such as XDR-I when the need is just to share imaging studies between two sites.
 
DICOMweb complements some of the existing profiles such as XDR-I when the need is just to share imaging studies between two sites.
 +
 +
Questions about whether this is focussed on a full workflow, or primarily capture and retrieval/display over the web.
 +
 +
Capture might be initial primary capture (e.g. photos for dermatology), or append cases (retrieve data, and make new data).

Revision as of 09:32, 4 September 2014


1. Proposed Workitem: Internet-Ready SWF

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

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.

3. Key Use Case

  • A user, using an Internet browser, launched the EMR
    • 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)
    • 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.
  • 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 Sending Site can also use FHIR to push the clinical context to the Receiving Site

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. 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.

DICOMweb complements some of the existing profiles such as XDR-I when the need is just to share imaging studies between two sites.

Questions about whether this is focussed on a full workflow, or primarily capture and retrieval/display over the web.

Capture might be initial primary capture (e.g. photos for dermatology), or append cases (retrieve data, and make new data).