PS3.1

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

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

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

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

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

Предисловие

Комитет по стандартам DICOM (DICOM Standards Committee) — это независимая международная организация по разработке стандартов, включающая биомедицинские профессиональные общества, специализирующиеся на использовании медицинской визуализации, производителей оборудования для медицинской визуализации и связанных информационных систем, а также правительственные учреждения, торговые ассоциации и другие организации по разработке стандартов, заинтересованные в стандартизации информации о медицинской визуализации и связанных данных. Членство открыто для всех организаций с существенным интересом в работе Комитета. Комитет тесно сотрудничает с другими организациями по разработке стандартов в области медицинской информатики и электротехнического оборудования в медицинской практике. Секретариатом Комитета является Национальная ассоциация производителей электрооборудования (National Electrical Manufacturers Association) и её подразделение «Альянс медицинской визуализации и технологий» (Medical Imaging and Technology Alliance).

Основным продуктом Комитета является настоящий Стандарт — «Цифровая визуализация и связь в медицине» (Digital Imaging and Communications in Medicine, DICOM).

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

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

Стандарт публикуется как стандарт NEMA PS3, а его Части идентифицируются нумерацией публикации NEMA (PS3.1, PS3.2 и т. д.).

DICOM® — зарегистрированный товарный знак Национальной ассоциации производителей электрооборудования (National Electrical Manufacturers Association) в отношении её публикаций стандартов по цифровой передаче медицинской информации, все права защищены.

SNOMED®, SNOMED Clinical Terms®, SNOMED CT® — зарегистрированные товарные знаки Международной организации по разработке стандартов терминологии здравоохранения Organisation (IHTSDO), все права защищены.

1 Область применения и назначения

PS3.1 содержит обзор всего стандарта «Цифровая визуализация и связь в медицине» (Digital Imaging and Communications in Medicine, DICOM). Он описывает историю, область применения, цели и структуру Стандарта. В частности, он содержит краткое описание содержания каждой Части Стандарта.

1.1 Область применения DICOM

«Цифровая визуализация и связь в медицине» (Digital Imaging and Communications in Medicine, DICOM) — это стандарт для обмена информацией и управления данными медицинской визуализации и связанными данными.

Стандарт DICOM обеспечивает интероперабельность оборудования для медицинской визуализации путём задания:

Для сетевого обмена — набор протоколов, которым должны следовать устройства, заявляющие соответствие Стандарту.
Синтаксис и семантика команд (Command) и связанной информации, которая может быть передана с использованием этих протоколов.
Для обмена через носители — набор служб хранения на носителях, которым должны следовать устройства, заявляющие соответствие Стандарту, а также формат файлов (File Format) и структура медицинского каталога для обеспечения доступа к изображениям и связанной информации, хранящейся на носителях для обмена.
Информация, которая должна быть предоставлена с реализацией, для которой заявляется соответствие Стандарту.

Стандарт DICOM не определяет:

Детали реализации любых функций Стандарта на устройстве, заявляющем соответствие.
Общий набор функций и возможностей, ожидаемых от системы, созданной путём интеграции группы устройств, каждое из которых заявляет о соответствии DICOM.
Процедуру тестирования/валидации для оценки соответствия реализации Стандарту.

1.2 Область применения

Стандарт DICOM относится к области медицинской информатики. В этой области он касается обмена цифровой информацией между оборудованием для медицинской визуализации и другими системами. Поскольку такое оборудование может взаимодействовать с другими медицинскими устройствами и информационными системами, область применения данного Стандарта должна пересекаться с другими областями медицинской информатики. Однако Стандарт DICOM не охватывает всю широту этой области.

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

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

1.3 История

С появлением компьютерной томографии (CT) и последующих цифровых методов диагностической визуализации в 1970-х годах и всё более широким использованием компьютеров в клинических приложениях, Американский колледж радиологии (American College of Radiology, ACR) и Национальная ассоциация производителей электрооборудования (National Electrical Manufacturers Association, NEMA) осознали возникающую потребность в стандартном методе передачи изображений и связанной информации между устройствами различных производителей. Эти устройства создают цифровые изображения в различных форматах.

Американский колледж радиологии (ACR) и Национальная ассоциация производителей электрооборудования (NEMA) в 1983 году создали совместный комитет для разработки стандарта, чтобы:

Содействовать обмену цифровой информацией изображений независимо от производителя устройства
Способствовать разработке и развитию систем архивации и передачи изображений (Picture Archiving and Communication Systems, PACS), которые также могут взаимодействовать с другими системами больничной информации
Позволить создавать базы данных диагностической информации, к которым могут обращаться самые разнообразные устройства, географически распределённые.

Публикация стандарта ACR-NEMA № 300-1985, изданная в 1985 году, была обозначена как версия 1.0. За Стандартом последовали две редакции: № 1 от октября 1986 г. и № 2 от января 1988 г. Эти публикации стандартов определяли аппаратный интерфейс, минимальный набор программных команд и единый набор форматов данных.

Публикация стандарта ACR-NEMA № 300-1988, изданная в 1988 году, была обозначена как версия 2.0. Она включала версию 1.0, опубликованные редакции и дополнительные изменения. Она также включала новые материалы для обеспечения поддержки команд устройств отображения, введения новой схемы иерархии для идентификации изображения и добавления элементов данных для большей специфичности при описании изображения.

