Материал: part02

- Standard -​

I.4.2.3.7 Connection Policies​

I.4.2.3.7.1 General​

All standard RS connection policies apply. There are no extensions for RS options.​

I.4.2.3.7.2 Number of Connections​

EXAMPLE-WADO-SERVICE limits the number of simultaneous RS requests. Additional requests will be queued after the HTTP​ connection is accepted. When an earlier request completes, a pending request will proceed.​

Table I.4.2.3-7. Number of Rs Requests Supported​

EXAMPLE-WADO-SERVICE does not support RS asynchronous response.​

I.4.3 Network Interfaces​

I.4.3.1 Physical Network Interface​

EXAMPLE-WADO-SERVICE uses the network interface from the hosting EXAMPLE-PACS-ARCHIVE. See its conformance claim​ for details.​

I.4.3.2 Additional Protocols​

EXAMPLE-WADO-SERVICE uses the network services from the hosting EXAMPLE-PACS-ARCHIVE. See its conformance claim​ for details.​

I.4.3.3 IPv4 and IPv6 Support​

This product supports both IPv4 and IPv6 connections.​

I.4.4 Configuration​

I.4.4.1 HTTP URI Interface​

The EXAMPLE-WADO-SERVICE can be configured to respond on two ports, one for unprotected HTTP traffic and one for TLS pro-​ tected traffic. The TLS port will refuse any connection from a system that is not recognized as authenticated by a known authority.​

I.4.4.2 WS Interface​

DICOM has retired the WADO-WS Service. See PS3.2-2017b. This product still supports this service as described here.​

The EXAMPLE-WADO-SERVICE can be configured to respond on either one or two service endpoints. Each endpoint offers both of​ the services.​

The WSDL file to be used by clients is made available at the location http://<servername>/EXAMPLE-WADO-SERVICE?WSDL.​

I.4.4.3 RS Interface​

The EXAMPLE-WADO-SERVICE can be configured to respond on two ports, one for unprotected HTTP traffic and one for TLS pro-​ tected traffic. The TLS port will refuse any connection from a system that is not recognized as authenticated by a known authority.​

I.5 Media Interchange​

Not applicable​

- Standard -​

I.6 Support of Character Sets​

All EXAMPLE-WADO-SERVICEs support Unicode UTF-8 for all Web Services transactions. The EXAMPLE-WADO-SERVICE does​ not convert character sets when returning SOP Instances using DICOM encoding. The original DICOM encoded character sets are​ preserved. When a PDF encoding is returned, character set conversion is performed and the PDF is returned with a UTF-8 encoding.​ JPEG renderings, will also utilize UTF-8 encoding for internal labels.​

See conformance claim for EXAMPLE-PACS-ARCHIVE for character sets used within the DICOM instances.​

I.7 Security​

EXAMPLE-WADO-SERVICE supports transport level security measures for all Web Services.​

The EXAMPLE-WADO-SERVICE supports the following transport level security measures:​

•​HTTP BASIC Authorization over SSL​

•​Digest Authorization​

•​SSL Client Certificates​

Thetransportlevelsecuritymeasuresarethesupportforbi-directionalauthenticationusingTLSconnections.TheEXAMPLE-WADO-​ SERVICE can provide it's certificate information, and can be configured with either a direct comparison (self-signed) certificate or a​ chain of trust certificate.​

The EXAMPLE-WADO-SERVICE will refuse a connection over TLS from a source that does not have a recognized authentication.​ For example, a certificate authenticated by "Big Bank Corp." will not be accepted unless the EXAMPLE-WADO-SERVICE has been​ configured to accept authentications from "Big Bank Corp." The list of acceptable certificates for EXAMPLE-WADO-SERVICE is not​ shared with certificates used by other system applications and must be maintained independently.​

The EXAMPLE-WADO-SERVICE can optionally be configured to support the following session authentication mechanisms:​

•​Kerberos Local Domain Sessions​

•​Shibboleth Cross Domain Sessions (using SAML2.0)​

I.8 Annexes​

I.8.1 IOD Contents​

See Conformance claim for the EXAMPLE-PACS-ARCHIVE.​

I.8.3 Coded Terminology and Templates​

