DICOMweb
DICOMweb is a set of RESTful web services defined in Part 18 (PS3.18) of the Digital Imaging and Communications in Medicine (DICOM) standard, enabling the query, retrieval, storage, and management of medical imaging data over the web using HTTP protocols and formats such as JSON and XML.[1][2] Introduced in 2013 as the second generation of DICOM web services, it builds on earlier efforts like the 2003 Web Access to DICOM Objects (WADO) specification to provide a modern, developer-friendly interface for integrating DICOM objects into web-based applications without requiring proprietary DICOM software.[3] The core services of DICOMweb include Query based on ID for DICOM Objects (QIDO-RS) for searching studies, series, and instances by identifiers like patient ID; Web Access to DICOM Objects using Retrieve (WADO-RS and WADO-URI) for fetching specific DICOM data; Store Over the Web (STOW-RS) for uploading instances; and Unified Procedure Step (UPS-RS) for workflow management, along with a Capabilities service to discover supported endpoints.[4] These services operate on resources representing DICOM hierarchies—such as studies, series, and instances—and support multipart MIME types for efficient transfer of binary image data alongside metadata. By leveraging standard web technologies, DICOMweb facilitates interoperability in healthcare IT systems, cloud storage of imaging data, and integration with electronic health records, addressing challenges in sharing large volumes of medical images across distributed environments.[1] Since its release, DICOMweb has evolved through supplements and change proposals, with the current version (2025d) incorporating enhancements like thumbnail services and improved error handling, while maintaining backward compatibility with the original 2013 APIs such as QIDO-RS, WADO-RS, and STOW-RS.[5] Its adoption has grown in telemedicine, AI-driven image analysis, and vendor-neutral archiving, promoting a shift from traditional DICOM DIMSE protocols to web-centric architectures that enhance accessibility for global healthcare providers.[3][6]Overview
Definition and Purpose
DICOMweb is a family of RESTful web services defined within the Digital Imaging and Communications in Medicine (DICOM) standard, designed to enable the sending, retrieving, and querying of medical images and associated information over HTTP and HTTPS protocols.[7] It extends the core DICOM information model—originally developed for network and media-based interchange—to web environments, allowing seamless interaction between user agents (such as web browsers or applications) and origin servers to manage DICOM resources like studies, series, and instances.[7] This web-native approach leverages standard HTTP methods and media types, supporting metadata encoding in formats such as JSON and XML to represent DICOM data sets without altering the underlying DICOM semantics.[1] The primary purpose of DICOMweb is to provide interoperable access to DICOM data for diverse healthcare applications, eliminating the need for specialized DICOM protocols like DIMSE while utilizing familiar web technologies.[1] By acting as a bridge between legacy DICOM systems and modern web infrastructures, it facilitates efficient data exchange in environments such as Picture Archiving and Communication Systems (PACS), Electronic Health Records (EHRs), and radiology information systems (RIS), promoting standardized workflows without requiring modifications to image-producing modalities.[8] This design ensures that developers can integrate medical imaging capabilities using industry-standard tools, enhancing accessibility for both clinical and non-clinical users.[1] In modern healthcare, DICOMweb plays a crucial role in advancing cloud integration, patient portals, and AI-driven analytics by enabling secure, scalable sharing of imaging data across devices and institutions.[8] It supports patient-centered care models through web-based retrieval and querying, allowing authorized access to images in EHRs and mobile tools, while fostering collaborative use in telemedicine and research applications.[8] Overall, DICOMweb addresses the limitations of traditional DICOM by aligning medical imaging with the broader web ecosystem, thereby improving interoperability and efficiency in an increasingly digital healthcare landscape.[7]Architecture and Technologies
DICOMweb employs a RESTful architecture, which defines a set of constraints for designing networked applications, emphasizing stateless client-server communication, uniform interfaces, and the use of standard HTTP methods to perform operations on resources identified by Uniform Resource Identifiers (URIs).[9] This design ensures that each request from a client to a server contains all necessary information for processing, without reliance on prior interactions, thereby promoting scalability and simplicity in medical imaging systems.[10] The architecture leverages HTTP/1.1, HTTPS/1.1, HTTP/2, and HTTPS/2 protocols for transport, with HTTPS recommended for secure transmission of sensitive health data over the internet.[11] At its core, DICOMweb utilizes JSON as the primary format for encoding metadata, defined in Appendix F of PS3.18, which maps DICOM data elements to JSON structures using the media type application/dicom+json and UTF-8 encoding.[12] For handling binary payloads such as DICOM instances or image data, the architecture supports the multipart/related MIME type as specified in RFC 2387, allowing a single HTTP request to bundle metadata and bulk data parts efficiently.[13] This combination enables seamless transfer of complex DICOM objects while adhering to web conventions. The resource model in DICOMweb organizes medical imaging data hierarchically through URI paths, representing studies, series, and instances as addressable entities—for example, /studies/{studyUID} for a study resource or /studies/{studyUID}/series/{seriesUID}/instances/{instanceUID} for a specific instance.[14] These URIs follow URI template syntax from RFC 6570, ensuring precise identification without proprietary extensions.[15] By integrating directly with established web standards, including HTTP headers like Accept and Content-Type, DICOMweb facilitates compatibility with browsers, standard APIs, and development tools, eliminating the need for custom protocols.[10]Standards
PS3.18: Web Services
PS3.18 of the DICOM standard defines the normative specifications for web services that enable the management and distribution of DICOM objects using RESTful principles over the HTTP/HTTPS family of protocols.[2] These services facilitate interactions such as querying, retrieving, and storing medical imaging data in a web-accessible manner, supporting resource-oriented architectures where DICOM instances, studies, and series are treated as addressable resources.[9] Service discovery is provided through the Retrieve Capabilities Transaction, accessible via a dedicated endpoint that returns an XML or JSON document detailing the available services, supported operations, and conformance levels of the DICOMweb implementation.[16] Chapter 8 of PS3.18 provides an overview of the common aspects applicable to all DICOMweb services, including transaction models, media types, and general requirements for requests and responses.[17] Chapter 10 specifies the core retrieval and storage services: QIDO-RS (Query/Retrieve Information for Display - RESTful Service) for searching and retrieving metadata of DICOM objects using query parameters; WADO-RS (Web Access to DICOM Objects - RESTful Service) for accessing rendered images, bulk data, or metadata from studies, series, or instances; and STOW-RS (STOre Over the Web - RESTful Service) for uploading DICOM objects via multipart payloads.[18] Chapter 11 details UPS-RS (Unified Procedure Step - RESTful Service), which manages workflow resources for procedure steps, including creation, subscription, and event reporting to coordinate multi-system interactions.[19] The specifications outline URI structures using standardized templates to identify resources, such as/studies/{[study](/page/Study)} for study-level access, with path parameters and query strings for filtering and pagination.[20] HTTP methods (GET, POST, etc.) are mandated for specific operations, with responses using standard status codes like 200 OK for success, 400 Bad Request for malformed inputs, and 404 Not Found for missing resources, as detailed in Table 8.5-1.[21] Error handling requires detailed status reports in failure responses, including failure reasons and codes to aid debugging and conformance testing.[22] Conformance requirements in Section 6 mandate support for specific IANA-registered media types, secure transport, and optional features like multipart responses, ensuring interoperability across implementations.[23]
Notable updates include the 2017 addition of thumbnail resources via Supplement 203, which introduced lightweight image representations retrievable by appending /thumbnail to resource URIs, enabling efficient previews without full data transfer.[24] In 2025, Change Proposal CP-2473 clarified HTTP response codes for search transactions returning zero results, aligning them more closely with HTTP semantics to improve interoperability in edge cases.[25]
PS3.19: XML Encoding
PS3.19 specifies the XML encoding rules for representing DICOM data structures in a format suitable for web-based services and application hosting, focusing on the Native DICOM Model defined in Appendix A.1. This model provides a direct mapping of binary-encoded DICOM Service-Object Pair (SOP) Instances to XML Infosets, enabling navigation and manipulation using standard XML tools without requiring specialized DICOM binary parsing libraries. The purpose is to facilitate interoperability in environments where XML processing is preferred, such as in hosted applications or RESTful web services, by defining precise representations for DICOM datasets, metadata, data elements, attributes, and sequences.[26] Key features of the XML encoding include the hierarchical structure of the Native DICOM Model, which uses elements like<NativeDicomModel>, <DicomDataSet>, and <DicomAttribute> to mirror DICOM's organization. Data elements are encoded as <DicomAttribute> with attributes such as tag (e.g., "00100020" for Patient ID), optional vr (Value Representation, e.g., "LO"), keyword (from PS3.6 definitions), and privateCreator for private attributes. Values are captured in <Value> elements with a number attribute to preserve multiplicity and order, supporting multi-valued attributes like those in sequences. Sequences are represented recursively with <Item> elements containing nested <DicomAttribute> structures, while bulk data references use <BulkData> with URI or UUID pointers, and inline binaries are base64-encoded in <InlineBinary>. Person names (PN VR) are further structured with sub-elements for alphabetic, ideographic, and phonetic components. This mapping supports full DICOM datasets and metadata extraction, with padding for even byte lengths preserved where applicable.[27][28]
The encoding includes validation schemas in Relax NG Compact format (detailed in A.1.6), which enforce structure but perform minimal type checking to ensure bi-directional fidelity between XML and binary DICOM. Usage in DICOMweb services positions XML as an alternative to JSON for responses in Query/Retrieve services like QIDO-RS (for search results) and WADO-RS (for instance metadata), with the media type application/dicom+xml. For example, a QIDO-RS response might return metadata in Native DICOM Model XML, allowing XPath queries such as /NativeDicomModel/DicomDataSet/DicomAttribute[@tag="00100020"]/Value[@number="1"] to extract specific values. Schemas enable rigorous validation of these representations, promoting consistency across implementations.[29][30][31]
Compared to JSON encoding (defined in PS3.18), XML is more verbose due to explicit element tagging and nesting but offers greater schema rigidity for validation and tool interoperability. While JSON uses lightweight key-value pairs, XML's Infoset allows unordered elements and supports advanced features like namespaces, though no canonical serialization is mandated. Integration with the deprecated WADO-WS (Web Services for DICOM, retired in PS3.18 Appendix C) previously leveraged XML but is no longer recommended, with Native DICOM Model XML now primarily used in modern RESTful contexts like STOW-RS for storage.[32][12][33]
Notable updates include Supplement 251 (March 2025), which introduces an updated RESTful Application Program Interface (API) for PS3.19 Application Hosting and retires the previous SOAP-based API.[34]
This example illustrates a simple dataset with Patient ID and Name attributes.[35]xml<NativeDicomModel> <DicomDataSet> <DicomAttribute tag="00100020" vr="LO" keyword="PatientID"> <Value number="1">12345</Value> </DicomAttribute> <DicomAttribute tag="00100010" vr="PN" keyword="PatientName"> <PersonName> <Alphabetic> <Value number="1">Doe^John</Value> </Alphabetic> </PersonName> </DicomAttribute> </DicomDataSet> </NativeDicomModel><NativeDicomModel> <DicomDataSet> <DicomAttribute tag="00100020" vr="LO" keyword="PatientID"> <Value number="1">12345</Value> </DicomAttribute> <DicomAttribute tag="00100010" vr="PN" keyword="PatientName"> <PersonName> <Alphabetic> <Value number="1">Doe^John</Value> </Alphabetic> </PersonName> </DicomAttribute> </DicomDataSet> </NativeDicomModel>
Services
Retrieval Services
DICOMweb retrieval services enable the access and download of DICOM objects and related data over HTTP/HTTPS, primarily through two mechanisms: the RESTful Web Access to DICOM Objects using Retrieve (WADO-RS) and the URI-based Web Access to DICOM Objects (WADO-URI).[5] These services support fetching studies, series, instances, metadata, and rendered formats without requiring prior knowledge of the full DICOM protocol, facilitating integration with web-based applications.[5] WADO-RS, defined in Section 10.4 of PS3.18, provides a RESTful interface for comprehensive retrieval using HTTP GET requests on resource-specific endpoints such as /studies, /series, and /instances.[5] It supports retrieval of entire studies or series, individual instances, specific frames from multi-frame objects via paths like /frames/{framelist} or the frameNumber parameter, bulk data items, pixel data URIs, thumbnails, and advanced rendered outputs including multi-planar reformatting (MPR) and 3D volumes.[5] Key parameters include accept for content negotiation, charset for encoding, annotation for display overlays, quality for compression levels in rendered images, and viewport/window for adjusting image presentation.[5] Responses can be in native DICOM format (application/dicom), multipart/related for bulk transfers, JSON metadata (application/dicom+json), octet-stream for pixel data, or various image/video formats like image/jpeg or video/mp4 for rendered content.[5] In contrast, WADO-URI, outlined in Chapter 9 of PS3.18, offers a simpler, legacy-oriented approach for retrieving single Composite SOP Instances or rendered images via HTTP GET with query parameters appended to a base URI.[5] Mandatory parameters include requestType=WADO, studyUID, seriesUID, and objectUID to specify the target, while optional ones like frameNumber enable access to specific frames in multi-frame instances, and transferSyntax allows selection of encoding.[5] It does not support bulk retrieval of multiple objects but is suitable for direct, lightweight access.[5] Response formats include application/dicom for raw data or image/jpeg for rendered views, often used in scenarios requiring anonymization or annotation via parameters like anonymize or annotation.[5] Both services emphasize secure, stateless retrieval operations, with WADO-RS providing greater scalability for modern systems through its RESTful design and support for partial or aggregated responses.[5] Common use cases include loading DICOM images into web-based viewers for clinical review, exporting pixel data or metadata to non-DICOM analysis tools, and generating thumbnails or rendered previews for user interfaces.[5] For instance, a web application might use WADO-RS to fetch a series of CT frames for interactive 3D visualization, while WADO-URI suits embedding a single annotated X-ray image in a report.[5]| Feature | WADO-RS (Section 10.4) | WADO-URI (Chapter 9) |
|---|---|---|
| Primary Use | RESTful access to studies, series, instances, frames, bulk data, rendered/3D outputs | URI-based access to single instances or rendered images |
| Bulk/Frame Support | Yes (multipart responses, /frames path, frameNumber param) | Frames only (frameNumber param); no bulk |
| Key Parameters | accept, frameNumber, viewport, window, quality | studyUID, seriesUID, objectUID, frameNumber, transferSyntax |
| Response Formats | DICOM, JSON metadata, octet-stream, image/video variants | DICOM, image/jpeg/png |
Query Services
Query Services in DICOMweb primarily revolve around the QIDO-RS (Query based on ID for DICOM Objects) transaction, which enables RESTful searching of DICOM repositories for studies, series, and instances using HTTP GET requests.[30] This service allows clients to discover and list DICOM objects based on specific identifiers and attributes, such as Patient ID, Study Instance UID, or Series Instance UID, without retrieving the full objects or pixel data.[30] It supports hierarchical queries at the study, series, or instance level, facilitating efficient metadata retrieval for applications that need to index or preview imaging data.[30] Key query parameters enhance the flexibility of QIDO-RS searches. Theincludefield parameter specifies which DICOM attributes (identified by tags like "00080005" for Specific Character Set) should be returned in the response, allowing customization to reduce payload size.[30] The limit parameter restricts the number of results (e.g., to 10 matches), supporting pagination for large datasets.[30] Additionally, the timezone parameter adjusts date and time attributes to a specified offset, such as UTC, ensuring consistency across global systems.[30] QIDO-RS also accommodates fuzzy semantic matching for person names via the fuzzymatching=true parameter and partial matching using wildcards like '*', as well as relational queries at different hierarchy levels, and multiple attribute-value pairs combined implicitly with AND for more precise filtering.[30]
Responses from QIDO-RS are formatted in JSON or XML, providing structured lists of matching resources with their metadata, such as unique identifiers and selected attributes.[30] These responses exclude bulk data like pixel elements, focusing instead on lightweight summaries that enable quick processing.[30] Common use cases include generating patient worklists in clinical applications or creating previews of available studies without the overhead of full data retrieval, thereby improving performance in web-based imaging workflows.[30] For instance, a query might search for all studies matching a Patient ID to build a dashboard view, leveraging the service's support for optional attributes and flexible matching rules.[30]
Storage Services
The Storage Services in DICOMweb are primarily provided by the STOW-RS (Store Over the Web - RESTful Services) transaction, which enables clients to upload and store DICOM objects such as studies, series, and instances to a server using HTTP POST requests. Defined in DICOM PS3.18 Section 10.5, STOW-RS targets resources like/studies for payloads containing instances from multiple studies or /studies/{study} for instances within a single study, with the request payload formatted according to specified media types for DICOM resources. This service supports storing complete DICOM SOP instances in binary form or separated metadata (encoded in XML per PS3.19 or JSON per Annex F) and bulkdata (e.g., pixel data as application/octet-stream for uncompressed items).[36][36]
Upon receiving a STOW-RS request, the origin server validates the payload for conformance to the defined media types and checks elements such as Study Instance UID consistency, supported SOP Classes, and Transfer Syntaxes. If validation passes, the server stores the instances and may perform attribute coercion, such as modifying or discarding non-conforming data elements, while generating necessary File Meta Information for the datasets. Bulk storage is facilitated by allowing multiple instances in a single request, optimizing uploads for efficiency in handling large volumes of imaging data. The server responds with HTTP status codes indicating overall success (200 OK for all instances stored without issues), partial success with warnings (202 Accepted), or failure (e.g., 400 Bad Request for syntax errors, 409 Conflict for unsupported SOP Classes), accompanied by an XML response body detailing instance-specific outcomes via modules like the Failed SOP Sequence or Referenced SOP Sequence.[36][36][37]
Common use cases for STOW-RS include uploading DICOM instances directly from imaging modalities, workstations, or mobile applications to Picture Archiving and Communication Systems (PACS) or Vendor Neutral Archives (VNAs), enabling seamless integration of new medical imaging data into enterprise storage without traditional DICOM network protocols. For successful stores, the response provides Retrieve URLs for the stored instances, allowing immediate access via other DICOMweb services. Warning reasons in responses, such as coercion of data elements (B000) or discarded elements (B006), inform clients of any modifications, ensuring data integrity while accommodating system-specific requirements.[38][37]