PS3.10

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

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

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

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

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

Предисловие

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

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

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

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

1 Область применения и сфера действия

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

Данная Часть определяет:

многоуровневую модель хранения медицинских изображений и связанной с ними информации на носителях хранения. Эта модель вводит концепцию профилей приложений хранения на носителях (Media Storage Application Profiles), которые определяют специфичные для приложений подмножества стандарта DICOM, на соответствие которым реализация хранения на носителях может заявлять о соответствии. Такое соответствие применяется только к записи, чтению и обновлению содержимого носителей хранения. Конкретные профили приложений хранения на носителях не включены в данную Часть, а приведены в PS3.11;
формат файлов DICOM, поддерживающий инкапсуляцию любой информационной объектной дефиниции (Information Object Definition, IOD);
защищённый формат файлов DICOM, поддерживающий инкапсуляцию файла формата DICOM в криптографическую оболочку;
файловый сервис DICOM, обеспечивающий независимость от базового формата носителя и физического носителя. Также рассматриваются политики, относящиеся к файлу DICOMDIR, используемому для хранения класса пары сервис-объект каталога хранения на носителях (Media Storage Directory Service/Object Pair Class).

Данная Часть связана с другими частями стандарта DICOM следующим образом:

PS3.2, Соответствие (Conformance), определяет требования, которые должны быть выполнены для достижения соответствия DICOM при хранении на носителях;
PS3.3, Информационные объектные дефиниции (Information Object Definitions), определяет ряд информационных объектных дефиниций (например, различные типы изображений), которые могут использоваться совместно с данной Частью;
PS3.4, развивает данную Часть, определяя сервисный класс хранения на носителях (Media Storage Service Class);
PS3.5, Структура и кодирование данных (Data Structure and Encoding), рассматривает правила кодирования, необходимые для построения набора данных (Data Set), инкапсулируемого в файл, как указано в данной Части;
PS3.6, Словарь данных (Data Dictionary), содержит реестр по тегам всех элементов данных, относящихся к атрибутам информационных объектов, определённых в PS3.3. Этот указатель включает представление значения (Value Representation) и кратность значения (Value Multiplicity) для каждого элемента данных;
PS3.11, Профили приложений хранения на носителях (Media Storage Application Profiles), стандартизирует ряд вариантов, относящихся к конкретной клинической потребности (выбор физического носителя и формата носителя, а также конкретных классов пары сервис-объект (Service/Object Pair Classes)). Это направлено на обеспечение взаимодействия между реализациями, заявляющими о соответствии одному и тому же профилю приложения хранения на носителях. Ожидается, что PS3.11 будет расширяться по мере развития клинических потребностей в обмене через носители хранения;
PS3.12, Форматы носителей и физические носители для обмена данными (Media Formats and Physical Media for Data Interchange), определяет ряд выбранных физических носителей и соответствующих форматов носителей. Эти форматы и выбор физических носителей ссылается один или несколько профилей приложений хранения на носителях из PS3.11. Ожидается, что PS3.12 будет расширяться по мере развития технологий, относящихся к физическим носителям.
PS3.15, Профили безопасности (Security Profiles), определяет ряд профилей для использования с защищёнными профилями приложений хранения на носителях DICOM (Secure DICOM Media Storage Application Profiles). Профили безопасности хранения на носителях определяют криптографические методы, используемые для каждого защищённого файла DICOM в защищённом профиле приложения хранения на носителях.

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

Примечание

PS3.3 определяет общую информационную объектную дефиницию базового каталога медицинской визуализации (Basic Directory Information Object Definition), а PS3.4 определяет соответствующий класс SOP каталога хранения на носителях (Media Storage Directory SOP Class), являющийся членом сервисного класса хранения на носителях (Media Storage Service Class).

Соблюдение положений PS3.10 реализациями, считывающими, записывающими или обновляющими носители хранения, представляет собой ключевую основу для открытого обмена на носителях хранения. Однако эффективное взаимодействие при обмене на носителях хранения достигается только при выборе стандартных физических носителей и соответствующих форматов носителей в PS3.12 и использовании конкретных профилей приложений хранения на носителях из PS3.11. Поэтому заявление о соответствии только PS3.10 не является действительным заявлением о соответствии DICOM (DICOM Conformance Statement). Соответствие хранению на носителях DICOM должно заявляться по отношению к профилю приложения хранения на носителях PS3.11 в соответствии со структурой, определённой PS3.2.

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

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

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

