Материал: 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 -​