В 1993 году стандарт ACR-NEMA 300 был существенно переработан и заменён настоящим Стандартом, обозначенным как «Цифровая визуализация и связь в медицине» (Digital Imaging and Communications in Medicine, DICOM). Он воплощает ряд крупных улучшений по сравнению с предыдущими версиями стандарта ACR-NEMA:

Он применим в сетевой среде. Стандарт ACR-NEMA был применим только в среде точка-точка; для работы в сетевой среде требовался сетевой интерфейсный блок (Network Interface Unit, NIU). DICOM поддерживает работу в сетевой среде с использованием промышленного стандартного сетевого протокола TCP/IP.
Он применим для обмена через автономные носители. Стандарт ACR-NEMA не определял формат файла, выбор физических носителей или логической файловой системы. DICOM поддерживает работу в среде автономных носителей с использованием стандартных носителей, таких как CD-R, DVD-R и USB, и распространённых файловых систем.
Это сервис-ориентированный протокол, определяющий семантику команд и связанных данных, а также то, как устройства, заявляющие о соответствии Стандарту, реагируют на команды и обмениваемые данные. Заданные службы включают поддержку управления рабочим процессом отделения визуализации. Стандарт ACR-NEMA ограничивался передачей данных с лишь неявными сервисными требованиями.
Он определяет уровни соответствия. Стандарт ACR-NEMA определял минимальный уровень соответствия. DICOM явно описывает, как разработчик должен структурировать Заявление о соответствии (Conformance Statement) для выбора конкретных параметров.

В 1995 году, с добавлением возможностей DICOM для кардиологической визуализации при поддержке Американского колледжа кардиологии, Объединённый комитет ACR-NEMA был реорганизован в Комитет по стандартам DICOM — широкую коалицию заинтересованных сторон по всем направлениям медицинской визуализации.

1.4 Принципы

1.4.1 Глобальная применимость и локализация

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

Локализация для удовлетворения требований национальной или местной политики в области здравоохранения и рабочих процессов может быть выполнена без отклонения от Стандарта. Такая локализация может включать задание наборов кодов (например, кодов процедур) или профилирование использования элементов данных (как задание локально допустимых значений, так и обязательное использование элементов, являющихся необязательными в Стандарте, для локального применения).

Локализация и профилирование могут задаваться рядом механизмов, выходящих за рамки Стандарта DICOM. Одним из таких механизмов являются Интеграционные профили (Integration Profiles) организации «Интеграция здравоохранения» (Integrating the Healthcare Enterprise, IHE). Важно, чтобы профилирование придерживалось концепции непротиворечия. Профиль может добавлять требования, но не должен противоречить требованиям DICOM, так как это сделало бы невозможным соблюдение как DICOM, так и Профиля.

1.4.2 Непрерывное сопровождение

Стандарт DICOM является развивающимся стандартом, и он поддерживается в соответствии с Процедурами Комитета по стандартам DICOM. Предложения по улучшению приветствуются от всех пользователей Стандарта и могут быть направлены Секретариату. Дополнения и исправления к Стандарту выносятся на голосование и утверждаются несколько раз в год. После утверждения в качестве окончательного текста (Final Text) каждое изменение становится официальным, публикуется отдельно и вступает в силу немедленно. Периодически все утверждённые изменения окончательного текста объединяются и публикуются в обновлённом издании Стандарта. После объединения изменений в обновлённое издание Стандарта отдельные документы об изменениях не поддерживаются; читателям рекомендуется использовать консолидированное издание Стандарта.

Требованием при обновлении Стандарта является сохранение эффективной совместимости с предыдущими изданиями.

Процесс сопровождения может включать изъятие разделов Стандарта.

Изъятие не означает, что эти функции не могут использоваться. Однако Комитет по стандартам DICOM не будет поддерживать документацию по изъятым функциям. Читатель обращается к более ранним изданиям Стандарта.

Использование изъятых функций не рекомендуется для новых реализаций в пользу тех альтернатив, которые остаются в Стандарте.

1.4.3 Информационные объекты и уникальная идентификация объектов

Многие службы DICOM включают обмен постоянными информационными объектами, такими как изображения. Экземпляр такого информационного объекта может быть передан между многими системами и организационными контекстами, а также с течением времени. Хотя в атрибуты экземпляра могут вноситься незначительные изменения для облегчения его обработки в рамках конкретной организации (например, путём приведения идентификатора пациента (Patient ID) к значению, используемому в локальном контексте), семантическое содержание экземпляра не изменяется.

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

1.4.4 Соответствие

Соответствие стандарту DICOM выражается через классы пары сервис-объект (Service-Object Pair, SOP), которые представляют службы (например, хранение с использованием сети, носителей или веб), работающие с типами информационных объектов (например, CT- или MR-изображениями).

Спецификации SOP-классов в стандарте DICOM изменяются только таким образом, которое предназначено для обеспечения прямой и обратной совместимости для всех изданий Стандарта. Требования соответствия и заявления о соответствии поэтому ссылаются на идентификатор SOP-класса и никогда не ссылаются на издание Стандарта.

Для каждой реализации требуется предоставить Заявление о соответствии (Conformance Statement) в соответствии с единой структурой pro forma , облегчающей сравнение продуктов на предмет интероперабельности.

