Материал: part17

HHH.3.3.1 URI Based WADO Use Case​

A.​The requesting system is Web Browser or other application that can make simple HTTP/HTTPS requests,​

B.​Reference information is provided as URL or similar information that can be easily converted into a URL.​

C.​The request specifies:​

1.​Individual SOP Instance​

2.​Desired format and subset selection for information to be returned​

D.​The Response provides​

1.​SOP instance, reformatted and subset as requested. This may be encoded as a DICOM PS3.10 instance, or rendered into​ a generic image format such as JPEG.​

HHH.3.3.2 DICOM (Encoded Content) Requester​

A.​TherequestingsystemisanapplicationcapableofmakingWebServicerequestsandabletoprocessdataencodedasaDICOM​

File, per DICOM PS3.10 encodings.​

B.​Reference information may come in a wide variety of forms. It is expected to include at least the Study UID, Series UID, and In-​ dividual SOP instance information. This may be encoded as part of an HL7 reference within a CDA document, a DICOM SOP​ Instance reference, or other formats.​

C.​The request specifies​

1.​Requested Data set​

a.​Study UID​

b.​List of Series UID​

c.​List of SOP Instance UIDs​

2.​Optionally, it may also specify subset information​

a.​Instance and Frame Level Retrieve SOP classes subset information for selecting frames​

b.​No-pixel data request (using the Transfer Syntax parameter)​

c.​Anonymization​

D.​The response provides​

1.​SOP Instances, encoded per DICOM PS3.10.​

HHH.3.3.3 Rendered (JPEG/PDF) Requester​

A.​The requesting system: application capable of making Web Service requests. System is not capable of decoding DICOM PS3.10​ formats. The system is capable of processing images in JPEG or other more generic formats.​

B.​Reference information may come in a wide variety of forms. It is expected to include at least the Study UID, Series UID, and In-​ dividual SOP instance information. This may be encoded as part of an HL7 reference within a CDA document, a DICOM SOP​ Instance reference, or other formats.​

C.​Request information​

1.​Requested Data set​

a.​Study UID​

- Standard -​

b.​List of Series UID​ c.​List of SOP Instance UIDs​

2.​Desired format and subset information​

a.​JPEG/PDF/etc. selection, subset area, presentation information​ b.​Frame selection for subsets of multi-frame objects​

c.​What should be done for requests where image shapes and SOP classes vary and a subset is requested?​ d.​Anonymize or not.​

D.​Response information​ 1.​JPEGs​

a.​Should JPEGs include tag information within the JPEG? If so, what information?​ b.​How will JPEGs be related to multi-frame and multi-instance requests? Order? Tag?​

2.​PDFs​

a.​How will PDFs be related to multi-frame and multi-instance requests? One per frame? One per instance? One for entire​ set?​

3.​Other encodings?​

HHH.3.3.4 Metadata (XML Without Pixel Data, Waveform Data, etc.) Requester​

A.​The requesting system: application capable of making Web Service requests. The requesting System is not capable of decoding​ DICOM PS3.10 formats. The system is capable of processing metadata that describes the image, provided that the metadata is​ encoded in an XML format. The system can be programmed based upon the DICOM definitions for XML encoding and Attribute​ meanings.​

B.​Reference information may come in a wide variety of forms. It is expected to include at least the Study UID, Series UID, and In-​ dividual SOP instance information. This may be encoded as part of an HL7 reference within a CDA document, a DICOM SOP​ Instance reference, or other formats.​

C.​Request information​

1.​Requested Data set​

a.​Study UID​

b.​List of Series UID​

c.​List of SOP Instance UIDs​

2.​Desired format and subset information​

a.​XPath definition for subset or total metadata selection​

b.​What should be done when SOP classes vary and a subset is requested? The XPath will fail.​

c.​Frame selection for subsets of multi-frame objects​

d.​Anonymize or not.​

e.​Response information​

D.​Response information​

- Standard -​

1.​XML encoded metadata.​

HHH.3.3.5 DICOM Requester​

A.​TherequestingsystemisanapplicationcapableofmakingHTTPServicerequestsandabletoprocessdataencodedasaDICOM​

File, per DICOM PS3.10 encodings.​

B.​Requesting information for DICOM Instances may come from a wide variety of forms. It is expected to include at least the Study​ UID. This may be encoded as part of an HL7 reference within a CDA document, a DICOM SOP Instance reference, or other​ formats.​

C.​The request specifies​

1.​Requested Data set​

a.​Study UID​

2.​Optionally, it may also specify subset information​

a.​Series UID​

b.​SOP Instance UID​

D.​The response provides​

1.​SOP Instances, encoded per DICOM PS3.10.​

HHH.3.3.6 Frame Pixel Data Requester​

A.​The requesting system is an application capable of making HTTP requests and able to process pixel data.​

B.​Requesting information for pixel data may come in a wide variety of forms. It is expected to include at least the Study UID, Series​ UID, Individual SOP Instance, and Frame List information. This may be encoded as part of an HL7 reference within a CDA doc-​ ument, a DICOM SOP Instance reference, or other formats.​

C.​The request specifies​

1.​Requested Data set​

a.​Study UID​

b.​Series UID​

c.​SOP Instance UID​

d.​Frame List comprised of one or more frame numbers​

D.​The response provides pixel data​

HHH.3.3.7 Bulk Data Requester​

A.​The requesting system is an application capable of making HTTP requests and able to process bulk data.​

B.​Requestinginformationforbulkdatamaycomeinawidevarietyofforms.ItisexpectedtoincludetheBulkDataURLasprovided​ by the RetrieveMetadata resource. This may be encoded as part of an HL7 reference within a CDA document, a DICOM SOP​ Instance reference, or other formats.​