[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 .

[ISO 7498-1] ISO. 1994. Information Processing Systems - Open Systems Interconnection - Basic Reference Model.

[ISO 7498-2] ISO. 1989. Information processing systems - Open Systems Interconnection - Basic reference Model - Part 2: Security Architecture.

[ISO/TR 8509] ISO. Information Processing Systems - Open Systems Interconnection - Service Conventions. ISO/TR 8509 был отозван. См. ISO/IEC 2382-26:1993 Information technology - Vocabulary - Part 26: Open systems interconnection .

[ISO 8822] ISO. 1988. Information processing systems - Open Systems Interconnection - Connection oriented presentation service definition.

[ISO/IEC 8859-1] ISO/IEC. 1987. Information processing - 8-bit single-byte coded graphic character sets - Part 1: Latin alphabet No. 1.

[RFC2557] IETF. March 1999. MIME Encapsulation of Aggregate Documents, such as HTML (MHTML). http://tools.ietf.org/html/rfc2557 .

[RFC3240] IETF. February 2002. Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration. http://tools.ietf.org/html/rfc3240 .

[RFC5652] IETF. September 2009. Cryptographic Message Syntax. http://tools.ietf.org/html/rfc5652 .

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

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

3.1 Определения эталонной модели

В данной Части Стандарта используются следующие термины, определённые в [ISO 7498-1] и [ISO 7498-2]:

Прикладная сущность (Application Entity): См. [ISO 7498-1].
Прикладной процесс (Application Process): См. [ISO 7498-1].
Сервис (Service): См. [ISO 7498-1].
Синтаксис передачи (Transfer Syntax): См. [ISO 7498-1].
Конфиденциальность данных (Data Confidentiality): См. [ISO 7498-2].

Примечание

Определение: «свойство, заключающееся в том, что информация не предоставляется и не раскрывается неуполномоченным лицам, организациям или процессам».
Аутентификация источника данных (Data Origin Authentication): См. [ISO 7498-2].

Примечание

Определение: «подтверждение того, что источник полученных данных соответствует заявленному».
Целостность данных (Data Integrity): См. [ISO 7498-2].

Примечание

Определение: «свойство, заключающееся в том, что данные не были изменены или уничтожены неуполномоченным образом».

3.2 Определения соглашений о сервисах

В данной Части Стандарта используются следующие термины, определённые в [ISO/TR 8509]:

Поставщик услуг (Service Provider): См. [ISO/TR 8509].
Пользователь сервиса (Service User): См. [ISO/TR 8509].

3.3 Определения сервиса представления

В данной Части Стандарта используются следующие термины, определённые в [ISO 8822]:

Абстрактный синтаксис (Abstract Syntax): См. [ISO 8822].
Имя абстрактного синтаксиса (Abstract Syntax Name): См. [ISO 8822].

3.4 Определения введения и обзора DICOM

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

Атрибут (Attribute): См. Attribute в PS3.1 .
Класс пары сервис-объект (Service-Object Pair Class) (SOP Class): См. Service-Object Pair Class в PS3.1 .

3.5 Определения информационных объектов DICOM

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

Информационная объектная дефиниция (Information Object Definition) (IOD): См. Information Object Definition в PS3.3 .

3.6 Определения структуры и кодирования данных DICOM

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

Элемент данных (Data Element): См. Data Element в PS3.5 .
Набор данных (Data Set): См. Data Set в PS3.5 .
Тип элемента данных (Data Element Type): См. Data Element Type в PS3.5 .
Значение (Value): См. Value в PS3.5 .
Кратность значения (Value Multiplicity): См. Value Multiplicity в PS3.5 .
Представление значения (Value Representation): См. Value Representation в PS3.5 .

3.7 Определения обмена сообщениями DICOM

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

UID класса реализации (Implementation Class UID): См. Implementation Class UID в PS3.7 .

3.8 Определения хранения на носителях и формата файлов DICOM

Следующие определения обычно используются в данной Части Стандарта:

Профиль приложения хранения на носителях (Media Storage Application Profile): Спецификация, определяющая выбор вариантов на различных уровнях модели хранения DICOM на носителях, применимых к конкретной потребности или контексту, в котором предполагается выполнять обмен на носителях.
Файловый сервис DICOM (DICOM File Service): Минимальное абстрактное представление файлов и операций, предоставляемых уровнем формата носителя (Media Format Layer). Ограничение доступа прикладных сущностей (Application Entities) к содержимому файлов через такую границу файлового сервиса DICOM обеспечивает независимость от формата носителя и физического носителя.
Файл DICOM (DICOM File): Файл, содержимое которого отформатировано в соответствии с требованиями данной Части стандарта DICOM. В частности, такие файлы содержат метаинформацию файла (File Meta Information) и надлежащим образом отформатированный набор данных (Data Set).
Файл DICOMDIR (DICOMDIR File): Файл DICOM в составе набора файлов (File-set), содержащий экземпляр SOP каталога хранения на носителях (Media Storage Directory SOP Instance). Этому файлу присваивается однокомпонентный идентификатор файла (File ID) — DICOMDIR.
Файл (File): Файл — это упорядоченная последовательность из нуля или более байтов, где первый байт находится в начале файла, а последний байт — в конце файла. Файлы идентифицируются уникальным идентификатором файла (File ID) и могут быть записаны, прочитаны и/или удалены.
Идентификатор файла (File ID): Идентификатор файла, уникальный в контексте набора файлов (File-set), к которому он принадлежит. Идентификатор файла (File ID) формируется из набора упорядоченных компонентов идентификатора файла (File ID Components) (максимум до восьми).
Компонент идентификатора файла (File ID Component): Строка из одного–восьми символов из заданного набора символов.
Метаинформация файла (File Meta Information): Идентификационная информация об инкапсулированном наборе данных (Data Set). Представляет собой заголовок в начале каждого файла DICOM.
Набор файлов (File-set): Совокупность файлов DICOM (и, возможно, файлов, не являющихся файлами DICOM), имеющих общее пространство имён, в пределах которого идентификаторы файлов (File ID) уникальны.
Создатель набора файлов (File-set Creator): Прикладная сущность (Application Entity), которая создаёт файл DICOMDIR (см. Раздел 8.6) и ноль или более файлов DICOM.
Читатель набора файлов (File-set Reader): Прикладная сущность (Application Entity), осуществляющая доступ к одному или нескольким файлам в наборе файлов (File-set).
Обновляющий набор файлов (File-set Updater): Прикладная сущность (Application Entity), осуществляющая доступ к файлам, создающая дополнительные файлы или удаляющая существующие файлы в наборе файлов (File-set). Обновляющий набор файлов вносит соответствующие изменения в файл DICOMDIR, отражающие добавления или удаления.
Формат файлов DICOM (DICOM File Format): Способ инкапсуляции в файле набора данных (Data Set), представляющего экземпляр SOP (SOP Instance), относящийся к информационному объекту DICOM.
Формат носителя (Media Format): Структуры данных и связанные с ними политики, организующие потоки битов, определённые форматом физических носителей, в структуры файлов данных и связанные с ними файловые каталоги.
Модель хранения DICOM на носителях (DICOM Media Storage Model): Структуры данных и операции, используемые на различных уровнях протокола для достижения совместимости посредством обмена на носителях.
Сервисы хранения на носителях (Media Storage Services): Набор операций с носителями, обеспечивающих сохранение на носители и извлечение с носителей экземпляров SOP DICOM. Часть спецификации файлового сервиса DICOM.
Физический носитель (Physical Media): Материал с возможностью записи потоков битов. Характеристики физического носителя включают форм-фактор, механические характеристики, свойства записи и правила записи и организации потоков битов в доступные структуры.
Защищённый файл DICOM (Secure DICOM File): Файл DICOM, инкапсулированный с использованием синтаксиса криптографических сообщений (Cryptographic Message Syntax), указанного в IETF STD 70 [RFC5652].
Защищённый набор файлов (Secure File-set): Набор файлов (File-set), в котором все файлы DICOM являются защищёнными файлами DICOM (Secure DICOM Files).
Защищённый профиль приложения хранения на носителях (Secure Media Storage Application Profile): Профиль приложения хранения на носителях, требующий защищённого набора файлов (Secure File-set).

3.9 Определения сервисного класса DICOM

В данной Части Стандарта используются следующие термины, определённые в PS3.4 стандарта DICOM:

Экземпляр пары сервис-объект (Service Object Pair Instance) (SOP Instance): См. Service-Object Pair Instance в PS3.4 .

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

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

ACC: Американский колледж кардиологии (American College of Cardiology)
ACR: Американский колледж радиологии (American College of Radiology)
ASCII: Американский стандартный код обмена информацией (American Standard Code for Information Interchange)
AE: Прикладная сущность (Application Entity)
ANSI: Американский национальный институт стандартов (American National Standards Institute)
CEN/TC/251: Европейский комитет по стандартизации — Технический комитет 251 — Медицинская информатика (Comite Europeen de Normalisation — Technical Committee 251 — Medical Informatics)
DICOM: Цифровая визуализация и связь в медицине (Digital Imaging and Communications in Medicine)
FSC: Создатель набора файлов (File-set Creator)
FSR: Читатель набора файлов (File-set Reader)
FSU: Обновляющий набор файлов (File-set Updater)
HL7: Health Level 7
HTML: Язык разметки гипертекста (Hypertext Markup Language)
IEEE: Институт инженеров электротехники и электроники (Institute of Electrical and Electronics Engineers)
ISO: Международная организация по стандартизации (International Organization for Standardization)
ID: Идентификатор (Identifier)
IOD: Информационная объектная дефиниция (Information Object Definition)
JIRA: Японская ассоциация промышленности систем медицинской визуализации и радиологии (Japan Industries Association of Radiological Systems)
MIME: Многоцелевые расширения интернет-почты (Multipurpose Internet Mail Extensions)
NEMA: Национальная ассоциация производителей электрооборудования (National Electrical Manufacturers Association)
OSI: Взаимодействие открытых систем (Open Systems Interconnection)
SOP: Пара сервис-объект (Service-Object Pair)
TCP/IP: Протокол управления передачей/Интернет-протокол (Transmission Control Protocol/Internet Protocol)
UID: Уникальный идентификатор (Unique Identifier)
VR: Представление значения (Value Representation)
XML: Расширяемый язык разметки (Extensible Markup Language)

5 Соглашения

В данном документе слова пишутся с заглавной буквы, чтобы помочь читателю понять, что эти слова были ранее определены в Разделе 3 данного документа и должны толковаться в этом значении.

Тег (Tag) представляется в виде (gggg,eeee), где gggg соответствует номеру группы (Group Number), а eeee — номеру элемента (Element Number) в пределах этой группы. Теги представляются в шестнадцатеричной нотации, как указано в PS3.5.

Атрибутам метаинформации файла (File Meta Information) присваивается тип (Type), указывающий, требуется ли конкретный атрибут в зависимости от сервисов хранения на носителях (Media Storage Services). Следующие обозначения типов (Type) произведены от обозначений PS3.5, но учитывают среду хранения на носителях:

Type 1: Такие атрибуты должны присутствовать с явным значением в файлах, созданных создателями наборов файлов (File-set Creators) и обновляющими наборы файлов (File-set Updaters). Они должны поддерживаться читателями наборов файлов (File-set Readers) и обновляющими наборы файлов (File-set Updaters);
Type 1C: Такие атрибуты должны присутствовать с явным значением в файлах, созданных создателями наборов файлов и обновляющими наборы файлов, если выполняется указанное условие. Они должны поддерживаться читателями наборов файлов и обновляющими наборы файлов;
Type 2: Такие атрибуты должны присутствовать с явным значением или со значением нулевой длины, если неизвестно, в файлах, созданных создателями наборов файлов и обновляющими наборы файлов. Они должны поддерживаться читателями наборов файлов и обновляющими наборы файлов;
Type 2C: Такие атрибуты должны присутствовать с явным значением или со значением нулевой длины, если неизвестно, в файлах, созданных создателями наборов файлов и обновляющими наборы файлов, если выполняется указанное условие. Они должны поддерживаться читателями наборов файлов и обновляющими наборы файлов;
Type 3: Такие атрибуты могут присутствовать с явным значением или значением нулевой длины в файлах, созданных создателями наборов файлов и обновляющими наборы файлов. Они могут поддерживаться или игнорироваться читателями наборов файлов и обновляющими наборы файлов.

6 Модели DICOM для хранения на носителях

Данный раздел определяет модель хранения DICOM на носителях (DICOM Media Storage Model), используемую прикладными сущностями DICOM (Application Entities) для связи путём обмена на съёмных носителях хранения. В частности, этот раздел предоставляет модель для разъяснения ряда концепций цифровой визуализации и связи и вводит ключевые термины, используемые throughout стандарта DICOM. Эта модель использовалась для разделения стандарта DICOM на отдельные части, относящиеся к обмену на носителях хранения.

6.1 Общая модель обмена данными DICOM

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

сервис сообщений DICOM и сервис верхнего уровня (DICOM Message Service and Upper Layer Service), обеспечивающий независимость от конкретной физической сетевой коммуникационной поддержки и протоколов, таких как TCP/IP;
API веб-сервиса DICOM и сервис HTTP (DICOM Web Service API and HTTP Service), позволяющий использовать общие протоколы гипертекста и связанные с ними протоколы для передачи сервисов DICOM;
базовый файловый сервис DICOM (Basic DICOM File Service), обеспечивающий доступ к носителям хранения независимо от конкретных физических форматов хранения и файловых структур, или
обмен данными DICOM в реальном времени (DICOM Real-Time Communication), обеспечивающий передачу метаданных DICOM в реальном времени на основе SMPTE и RTP.

PS3.10 описывает базовый файловый сервис DICOM, как показано на Рисунке 6.1-1.

DICOM Communication Model for Media Interchange

Рисунок 6.1-1. Модель обмена DICOM для обмена на носителях

6.2 Модель хранения DICOM на носителях

Модель хранения DICOM на носителях представлена на Рисунке 6.2-1 и расширяет общую модель обмена DICOM, введённую ранее в Разделе 6.1.

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

Примечание

Определение интерфейсов программирования приложений (Application Programming Interfaces) на этих границах не входит в область применения данного Стандарта.

Рисунок 6.2-1. Модель хранения DICOM на носителях

Модель хранения DICOM на носителях включает три уровня, которые описаны в следующих разделах.

6.2.1 Уровень физических носителей

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

Примечание

Примером уровня физических носителей в среде персональных компьютеров является дискета 3,5 дюйма, двусторонняя, высокой плотности.
Спецификация одного или нескольких конкретных физических носителей для данного приложения выходит за рамки данной Части стандарта DICOM. PS3.12 и его приложения определяют несколько вариантов физических носителей. PS3.11 определяет ряд профилей приложений хранения на носителях, выбирающих конкретные физические носители в зависимости от требований конкретных приложений медицинской визуализации.

6.2.2 Уровень формата носителя

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

Примечание

Этот уровень часто специфичен для конкретной операционной системы. Примером такого определения уровня формата носителя, связанного с дискетой 3,5 дюйма, являются структуры данных, используемые операционными системами различных файловых систем персональных компьютеров. PS3.12 и его приложения определяют несколько вариантов форматов носителей.

Форматы носителей, поддерживаемые стандартом DICOM, выбраны для обеспечения минимальных требований, определённых файловым сервисом DICOM, как указано в Разделе 8 данной Части. Ограничение доступа к содержимому файла через такой файловый сервис DICOM обеспечивает независимость уровня формата данных DICOM от выбора формата носителя и физического носителя.

6.2.3 Уровень формата данных DICOM

Уровень формата данных DICOM включает следующие элементы спецификации:

Классы SOP хранения на носителях DICOM и связанные с ними информационные объектные дефиниции;
Формат файлов DICOM;
Защищённый формат файлов DICOM;
Класс SOP каталога хранения на носителях DICOM;
Профили приложений хранения на носителях DICOM;
Профили безопасности DICOM для хранения на носителях.

6.2.3.1 Классы SOP DICOM

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

Использование IOD DICOM совместно с сервисами хранения на носителях (Media Storage Services) образует ряд классов пары сервис-объект хранения на носителях (Media Storage SOP Classes). Сервисы хранения на носителях (например, чтение, запись, удаление и т.д.) должны выполняться через файловый сервис DICOM. Содержимое результирующих файлов DICOM должно быть отформатировано в соответствии с форматом файлов DICOM, как указано ниже.

PS3.4 определяет ряд классов SOP, которые могут использоваться для хранения на носителях, в Приложении I. Эти классы SOP основаны на стандартных IOD DICOM, которые можно найти в PS3.3.

Структура и кодирование набора данных (Data Set), представляющего данные, связанные с классом SOP, должны соответствовать PS3.5. Спецификация синтаксисов передачи (Transfer Syntaxes), которые могут использоваться для кодирования такого набора данных, также определена в PS3.5.

6.2.3.2 Концепция формата файлов DICOM

Инкапсуляция набора данных DICOM в файле должна соответствовать спецификациям Раздела 7 данной Части. Эти правила инкапсуляции определяют формат файлов DICOM, способный содержать в файле любой набор данных DICOM. Файлы идентифицируются идентификаторами файлов (File ID). Из этих идентификаторов файлов, а также из их структуры не должен делаться вывод о какой-либо семантике.

Примечание

Приложение медицинской визуализации, выступающее в роли создателя файла DICOM, может использовать семантическую информацию для генерации идентификатора файла (File ID), однако читатели файлов DICOM не должны полагаться на очевидное семантическое содержимое идентификатора файла.

Инкапсуляция набора данных должна основываться на файловом сервисе DICOM, как указано в Разделе 8 данной Части.

Примечание

Допустимо, чтобы конкретный формат носителя предлагал больше файловых сервисов, чем specified в файловом сервисе DICOM. Такие сервисы могут быть локальными или внутренними для реализации. Их использование выходит за рамки стандарта DICOM. Однако в случаях, когда такие сервисы отражены в файловых структурах уровня формата носителя или в кодировании набора данных информационного объекта, расширение таких сервисов способом, ставящим под угрозу совместимость, не должно осуществляться (например, идентификаторы файлов длиннее, чем specified в файловом сервисе DICOM).

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

6.2.3.3 Каталог медицинской информации DICOM

В дополнение к классам SOP изображений DICOM и связанных с изображениями классов SOP (например, результаты, пациенты), другие классы SOP, предназначенные для хранения на носителях, могут использоваться для предоставления ссылок (или каталогов) на основе медицинской информации, тем самым облегчая доступ к информации клинической визуализации. Таким классом SOP является класс SOP каталога хранения на носителях, определённый в PS3.4. Экземпляры этого класса SOP передаются в файле с идентификатором файла DICOMDIR.

6.2.4 Профили приложений хранения на носителях DICOM

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

Профили приложений хранения на носителях должны включать:

Описание потребности, удовлетворяемой профилем приложения хранения на носителях (например, кардиология, эхография, ангиография), и контекста его применения;
Выбор на уровне формата данных ряда конкретных IOD и связанных с ними классов SOP. Для стандартных классов SOP DICOM это должно осуществляться путём ссылки на PS3.4. Этим классам SOP, как и любым другим классам SOP DICOM, присваивается уникальный зарегистрированный UID. Для каждого класса SOP должно быть указано, является ли его поддержка обязательной или опциональной в контексте данного профиля;
Выбор конкретного определения формата носителя. Это осуществляется путём ссылки на PS3.12, где specified выбранный физический носитель, конкретный связанный с ним формат носителя и сопоставление сервисов этого формата носителя (или файловой системы) с файловым сервисом DICOM;
Выбор подходящих синтаксисов передачи (Transfer Syntaxes);
Выбор конкретного профиля безопасности. Это осуществляется путём ссылки на PS3.15, где specified криптографические алгоритмы, используемые для инкапсуляции файлов DICOM из набора файлов DICOM в защищённые файлы DICOM. Если профиль приложения хранения на носителях не выбирает профиль безопасности, то такой профиль приложения хранения на носителях является незащищённым, и защищённый формат файлов DICOM не должен использоваться с этим профилем приложения хранения на носителях;
Другие варианты, облегчающие совместимость, такие как конкретные ограничения (например, максимальные размеры файлов, при необходимости поддержка опций, если таковые имеются).

Полное определение и структура профилей приложений хранения на носителях специфицированы в PS3.11. Ряд стандартных профилей приложений хранения на носителях, соответствующих различным потребностям, включён в PS3.11.

6.2.5 Хранение на носителях и структура стандарта DICOM

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

Рисунок 6.2-2. Хранение на носителях и части DICOM

7 Формат файлов DICOM

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

Рисунок 7-1. Набор файлов и формат файлов

7.1 Метаинформация файла DICOM

Метаинформация файла (File Meta Information) включает идентификационную информацию об инкапсулированном наборе данных. Этот заголовок состоит из преамбулы файла (File Preamble) размером 128 байт, за которой следует 4-байтовый префикс DICOM, а затем — элементы метаинформации файла (File Meta Elements), показанные в Таблице 7.1-1. Этот заголовок должен присутствовать в каждом файле DICOM.

Преамбула файла (File Preamble) доступна для использования, как определено профилями приложений хранения на носителях (Media Storage Application Profiles) или конкретными реализациями. Данная Часть стандарта DICOM не требует какой-либо структуры для этой преамбулы фиксированного размера. Она не обязана быть структурирована как элемент данных DICOM с тегом и длиной. Она предназначена для облегчения доступа к изображениям и другим данным в файле DICOM путём обеспечения совместимости с рядом распространённых форматов файлов компьютерных изображений. Независимо от того, содержит ли преамбула файла информацию, содержимое файла DICOM должно соответствовать требованиям данной Части, а набор данных должен соответствовать классу SOP, указанному в метаинформации файла.

Примечание

Если преамбула файла не используется профилем приложения хранения на носителях или конкретной реализацией, все 128 байт должны быть установлены в 00H. Это предназначено для облегчения распознавания того, что преамбула используется, когда не все 128 байт установлены, как указано выше.
Преамбула файла может, например, содержать информацию, позволяющую мультимедийному приложению осуществлять произвольный доступ к изображениям, хранящимся в наборе данных DICOM. Доступ к одному и тому же файлу может осуществляться двумя способами: мультимедийным приложением, использующим преамбулу, и приложением DICOM, которое игнорирует преамбулу.

Четырёхбайтовый префикс DICOM должен содержать строку символов «DICM», закодированную прописными буквами репертуара символов ISO 8859 G0. Этот четырёхбайтовый префикс не структурирован как элемент данных DICOM с тегом и длиной.

За преамбулой и префиксом следует набор элементов метаинформации DICOM с тегами и длинами, как определено в Таблице 7.1-1.

Таблица 7.1-1. Метаинформация файла DICOM

Attribute Name	Tag	Type	Attribute Description
File Preamble	Без полей тега и длины	1	Фиксированное поле размером 128 байт, доступное для использования профилем приложения хранения на носителях или реализацией. Если не используется профилем приложения хранения на носителях или конкретной реализацией, все байты должны быть установлены в 00H. Читатели или обновляющие наборы файлов не должны полагаться на содержимое этой преамбулы для определения того, является ли данный файл файлом DICOM или нет.
DICOM Prefix	Без полей тега и длины	1	Четыре байта, содержащие строку символов «DICM». Этот префикс предназначен для распознавания того, является ли данный файл файлом DICOM или нет.
File Meta Information Group Length	(0002,0000)	1	Количество байтов, следующих за этим элементом метаинформации файла (конец поля значения), до последнего элемента метаинформации файла группы 2 включительно.
File Meta Information Version	(0002,0001)	1	Это двухбайтовое поле, в котором каждый бит идентифицирует версию заголовка метаинформации файла. В версии 1 значение первого байта — 00H, значение второго байта — 01H. Реализации, читающие файлы с метаинформацией, где этот атрибут имеет бит 0 (младший) второго байта, установленный в 1, могут интерпретировать метаинформацию файла, как указано в данной версии PS3.10. Все остальные биты не должны проверяться. Примечание Битовое поле, в котором каждый бит идентифицирует версию, позволяет явно указать поддержку нескольких предыдущих версий. В будущих версиях метаинформации файла, которые могут быть прочитаны читателями версии 1, бит 0 второго байта будет установлен в 1.
Media Storage SOP Class UID	(0002,0002)	1	Однозначно идентифицирует класс SOP, связанный с набором данных. Допустимые UID классов SOP для хранения на носителях specified в Разделе I.4 «Media Storage SOP Classes» стандарта PS3.4.
Media Storage SOP Instance UID	(0002,0003)	1	Однозначно идентифицирует экземпляр SOP, связанный с набором данных, помещённым в файл и следующим за метаинформацией файла.
Transfer Syntax UID	(0002,0010)	1	Однозначно идентифицирует синтаксис передачи (Transfer Syntax), используемый для кодирования следующего набора данных. Этот синтаксис передачи не применяется к метаинформации файла. Примечание Рекомендуется использовать один из синтаксисов передачи DICOM, поддерживающих кодирование с явным представлением значения (Explicit VR), для облегчения интерпретации значений элементов метаинформации файла. Синтаксисы передачи JPIP Referenced Pixel Data не используются (см. PS3.5).
Implementation Class UID	(0002,0012)	1	Однозначно идентифицирует реализацию, записавшую этот файл и его содержимое. Обеспечивает однозначную идентификацию типа реализации, последней записавшей файл, в случае проблем при обмене. Следует тем же правилам, что определены в PS3.7 (согласование ассоциации).
Implementation Version Name	(0002,0013)	3	Идентифицирует версию для Implementation Class UID (0002,0012) с использованием до 16 символов репертуара ISO 646:1990 (базовый набор G0). Следует тем же правилам, что определены в PS3.7 (согласование ассоциации).
Source Application Entity Title	(0002,0016)	3	Заголовок прикладной сущности DICOM (Application Entity Title) AE, записавшей содержимое этого файла (или последней его обновившей). Если используется, это позволяет отслеживать источник ошибок в случае проблем при обмене на носителях. Правила, связанные с заголовками AE, те же, что определены в PS3.8. Примечание Если набор данных был создан заново приложением, записывающим файл, может использоваться его заголовок AE, если он имеется. Если набор данных был получен по сети, существует потенциальная неоднозначность в том, совпадает ли значение с Sending Application Entity Title (0002,0017) или Receiving Application Entity Title (0002,0018) или с некоторым другим значением.
Sending Application Entity Title	(0002,0017)	3	Заголовок прикладной сущности DICOM (AE Title) для AE, отправившей содержимое этого файла по сети. Примечание Это AE, которое было отправителем (источником) содержимого (набора данных) в случае набора данных, отправленного по сети (т.е. Calling AET для SCU при операции C-STORE). Если набор данных был создан заново приложением, записывающим файл, этот атрибут не должен присутствовать.
Receiving Application Entity Title	(0002,0018)	3	Заголовок прикладной сущности DICOM (AE Title) для AE, получившей содержимое этого файла по сети. Примечание Это AE, которое было получателем (адресатом) содержимого (набора данных) в случае набора данных, полученного по сети (т.е. Called AET для SCP при операции C-STORE). Если набор данных был создан заново приложением, записывающим файл, этот атрибут не должен присутствовать.
Source Presentation Address	(0002,0026)	3	Адрес представления DICOM (Presentation Address), соответствующий Source Application Entity Title (0002,0016). См. Раздел 7.1.1.1.
Sending Presentation Address	(0002,0027)	3	Адрес представления DICOM, соответствующий Sending Application Entity Title (0002,0017). См. Раздел 7.1.1.1.
Receiving Presentation Address	(0002,0028)	3	Адрес представления DICOM, соответствующий Receiving Application Entity Title (0002,0018). См. Раздел 7.1.1.1.
Private Information Creator UID	(0002,0100)	3	UID создателя приватной информации (0002,0102).
Private Information	(0002,0102)	1C	Содержит приватную информацию (Private Information), помещённую в метаинформацию файла. Создатель должен быть идентифицирован в (0002,0100). Обязательно, если присутствует Private Information Creator UID (0002,0100).

За исключением 128-байтной преамбулы и 4-байтового префикса, метаинформация файла должна кодироваться с использованием синтаксиса передачи Explicit VR Little Endian (UID=1.2.840.10008.1.2.1), как определено в DICOM PS3.5. Значения каждого элемента метаинформации файла должны быть дополнены при необходимости для достижения чётной длины, как указано в PS3.5, в соответствии с соответствующим представлением значения (Value Representation). Представление значения Unknown (UN) не должно использоваться в метаинформации файла. Для совместимости с будущими версиями данного Стандарта любой тег (0002,xxxx), не определённый в Таблице 7.1-1, должен игнорироваться.

Значения всех тегов (0002,xxxx) зарезервированы для использования данным Стандартом и последующими версиями DICOM. Элементы данных с группой 0002 не должны использоваться в наборах данных, отличных от метаинформации файла.

Примечание

PS3.5 specifies, что элементы с тегами (0001,xxxx), (0003,xxxx), (0005,xxxx) и (0007,xxxx) не должны использоваться.

7.1.1 Атрибуты метаинформации файла DICOM

7.1.1.1 Атрибуты адреса представления

Кодирование адреса представления зависит от сетевого транспортного протокола.

Для объектов, обмениваемых с использованием протокола верхнего уровня DICOM для TCP/IP (PS3.8), адрес представления должен кодироваться как URI, состоящий из схемы «dicom», за которой следует двоеточие, затем либо полное доменное имя хоста, либо IP-адрес, затем двоеточие и номер порта. Например: «dicom:127.0.0.1:104», «dicom:myhost.mydomain.com:104».

Для объектов, обмениваемых с использованием веб-сервисов PS3.18, адрес представления должен кодироваться как абсолютный URL конечной точки базы ресурса или сервиса, достаточный для идентификации системы. Например: «http://myhost.mydomain.com:80/wado-rs/». Адрес представления не обязан быть полным адресом ресурса. Схема должна быть «http», независимо от того, использовалась ли защищённая передача фактически или нет.

Примечание

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

7.2 Инкапсуляция набора данных

Каждый файл должен содержать один набор данных (Data Set), представляющий один экземпляр SOP (SOP Instance), относящийся к одному классу SOP (и соответствующему IOD).

Примечание

Файл может содержать более одного двумерного кадра изображения (image frame), поскольку конкретные IOD могут быть определены для включения нескольких кадров.

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

Примечание

Синтаксис передачи, используемый для кодирования набора данных, не может быть изменён внутри набора данных; т.е. элемент данных Transfer Syntax UID не может встречаться где-либо внутри набора данных, например, вложенным в элемент последовательности (Sequence Item).
Набор данных DICOM не включает свою общую длину. Индикация конца файла, предоставляемая файловым сервисом DICOM (см. Раздел 8.4), является единственным указанием конца набора данных.

Последним элементом данных набора данных может быть элемент данных (FFFC,FFFC), если требуется дополнение набора данных при записи файла. Значение этого элемента данных Data Set Trailing Padding (FFFC,FFFC) не имеет значения и должно игнорироваться всеми реализациями DICOM, читающими данный набор данных. Читатели или обновляющие наборы файлов должны уметь обрабатывать этот элемент Data Set Trailing Padding (FFFC,FFFC) как в наборе данных, следующем за метаинформацией, так и в наборах данных, вложенных в последовательность (см. PS3.5).

7.3 Поддержка информации по управлению файлами

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

Идентификация владельца содержимого файла;
Статистика доступа к файлам (например, дата и время создания);
Управление доступом приложений к файлам;
Управление доступом к физическим носителям (например, защита от записи).

7.4 Защищённый формат файлов DICOM

Защищённый файл DICOM должен содержать один файл DICOM, инкапсулированный с использованием синтаксиса криптографических сообщений (Cryptographic Message Syntax), как определено в IETF STD 70 [RFC5652]. В зависимости от криптографических алгоритмов, используемых для инкапсуляции, защищённый файл DICOM может обеспечивать одно или несколько из следующих свойств безопасности:

Конфиденциальность данных (посредством шифрования)
Аутентификация источника данных (посредством сертификатов и цифровой подписи)
Целостность данных (посредством цифровых подписей)

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

7.5 Вопросы безопасности для формата файлов DICOM

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

В зависимости от использования и назначения конкретного приложения может быть целесообразным:

Санитизировать преамбулу, например путём:
- Проверки того, что преамбула:
  - состоит из всех нулей, или
  - начинается с корректного магического числа для распознаваемого содержимого двойного формата (например, TIFF или BigTIFF), или
  - содержит другое известное безопасное содержимое.
- Очистки преамбулы независимо от её содержимого
  
  Примечание
  
  Это сделает невозможным использование приложениями, зависящими от формата, отличного от DICOM, если возможность двойного формата была использована.
- Явной проверки исполняемого содержимого преамбулы.
  
  Примечание
  
  Надлежащая реакция на наличие исполняемого содержимого зависит от назначения приложения, однако, как правило, легитимное исполняемое содержимое не должно обнаруживаться в файле DICOM. Гипотетический пример исключения — если файл содержит собственную программу просмотра; это достаточно маловероятно, чтобы не принимать во внимание.
Явно проверить наличие исполняемого содержимого в любом месте файла DICOM.
Проверить, что значения, структуры и содержимое DICOM соответствуют стандартным правилам кодирования и IOD указанного класса SOP, включая приватные элементы данных (Private Data Elements).

Примечание

Проверка того, что значения элементов данных соответствуют их представлению значения (Value Representation), может частично снизить риск скрытого вредоносного содержимого, однако может потребоваться удалить или проанализировать содержимое непрозрачных двоичных данных в элементах данных OB или других двоичных числовых значениях, будь то стандартные или приватные элементы данных. VR приватных элементов данных может быть неизвестен. Без исполняемой преамбулы такое скрытое содержимое может не быть напрямую исполняемым, но всё же может служить хранилищем вредоносного кода для активации другим сопутствующим эксплойтом.
Проверить, что содержимое относится к соответствующим классам SOP.
Проверить, что файлы формата DICOM, созданные для HTTP-запросов и ответов, не содержат такого вредоносного содержимого.

Примечание

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

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

Примечание

Например, архив может выбрать санитизацию экземпляров SOP при получении, санитизацию экземпляров SOP при извлечении, проверку структуры и отклонение запросов на сохранение экземпляров SOP, не прошедших проверку, или иное поведение на основе назначения продукта и среды угроз. Это поведение не specified в DICOM, поскольку назначение продукта и среда угроз сильно зависят от приложения.

Реализация должна описать в своём заявлении о соответствии (Conformance Statement) своё поведение в отношении санитизации преамбулы и любых других выполняемых проверок.

8 Файловый сервис DICOM

Файловый сервис DICOM определяет абстрактное представление файлов с точки зрения пользователя сервиса на уровне формата данных (Data Format Layer). Ограничение доступа прикладных сущностей (Application Entity, AE) к содержимому файлов через такой файловый сервис DICOM обеспечивает независимость функций уровня формата данных от конкретного выбора формата носителей (Media Format) и физического носителя (Physical Media).

Примечание

Данное определение файлового сервиса DICOM является абстрактным в том смысле, что оно представляет собой лишь спецификацию границы. Его область ограничена аспектами, непосредственно связанными с доступом к структурам данных уровня формата носителей (а не спецификациями самих структур данных). Несмотря на то, что файловый сервис DICOM может быть описан с помощью ряда абстрактных примитивов, таких как чтение, запись, удаление и т.д., он не предназначен для определения программного интерфейса приложения (Application Programming Interface, API).

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

Примечание

Допустимо, чтобы конкретный формат носителей предлагал больше файловых сервисов, чем определено в файловом сервисе DICOM. Такие сервисы могут быть внутренними для реализации (т.е. невидимыми через структуры данных на носителе хранения). Их использование выходит за рамки стандарта DICOM. Однако в случаях, когда такие сервисы отражаются в файловых структурах уровня формата носителей или в кодировании набора данных (Data Set) информационного объекта, не следует расширять такие сервисы способом, ставящим под угрозу совместимость (например, идентификаторы файлов (File ID) длиннее, чем определено в файловом сервисе DICOM).

8.1 Набор файлов (File-set)

Файловый сервис DICOM предоставляет возможность создавать файлы и обращаться к одному или нескольким файлам в наборе файлов (File-set). Набор файлов — это коллекция файлов, разделяющих общее пространство имён, в пределах которого идентификаторы файлов (File ID) (см. Раздел 8.2) являются уникальными. Порядок файлов в наборе файлов не имеет семантического значения.

Примечание

Файловый сервис DICOM не требует, чтобы файлы в наборе файлов были одновременно доступны (например, поддерживаются носители с последовательным доступом, такие как магнитные ленты).
Файловый сервис DICOM явно не включает понятие распределения набора файлов или файла по нескольким «томам/физическим носителям». Однако прозрачная поддержка такой возможности уровнем формата носителей не исключается.

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

Примечание

Примером такой взаимосвязи является сопоставление пространства имён идентификаторов файлов тому (volume) в формате носителей персонального компьютера или разделу (partition) в файловой системе рабочей станции на съёмном носителе. Другой пример — сопоставление пространства имён идентификаторов файлов каталогу и его дереву подкаталогов. В этом случае могла бы быть предоставлена возможность поддержки нескольких наборов файлов (по одному на каталог) на одном физическом носителе. Каждый набор файлов имел бы собственный файл DICOMDIR. Для обеспечения совместимости в PS3.12 должны быть определены конкретные правила сопоставления между каталогами и пространством имён идентификаторов файлов набора файлов (включая правила однозначного определения местоположения файла DICOMDIR).

В каждый набор файлов должен быть включён один файл с идентификатором DICOMDIR.

Каждый набор файлов должен быть однозначно идентифицирован UID набора файлов (File-set UID), который должен быть зарегистрирован в соответствии с правилами регистрации UID, указанными в PS3.5. При добавлении файлов в набор файлов или удалении их из него UID набора файлов не должен изменяться.

Набор файлов может также идентифицироваться идентификатором набора файлов (File-set ID), который обеспечивает простую (но, возможно, не глобально уникальную) удобочитаемую ссылку. Идентификатор набора файлов представляет собой строку от нуля (0) до шестнадцати (16) символов из подмножества репертуара G0 стандарта ISO 8859 (см. Раздел 8.5). Идентификатор набора файлов может быть связан или сопоставлен с подходящим идентификатором на уровне формата носителей.

Примечание

Продолжая пример с форматом носителей персонального компьютера, впервые использованный в предыдущем примечании, идентификатор набора файлов может быть определён как идентичный метке тома (volume label).
Файлы, не относящиеся к DICOM (файлы с содержимым, не отформатированным в соответствии с требованиями данной части стандарта DICOM), могут присутствовать в наборе файлов. Такие файлы не должны содержать метаинформацию файла DICOM (DICOM File Meta Information), указанную в Таблице 7.1-1, и могут не ссылаться на каталог медийного хранения DICOM (DICOM Media Storage Directory) (см. Раздел 8.6).

К набору файлов может также быть прикреплён файл-дескриптор набора файлов (файл «readme»). См. PS3.3 для подробной спецификации IOD базового каталога (Basic Directory IOD).

8.2 Идентификаторы файлов (File IDs)

Файлы идентифицируются по идентификатору файла (File ID), уникальному в контексте набора файлов. Идентификатор файла представляет собой упорядоченную последовательность компонентов идентификатора файла (File ID Components). Идентификатор файла может содержать от одного до восьми компонентов. Каждый компонент представляет собой строку из одного–восьми символов из подмножества репертуара G0 стандарта ISO 8859 (см. Раздел 8.5).

Такая структура идентификаторов файлов (последовательность компонентов) позволяет файловому сервису DICOM организовать выбор файлов в иерархическом режиме. Стандарт DICOM не определяет никаких соглашений об использовании структуры компонентов идентификаторов файлов и их содержимого (за исключением зарезервированного идентификатора файла DICOMDIR, см. Раздел 8.6). Более того, структура и содержимое таких идентификаторов файлов не должны передавать какой-либо семантики. Это означает, что при назначении идентификатора файла любому файлу в наборе файлов создающая прикладная сущность DICOM (DICOM Application Entity) может структурировать идентификатор файла по своему усмотрению. От любой другой AE, читающей существующие файлы или создающей новые файлы, не требуется знание какой-либо семантики, которую исходный создатель мог связать с такой структурой.

Идентификатор файла, используемый для доступа к файлу через абстрактный файловый сервис DICOM, не обязательно является единственным идентификатором файла. Формат носителей обмена (файловая система) может позволять нескольким именам файлов указывать на один и тот же физический файл. Любое использование альтернативных имён файлов выходит за рамки стандарта DICOM.

Примечание

Идентификатор файла DICOM эквивалентен общеупотребительному понятию «пути» (path name), объединённому с «именем файла». Пример допустимого идентификатора файла DICOM с четырьмя компонентами, показанными разделёнными обратной косой чертой:SUBDIR1\SUBDIR2\SUBDIR3\ABCDEFGH
Как указано в модели носителей хранения DICOM, содержимое и структура идентификатора файла не имеют семантического значения в связи с информационными объектами DICOM, хранящимися в этих файлах. Если она используется, иерархическая структура просто предоставляет средство организации файлов набора файлов и облегчает их выбор.
Файловый сервис DICOM не определяет никакого «разделителя» между компонентами идентификатора файла. Это вопрос представления значения (Value Representation), который может решаться конкретным образом на каждом уровне формата носителей. В IOD DICOM компоненты идентификатора файла обычно обрабатываются как множественные значения (multiple Values) и разделяются «обратной косой чертой». Не существует требования, чтобы уровни формата носителей использовали этот разделитель.
Файлы DICOM, хранящиеся на носителях обмена, могут иметь альтернативное имя файла или ссылку, использующую менее ограниченные имена файлов, такие как расширение имени файла (например, «.dcm» в соответствии с [RFC3240]).

8.3 Роли и сервисы управления файлами

Когда прикладные сущности DICOM участвуют в обмене информацией путём обмена носителями хранения, они выполняют через файловый сервис DICOM ряд сервисов медийного хранения (Media Storage Services):

M-WRITE — для создания новых файлов в наборе файлов и назначения им идентификатора файла;
M-READ — для чтения существующих файлов по их идентификатору файла;
M-DELETE — для удаления существующих файлов по их идентификатору файла;
M-INQUIRE FILE-SET — для запроса свободного места, доступного для создания новых файлов в наборе файлов;
M-INQUIRE FILE — для запроса даты и времени создания файла (или последнего обновления, если применимо) для любого файла в наборе файлов.

Прикладная сущность DICOM может принимать одну или более из следующих трёх ролей:

Создатель набора файлов (File-set Creator, FSC). Такая прикладная сущность осуществляет эту роль посредством операций M-WRITE для создания файла DICOMDIR (см. Раздел 8.6) и нуля или более файлов DICOM;
Читатель набора файлов (File-set Reader, FSR). Такая прикладная сущность осуществляет эту роль посредством операций M-READ для доступа к одному или нескольким файлам в наборе файлов. Читатель набора файлов не должен изменять ни один из файлов набора файлов (включая файл DICOMDIR);
Обновитель набора файлов (File-set Updater, FSU). Такая прикладная сущность осуществляет эту роль посредством операций M-READ, M-WRITE и M-DELETE. Он читает, но не должен изменять содержимое любого из файлов DICOM в наборе файлов, за исключением файла DICOMDIR. Он может создавать дополнительные файлы посредством M-WRITE или удалять существующие файлы в наборе файлов посредством M-DELETE.

Примечание

Хотя обновитель набора файлов (FSU) может включать функции, соответствующие создателю набора файлов (FSC) и читателю набора файлов (FSR), не требуется, чтобы реализации, поддерживающие роль FSU, также поддерживали роль FSC или FSR.

Использование концепции ролей в заявлениях о соответствии (Conformance Statement) DICOM позволит более точно выразить возможности реализаций, поддерживающих медийное хранение DICOM. Соответствующие реализации должны поддерживать один из следующих вариантов:

Создатель набора файлов,
Читатель набора файлов,
Создатель набора файлов и читатель набора файлов,
Обновитель набора файлов,
Обновитель набора файлов и создатель набора файлов,
Обновитель набора файлов и читатель набора файлов,
Обновитель набора файлов, создатель набора файлов и читатель набора файлов.

На основе ролей, поддерживаемых прикладной сущностью DICOM, файловый сервис DICOM должен поддерживать медийные операции, определённые в Таблице 8.3-1.

Таблица 8.3-1. Медийные операции и роли

Роли медийных операций	M-WRITE	M-READ	M-DELETE	M-INQUIRE FILE-SET	M-INQUIRE FILE
FSC	Обязательно	Не требуется	Не требуется	Обязательно	Не требуется
FSR	Не требуется	Обязательно	Не требуется	Не требуется	Обязательно
FSC+FSR	Обязательно	Обязательно	Не требуется	Обязательно	Обязательно
FSU	Обязательно	Обязательно	Обязательно	Обязательно	Обязательно
FSU+FSC	Обязательно	Обязательно	Обязательно	Обязательно	Обязательно
FSU+FSR	Обязательно	Обязательно	Обязательно	Обязательно	Обязательно
FSU+FSC+FSR	Обязательно	Обязательно	Обязательно	Обязательно	Обязательно

Примечание

Подготовка носителей выходит за рамки данной части стандарта DICOM. Однако предполагается, что она выполняется создателем набора файлов (FS Creator).
Файловый сервис DICOM не требует, чтобы возможности обновления файлов (например, дописывание) поддерживались каждым выбранным определением формата носителей. Отсутствие поддержки таких возможностей обновления файлов для файла DICOMDIR может просто привести к необходимости удалить файл и создать новый, чтобы сохранить согласованность информации каталога.
Если содержимое файла должно быть обновлено или изменено обновителем набора файлов (FSU), это считается согласно данной части стандарта DICOM операцией M-DELETE, за которой следует операция M-WRITE. FSU несёт ответственность за обеспечение внутренней согласованности файла и его соответствия PS3.10 и конкретному хранимому классу SOP (SOP Class), точно так же, как если бы FSU создавал новый файл. В частности, если реализации FSU необходимо обновить содержимое файла, но она не способна распознать и полностью обработать содержимое преамбулы файла (см. Раздел 7.1), она может рассмотреть возможность установки первых четырёх байтов преамбулы в «DICM» с последующими 124 байтами в 00H. Это позволило бы избежать внесения несоответствий между содержимым преамбулы файла и остальным содержимым файла. Пример такой ситуации может возникнуть, когда смещение TIFF IFD 0 в преамбуле файла указывает на дополнительный TIFF IFD, встроенный в набор данных DICOM, и операция обновления изменяет местоположение этого встроенного TIFF IFD.

8.4 Доступ к содержимому файла

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

Примечание

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

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

Файловый сервис DICOM должен предоставлять возможность:

для FSR или FSU выполнить M-READ для чтения нуля или более байтов содержимого файла;
для FSC или FSU выполнить M-WRITE для записи одного или более байтов, составляющих содержимое файла.

Примечание

Файловый сервис DICOM не требует какой-либо конкретной возможности для выборочного доступа на чтение или запись содержимого файла (например, позиционирование (seek) или дописывание (append)). Однако он не ограничивает конкретные определения формата носителей в поддержке таких функций.

8.5 Набор символов

Идентификаторы файлов и идентификаторы наборов файлов должны быть символьными строками, состоящими из символов подмножества репертуара G0 стандарта ISO 8859. В это подмножество входят следующие символы:

A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z (заглавные)

1, 2, 3, 4, 5, 6, 7, 8, 9, 0 и _ (подчёркивание)

Примечание

Это набор символов, определённый для кодовых строк (Code Strings, представление значения CS — см. PS3.5), за исключением того, что ПРОБЕЛ не включён.
Этот набор символов выбран для ограничения символов в идентификаторах файлов и идентификаторах наборов файлов теми, которые не конфликтуют с зарезервированными символами и разделителями в файловых системах, определённых в PS3.12. Разделители компонентов или другие требуемые разграничения, определённые в PS3.12, не являются частью идентификаторов файлов или идентификаторов наборов файлов.

8.6 Зарезервированный идентификатор файла DICOMDIR

В каждом наборе файлов должен существовать один файл с идентификатором DICOMDIR как член набора. Этот идентификатор файла состоит из единственного компонента (см. Раздел 8.2 о структуре идентификатора файла). Он содержит каталог медийного хранения DICOM (DICOM Media Storage Directory) (см. PS3.3 для подробной спецификации IOD базового каталога (Basic Directory IOD)), который включает общую информацию обо всём наборе файлов. Эта общая информация присутствует всегда, но при необходимости содержимое каталога может быть оставлено пустым в средах, где оно не требуется. Если файл DICOMDIR не существует в наборе файлов, набор файлов не соответствует PS3.10. DICOMDIR не должен ссылаться на файлы вне набора файлов, к которому он принадлежит.

Примечание

Пример содержимого файла DICOMDIR можно найти в Приложении A.
Если спецификация формата носителей в PS3.12 сопоставляет начало набора файлов с конкретным узлом каталога в конкретной файловой системе, идентификаторы файлов, включая идентификаторы файлов DICOMDIR, будут относиться к пути этого узла каталога.

Файл DICOMDIR должен использовать явный синтаксис передачи Explicit VR Little Endian (UID=1.2.840.10008.1.2.1) для кодирования экземпляра SOP каталога медийного хранения (Media Storage Directory SOP Instance). Файл DICOMDIR должен соответствовать формату файла DICOM, указанному в Разделе 7 настоящего стандарта. В частности:

SOP Class UID в метаинформации файла (заголовок файла DICOMDIR) должен иметь значение, указанное в PS3.4 настоящего стандарта для класса SOP каталога медийного хранения (Media Storage Directory SOP Class);
SOP Instance UID в метаинформации файла (заголовок файла DICOMDIR) должен содержать значение UID набора файлов (File-set UID). UID набора файлов назначается прикладной сущностью, создавшей набор файлов (роль FSC, см. Раздел 8.3), с нулём или более файлов DICOM. Это значение UID набора файлов не должно изменяться никакими другими прикладными сущностями, читающими или обновляющими содержимое набора файлов.

Примечание

Эта политика отражает тот факт, что набор файлов является абстракцией «контейнера», внутри которого файлы могут создаваться или читаться. UID набора файлов относится к «контейнеру», а не к его содержимому. Набор файлов в файловом сервисе DICOM предназначен для сопоставления с поддерживающим элементом выбранного формата носителей (например, томом или разделом).
Стандарт не запрещает создание дубликатов набора файлов (т.е. набора файлов с тем же UID набора файлов). Однако в пределах управляемого домена наборов файлов для предотвращения создания таких дубликатов может использоваться доменная политика.

9 Требования к соответствию

Реализация PS3.10 должна:

иметь заявление о соответствии (Conformance Statement), основанное на профиле приложения медийного хранения (Media Storage Application Profile) PS3.11, в соответствии с рамочной моделью, определённой в PS3.2, которое будет включать рассмотрение требований безопасности, определённых в Разделе 7.5;
соответствовать требованиям формата файла DICOM, указанным в Разделе 7;
поддерживать файловый сервис DICOM, как указано в Разделе 8, в одной или более ролях, определённых в Разделе 8.3;
выполнять медийные операции, определённые в Таблице 8.3-1, в соответствии с поддерживаемой ролью;
поддерживать файл DICOMDIR с содержимым, указанным для класса SOP каталога медийного хранения (Media Storage Directory SOP Class) в PS3.4.

A Пример содержимого файла DICOMDIR (информативное)

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

A.1 Пример простого содержимого каталога

Таблица A.1-1 показывает в упрощённом виде содержимое простого файла DICOMDIR. Значения элементов указаны в квадратных скобках (например, [1.2.840.10008.34.7.6]). Байтовые смещения показаны символическими значениями в фигурных скобках (например, {1493}).

Таблица A.1-1. Пример содержимого каталога

	Мета-инфо	128 bytes 4 bytes 0002,0000 0002,0001 0002,0002 0002,0003 0002,0010 0002,0012 ...	File Preamble [all bytes set to 00H] DICOM Prefix [DICM] File Meta Information Group Length File Meta-Information Version [0001] Media Storage SOP Class UID [1.2.840.10008.1.3.10] Media Storage SOP Instance UID [1.2.840.23856.36.45.3] Transfer Syntax UID [1.2.840.10008.1.1] Implementation Class UID [1.2.840.23856.34.90.3] ...
	Идентификация набора файлов	0004,1130 ...	File-set ID [EXAMPLE] ...
	Общая информация каталога	0004,1200 0004,1202 0004,1212 ... 0004,1220	Offset of First Record of Root Directory Entity {1688} Offset of Last Record of Root Directory Entity {6F18} File-set Consistency Flag [0000H] ... Sequence записей каталога (Directory Record Sequence). Значение этого элемента данных включает следующую последовательность элементов (Sequence of Items).
{1688}	Item Tag	FFFE,E000	Элемент данных Item (включает следующие элементы данных)
	Patient A Запись каталога	0004,1400 0004,1410 0004,1420 ...	Offset of the next Directory Record in Directory Entity {4624} Record In-use Flag [FFFFH] Offset of Referenced Lower Level Directory Entity {1828} ...
	Patient A Запись каталога	0004,1430	Directory Record Type [PATIENT]
	Ключи выбора	0010,0010 0010,0020 ...	Patient's Name [Patient A] Patient ID [123456789AB] ....
	Item Delimitation Tag	FFFE,E00D	Тег Item Delimitation присутствует только если элемент имеет неопределённую длину
{1828}	Item Tag	FFFE,E000	Элемент данных Item (включает следующие элементы данных)
	Study 1 Запись каталога	0004,1400 0004,1410 0004,1420 ...	Offset of the next Directory Record in Directory Entity (не показано в примере) Record In-use Flag [FFFFH] Offset of Referenced Lower Level Directory Entity {2300} ...
	Study 1 Запись каталога	0004,1430	Directory Record Type [STUDY]
	Ключи выбора	0020,000D 0020,0010 ...	Study Instance UID [1.2.840.4656.23.4568745] Study ID [srt78UJ] ....
	Item Delimitation Tag	FFFE,E00D	Тег Item Delimitation присутствует только если элемент имеет неопределённую длину
{2300}	Item Tag	FFFE,E000	Элемент данных Item (включает следующие элементы данных)
	Series 1 Запись каталога	0004,1400 0004,1410 0004,1420 ...	Offset of the next Directory Record in Directory Entity (не показано в примере) Record In-use Flag [0FFFFH] Offset of Referenced Lower Level Directory Entity {2682} ...
	Series 1 Запись каталога	0004,1430	Directory Record Type [SERIES]
	Ключи выбора	0008,0060 0020,0011 ...	Modality [NM] Series Number [2] ...
	Item Delimitation Tag	FFFE,E00D	Тег Item Delimitation присутствует только если элемент имеет неопределённую длину
{2682}	Item Tag	FFFE,E000	Элемент данных Item (включает следующие элементы данных)
	Image 1 Запись каталога	0004,1400 0004,1410 0004,1420 ...	Offset of the next Directory Record in Directory Entity {3420} Record In-use Flag [FFFFH] Offset of Referenced Lower Level Directory Entity [00000000H] ...
		0004,1430	Directory Record Type [IMAGE]
		0004,1500 0004,1510 0004,1511 0004,1512	Referenced File ID [DIR\TDRI\3856G3] Referenced SOP Class UID in File [1.2.840.10008.5.1.4.1.1.20] Referenced SOP Instance UID in File [1.2.840.34.56.78999654.234] Referenced Transfer Syntax UID in File [1.2.840.10008.1.2.1]
	Ключи выбора	0008,0018 0020,0013 ...	Image SOP Instance UID [1.2.840.34.56.78999654.234] Image Number [1] ...
	Item Delimitation Tag	FFFE,E00D	Тег Item Delimitation присутствует только если элемент имеет неопределённую длину
{3420}	Item Tag	FFFE,E000	Элемент данных Item (включает следующие элементы данных)
	Image 2 Запись каталога	0004,1400 0004,1410 0004,1420 ...	Offset of the next Directory Record in Directory Entity [00000000H] Record In-use Flag [FFFFH] Offset of Referenced Lower Level Directory Entity [00000000H] ...
		0004,1430	Directory Record Type [IMAGE]
		0004,1500 0004,1510 0004,1511 0004,1512	Referenced File ID [DIR\TDRI\3856G7] Referenced SOP Class UID in File [1.2.840.10008.5.1.4.1.1.20] Referenced SOP Instance UID in File [1.2.840.34.56.78999654.235] Referenced Transfer Syntax UID in File [1.2.840.10008.1.2.2]
	Ключи выбора	0008,0018 0020,0013 ...	Image SOP Instance UID [1.2.840.34.56.78999654.235] Image Number [2] ...
	Item Delimitation Tag	FFFE,E00D	Тег Item Delimitation присутствует только если элемент имеет неопределённую длину
{4624}	Item Tag	FFFE,E000	Элемент данных Item (включает следующие элементы данных)
	Patient B Запись каталога	0004,1400 0004,1410 0004,1420 ...	Offset of the next Directory Record in Directory Entity {6F18} Record In-use Flag [FFFFH] Offset of Referenced Lower Level Directory Entity {5012} ...
	Patient B Запись каталога	0004,1430	Directory Record Type [PATIENT]
	Ключи выбора	0010,0010 0010,0020 ...	Patient's Name [Patient B] Patient ID [23456789ABC] ....
	Item Delimitation Tag	FFFE,E00D	Тег Item Delimitation присутствует только если элемент имеет неопределённую длину
{5012}	Item Tag	FFFE,E000	Элемент данных Item (включает следующие элементы данных)
{5012}	Study 1 Запись каталога ...
... (Элементы последовательности для остальных подчинённых записей каталога)
{6F18}	Item Tag	FFFE,E000	Элемент данных Item (включает следующие элементы данных)
	Patient C Запись каталога	0004,1400 0004,1410 0004,1420 0004,1430 ...	Offset of the next Directory Record in Directory Entity {00000000H} Record In-use Flag [FFFFH] Offset of Referenced Lower Level Directory Entity {...} Directory Record Type [PATIENT] ...
	Ключи выбора	0010,0010 0010,0020 ....	Patient Name [Patient C] Patient ID [34567890ABC] ....
	Item Delimitation Tag	FFFE,E00D	Тег Item Delimitation присутствует только если элемент имеет неопределённую длину
	Sequence Delimitation Tag	FFFE,E0DD	Используется только если Directory Record Sequence (0004,1220) имеет неопределённую длину — для разграничения конца значения элемента данных Directory Record Sequence.
... (Элементы последовательности для остальных подчинённых записей каталога)

A.2 Пример содержимого файла DICOMDIR с несколькими ссылочными файлами

Этот раздел был ранее определён в DICOM. В настоящее время он выведен из употребления. См. PS3.3-1998.

B Файлы структурированных документов HL7

Структурированные документы (Structured Documents), определённые стандартом HL7, могут храниться на носителях обмена DICOM и могут ссылаться из экземпляров SOP DICOM (включая каталог медийного хранения DICOMDIR).

Инкапсулированный документ CDA (Encapsulated CDA) ссылается из каталога медийного хранения так же, как и любой другой экземпляр SOP DICOM.

Структурированный документ HL7 — это агрегированный мультимедийный объект, состоящий из базового XML-кодированного документа и нуля или более мультимедийных компонентов (например, графических материалов), которые считаются неотъемлемой частью объекта. Мультимедийные компоненты должны кодироваться встроенными в инкапсулированный XML-документ, за исключением случаев, когда они являются ссылками на другие экземпляры SOP DICOM, содержащиеся на носителе.