Материал: part17

certain thickness (specified in specific DICOM tags) and frame of reference to be returned. The software then uses this information​ to retrieve, using the WADO-RS service, the appropriate DICOM objects needed to prepare the rendered volume for display.​

HHH.4.2.6 Mobile Device Access​

A General Practitioner (GP) has left the medical ward for a few hours, and is paged with a request to look at a patient X-Ray image​ inordertograntadischarge.TheGPcarriesasmartphonethathasbeenpre-loadedwithcredentialsandsecured.Thedevicemakes​ aQIDOrequesttotheserver,tolookforstudiesfromthelasthourthatlisttheGPastheReferringPhysician.TheGPisabletoretrieve​ and view the matching studies, and can make a determination whether to return to the ward for further review or to sign the discharge​ order using the phone.​

HHH.4.3 Description of The Use Cases​

The use cases described above in terms of clinical scenarios correspond to the following technical implementation scenarios. In each​ case the use is distinguished by the capabilities of the requesting system:​

a.​Does it prefer XML or JSON results?​

b.​Does it need to perform searches at the Series and Instance level or can it process the full Study metadata?​

c.​What Attributes does it need to search against?​

d.​What Attributes does it need for each matching Study, Series or Composite Instance?​

These questions can be applied to the use cases:​

a.​Search from EMR​

1.​JSON or XML​

2.​Study​

3.​Study Instance UID, Patient ID​

4.​Accession Number, Issuer of Accession Number, Study Description, Study Date, Modality, Number of Series, Number of​ Instances​

b.​Populating FHIR resources​

1.​JSON or XML​

2.​Study, Series and Instance​

3.​Patient ID and Issuer of Patient ID​