C.​The request specifies​

1.​Requested Data set​

a.​Bulk Data URL​

- Standard -​

D.​The response provides bulk data​

HHH.3.3.8 Metadata Requester​

A.​The requesting system is an application capable of making HTTP requests and able to process data encoded as a XML, per​ DICOM PS3.19 encodings.​

B.​The Study UID may be obtained as part of an HL7 reference within a CDA document, a DICOM SOP Instance reference, or​ other formats.​

C.​Request information​

1.​Requested Data set​

a.​Study UID​

D.​The response provides full study metadata encoded in XML, encoded per DICOM PS3.19.​

HHH.3.3.9 DICOM Creator​

A.​The requesting system is an application capable of making HTTP Service requests and able to process data encoded as PS3.10​

binary instances.​

B.​The request specifies​

1.​The STOW-RS Service to store POST requests.​

2.​Optionally, it may also specify Study Instance UID indicating all POST requests are for the indicated study.​

3.​SOP Instances, per DICOM PS3.10 encoding.​

C.​The response is a standard HTTP status line and an XML response message body. The meaning of the success, warning, or​ failure statuses are defined in PS3.18.​

HHH.3.3.10 Metadata and Bulk Data Creator​

A.​The requesting system is an application capable of making HTTP requests and able to process data encoded as PS3.19 XML​ metadata.​

B.​The request specifies​

1.​The STOW-RS Service to store POST requests.​

2.​Optionally, it may also specify Study Instance UID indicating all POST requests are for the indicated study.​

3.​XML metadata, per DICOM PS3.19 encodings, and bulk data.​

C.​The response is a standard HTTP status line and an XML response message body. The meaning of the success, warning, or​ failure statuses are defined in PS3.18.​

HHH.4 Uses For QIDO Services​

HHH.4.1 General Requirements​

Imaging information is important in the context of EMR/EHR. But EMR/EHR systems often do not support DICOM service classes.​ The EMR/EHR vendors need access using web and web service technologies to satisfy their users.​

HHH.4.2 Analysis of Use Cases​

Examples of use cases / clinical scenarios, used as the basis for the development of the QIDO-RS requirements, include:​

- Standard -​

a.​Search from EMR​ b.​Populating FHIR resources​ c.​Worklist in Viewer​

d.​Study Import Duplication Check​ e.​Multiple System Query​

f.​ Clinical Reconstruction​ g.​Mobile Device Access​

HHH.4.2.1 Search From EMR​

A General Practitioner (GP) in a clinic would like to check for imaging studies for the current patient. These studies are stored in a​ PACS, Vendor Neutral Archive (VNA) or HIE that supports QIDO functionality. The GP launches an Electronic Medical Record (EMR)​ application, and keys in the patient demographics to search for the patient record within the EMR. Once the record is open, the EMR,​ using QIDO, makes requests to the back-end systems, supplying Patient ID (including issuer) and possibly other parameters (date​ of birth, date range, modality, etc.). That system returns the available studies along with meta-data for each study that will help the​ GPselectthestudytoopen.Themeta-datawouldinclude,butisnotlimitedto,StudyDescription,StudyDate,Modality,andReferring​ Physician.​

HHH.4.2.2 Populating FHIR Resources​

HL7 has introduced FHIR (Fast Healthcare Interoperability Resources) as a means of providing access to healthcare informatics in-​ formation using RESTful web services.​

While FHIR will not replicate the information contained in a PACS or other medical imaging storage system, it is desirable for FHIR​ to present a view of the medical imaging studies available for a particular patient along with the means of retrieving the imaging data​ using other RESTful services.​

HHH.4.2.3 Worklist in Viewer​

A Radiologist, is reading studies in the office, using software that maintains diagnostic orders for the facility. This system produces​ the radiology worklist of studies to be read and provides meta-data about each scheduled procedure, including the Study Instance​ UID. When the next study is selected to be read on the worklist, the system, using the Study Instance UID, makes a QIDO request​ to the local archive to discover the instances and relevant study meta-data associated with the procedure to display. Subsequent​ QIDO requests are made to the local archive and to connected VNA archives to discover candidate relevant prior studies for that​ patient.​

For each candidate relevant prior, the full study metadata will be retrieved using WADO-RS and processed to generate the list of​ relevant priors.​

HHH.4.2.4 Multiple Systems Query​

A Radiologist is working in a satellite clinic, which has a system with QIDO functionality and small image cache. The main hospital​ withwhichtheclinicisaffiliatedhasasystemwithQIDOfunctionalityandalargehistoricalimagearchiveorVNA.Theviewingsoftware​ displays a worklist of patients, and a study is selected for viewing. The viewer checks for prior studies, by making QIDO requests to​ boththelocalcacheandremotearchiveusingthePatientID,NameandDateofBirth,ifavailable.IfthePatientIdentifierisn'tavailable,​ other means (such as by other demographics, or a Master Patient Index) could be utilized. Any studies that meet relevant prior criteria​ can be pre-fetched.​

HHH.4.2.5 Clinical Reconstruction​

A Neurologist is preparing a surgical plan for a patient with a brain tumor using three-dimensional reconstruction software, which​ takes CT images and builds a 3D model of various structures. After supplying the patient demographics (or Patient Identifier), the​ software requests a list of appropriate studies for reconstruction (based on Study Date, Body Region and Modality). Once the user​ has selected a study and series, the software contacts the QIDO server again, requesting the SOP Instance UIDs of all images of a​

- Standard -​