PS-2020a / part17

•​An SCU that completes a step with a different intent and scope in place of a scheduled UPS would cancel the original scheduled​ UPS, listing no work output products, and schedule a new UPS describing what was actually done, and reference the original UPS​ that it replaces in the Replaced Procedure Step Sequence to facilitate monitoring systems "closing the loop".​

•​An SCU that completes multiple steps, scheduled as separate UPS instances (e.g., a dictation & a transcription & a verification),​ as a block would individually report each of them as completed.​

•​An SCU that completes additional unscheduled work in the course of completing a scheduled UPS would either report additional​ procedure codes in the completed UPS, or create one or more new UPS instances to record the unscheduled work.​

GGG.3.2 Complex Procedure Steps​

There are cases where it may be useful to schedule a complex procedure that is essentially a grouping of multiple workitems. Placing​ multiple workitem codes in the Scheduled Workitem Code Sequence is not permitted (partly due to the additional complexities that​ would result related to sequencing, dependency, partial completion, etc.)​

One approach is to schedule separate UPS instances for each of the component workitems and to identify the related UPS instances​ based on their use of a common Study UID or Order Number.​

Another approach is for the site to define a single workitem code that means a pre-defined combination of what would otherwise be​ separate workitems, along with describing the necessary sequencing, dependencies, etc.​

GGG.3.3 Gift Subscriptions​

The UPS Subscription allows the Receiving AE Title to be different than the AE Title of the SCU of the N-ACTION request. This allows​ anSCUtosignupsomeoneelsewhowouldbeinterestedforasubscription.Forexample,areportingworkflowmanagercouldsubscribe​ theRIStoUPSsthereportingworkflowmanagercreatesforradiologystudies,andsubscribetheCIStoUPSsitcreatesforcardiology​ studies. Or a RIS could subscribe the MPPS broker or the order tracking system to the high level UPS instances and save them from​ having independent business logic to determine which ones are significant.​

This can provide an alternative to systems using global subscriptions to stay on top of things. It also has the benefit of providing a​ way to avoid having to "forward" events. All interested SCUs get their events directly from the SCP. Instead of SCU A forwarding​ relevant events to SCU B, SCU A can simply subscribe SCU B to the relevant events.​

- Standard -​

- Standard -​

HHH Transition from WADO to RESTful​ Services (Informative)​

This annex discusses the design considerations that went into the definition of the WADO extension to Web and REST services.​

HHH.1 Request and Response Parameters​

HHH.1.1 Request Parameters​

The WADO-RS and STOW-RS requests have no parameters because data is requested through well defined URLs and content ne-​ gotiation through HTTP headers.​

Table HHH.1-1. Summary of DICOM/Rendered URI Based WADO Parameters​

HHH.1.2 Response Parameters​

HHH.1.2.1 URI WADO-URI​

In the URI based WADO, the response is the single payload returned in the HTTP Get response. It may be the DICOM object in a​ DICOM format or in a rendered format.​

HHH.1.2.2 Retired​

See PS3.17-2017b.​

HHH.1.2.3 WADO-RS​

The WADO-RS Service is a transport service, as opposed to a rendering service, which provides resources that enable machine to​ machine transfers of binary instances, pixel data, bulk data, and metadata. These services are not primarily intended to be directly​ displayable in a browser.​

- Standard -​

In the REST Services implementation:​

•​For the "DICOM Requester", one or more multipart/related parts are returned containing PS3.10 binary DICOM instances of a​ Study, Series, or a single Instance.​

•​For the "Frame Pixel Data Requester", one or more multipart/related parts are returned containing the pixel data of a multi-frame​ SOP Instance.​

•​For the "Bulk Data Requester", one or more multipart/related parts are returned containing the bulk data of a Study, Series or SOP​ Instance.​

•​For the "Metadata Requester", an item is returned containing the XML encoded metadata selected from the retrieved objects​ header as described in the Native DICOM Model defined in PS3.19.​

HHH.1.2.4 STOW-RS​

The STOW-RS Service provides the ability to STore Over the Web using RESTful Services (i.e., HTTP based functionality equivalent​ to C-Store).​

•​For the "DICOM Creator", one or more multipart/related parts are stored (posted to a STOW-RS Service) containing one or more​ DICOM Composite SOP Instances.​

