PS-2020a / 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 -​

L.4.3.3 IPv4 and IPv6 Support​

This product supports both IPv4 and IPv6 connections.​

L.4.4 Configuration​

L.4.4.1 DICOM-RTV Interface​

The EXAMPLE-RTV-SERVICE is configured to define the following parameters expressed in the SDP object:​

•​the RTP payload type (PT) used for the video is 96​

•​the RTP payload type (PT) used for DICOM-RTV Metadata is 104.​

L.5 Media Interchange​

Not applicable.​

L.6 Support of Character Sets​

All EXAMPLE-RTV-SERVICEs support Unicode UTF-8 for all communications.​

L.7 Security​

Has to be managed at the individual sites and installations.​

L.8 Annexes​

L.8.1 IOD Contents​

SeeconformanceclaimfortheEXAMPLE-INTEGRATED-MODALITY.ThemodulesandfieldscontainedintheDICOM-RTVmetadata​ are reflecting the values of the corresponding ones in the EXAMPLE-INTEGRATED-MODALITY X-Ray Radiofluoroscopic Image​ Storage IOD.​

L.8.2 Data Dictionary of Private Attributes​

No private Attributes are used.​

L.8.3 Coded Terminology and Templates​

See conformance claim for EXAMPLE-INTEGRATED-MODALITY.​

L.8.4 Standard Extended / Specialized / Private SOP Classes​

Not Applicable.​

L.8.5 Private Transfer Syntaxes​

Private transfer syntaxes are not supported.​

- Standard -​

M Conformance Statement Sample​

DICOM-RTV Service Consumer (Informative)​

Disclaimer:​

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

M.0 Cover Page​

Company Name: EXAMPLE-Viewing ÂPRODUCTS​

Product Name: EXAMPLE-RTV-DISPLAY​

Version: 1.0-rev. A.1​

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

Date: YYYYMMDD​

M.1 Conformance Statement Overview​

This fictional product EXAMPLE-RTV-DISPLAY implements the DICOM-RTV services for consuming video, audio and associated​ metadata, provided by another compliant device, and displaying the information in a window on the screen. The EXAMPLE-RTV-​ DISPLAY is only available as a plug in option for the EXAMPLE-INTEGRATED-MODALITY. All of the networking, database, and​ other services are provided by the "SAMPLE DICOM Image Viewer". This conformance claim refers to the conformance claim for the​ "SAMPLE DICOM Image Viewer" for all such services.​

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

Table M.1-1. Network Services​

M.2 Table of Contents​

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

M.3 Introduction​

M.3.1 Revision History​

Table M.3.1-1. Revision History​

- Standard -​

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

See example text in Section A.3.​

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

M.4 Networking​

M.4.1 Implementation Model​

M.4.1.1 Application Data Flow​

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

The DICOM-RTV Service Application consumes one or multiple DICOM-RTV compliant Flows, transported in RTP over IP, that is/are​ provided by one other DICOM-RTV Service Application.​

M.4.1.2 Functional Definition of AEs​

M.4.1.2.1 Functional Definition of RTV Service Application​

TheDICOM-RTVServiceisActivewhenthereal-timedisplayfeatureoftheequipmentisrunningandsomevideoand/oraudiocontent​ is provided.​

M.4.2 AE Specifications​

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

M.4.2.1 DICOM-RTV Application Entity Specifications​

M.4.2.1.1 SOP Classes​

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

- Standard -​

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

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

The resolution is automatically determined based on the one provided by the sent video.​

M.4.2.1.2 Connection Policies​

M.4.2.1.2.1 General​

The URL to be accessed by the equipment to get the SDP object is set by configuration.​

M.4.2.1.2.2 Number of Connections​

EXAMPLE-RTV-DISPLAY is consuming multicast communication.​

M.4.3 Network Interfaces​

M.4.3.1 Physical Network Interface​

M.4.3.1 Physical Network Interface​

- Standard -​

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

EXAMPLE-RTV-DISPLAY uses the network interface from the hosting "SAMPLE DICOM Image Viewer". See its conformance claim​ for details.​

M.4.3.2 Additional Protocols​

EXAMPLE-RTV-DISPLAY uses the network services from the hosting "SAMPLE DICOM Image Viewer". See its conformance claim​ for details.​

M.4.3.3 IPv4 and IPv6 Support​

This product supports both IPv4 and IPv6 connections.​

M.4.4 Configuration​

M.4.4.1 DICOM-RTV Interface​

The EXAMPLE-RTV-DISPLAY uses the network parameters (IP, port…) defined in the SDP.​

M.5 Media Interchange​

Not applicable.​

M.6 Support of Character Sets​

EXAMPLE-RTV-DISPLAY supports only Unicode UTF-8 for all communications.​

M.7 Security​

Has to be managed at the individual sites and installations.​

M.8 Annexes​

M.8.1 IOD Contents​

Not Applicable.​

M.8.2 Data Dictionary of Private Attributes​

No private Attributes are used.​

M.8.3 Coded Terminology and Templates​

Not Applicable.​

M.8.4 Standard Extended / Specialized / Private SOP Classes​

Not Applicable.​

M.8.5 Private Transfer Syntaxes​

Private transfer syntaxes are not supported.​

- Standard -​