Difference between revisions of "Internet-Ready SWF - Proposal"
| Line 36: | Line 36: | ||
Questions about whether this is focussed on a full workflow, or primarily capture and retrieval/display over the web. | 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). 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. See also PDQm and UPS-RS | + | 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. See also PDQm and UPS-RS. |
| + | |||
| + | Could be a whitepaper first. Maybe drop the retrieve part since we have that? Certainly rework the title of the proposal. | ||
Revision as of 10:36, 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). 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. See also PDQm and UPS-RS.
Could be a whitepaper first. Maybe drop the retrieve part since we have that? Certainly rework the title of the proposal.