1.4.5 Согласованность информационной модели

Большое число информационных объектов, определённых в стандарте DICOM, следуют общей составной информационной модели с информационными сущностями, представляющими пациента (Patient), исследование (Study), серию (Series), оборудование (Equipment), систему координат (Frame of Reference) и специфический тип данных экземпляра. Эта информационная модель является упрощением реальных концепций и процессов медицинской визуализации; для модальностей сбора данных исследование приблизительно эквивалентно назначенной процедуре, а серия приблизительно эквивалентна выполненному элементу протокола сбора данных. В других областях, таких как лучевая терапия, исследование и серия менее чётко связаны с реальными сущностями или процессами, но по-прежнему требуются для согласованности. Эта упрощённая модель достаточна для практических нужд управления данными визуализации и связанными данными, собираемыми в рутинной практике.

Новые информационные объекты, определяемые в DICOM, обычно соответствуют этой существующей общей информационной модели, что позволяет повторно использовать реализации с минимальными изменениями для поддержки новых объектов.

2 Нормативные ссылки

[ISO/IEC Directives, Part 2] ISO/IEC. 2021. 9.0. Rules for the structure and drafting of International Standards. http://www.iso.org/sites/directives/current/part2/index.xhtml .

[ACR/NEMA 300] ACR/NEMA. 1988. Digital Imaging and Communications.

[EBU-SMPTE-VSF JT-NM Phase 2 Report] European Broadcasting Union (EBU), Society of Motion Picture and Television Engineers (SMPTE), and Video Services Forum (VSF). 2015. v1.0. Joint Task Force on Networked Media (JT-NM) Phase 2 Report- Reference Architecture. https://static.jt-nm.org/RA-1.0/JT-NMReferenceArchitecturev1.0%20150904%20FINAL.pdf .

[ISO/IEC 8822] ISO/IEC. 1994. Information Processing Systems - Open Systems Interconnection - Connection Oriented Presentation Service Definition.

[ISO/IEC 8649] ISO/IEC. 1996. Information Processing Systems - Open Systems Interconnection - Service Definition for the Association Control Service Element. Withdrawn 2012. .

[SMPTE ST 2110-10] Society of Motion Picture and Television Engineers (SMPTE). 2017. Professional Media over IP Networks: System Timing and Definitions.

[SMPTE ST 2110-20] Society of Motion Picture and Television Engineers (SMPTE). 2017. Professional Media over IP Networks: Uncompressed Active Video.

[SMPTE ST 2110-30] Society of Motion Picture and Television Engineers (SMPTE). 2017. Professional Media over IP Networks: PCM Digital Audio.

3 Определения

Attribute: Свойство Information Object. Attribute имеет имя и значение, которые не зависят от какой-либо схемы кодирования.
Command: Запрос на выполнение операции с информацией по сети.
Command Element: Кодирование параметра команды, передающее значение этого параметра.
Command Stream: Результат кодирования набора DICOM Command Elements с использованием схемы кодирования DICOM.
Conformance Statement: Формальное заявление, описывающее конкретную реализацию стандарта DICOM. В нём указываются Service Classes, Information Objects, Communication Protocols, Security Profiles и Media Storage Application Profiles, поддерживаемые реализацией.
Data Dictionary: Реестр DICOM Data Elements, который назначает каждому Data Element уникальный тег, имя, характеристики значения и семантику.
Data Element: Единица информации, определяемая одной записью в словаре данных.
Data Set: Обмениваемая информация, состоящая из структурированного набора Attributes. Значение каждого Attribute в Data Set выражается как Data Element.
Data Stream: Результат кодирования Data Set с использованием схемы кодирования DICOM: номеров Data Element и представлений, заданных Data Dictionary.
Information Object: Абстракция реальной информационной сущности, например CT Image или Structured Report, над которой выполняются одна или несколько DICOM Commands.

Примечание

Этот термин преимущественно используется в PS3.1, с несколькими ссылками в PS3.3. Это неформальный термин, соответствующий формальному термину, введённому в PS3.3. Во всех остальных частях стандарта DICOM этот формальный термин известен как Information Object Definition.
Information Object Class: Формальное описание Information Object, включающее описание его назначения и Attributes, которыми он обладает. Оно не включает значения этих атрибутов.

Примечание

Этот термин используется только в PS3.1. Это неформальный термин, соответствующий формальному термину, введённому в PS3.4. Этот формальный термин известен как класс пары сервис-объект (Service-Object Pair Class) или, чаще, SOP Class.
Information Object Instance: Представление экземпляра реальной сущности, включающее значения Attributes класса Information Object, к которому принадлежит эта сущность.

Примечание