4.​AllAttributesrequiredbytheFHIRImagingStudyResource(seehttp://www.hl7.org/implement/standards/fhir/imagingstudy.htm)​

c.​Worklist in Viewer​

1.​JSON or XML​

2.​Study​

3.​Study Instance UID, Patient ID, Issuer of Patient ID​

4.​Series Instance UIDs, SOP Instance UIDs, patient demographics, Study Description, Study Date, Modality, Referring​ Physician​

d.​Study Import Duplication Check​

1.​JSON or XML​

2.​Study​

- Standard -​

3.​Study Instance UID, Series Instance UID, SOP Instance UID​ 4.​Study Instance UID​

e.​Multiple System Query​ 1.​JSON or XML​ 2.​Study​

3.​Patient ID, Issuer of Patient ID, Patient Name, Patient Date of Birth​

4.​Study Instance UID, Accession Number, Study Description, Study Date, Modalities in Study​ f.​ Clinical Reconstruction​

1.​JSON or XML​ 2.​Study, Series, Instance​

3.​Study Instance UID, Series Instance UID​ 4.​SOP Instance UID, Image Instance Level Attributes​

g.​Mobile Device Access​ 1.​JSON​

2.​Study, Series and Instance​

3.​Patient ID, Issuer of Patient ID, Patient Name, Patient Date of Birth, Study Date, Referring Physician​ 4.​Instance Date/time, Modalities in Study​

These then become the following technical use cases.​

HHH.4.3.1 XML Study Search Use Case​

A.​The requesting web-based application can make QIDO-RS requests, parse XML and then make WADO-RS requests​ B.​The request specifies:​

1.​Multipart XML​

2.​Search parameters, including:​ a.​Patient ID​

b.​Issuer of Patient ID​ c.​Patient Name​ d.​Study Description​ e.​Study Date​

f.​ Modalities in Study​ g.​Referring Physician​ h.​etc.​

C.​The Response provides​

- Standard -​

1.​One PS3.19 XML NativeDicomModel element for each matching Study​ 2.​All requested DICOM Attributes for each matching Study​ 3.​WADO-RS Retrieve URL for each matching Study​

D.​The requesting system identifies the Studies of interest and uses WADO-RS to retrieve data​

HHH.4.3.2 XML Study, Series and Instance Search Use Case​

A.​The requesting system is a simple web-based application that can make QIDO-RS requests and parse XML and then make​ WADO URL requests​

B.​The request specifies:​ 1.​Multipart XML​

2.​Search parameters, including:​ a.​Patient ID​

b.​Issuer of Patient ID​ c.​Patient Name​ d.​Patient Date of Birth​ e.​Study Description​ f.​ Study Date​ g.​Modalities in Study​ h.​Referring Physician​

C.​The Response provides​

1.​One PS3.19 XML NativeDicomModel element for each matching Study​ 2.​All requested DICOM Attributes for each matching Study​

D.​The requesting system identifies the Study of interest and uses Search For Series to identify a series of interest​ E.​[repeat B-D for Series, Instance]​

F.​The requesting system uses WADO URL to retrieve specific instances​

HHH.4.3.3 JSON Use Case​

A.​TherequestingsystemisamobileapplicationthatcanmakeQIDO-RSrequests,parseJSONandthenmakeWADOURLrequests.​ B.​The request specifies:​

1.​JSON​

2.​Search parameters, including:​ a.​Patient ID​

b.​Issuer of Patient ID​ c.​Patient Name​ d.​Patient Date of Birth​

- Standard -​

e.​Study Description​

f.​ Study Date​

g.​Modalities in Study​

h.​Referring Physician​

C.​The Response provides​

1.​One DICOM JSON element containing all matching Studies​

2.​All requested DICOM Attributes for each matching Study​

D.​The requesting system identifies the Study of interest and uses Search For Series to identify a series of interest​

E.​[repeat B-D for Series, Instance]​

F.​The requesting system uses WADO URL to retrieve specific instances​

HHH.5 Retired​

See PS3.17-2017b.​

HHH.6 Retired​

See PS3.17-2017b.​

HHH.7 Uses for Server Options Services​

Clients would like to be able to discover a list of devices that support DICOM RESTful services and query a DICOM RESTful service​ to determine which options are supported, such as:​

•​Supported services and transactions​

•​Supported Transfer Syntaxes and Media Types​

•​Supported Accept header values​

•​Supported query parameters​

HHH.7.1 WADL Example (XML)​

The following WADL XML example contains all the required elements for an origin-server that supports WADO-RS, QIDO-RS and​ STOW-RS with all required services and parameters.​

<application xsi:schemaLocation="http://wadl.dev.java.net/2009/02 wadl.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://wadl.dev.java.net/2009/02">

<resources base="http://medical.examplehospital.org/dicomweb"> <resource path="studies">

<method name="GET" id="SearchForStudies"> <request>

<param name="Accept" style="header" default="type=application/dicom+json">

<option value="multipart/related; type=application/dicom+xml" /> <option value="application/dicom+json" />

</param>

<param name="Cache-control" style="header"> <option value="no-cache" />

</param>

- Standard -​

<param name="limit" style="query" /> <param name="offset" style="query" /> <param name="StudyDate" style="query" /> <param name="00080020" style="query" /> <param name="StudyTime" style="query" /> <param name="00080030" style="query" />

<param name="AccessionNumber" style="query" /> <param name="00080050" style="query" />

<param name="ModalitiesInStudy" style="query" /> <param name="00080061" style="query" />

<param name="ReferringPhysicianName" style="query" /> <param name="00080090" style="query" />

<param name="PatientName" style="query" /> <param name="00100010" style="query" /> <param name="PatientID" style="query" /> <param name="00100020" style="query" />

<param name="StudyInstanceUID" style="query" repeating="true" /> <param name="0020000D" style="query" repeating="true" />

<param name="StudyID" style="query" /> <param name="00200010" style="query" />

<param name="includefield" style="query" repeating="true"> <option value="all" />

</param>

</request>

<response status="200">

<param name="Warning" style="header"

fixed="299 {SERVICE}: The fuzzymatching parameter is not supported. Only literal matching has been performed." />

<representation mediaType="multipart/related; type=application/dicom+xml" /> <representation mediaType="application/dicom+json" />

</response>

<response status="400 401 403 413 503" /> </method>

<method name="POST" id="StoreInstances"> <request>

<param name="Accept" style="header" default="application/dicom+xml"> <option value="application/dicom+xml" />

</param>

<representation mediaType="multipart/related; type=application/dicom" /> <representation mediaType="multipart/related; type=application/dicom;

transfer-syntax=1.2.840.10008.1.2.1" /> <representation mediaType="multipart/related; type=application/dicom+xml" /> </request>

<response status="202 409">

<representation mediaType="application/dicom+xml" /> </response>

<response status="400 401 403 503" /> </method>

<resource path="{StudyInstanceUID}"> <method name="GET" id="RetrieveStudy"> <request>

<param name="Accept" style="header" default="multipart/related; type=application/dicom">

<option value="multipart/related; type=application/dicom" /> <option value="multipart/related; type=application/dicom;

transfer-syntax=1.2.840.10008.1.2.1" /> <option value="multipart/related; type=application/octet-stream" /> </param>

</request>

<response status="200 206">

- Standard -​