See conformance claim for EXAMPLE-PACS-ARCHIVE​

I.8.4 Grayscale Image Consistency​

The EXAMPLE-WADO-SERVICE assumes that the JPEG images will be displayed with monitors calibrated to the sRGB profile when​ rendering images.​

I.8.5 Standard Extended / Specialized / Private SOP Classes​

See conformance claim for EXAMPLE-PACS-ARCHIVE​

I.8.6 Private Transfer Syntaxes​

If you request a DICOM object, it will not be returned in a private transfer syntax.​

- Standard -​

J Conformance Statement Sample STOW​

Service (Informative)​

Disclaimer:​

This document is an example DICOM Conformance Statement for a fictional application service called EXAMPLE-STOW-SERVICE​ produced by a fictional vendor called EXAMPLE-PACS-PRODUCTS.​

As stated in the annex title, this document is truly informative, and not normative. A conformance statement of an actual product might​ implement additional services and options as appropriate for its specific purpose. In addition, an actual product might implement the​ servicesdescribedinadifferentmannerand,forexample,withdifferentcharacteristicsand/orsequencingofactivities.Inotherwords,​ this conformance statement example does not intend to standardize a particular manner that a product might implement DICOM​ functionality.​

J.0 Cover Page​

Company Name: EXAMPLE-PACS-PRODUCTS-VENDOR​

Product Name: EXAMPLE-STOW-SERVICE​

Version: 1.0-rev. A.1​

Internal document number: 1024-1960-xx-yy-zz rev 1​

Date: YYYYMMDD​

J.1 Conformance Statement Overview​

This fictional product EXAMPLE-STOW-SERVICE implements the STOW-RS services for storing DICOM SOP Instances into an​ EXAMPLE-PACS-ARCHIVE.TheEXAMPLE-STOW-SERVICEisonlyavailableasapluginoptionfortheEXAMPLE-PACS-ARCHIVE.​ All of the networking, database, and other services are provided by the EXAMPLE-PACS-ARCHIVE. This conformance claim refers​ to the conformance claim for the EXAMPLE-PACS-ARCHIVE for all such services.​

Table J.1-1 provides an overview of the network services supported by EXAMPLE-STOW-SERVICE.​

Table J.1-1. Network Services​

J.2 Table of Contents​

A table of contents shall be provided to assist readers in easily finding the needed information.​

J.3 Introduction​

J.3.1 Revision History​

Table J.3.1-1. Revision History​

- Standard -​

J.3.2 Audience, Remarks, Terms and Definitions, Basics of DICOM Communication, Abbrevi-​ ations, References​

See example text in Section A.3.​

J.3.3 Additional Remarks for This Example​

ThisdocumentisasampleDICOMConformanceStatementcreatedforDICOMPS3.2.Itistobeusedsolelyasanexampletoillustrate​ howtocreateaDICOMConformanceStatementforaDICOMServiceClassProvider(SCP).Thesubjectofthedocument,EXAMPLE-​ STOW-SERVICE, is a fictional product.​

J.4 Networking​

J.4.1 Implementation Model​

J.4.1.1 Application Data Flow​

Example STOW Service​

Figure J.4.1-1. Application Data Flow Diagram​

The STOW-RS Service Application receives STOW requests from a remote AE. These requests are HTTP POST requests. It is as-​ sociated with the local real-world activity "Store Instances". It converts these requests into internal functions to store the given SOP​ Instances. It returns a summary HTTP status line, including a status code and an associated textual phase, followed by an XML​ message indicating success, warning, or failure for each instance to the requesting remote AE.​

J.4.1.2 Functional Definition of AEs​

J.4.1.2.1 Functional Definition of STOW Service Application​

The reception of a STOW-RS POST request will activate the STOW-RS Service. The storage request is based upon the accept​ headers in the STOW-RS POST request. The response includes an HTTP status line, including a status-code and its associated​ textualphrase,followedbyanXMLmessageindicatingsuccess,warning,orfailureforeachinstancestoredbytheSTOW-RSservice.​

J.4.2 AE Specifications​

This AE complies with Section 10.5 “Store Transaction” in PS3.18, specification for STOW-RS storage.​

- Standard -​