Этот термин используется только в PS3.1. Это неформальный термин, соответствующий формальному термину, введённому в PS3.4. Этот формальный термин известен как Service-Object Pair Instance или, чаще, SOP Instance.
Message: Единица данных Message Exchange Protocol, которой обмениваются два взаимодействующих DICOM Applications. Message состоит из Command Stream, за которым следует необязательный Data Stream.
Part: Раздел стандарта DICOM, охватывающий связанный предметный материал.
Service Class: Структурированное описание службы, поддерживаемой взаимодействующими DICOM Applications с использованием конкретных DICOM Commands, действующих над конкретным классом Information Object.
Класс пары сервис-объект (Service-Object Pair Class, SOP Class): Пара, состоящая из Information Object и либо DIMSE Service Group, либо Media Storage Service, либо Web Service.
Essence: Тип источника видео, аудио или данных, как определено в [EBU-SMPTE-VSF JT-NM Phase 2 Report].
Flow: Последовательность Grains из Source; конкретное представление содержимого, исходящего из Source, как определено в [EBU-SMPTE-VSF JT-NM Phase 2 Report].
Grain: Представляет элемент Essence или другие данные, связанные с конкретным временем, например кадр, группу последовательных аудиосэмплов или субтитры, как определено в [EBU-SMPTE-VSF JT-NM Phase 2 Report].
Rendition: Набор синхронизированных по времени Flows, предназначенных для одновременного представления и обеспечивающих полный опыт Source Group, как определено в [EBU-SMPTE-VSF JT-NM Phase 2 Report].
Source: Абстрактное понятие, представляющее основной источник Flow или набора Flows, как определено в [EBU-SMPTE-VSF JT-NM Phase 2 Report].

4 Символы и сокращения

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

ACSE: Association Control Service Element
Элемент службы управления ассоциацией
API: Application Programming Interface
Интерфейс прикладного программирования
CT: Computed Tomography
DICOM: Digital Imaging and Communications in Medicine
Цифровые изображения и обмен ими в медицине
DICOM-RTV: DICOM Real-Time Video
DIMSE: DICOM Message Service Element
HIS: Hospital Information System
HTTP: Hyper-Text Transfer Protocol
HTTPS: Hyper-Text Transfer Protocol Secure
Защищённый протокол передачи гипертекста
JIRA: Japan Medical Imaging and Radiological Systems Industries Association
Японская ассоциация индустрии медицинской визуализации и радиологических систем
OSI: Open Systems Interconnection
PACS: Picture Archiving and Communication Systems
Системы архивирования и передачи изображений
PTP: Precision Time Protocol
REST: Representational State Transfer
Передача репрезентативного состояния
RESTful: RESTful Web service — это веб-служба, реализованная с использованием архитектуры REST и HTTP (см. http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf).
RIS: Radiology Information System
RTP: Real-Time Transport Protocol
SMPTE: Society of Motion Picture and Television Engineers
Общество инженеров кино и телевидения
STOW-RS: STore Over the Web by RESTful Services
Сохранение через веб с использованием RESTful Services
TCP/IP: Transmission Control Protocol/Internet Protocol
Протокол управления передачей / интернет-протокол
WADO-RS: Web Access to DICOM Objects by RESTful Services
Веб-доступ к объектам DICOM с использованием RESTful Services
WADO-URI: Web Access to DICOM Objects by URI
Веб-доступ к объектам DICOM по URI

5 Модель обмена данными DICOM

Стандарт DICOM обеспечивает интероперабельность устройств, заявляющих о соответствии. В частности, он:

Определяет семантику команд (Command) и связанных данных. Для взаимодействия устройств необходимы стандарты того, как ожидается, что устройства будут реагировать на команды и связанные данные, а не только на информацию, передаваемую между устройствами.
Определяет семантику файловых служб, форматов файлов и каталогов информации, необходимых для обмена через автономные носители.
Явно определяет требования к соответствию реализаций Стандарта. В частности, заявление о соответствии должно содержать достаточно информации для определения функций, для которых может быть ожидаема интероперабельность с другим устройством, заявляющим о соответствии.
Обеспечивает работу в сетевой среде.
Структурирован для учёта внедрения новых служб, тем самым облегчая поддержку будущих приложений медицинской визуализации.
Использует существующие международные стандарты везде, где это применимо, и сам соответствует установленным руководящим принципам документации для международных стандартов.

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

службу сообщений DICOM и службу верхнего уровня, которая обеспечивает независимость от конкретной физической поддержки сетевого обмена и протоколов, таких как TCP/IP.
API веб-службы DICOM и службу HTTP, которая позволяет использовать распространённые протоколы гипертекста и связанные протоколы для передачи служб DICOM.
базовую службу файлов DICOM, которая обеспечивает доступ к носителям хранения независимо от конкретных форматов хранения на носителях и файловых структур.
обмен DICOM в реальном времени, обеспечивающий передачу метаданных DICOM в реальном времени на основе SMPTE и RTP.

Рисунок 5-1. Общая модель обмена данными

6 Обзор содержания стандарта DICOM

6.1 Структура документа

DICOM состоит из следующих частей:

Эти части Стандарта связаны между собой, но являются независимыми документами. Краткое описание каждой Части приводится в данном разделе.

6.2 PS3.2: Соответствие

PS3.2 стандарта DICOM определяет принципы, которым должны следовать реализации, заявляющие соответствие Стандарту:

Требования соответствия. PS3.2 определяет общие требования, которые должны быть соблюдены любой реализацией, заявляющей о соответствии. Он ссылается на разделы о соответствии других частей Стандарта.
Заявление о соответствии. PS3.2 определяет структуру Заявления о соответствии. Он определяет информацию, которая должна присутствовать в Заявлении о соответствии. Он ссылается на разделы Заявления о соответствии других частей Стандарта.

PS3.2 не определяет процедуру тестирования/валидации для оценки соответствия реализации Стандарту.

