Difference between revisions of "Web-based Image Capture"
Line 103: | Line 103: | ||
[[Category:Profiles]] | [[Category:Profiles]] | ||
+ | [[Category:RAD Profile]] | ||
+ | [[Category:DICOMweb]] |
Revision as of 15:34, 25 May 2018
Web-based Image Capture (WIC) enables a device to use DICOM RESTful API to send imaging objects to an Image Manager.
Summary
The Web-based Image Capture (WIC) Profile provides a simple, lightweight, mobile-friendly mechanism to encode and send DICOM encapsulated images, videos and evidence documents from the mobile device to the Image Manager so that these objects can be easily integrated into the rest of the imaging workflow.
Benefits
- Provides a mechanism to send fully DICOM compliant imaging objects using DICOM RESTful API (STOW-RS) and JSON/XML representation of the object header (JSON in PS 3.18 and XML in 3.19) rather than traditional binary format
- Ease the adoption of non-traditional DICOM devices (e.g. mobile devices) to send imaging objects to the existing image sharing infrastructure (PACS, VNA, etc.)
- Support metadata enhancement and data conversion by the Image Manager for certain types of objects
- Easy to work across firewalls using HTTP(S) compared to DICOM
- Easy to support authentication and encryption using HTTPS compared to DICOM without dependent on an existing secure network (VPN between sites)
Use Cases
- Create new study
- Append to existing study
- Content can be
- Static images, videos, or DICOM objects
- Non-image objects such as Key Image Note or evidence documents (e.g. GSPS)
Key highlights
- Capture Patient and Study Context
- Implicit (e.g. with the integrated viewer, EMR, etc.) in case of the Append Case
- Explicit (via IHE ITI PDQm, QR code, bar code, manual entry, etc.)
- Uses DICOMweb for content and transport
- Content can be created using DICOM binary, XML or JSON
- Client is responsible for including all proper contents
- Use STOW-RS for transport
- Image Manager
- Converts received objects into DICOM binary instances
Details
- Specifies a list of critical patient and study level attributes that the Image Capturer must provide
- Provide the necessary context for the captured objects
- Provide recommended SOP Classes to use for various types of captured objects
- Still images (Photograph vs Screenshots)
- Videos (Video Photograph)
- Evidence documents (Presentation State, Structured Report, Key Object, Encapsulated Document)
- For still images and videos, relax the mandatory non-empty (Type 1) attributes of Image Pixel Macro to mandatory but can be emptied (Type 2)
- Mobile devices may not be able to provide correct values
- If empty, Image Manager is responsible to populate them
Systems Affected
- Image Capturer (e.g. mobile tablet, medical camera, etc.) that captures imaging objects
- Image Manager (e.g. PACS, VNA) that receives imaging objects from Image Capturer via DICOM RESTful API and converts to DICOM object in binary format
Actors & Transactions:
Process Flow:
Image Upload to a New Study with PDQm Process Flow. Note that PDQm is not mandatory. Other means of obtaining proper patient demographics are also applicable.
Image Upload to an Existing Study Process Flow.
Examples:
Step 1: Fill in the required patient and study level metadata. In this example, it uses PDQm to query for patient demographics
Step 2: Capture the images and store the object to the Image Manager using STOW-RS
Step 2b: Alternatively, a viewer may be already viewing an image. So using the same patient and study context of the image currently display, store the markup to the Image Manager using STOW-RS
Specification
Profile Status: Trial Implementation
Documents:
Underlying Standards:
- DICOM PS3.18 STOW-RS
See Also
IHE Webinar
Consumer Information
Implementer Information
Reference Articles
This page is based on the Profile Overview Template