The information in this publication was considered technically sound by the consensus of persons engaged in the development and approval of the document at the time it was developed. Consensus does not necessarily mean that there is unanimous agreement among every person participating in the development of this document.

NEMA standards and guideline publications, of which the document contained herein is one, are developed through a voluntary consensus standards development process. This process brings together volunteers and/or seeks out the views of persons who have an interest in the topic covered by this publication. While NEMA administers the process and establishes rules to promote fairness in the development of consensus, it does not write the document and it does not independently test, evaluate, or verify the accuracy or completeness of any information or the soundness of any judgments contained in its standards and guideline publications.

NEMA disclaims liability for any personal injury, property, or other damages of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the publication, use of, application, or reliance on this document. NEMA disclaims and makes no guaranty or warranty, expressed or implied, as to the accuracy or completeness of any information published herein, and disclaims and makes no warranty that the information in this document will fulfill any of your particular purposes or needs. NEMA does not undertake to guarantee the performance of any individual manufacturer or seller's products or services by virtue of this standard or guide.

In publishing and making this document available, NEMA is not undertaking to render professional or other services for or on behalf of any person or entity, nor is NEMA undertaking to perform any duty owed by any person or entity to someone else. Anyone using this document should rely on his or her own independent judgment or, as appropriate, seek the advice of a competent professional in determining the exercise of reasonable care in any given circumstances. Information and other standards on the topic covered by this publication may be available from other sources, which the user may wish to consult for additional views or information not covered by this publication.

NEMA has no power, nor does it undertake to police or enforce compliance with the contents of this document. NEMA does not certify, test, or inspect products, designs, or installations for safety or health purposes. Any certification or other statement of compliance with any health or safety-related information in this document shall not be attributable to NEMA and is solely the responsibility of the certifier or maker of the statement.

This DICOM Standard was developed according to the procedures of the DICOM Standards Committee.

The DICOM Standard is structured as a multi-part document using the guidelines established in [ISO/IEC Directives, Part 2].

This Part of the DICOM Standard specifies an SMPTE ST 2110-10 based service, relying on RTP, for the real-time transport of DICOM metadata. It provides a mechanism for the transport of DICOM metadata associated with a video or an audio flow based on the SMPTE ST 2110-20 and SMPTE ST 2110-30, respectively.

The following standards contain provisions that, through reference in this text, constitute provisions of this Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibilities of applying the most recent editions of the standards indicated below.

For the purposes of this Standard the following definitions apply.

The following symbols and abbreviations are used in this Part of the Standard.

Figure 5-1 in PS3.1 presents the general communication model of the DICOM Standard, which spans both network (on-line) and storage media interchange (off-line) communications. Application Entities may utilize any of the following transport mechanisms:

This Part describes the DICOM Real-Time Communication, which uses the RTP protocol as defined in [SMPTE ST 2110-10], as depicted in Figure 6-1a.

Figure 6-1a. DICOM Communication Model for Real-Time Communication

6.1 Interaction

As shown in Figure 6-1, a device can have multiple Sources, one for each Essence which corresponds of the type of bulk data (video, audio or medical metadata), each Source producing one or multiple Flows representing the same content in different formats (high definition, low definition, uncompressed, compress with or without loss, …).

Several Sources may be grouped in a Source Group. A concrete experience of a Source Group is a Rendition, defined as a collection of time-synchronized Flows intended for simultaneous presentation (e.g., the audio channel of a surgical camera).

Figure 6-1. Real World diagram of DICOM-RTV

DICOM Real-Time Video standard specifies the communication mechanism for metadata, associated with real-time video and/or audio, originated from a medical imaging device. The mechanism involves one Source and one Flow of "DICOM Video Metadata Essence" for each video Flow and one Source and one Flow of "DICOM Audio Metadata Essence" for each audio Flow. Optionally, there is one Source and one Flow for the "DICOM Rendition Metadata" associating multiple Flows produced by the same device.

The interaction shall be as shown in Figure 6-2.

Figure 6-2. Interaction Diagram

[SMPTE ST 2110-10] provides end-to-end network transport functions for applications transmitting real-time data. Content is transmitted in RTP sessions using RTP packets respecting [SMPTE ST 2110-10].

A device can provide and/or consume content. A device that provides content has one or more Sources that can be of different Essences (e.g., Video and Audio). A Source is the origin of one or more Flows. Multiple Flows coming from the same Source are representations of the same content in different resolutions and/or codings. This is a broadcast/multicast protocol, so a device provides content whether or not a consuming device is present. A device that consumes content can subscribe/unsubscribe to available Flows.

The context and content of a video and/or audio Flow is described by a DICOM Metadata Flow, which is associated with each Flow. However the same DICOM Metadata Flow may be used to describe more than one Flow if their content is the same and their coding are close enough not to affect professional interpretation. A DICOM Rendition Metadata Flow may be used to associate multiple Flows provided by one device.

The DICOM Real-Time Format provides a means to encapsulate in an RTP session the Data Set representing a SOP Instance.

Figure 7-1 illustrates the encapsulation of a DICOM audio or video dataset in RTP. The byte stream of the Data Set is placed into the RTP Payload after the DICOM-RTV Meta Information. Each RTP session corresponds to a single SOP Instance.

Figure 7-1. DICOM Dataset Encapsulation Within RTP

The metadata and ancillary streams usually contain Personally Identifiable Information (PII). The video and audio streams might contain protected information. The underlying SMPTE protocols do not specify any security protections to ensure confidentiality, integrity, or availability of the various data streams. DICOM does not specify any additions to the SMPTE protocols to provide such protection. Authorization and authentication of access to the DICOM-RTV Service is handled by configuration. Authentication is not re-confirmed at initiation of the underlying SMPTE protocols, and DICOM does not specify any additions to the SMPTE protocols for access control, authorization, or authentication.

The potential eavesdropping, replay, message insertion, deletion, modification, man-in-the-middle and denial of service attacks have not been analyzed. That analysis is up to the individual sites and installations.

Individual sites and installations will also need to perform their own assessments and selection of security mechanisms and add protections as necessary. The data rates and strict timing requirements for the data streams require careful analysis of any security mechanisms that are added. There do exist security mechanisms that operate at and below the IP level that can meet foreseen use cases, but there is insufficient experience or evidence to justify DICOM making a recommendation.

An implementation claiming conformance to PS3.22 shall function in accordance with all its mandatory sections.

DICOM-RTV Services are used to transmit in real-time Composite SOP Instances. All Composite SOP Instances transmitted shall conform to the requirements specified in other Parts of the Standard.

An implementation may conform to the DICOM-RTV Services by supporting the role of origin device or receiving device, or both, for any of the Services defined in PS3.22.

The structure of Conformance Statements is specified in PS3.2.

An implementation shall describe in its Conformance Statement the Real-World Activity associated with its use of DICOM-RTV Services, including any proxy functionality between a DICOM-RTV and another service provided through DIMSE Service or RESTful (i.e.; storage of received video and audio with associated metadata).

In addition, the Conformance Statement document for a DICOM-RTV sending device shall specify how the receivers can get the content of the SDP objects describing the metadata and associated video and/or audio flows.