Рисунок 6.2-1 and Рисунок 6.2-2 изображают процесс формирования Заявления о соответствии для как сетевого обмена, так и обмена через носители. Заявление о соответствии состоит из следующих частей:

Набор информационных объектов, распознаваемых данной реализацией
Набор сервисных классов, поддерживаемых данной реализацией
Набор протоколов связи или физических носителей, поддерживаемых данной реализацией
Набор мер безопасности, поддерживаемых данной реализацией.

Рисунок 6.2-1. Процесс формирования заявления о соответствии для сети

Рисунок 6.2-2. Процесс формирования заявления о соответствии для носителей

6.3 PS3.3: Информационные объектные дефиниции

PS3.3 стандарта DICOM определяет ряд классов информационных объектов, которые дают абстрактное определение реальных сущностей, применимых к обмену цифровыми медицинскими изображениями и связанной информацией (например, сигналами, структурированными отчётами, дозой лучевой терапии и т. д.). Каждое определение класса информационного объекта состоит из описания его назначения и атрибутов, его определяющих. Класс информационных объектов не включает значения атрибутов, составляющих его определение.

Определены два типа классов информационных объектов: нормализованные и составные.

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

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

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

PS3.3 определяет модель реального мира (Real World) наряду с соответствующей информационной моделью, которая отражена в информационных объектных дефинициях. Будущие издания настоящего Стандарта могут расширить этот набор информационных объектов для поддержки новых функций.

Для представления отдельного случая реальной сущности создаётся экземпляр информационного объекта, который включает значения атрибутов класса информационных объектов. Значения атрибутов этого экземпляра информационного объекта могут изменяться с течением времени для точного отражения меняющегося состояния сущности, которую он представляет. Это достигается путём выполнения различных базовых операций над экземпляром информационного объекта для обеспечения конкретного набора служб, определяемых как сервисный класс. Эти сервисные классы определены в PS3.4 Стандарта.

6.4 PS3.4: Спецификации сервисных классов

PS3.4 стандарта DICOM определяет ряд сервисных классов. Сервисный класс связывает один или несколько информационных объектов с одной или несколькими командами, выполняемыми над этими объектами. Спецификации сервисного класса устанавливают требования к элементам команд и как результирующие команды применяются к информационным объектам. Спецификации сервисного класса устанавливают требования как для поставщиков, так и для пользователей служб обмена.

PS3.4 стандарта DICOM определяет характеристики, общие для всех сервисных классов, и то, как структурировано Заявление о соответствии для отдельного сервисного класса. Он содержит ряд нормативных приложений, подробно описывающих отдельные сервисные классы.

Примерами сервисных классов являются следующие:

Сервисный класс хранения (Storage Service Class)
Сервисный класс запроса/извлечения (Query/Retrieve Service Class)
Сервисный класс управления базовым списком работ (Basic Worklist Management Service Class)
Сервисный класс управления печатью (Print Management Service Class).

PS3.4 определяет операции, выполняемые над информационными объектами, определёнными в PS3.3. PS3.7 определяет команды и протоколы для использования команд с целью выполнения операций и уведомлений, описанных в PS3.4.

6.5 PS3.5: Структура и семантика данных

PS3.5 стандарта DICOM определяет, как приложения DICOM формируют и кодируют информацию набора данных, получаемую в результате использования информационных объектов и сервисных классов, определённых в PS3.3 и PS3.4 стандарта DICOM. Поддержка ряда стандартных методов сжатия изображений (например, JPEG без потерь и с потерями) определена.

PS3.5 определяет правила кодирования, необходимые для формирования потока данных, передаваемого в сообщении, как определено в PS3.7 стандарта DICOM. Этот поток данных создаётся из совокупности элементов данных, составляющих набор данных.

PS3.5 также определяет семантику ряда общих функций, характерных для многих информационных объектов. PS3.5 определяет правила кодирования международных наборов символов, используемых в DICOM.

6.6 PS3.6: Словарь данных

PS3.6 стандарта DICOM является централизованным реестром, определяющим совокупность всех элементов данных DICOM, доступных для представления информации, наряду с элементами, используемыми для кодирования на сменных носителях, и списком уникально идентифицированных элементов, назначаемых DICOM.

Для каждого элемента PS3.6 определяет:

его уникальный тег, состоящий из номера группы и номера элемента,
его имя,
его представление значения (строка символов, целое число и т. д.),
его множественность значения (сколько значений на атрибут),
является ли он изъятым.

Для каждого уникально идентифицированного элемента PS3.6 определяет:

его уникальное значение, являющееся числовым с несколькими компонентами, разделёнными десятичными точками и ограниченное 64 символами,
его имя,
его тип: класс информационных объектов, определение кодирования для передачи данных или определённые известные экземпляры информационных объектов,
в какой Части стандарта DICOM он определён.

6.7 PS3.7: Обмен сообщениями

PS3.7 стандарта DICOM определяет как службу, так и протокол, используемые приложением в среде медицинской визуализации для обмена сообщениями через службы поддержки обмена, определённые в PS3.8. Сообщение состоит из потока команд, определённого в PS3.7, за которым следует необязательный поток данных, определённый в PS3.5.

PS3.7 определяет:

