DICOM PS3.18 2024e - Web Services |
---|
This example shows the flow of messages between the user agent and the origin server for the scenario in which 1) the user agent requests storage commitment for two SOP Instances in JSON, 2) the origin server tells the user agent to check for the result of this request later, 3) the user agent checks for the result, and 4) the result provided by the origin server shows that it commits to safely store one of the Instances, while it does not commit to safely store the other Instance.
Step 1 of this scenario involves the user agent sending a POST request for the two Instances with Transaction UID 1.1.99999.20220901 in the HTTP header:
POST/radiology/commitment-requests/1.1.99999.20220901 HTTP/1.1 Host: www.hospital-stmarco Content-Type: application/dicom+json … { "00081199": { "vr": "SQ", "Value": [{ "00081150": { "vr": "UI", "Value": [ "1.2.840.10008.5.1.4.1.1.2" ] }, "00081155": { "vr": "UI", "Value": [ "1.3.12.2.1107.5.99.3.30000012031310075961300000059" ] } }, { "00081150": { "vr": "UI", "Value": [ "1.2.840.10008.5.1.4.1.1.2" ] }, "00081155": { "vr": "UI", "Value": [ "1.3.12.2.1107.5.99.3.30000012031310075961300000060" ] } }] } }
Here, the references to the applicable SOP Instances are in the Referenced SOP Sequence (0008,1199); see Table J.1-1 for the possible structures of the storage commitment request. The SOP Class UID of both the Instances is CT Image (for both Instances, Referenced SOP Class UID (0008,1150) has the value 1.2.840.10008.5.1.4.1.1.2), and the applicable Instances are identified by their respective SOP Instance UIDs (the values of Referenced SOP Instance UID (0008,1155) are 1.3.12.2.1107.5.99.3.30000012031310075961300000059 and …00060) respectively).
In step 2 the origin server returns its response to the request. In this scenario this is the asynchronous case where there is no immediate result (return code 202 Accepted), and where the server also notifies the user agent that it ought to wait at least 300 seconds before making a follow-up request for the result; the synchronous response case would skip steps 2 and 3, and would continue at step 4.
HTTP/1.1 202 Accepted Retry-After: 300 …
In step 3, after waiting the suggested period of time, the user agent GETs the status of the request using the same transaction UID as given in the original request:
GET /radiology/commitment-requests/1.1.99999.20220901 HTTP/1.1 Host: www.hospital-stmarco Content-Type: application/dicom+json …
Step 4 of this scenario involves the origin server returning the result of the storage commitment request. In this case it is the response to the result check as shown in step 3. Note that in case the server initially responds to the POST request of step 1 with the HTTP response status code 200 (the synchronous case) the same result would be returned:
HTTP/1.1 200 OK Content-Length: 842 Content-Type: application/dicom+json; charset=utf-8 { "00081199": { "vr": "SQ", "Value": [{ "00081150": { "vr": "UI", "Value": [ "1.2.840.10008.5.1.4.1.1.2" ] }, "00081155": { "vr": "UI", "Value": [ "1.3.12.2.1107.5.99.3.30000012031310075961300000059" ] } }] }, "00081198": { "vr": "SQ", "Value": [{ "00081150": { "vr": "UI", "Value": [ "1.2.840.10008.5.1.4.1.1.2" ] }, "00081155": { "vr": "UI", "Value": [ "1.3.12.2.1107.5.99.3.30000012031310075961300000060" ] }, "00081197": { "vr": "US", "Value": [ 274 ] } }] } }
The origin server provided 274 as value of the Failure Reason (0008,1197). This is 0112H and means "No such object Instance" (see Section C.14.1.1 in PS3.3 ). Apparently, the SOP Instance identified by SOP Instance UID 1.3.12.2.1107.5.99.3.30000012031310075961300000060 is not on the origin server.
DICOM PS3.18 2024e - Web Services |
---|