Информация в данной публикации была признана технически обоснованной по консенсусу лиц, занимавшихся разработкой и утверждением данного документа на момент его создания. Консенсус не обязательно означает единогласное согласие всех лиц, участвовавших в разработке данного документа.

Стандарты и руководства NEMA, одним из которых является данный документ, разрабатываются в рамках добровольного процесса разработки стандартов на основе консенсуса. Этот процесс объединяет добровольцев и/или привлекает мнения лиц, заинтересованных в теме, охватываемой данной публикацией. Хотя NEMA администрирует процесс и устанавливает правила для обеспечения справедливости при достижении консенсуса, NEMA не составляет документ и не проводит независимое тестирование, оценку или проверку точности или полноты какой-либо информации или обоснованности каких-либо суждений, содержащихся в его стандартах и руководствах.

NEMA не несёт ответственности за любые телесные повреждения, имущественный ущерб или иные убытки любого характера, будь то специальные, косвенные, последовательные или компенсационные, прямо или косвенно возникшие в результате публикации, использования, применения данного документа или доверия к нему. NEMA не гарантирует и не предоставляет никаких гарантий, явных или подразумеваемых, относительно точности или полноты любой информации, опубликованной в данном документе, и не гарантирует, что информация в данном документе будет отвечать каким-либо конкретным целям или потребностям. NEMA не берёт на себя обязательств по гарантированию характеристик продуктов или услуг какого-либо отдельного производителя или продавца на основании данного стандарта или руководства.

Публикуя и предоставляя доступ к данному документу, NEMA не берёт на себя оказание профессиональных или иных услуг от лица какого-либо лица или организации, а также не берёт на себя выполнение каких-либо обязанностей, возложенных на какое-либо лицо или организацию перед третьими лицами. Любой, использующий данный документ, должен опираться на собственное независимое суждение или, в зависимости от обстоятельств, обратиться за консультацией к компетентному специалисту для определения разумной осмотрительности в каждой конкретной ситуации. Информация и иные стандарты по теме, охватываемой данной публикацией, могут быть доступны из других источников, которые пользователь может пожелать привлечь для получения дополнительных взглядов или информации, не охваченных данной публикацией.

NEMA не имеет полномочий и не берёт на себя контроль за соблюдением или обеспечение соответствия содержанию данного документа. NEMA не сертифицирует, не тестирует и не инспектирует продукты, конструкции или установки в целях безопасности или охраны здоровья. Любая сертификация или иное заявление о соответствии любой информации в области безопасности или охраны здоровья в данном документе не может быть приписано NEMA и является исключительно ответственностью лица, выполнившего сертификацию или сделавшего данное заявление.

Настоящий стандарт DICOM был разработан в соответствии с процедурами Комитета по стандартам DICOM.

Стандарт DICOM структурирован как документ, состоящий из нескольких частей, в соответствии с руководящими принципами, установленными в [ISO/IEC Directives, Part 2].

Настоящая Часть стандарта DICOM определяет службу на основе SMPTE ST 2110-10, использующую RTP, для передачи метаданных DICOM (DICOM metadata) в реальном времени. Она предоставляет механизм для передачи метаданных DICOM, связанных с видеопотоком или аудиопотоком, на основе SMPTE ST 2110-20 и SMPTE ST 2110-30, соответственно.

Следующие стандарты содержат положения, которые посредством ссылок в данном тексте составляют положения настоящего Стандарта. На момент публикации были действительны указанные редакции. Все стандарты подлежат пересмотру, и сторонам соглашений, основанных на настоящем Стандарте, рекомендуется изучить возможности применения самых последних редакций стандартов, указанных ниже.

Для целей настоящего Стандарта применяются следующие определения.

В настоящей Части Стандарта используются следующие символы и сокращения.

Рисунок 5-1 в PS3.1 представляет общую модель обмена данными стандарта DICOM, которая охватывает как сетевые (онлайн), так и обмен через носители информации (офлайн) коммуникации. Прикладные объекты (Application Entities) могут использовать любой из следующих транспортных механизмов:

Настоящая Часть описывает связь DICOM в реальном времени, использующую протокол RTP, определённый в [SMPTE ST 2110-10], как показано на Рисунке 6-1a.

Рисунок 6-1a. Модель обмена данными DICOM для связи в реальном времени

6.1 Взаимодействие

Как показано на Рисунке 6-1, устройство может иметь несколько источников (Source), по одному для каждого типа эссенции (Essence), соответствующего типу объемных данных (видео, аудио или медицинские метаданные), причём каждый источник создаёт один или несколько потоков (Flow), представляющих один и тот же контент в различных форматах (высокое разрешение, низкое разрешение, без сжатия, со сжатием с потерями или без потерь и т. д.).

Несколько источников (Source) могут быть объединены в группу источников (Source Group). Конкретное восприятие группы источников — это воплощение (Rendition), определяемое как совокупность синхронизированных по времени потоков (Flow), предназначенных для одновременного воспроизведения (например, аудиоканал хирургической камеры).

Рисунок 6-1. Схема реального мира DICOM-RTV