операции и уведомления (службы DIMSE), доступные сервисным классам, определённым в PS3.4,
правила установления и завершения ассоциаций, предоставляемых поддержкой обмена, определённой в PS3.8, и влияние на незавершённые транзакции,
правила, регулирующие обмен запросами и ответами команд,
правила кодирования, необходимые для формирования потоков команд и сообщений.

6.8 PS3.8: Поддержка сетевого обмена для обмена сообщениями

PS3.8 стандарта DICOM определяет службы обмена и протоколы верхнего уровня, необходимые для поддержки в сетевой среде обмена между приложениями DICOM, как указано в PS3.3, PS3.4, PS3.5, PS3.6 и PS3.7. Эти службы и протоколы обмена обеспечивают выполнение обмена между приложениями DICOM эффективным и скоординированным образом через сеть.

Службы обмена, определённые в PS3.8, являются подмножеством служб, предоставляемых службой представления OSI (ISO 8822) и элементом службы управления ассоциацией ACSE (Association Control Service Element) (ISO 8649). Они называются службой верхнего уровня, которая позволяет одноранговым приложениям устанавливать ассоциации, передавать сообщения и завершать ассоциации.

Это определение службы верхнего уровня определяет использование протокола верхнего уровня DICOM совместно с транспортными протоколами TCP/IP.

Протокол обмена TCP/IP, определённый PS3.8, является протоколом обмена общего назначения, не специфичным для стандарта DICOM. Рисунок 5-1 показывает этот стек протоколов.

6.9 PS3.9: Изъят (ранее — Поддержка обмена по протоколу точка-точка для обмена сообщениями)

PS3.9 стандарта DICOM ранее определял службы и протоколы, используемые для связи по протоколу точка-точка способом, совместимым с ACR-NEMA 2.0. Он был изъят.

6.10 PS3.10 Хранение на носителях и формат файлов для обмена через носители

PS3.10 стандарта DICOM определяет общую модель хранения информации медицинской визуализации на съёмных носителях (см. Рисунок 6.10-1). Цель данной Части — предоставить основу, позволяющую обмениваться различными типами медицинских изображений и связанной информацией на широком спектре физических носителей хранения.

Примечание

См. Рисунок 5-1 для понимания того, как модель обмена через носители связана с сетевой моделью.

PS3.10 определяет:

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

PS3.10 определяет различные концепции хранения на носителях:

метод идентификации набора файлов на одном носителе;
метод именования файла DICOM в конкретной файловой системе.

Рисунок 6.10-1. Модель обмена DICOM для обмена через носители

6.11 PS3.11: Профили приложений хранения на носителях

PS3.11 стандарта DICOM определяет специфичные для приложений подмножества стандарта DICOM, для которых реализация может заявить о соответствии. Эти специфичные для приложений подмножества будут называться профилями приложений хранения на носителях в данном разделе. Такое Заявление о соответствии применяется к интероперабельному обмену медицинскими изображениями и связанной информацией на носителях хранения для конкретных клинических применений. Оно следует основе, определённой в PS3.10, для обмена различными типами информации на носителях хранения.

Приложение профиля приложения хранения на носителях организовано в следующие основные части:

Имя профиля приложения хранения на носителях или список профилей приложений хранения на носителях, сгруппированных в связанный класс
Описание клинического контекста профиля приложения хранения на носителях
Определение сервисного класса хранения на носителях с ролями устройств для профиля приложения хранения на носителях и связанных параметров
Информативный раздел, описывающий эксплуатационные требования профиля приложения
Спецификация классов информационных объектов и связанных информационных объектов, поддерживаемых, и кодирования, используемого для передачи данных
Выбор форматов носителей и физических носителей для использования
Другие параметры, которые необходимо задать для обеспечения интероперабельного обмена через носители
Параметры безопасности, определяющие криптографические методы, используемые с профилями приложений защищённого хранения на носителях

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

Примечание

Рисунок 6.11-1 показывает, как отдельные аспекты профиля приложения соотносятся с различными частями стандарта DICOM.

Рисунок 6.11-1. Связь между профилем приложения хранения на носителях и частями DICOM

6.12 PS3.12: Функции хранения и форматы носителей для обмена данными

PS3.12 стандарта DICOM облегчает обмен информацией между приложениями в медицинских учреждениях путём задания:

Структуры для описания связи между моделью хранения на носителях и конкретным физическим носителем и форматом носителя.
Конкретных характеристик физических носителей и связанных форматов носителей.

6.13 PS3.13: Изъят (ранее — Поддержка обмена по протоколу точка-точка для управления печатью)

PS3.13 ранее определял службы и протоколы, используемые для связи по протоколу точка-точка для служб управления печатью. Он был изъят.

6.14 PS3.14: Стандартная полутоновая функция отображения

PS3.14 определяет стандартизированную функцию отображения для согласованного отображения полутоновых изображений. Эта функция предоставляет методы калибровки конкретной системы отображения для цели согласованного представления изображений на различных устройствах отображения (например, мониторах и принтерах).

Выбранная функция отображения основана на человеческом зрительном восприятии. Контрастная чувствительность человеческого глаза явно нелинейна в диапазоне яркости устройств отображения. Этот Стандарт использует модель зрительной системы человека Бартена.

6.15 PS3.15: Профили безопасности и управления системой

