Figure 5-1 of PS3.1 presents the general communication model of the DICOM Standard, which spans both network (on-line) and storage media interchange (off-line) communications. Application Entities may utilize any of the following transport mechanisms:
-
the DICOM Message Service and Upper Layer Service, which provides independence from specific physical networking communication support and protocols such as TCP/IP,
-
the DICOM Web Service API and HTTP Service, which allows use of common hypertext and associated protocols for transport of DICOM services,
-
the Basic DICOM File Service, which provides access to Storage Media independently from specific physical media storage formats and file structures, or
-
DICOM Real-Time Communication, which provides real-time transport of DICOM metadata based on SMPTE and RTP.
PS3.18 describes the DICOM Web Services, which use the HTTP and HTTPS protocols as their transport medium, as depicted in Figure 7-1.
This Part of the Standard defines DICOM Web Services. Each service allows a user agent to interact with an origin server to manage a set of DICOM Resources. Each DICOM Web Service operates on a set of resources and defines a set of Transactions that operate on those resources. All Transactions are defined in terms of HTTP request/response message pairs.
When used in this Part of the Standard, the term HTTP refers to the family of HTTP protocols including: HTTP/1.1, HTTPS/1.1, HTTP/2, and HTTPS/2, as defined by the relevant IETF RFCs, but does not include HTTP/1.0 or HTTPS/1.0. The HTTP standards are normative for all aspects of HTTP message format and transmission.
There are two general types of DICOM Web Services: URI and RESTful. This distinction is based on the type of web service protocol used to specify resources and transactions.
The URI Web Service retrieves representations of its resources, those resources being Composite SOP Instances (Instance). The URI service defines two transactions that retrieve Instances in different media types. All URI transactions use the query component of the URI in the request message to specify the transaction.
The functionality of the URI Web Service Transactions is similar to, but more limited than, the Retrieve Transaction of the Studies Web Service.
Each RESTful Web Service defines the set of resources, and the transactions that can be applied to those resources.
The defined RESTful Web Services are:
- Studies Web Service
-
Enables a user agent to manage Studies stored on an origin server.
- Worklist Web Service
-
Enables a user agent to manage the Worklist containing Workitems stored on an origin server.
- Non-Patient Instance Web Service
-
Enables a user agent to manage Non-Patient Instances, e.g., Color Palettes, stored on an origin server.