Материал: part02

K.4.3.2 Additional Protocols​

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

K.4.3.3 IPv4 and IPv6 Support​

This product supports both IPv4 and IPv6 connections.​

K.4.4 Configuration​

K.4.4.1 QIDO-RS Interface​

The EXAMPLE-QIDO-SERVICE can be configured to respond on one port for TLS protected traffic. The TLS port will refuse any​ connection from a system that is not recognized as authenticated by a known authority.​

K.5 Media Interchange​

Not applicable​

K.6 Support of Character Sets​

EXAMPLE-QIDO-SERVICE supports Unicode UTF-8 for all RS transactions.​

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

K.7 Security​

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

•​HTTP BASIC Authorization over SSL​

•​Digest Authorization​

•​SSL Client Certificates​

The transport level security measures support bi-directional authentication using TLS connections. The EXAMPLE-QIDO-SERVICE​ can provide its certificate information, and can be configured with either a direct comparison (self-signed) certificate or a chain of trust​ certificate.​

The EXAMPLE-QIDO-SERVICE will refuse a connection over TLS from a source that does not have a recognized authentication.​ For example, a certificate authenticated by "Big Hospital Provider." will not be accepted unless the EXAMPLE-QIDO-SERVICE has​ beenconfiguredtoacceptauthenticationsfrom"BigHospitalProvider."ThelistofacceptablecertificatesforEXAMPLE-QIDO-SERVICE​ is not shared with certificates used by other system applications and must be maintained independently.​

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

•​Kerberos Local Domain Sessions​

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

•​OAuth 2.0 complying with IHE ITI Internet User Authentication (IUA) Profile​

- Standard -​

- Standard -​

L Conformance Statement Sample​

DICOM-RTV Service Provider (Informative)​

Disclaimer:​

This document is an example DICOM Conformance Statement for a fictional application service called EXAMPLE-RTV-SERVICE​ produced by a fictional vendor called EXAMPLE-IMAGING-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-RTV​ functionality.​

L.0 Cover Page​

Company Name: EXAMPLE-IMAGING-PRODUCTS​

Product Name: EXAMPLE-RTV-SERVICE​

Version: 1.0-rev. A.1​

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

Date: YYYYMMDD​

L.1 Conformance Statement Overview​

This fictional product EXAMPLE-RTV-SERVICE implements the DICOM-RTV services for sending video and associated metadata,​ to be consumed in real-time by other compliant devices. The EXAMPLE-RTV-SERVICE is only available as a plug in option for the​ EXAMPLE-INTEGRATED-MODALITY.Allofthenetworking,database,andotherservicesareprovidedbytheEXAMPLE-INTEGRATED-​ MODALITY.ThisconformanceclaimreferstotheconformanceclaimfortheEXAMPLE-INTEGRATED-MODALITYforallsuchservices.​

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

Table L.1-1. Network Services​

L.2 Table of Contents​

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

L.3 Introduction​

L.3.1 Revision History​

Table L.3.1-1. Revision History​

- Standard -​

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

See example text in Section A.3.​

L.3.3 Additional Remarks for This Example​

ThisdocumentisasampleDICOMConformanceStatementcreatedforDICOMPS3.2.Itistobeusedsolelyasanexampletoillustrate​ how to create a DICOM Conformance Statement for a DICOM-RTV Service Provider. The subject of the document, EXAMPLE-RTV-​ SERVICE, is a fictional product.​

L.4 Networking​

L.4.1 Implementation Model​

L.4.1.1 Application Data Flow​

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

TheDICOM-RTVServiceApplicationprovidesmultipleDICOM-RTVcompliantFlows,transportedinRTPoverIP,thatcanbeconsumed​ by one or multiple other DICOM-RTV Service Application(s).​

L.4.1.2 Functional Definition of AEs​

L.4.1.2.1 Functional Definition of RTV Service Application​

The DICOM-RTV Service is Active when the equipment produces video content.​

L.4.2 AE Specifications​

This AE complies with Section 6.2 “Transport” in PS3.22, specification for DICOM-RTV.​

L.4.2.1 DICOM-RTV Application Entity Specifications​

L.4.2.1.1 SOP Classes​

EXAMPLE-RTV-SERVICE provides Standard Conformance to the following SOP Classes:​

- Standard -​

DICOM PS3.2 2020a - Conformance​ Page 325​

Table L.4.2-1. SOP Classes for DICOM-RTV AE​

The resolution is defined by the equipment configuration, and is reflected in the SDP object.​

L.4.2.1.2 Connection Policies​

L.4.2.1.2.1 General​

The consumer shall get the SDP object on the following URL: http://<local-IP-address-of-the-device>/SDP.​

L.4.2.1.2.2 Number of Connections​

L.4.2.1.2.2​

EXAMPLE-RTV-SERVICE is provided in multicast. The limit of simultaneous connection depends on the local network infrastructure.​

L.4.3 Network Interfaces​

L.4.3.1 Physical Network Interface​

EXAMPLE-RTV-SERVICE uses the network interface from the hosting EXAMPLE-INTEGRATED-MODALITY. See its conformance​ claim for details.​

L.4.3.2 Additional Protocols​

EXAMPLE-RTV-SERVICE uses the network services from the hosting EXAMPLE-INTEGRATED-MODALITY. See its conformance​ claim for details.​

- Standard -​