PS3.15 стандарта DICOM определяет профили безопасности и управления системой, для которых реализации могут заявить о соответствии. Профили безопасности и управления системой определяются путём ссылки на внешние разработанные стандартные протоколы, такие как DHCP, LDAP, TLS и ISCL. Протоколы безопасности могут использовать методы безопасности, такие как открытые ключи и «смарт-карты». Шифрование данных может использовать различные стандартизированные схемы шифрования данных.

Данная Часть не рассматривает вопросы политик безопасности. Стандарт только предоставляет механизмы, которые могут быть использованы для реализации политик безопасности в отношении обмена объектами DICOM. Установление соответствующих политик безопасности является ответственностью местного администратора.

6.16 PS3.16: Ресурс сопоставления содержимого

PS3.16 стандарта DICOM определяет:

шаблоны для структурирования документов как DICOM Information Objects
наборы кодированных терминов для использования в Information Objects
лексикон терминов, определяемых и поддерживаемых DICOM
переводы кодированных терминов, специфичные для отдельных стран

6.17 PS3.17: Пояснительная информация

PS3.17 стандарта DICOM определяет:

информативные и нормативные приложения, содержащие пояснительную информацию

6.18 PS3.18: Веб-службы

PS3.18 стандарта DICOM определяет средства, с помощью которых Web Services могут использоваться для получения или сохранения объекта DICOM.

Запросы, получающие данные, указывают media type (формат) тела ответа. Запросы, сохраняющие данные, указывают media type тела запроса.

HTTP-запросов, определённых в этом стандарте, достаточно, чтобы HTTP server действовал как DICOM SCU (Service Class User) для получения или сохранения запрошенных объектов от соответствующего DICOM SCP (Service Class Provider) с использованием базовой функциональности DICOM, определённой в PS3.4 и PS3.7; иными словами, HTTP server может действовать как прокси для DICOM SCP.

6.19 PS3.19: Размещение приложений

PS3.19 стандарта DICOM задаёт Application Programming Interface (API) к основанной на DICOM медицинской вычислительной системе, в которую программы, написанные для этого стандартизованного интерфейса, могут подключаться как «plug-in» (см. Рисунок 6.19-1). Реализатору Hosting System достаточно один раз создать стандартизованный API, чтобы поддерживать широкий набор дополнительных Hosted Applications.

Рисунок 6.19-1. Интерфейс между Hosted Application и Hosting System

В традиционной модели «plug-in» модуль «plug-in» предназначен для конкретной host system, например программы веб-браузера, и может не работать в других host systems, например в других веб-браузерах. PS3.19 определяет API, который может быть реализован любой Hosting System. Hosted Application, написанное для этого API как «plug-in», сможет работать в любой среде, предоставленной Hosting System, реализующей этот API (см. Рисунок 6.19-2).

Рисунок 6.19-2. Иллюстрация независимости от платформы через Hosted Application

PS3.19 задаёт как взаимодействия, так и Application Programming Interfaces (API) между Hosting Systems и Hosted Applications. PS3.19 также определяет модели данных, используемые API.

6.20 PS3.20: Отчёты по визуализации с использованием клинической архитектуры документов HL7

PS3.20 стандарта DICOM задаёт шаблоны для кодирования отчётов по визуализации с использованием стандарта HL7 Clinical Document Architecture Release 2 (CDA R2, или просто CDA). В эту область входят отчёты о клинических процедурах для специальностей, использующих визуализацию в целях скрининга, диагностики или терапии.

PS3.20 является руководством по реализации CDA и согласован с подходом к стандартизованным шаблонам для руководств по реализации CDA, разработанным HL7. Он также предоставляет Business Names для элементов данных, связывающие данные в пользовательской терминологии, например собранные приложением для составления отчётов, с конкретными элементами, закодированными в CDA.

Как руководство по реализации отчётов по визуализации, эта часть уделяет особое внимание использованию и ссылкам на данные, собранные в процедурах визуализации, как на явные доказательства в отчётах. Эти данные включают изображения, формы сигналов, измерения, аннотации и другие аналитические результаты, управляемые как DICOM SOP Instances. В частности, эта часть включает спецификацию преобразования в документы CDA экземпляров DICOM Structured Report, представляющих отчёты по визуализации.

6.21 PS3.21: Преобразования между DICOM и другими представлениями

PS3.21 стандарта DICOM задаёт преобразования между DICOM и другими представлениями той же информации. В его область входят преобразования в формат NCI Annotation and Image Markup и из него.

6.22 PS3.22: Обмен в реальном времени (DICOM-RTV)

PS3.22 стандарта DICOM задаёт основанную на [SMPTE ST 2110-10] службу для передачи метаданных DICOM в реальном времени. Она предоставляет механизм передачи метаданных DICOM, связанных с видео- или аудиопотоком, основанным соответственно на [SMPTE ST 2110-20] и [SMPTE ST 2110-30].

7 Ссылки на стандарт DICOM

В соответствии с процедурами DICOM Standards Committee стандарт постоянно пересматривается. Дополнения и исправления к стандарту выносятся на голосование и утверждаются несколько раз в год. Каждое изменение после утверждения как Final Text немедленно вступает в силу. Периодически все утверждённые изменения Final Text объединяются в опубликованную редакцию стандарта, идентифицируемую годом публикации, однако такая публикация является лишь удобством для пользователя; официально стандарт изменяется в момент утверждения каждого изменения.