Стандарт DICOM для видео в реальном времени (DICOM Real-Time Video) определяет механизм обмена метаданными, связанными с видео и/или аудио в реальном времени, исходящими от медицинского устройства визуализации. Механизм предполагает один источник (Source) и один поток (Flow) эссенции метаданных DICOM-видео (DICOM Video Metadata Essence) для каждого видеопотока и один источник и один поток эссенции метаданных DICOM-аудио (DICOM Audio Metadata Essence) для каждого аудиопотока. Дополнительно может присутствовать один источник и один поток для метаданных воплощения DICOM (DICOM Rendition Metadata), связывающих несколько потоков, создаваемых одним устройством.

Взаимодействие должно осуществляться, как показано на Рисунке 6-2.

Рисунок 6-2. Схема взаимодействия

[SMPTE ST 2110-10] обеспечивает функции сквозной сетевой передачи для приложений, передающих данные в реальном времени. Контент передаётся в RTP-сессиях с использованием RTP-пакетов в соответствии с [SMPTE ST 2110-10].

Устройство может предоставлять и/или потреблять контент. Устройство, предоставляющее контент, имеет один или несколько источников (Source), которые могут относиться к разным типам эссенции (Essence) (например, видео и аудио). Источник является источником одного или нескольких потоков (Flow). Несколько потоков, исходящих от одного источника, представляют один и тот же контент в разных разрешениях и/или кодированиях. Это протокол широковещательной/мультикаст-передачи, поэтому устройство предоставляет контент независимо от того, присутствует ли принимающее устройство. Устройство, потребляющее контент, может подписываться/отписываться от доступных потоков.

Контекст и содержимое видео- и/или аудиопотока (Flow) описываются потоком метаданных DICOM (DICOM Metadata Flow), который связан с каждым потоком. Однако один и тот же поток метаданных DICOM может использоваться для описания нескольких потоков, если их содержимое одинаково, а кодирование достаточно близко, чтобы не повлиять на профессиональную интерпретацию. Поток метаданных воплощения DICOM (DICOM Rendition Metadata Flow) может использоваться для связывания нескольких потоков, предоставляемых одним устройством.

Формат DICOM для реального времени (DICOM Real-Time Format) предоставляет средство инкапсуляции в RTP-сеансе набора данных (Data Set), представляющего экземпляр SOP (SOP Instance).

Рисунок 7-1 иллюстрирует инкапсуляцию аудио- или видеонабора данных DICOM в RTP. Байтовый поток набора данных (Data Set) помещается в полезную нагрузку RTP после метаинформации DICOM-RTV. Каждый RTP-сеанс соответствует одному экземпляру SOP (SOP Instance).

Рисунок 7-1. Инкапсуляция набора данных DICOM в RTP

Потоки метаданных и вспомогательных данных обычно содержат персональные данные (Personally Identifiable Information, PII). Видео- и аудиопотоки могут содержать защищаемую информацию. Базовые протоколы SMPTE не определяют никаких механизмов безопасности для обеспечения конфиденциальности, целостности или доступности различных потоков данных. DICOM не определяет никаких дополнений к протоколам SMPTE для обеспечения такой защиты. Авторизация и аутентификация доступа к службе DICOM-RTV обеспечивается конфигурированием. Аутентификация не подтверждается повторно при инициализации базовых протоколов SMPTE, и DICOM не определяет никаких дополнений к протоколам SMPTE для управления доступом, авторизации или аутентификации.

Потенциальные атаки, такие как перехват (eavesdropping), повторное воспроизведение (replay), вставка сообщений, удаление, модификация, атака "человек посередине" (man-in-the-middle) и отказ в обслуживании (denial of service), не были проанализированы. Этот анализ остаётся за отдельными площадками и инсталляциями.

Отдельным площадкам и инсталляциям также необходимо самостоятельно проводить оценку и выбор механизмов безопасности и добавлять защиту по мере необходимости. Скорости передачи данных и жёсткие требования к синхронизации потоков данных требуют тщательного анализа любых добавляемых механизмов безопасности. Существуют механизмы безопасности, работающие на уровне IP и ниже, которые могут удовлетворить предсказуемые сценарии использования, однако недостаточно опыта или данных для того, чтобы DICOM мог дать конкретную рекомендацию.

Реализация, заявляющая о соответствии PS3.22, должна функционировать в соответствии со всеми её обязательными разделами.

Службы DICOM-RTV используются для передачи в реальном времени составных экземпляров SOP (Composite SOP Instance). Все передаваемые составные экземпляры SOP должны соответствовать требованиям, указанным в других Частях Стандарта.

Реализация может соответствовать службам DICOM-RTV, поддерживая роль исходного устройства или принимающего устройства, или обе роли для любой из служб, определённых в PS3.22.

Структура заявлений о соответствии (Conformance Statements) определена в PS3.2.

В своем заявлении о соответствии реализация должна описать деятельность в реальном мире (Real-World Activity), связанную с использованием служб DICOM-RTV, включая любую функциональность прокси между DICOM-RTV и другой службой, предоставляемой через DIMSE-службу или RESTful API (т. е. хранение полученных видео и аудио со связанными метаданными).

Кроме того, документ заявления о соответствии для отправляющего устройства DICOM-RTV должен указывать, каким образом получатели могут получить содержимое объектов SDP, описывающих потоки метаданных и связанные видео- и/или аудиопотоки.