•​Forthe"MetadataandBulkDataCreator",oneormoremultipart/relatedpartsarestored(postedtoaSTOW-RSService)containing​ the XML encoded metadata defined in PS3.19 and one or more parts containing the bulk data of a Study, Series or SOP Instance.​

HHH.2 Web Services Implementation​

The implementation architecture has to maximize interoperability, preserve or improve performance and minimize storage overhead.​

The Web Services technologies have been selected to:​

a.​be firewall friendly and supporting security,​

b.​be supported by and interoperable between multiple development environments, and​

c.​have sufficient performance for both large and small text and for binary data.​

TheWADO-RSresponsewillbeprovidedasalistofXMLand/orbinaryinstancesinamultipart/relatedresponse.Thetypeofresponse​ depends on the media types listed in the Accept header.​

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

HHH.3 Uses for Web Services​

HHH.3.1 General Requirements​

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

HHH.3.2 Analysis of Use Cases​

Examples of use cases / clinical scenarios, as the basis to develop the requirements, include:​

•​Providing access to images and reports from a point-of-service application e.g., EMR.​

•​Following references to significant images used to create an imaging report and displaying those images.​

•​Followingreferences/linkstorelevantimagesandimagingreportsinemailcorrespondenceorclinicalreportse.g.,clinicalsummary.​

•​Providing access to anonymized DICOM images and reports for clinical research and teaching purposes.​

- Standard -​

•​ProvidingaccesstoaDICOMencodedimagingreportassociatedwiththeDICOMIE(patient/study/series/objects)tosupportremote​ diagnostic workflows e.g., urgent medical incidents, remote consultation, clinical training, teleradiology/telemedicine applications.​

•​Providing access to summary or selected information from DICOM objects.​

•​Providing access to complete studies for caching, viewing, or image processing.​

•​Storing DICOM SOP Instances using HTTP over a Network from PACS to PACS, from PACS to VNA, from VNA to VNA, from​ clinical application to PACS, or any other DICOM SCP.​

•​Web clients, including mobile ones, retrieving XML and bulk data from a WADO-RS Service and adding new instances to a study.​

Examples of the use cases described in 1 above are:​

a.​The EMR displays in JPEG one image with annotations on it (patient and/or technique related), based upon information provided​ in a report.​

b.​The EMR retrieves from a "Manifest" document all the referenced objects in DICOM and launches a DICOM viewer for displaying​ them (use case addressed by the IHE XDS-I.b profile).​

c.​The EMR displays in JPEG one image per series with information describing every series (e.g., series description).​

d.​The EMR displays in JPEG all the images of a series with information describing the series as well as every image (e.g., instance​ number and slice location for scanner images).​

e.​The EMR populates in its database for all the instances referred in a manifest (KOS) the relevant information (study ID/UID/Ac-​ cessionNumber/Description/DateTime,seriesUID/Modality/Description/DateTime,instanceUID/InstanceNumber/SliceLocation).​

f.​ The EMR displays patient demographics and image slices in a browser by accessing studies through URLs that are cached and​ rendered in a remote data center.​

g.​A hospital transfers a DICOM Study over a network to another healthcare provider without needing special ports opened in either​ firewall.​

h.​A diagnostic visualization client, during post-processing, adds a series of Instances containing measurements, annotations, or​ reports.​

i.​ A healthcare provider transfers a DICOM Study to a Patient Health Record (PHR) at the request of the patient.​

As an example, the 1c use case is decomposed in the following steps (all the other use cases can be implemented through a similar​ sequence of basic transactions):​

A.​The EMR sends to the DICOM server the list of the objects ("selection"), asking for the object content.​

B.​The DICOM server sends back the JPEG images corresponding to the listed objects.​

C.​TheEMRsendstotheDICOMserverthe"selection"informationforobtainingtherelevantinformationabouttheobjectsretrieved.​

D.​The DICOM server sends back the corresponding information in the form of a "metadata" document, converted in XML.​

HHH.3.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:​

•​Does it prefer the URI based requests, or the web-services based requests.​

•​Does it have the ability to decode and utilize the DICOM PS3.10 format or not.​

•​Does it need the metadata describing the image and its acquisition, and/or does it need an image to be displayed.​

These then become the following technical use cases.​

- Standard -​

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 -​