Соответствие стандарту DICOM обеспечивается через указанные SOP Classes с использованием сообщений DIMSE (см. PS3.4), Web Services (см. PS3.18), обмена на носителях (см. Annex I “Media Storage Service Class” in PS3.4 и PS3.10) или API размещаемых приложений (см. PS3.19). Дополнительные заявления о соответствии могут относиться к Profiles (см. PS3.11 и PS3.15). После того как такая единица соответствия определена в стандарте, все её изменения являются совместимыми вперёд и назад, за исключением редких случаев, когда исходная спецификация была невзаимодействующей или конфликтовала с другим стандартом. Поэтому требования к соответствию и заявления о соответствии ссылаются на имя и/или идентификатор функции и никогда не ссылаются на редакцию стандарта. Как правило, единственная уместная ссылка на конкретную редакцию стандарта — это указание изъятой функции (см. Section 1.4.2 Continuous Maintenance).

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

NEMA PS3 / ISO 12052, Digital Imaging and Communications in Medicine (DICOM) Standard, National Electrical Manufacturers Association, Rosslyn, VA, USA (доступно бесплатно на http://www.dicomstandard.org/)

Требования этого раздела не отменяют требование предоставлять DICOM Conformance Statement, как описано в PS3.2.

Следующие формы предпочтительны для ссылок на единицы соответствия стандарту, когда такие ссылки делаются вне контекста DICOM Conformance Statement, например в требованиях заказчика:

“… соответствует DICOM <name> SOP Class для сетевого обмена [как Service Class <User | Provider>], как указано в DICOM PS3.4: Service Class Specifications.”
“… соответствует DICOM <name> SOP Class для обмена на носителях [как File Set <Creator | Updater | Reader>], как указано в DICOM PS3.4: Service Class Specifications.”
“… соответствует DICOM <name> Web Service [как <Origin-server | User-agent>] [для <name> SOP Class], как указано в DICOM PS3.18: Web Services.”
“… соответствует DICOM Application Hosting [как <Hosting System | Hosted Application>] для <name> SOP Class, как указано в DICOM PS3.19: Application Hosting.”
“… соответствует DICOM <identifier> Media Storage Application Profile [как File Set <Creator | Updater | Reader>] [для <name> SOP Class], как указано в DICOM PS3.11: Media Storage Application Profiles.”
“… соответствует DICOM <name> Profile, как указано в DICOM PS3.15: Security and System Management Profiles.”

Примечание

Некоторые Media Storage Application Profiles и Web Services могут полностью определять обмениваемые Information Objects, тогда как другие могут требовать явного указания SOP Classes в ссылках.
Примеры:
- “Модальность должна соответствовать DICOM CT Image Storage и MR Image Storage SOP Classes для сетевого обмена как Service Class User, как указано в DICOM PS3.4: Service Class Specifications.”
- “Рабочая станция должна соответствовать DICOM STD-XA1K-DVD Media Storage Application Profile как File Set Reader, как указано в DICOM PS3.11: Media Storage Application Profiles.”
- “PACS должна соответствовать DICOM WADO-RS и STOW-RS Web Services как Origin-server для SOP Classes, перечисленных в Table X, как указано в DICOM PS3.18: Web Services.”
Такие ссылки не допускаются вместо Conformance Statement для продукта. Например, продукт, который читает или создаёт носители обмена DICOM, обязан иметь Conformance Statement (как описано в PS3.2), перечисляющий реализуемые им Media Storage Application Profiles. Заявление в каком-либо другом формате или документ, описывающий, что продукт поддерживает запись файлов определённого SOP Class, определённого в PS3.4, недостаточны как альтернатива Conformance Statement.

Можно ссылаться на другие функции стандарта, но такие ссылки не должны трактоваться как требования соответствия DICOM, хотя они могут быть требованиями соответствия для не-DICOM руководств по реализации или нормативных документов. Ниже приведены примеры:

“… SOP Instances в соответствии с <name> Information Object Definition, как указано в DICOM PS3.3: Information Object Definitions.”
“… Structured Reporting SOP Instances с использованием DICOM Template ID <number and name>, как указано в DICOM PS3.16: Content Mapping Resource.”
“… HL7 CDA instances с использованием Template ID <identifier and name>, как указано в DICOM PS3.20: Imaging Reports using HL7 Clinical Document Architecture.”
“… с использованием <name> Transfer Syntax, как указано в DICOM PS3.5: Data Structure and Semantics.”

Примечание

Например, продукты, создающие или принимающие SR-документы, должны соответствовать SOP Class, такому как Enhanced SR; такие продукты могут также ссылаться на использование Template ID 5200 Echocardiography Procedure Report, но это не является формальным заявлением о соответствии DICOM. Однако не-DICOM руководство по реализации, например IHE Echocardiography Workflow Profile, может требовать использования такого Template, а реализация может описывать использование конкретных Templates в своём Conformance Statement.

Поскольку изменения стандарта не должны цитироваться до их принятия как Final Text, и поскольку после принятия они формально становятся частью стандарта, не должно быть ссылок на supplements или correction items с целью описания соответствия. Ссылки на такие документы изменений могут использоваться для описания исторического развития стандарта DICOM.