ГОСТ Р ИСО 17432-2009. Национальный стандарт Российской Федерации. Информатизация здоровья. Сообщения и обмен информацией. Веб-доступ к постоянным объектам DICOM

(утв. и введен в действие Приказом Ростехрегулирования от 14.09.2009 № 407-ст)

1 июля 2010 года

1 ПОДГОТОВЛЕН Федеральным государственным учреждением «Центральный научно-исследовательский институт организации и информатизации здравоохранения Росздрава» (ЦНИИОИЗ Росздрава) и Государственным научным учреждением «Центральный научно-исследовательский и опытно-конструкторский институт робототехники и технической кибернетики» на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 468 «Информатизация здоровья» при ЦНИИОИЗ Росздрава — постоянным представителем ИСО ТК 215

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 14 сентября 2009 г. № 407-ст

4 Настоящий стандарт идентичен международному стандарту ИСО 17432:2004 «Информатизация здоровья. Сообщения и обмен информацией. Веб-доступ к постоянным объектам DICOM» (ISO 17432:2004 «Health informatics — Messages and communication — Web access to DICOM persistent objects», IDT).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА

5 ВВЕДЕН ВПЕРВЫЕ

6 ПЕРЕИЗДАНИЕ. Ноябрь 2018 г.

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

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

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

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

Настоящий стандарт определяет средства, на основании которых запрос на доступ к постоянным объектам DICOM имеет вид HTTP URL/URI-запроса (см. IETF RFC2396), который, в свою очередь, содержит указатель на конкретный объект DICOM в форме уникального идентификатора. Запрос также определяет формат возвращаемого результата. Примеры включают:

• MIME (многоцелевые расширения электронной почты в сети Интернет) тип содержимого (например, application/dicom или image/jpeg для изображений, application/dicom или application/rtf или xml для отчетов);
• кодировку содержимого;
• отчет в виде HL7/CDA Level 1.

Параметры запроса URL, как описывается в настоящем стандарте, являются достаточными для сервера HTTP, чтобы он мог действовать как DICOM SCU (пользовательская служба) и получать запрашиваемый объект от подходящего DICOM SCP (служба доступа), используя базовую линию функциональности DICOM, как описывается в DICOM PS 3.4 и DICOM PS 3.7.

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

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

Настоящий стандарт определяет веб-сервис для доступа и воспроизведения объектов DICOM (Digital Imaging and Communications in Medicine — Цифровые изображения и связь в медицине) (например, изображений, иллюстрированных медицинских отчетов). Такие услуги требуются для распределения результатов и изображений между медицинскими специалистами. Настоящий стандарт предлагает простой механизм доступа к объектам DICOM с HTML-страниц или из XML-документов, по протоколу HTTP/HTTPs с использованием уникальных идентификаторов DICOM (DICOM UIDs). Данные могут по желанию запрашивающей стороны быть получены либо в виде, готовом для просмотра (например, в формате JPEG или GIF), либо в исходном формате DICOM.

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

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

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

В настоящем стандарте использованы нормативные ссылки на следующие стандарты. Если в ссылке указана дата издания, то должно использоваться только цитируемое издание. Если дата в ссылке не указана, то должно использоваться последнее издание документа (включая все поправки).

ИСО/МЭК 10918-2:1995 Информационная технология. Цифровое сжатие и кодирование однотонных статичных изображений. Тестирование совместимости (ISO/IEC 10918-2:1995, Information technology — Digital compression and coding of continuous-tone still images: Compliance testing)

DICOM PS 3.3 Цифровое формирование изображений и передача информации в медицине. Определения информационных объектов (DICOM PS 3.3, Digital Imaging and Communications in Medicine, Information Object Definitions)

DICOM PS 3.4 Цифровое формирование изображений и передача информации в медицине. Условия категорий обслуживания (DICOM PS 3.4, Digital Imaging and Communications in Medicine, Service Class Specifications)

DICOM PS 3.5 Цифровое формирование изображений и передача информации в медицине. Структура данных и кодирование (DICOM PS 3.5, Digital Imaging and Communications in Medicine, Data Structures and Encoding)

DICOM PS 3.6 Цифровое формирование изображений и передача информации в медицине. Словарь данных (DICOM PS 3.6, Digital Imaging and Communications in Medicine, Data Dictionary)

DICOM PS 3.7 Цифровое формирование изображений и передача информации в медицине. Обмен сообщениями (DICOM PS 3.7, Digital Imaging and Communications in Medicine, Message Exchange)

DICOM PS 3.10 Цифровое формирование изображений и передача информации в медицине. Хранение данных и форматы файлов для обмена данными (DICOM PS 3.10, Digital Imaging and Communications in Medicine, Media Storage and File Format for Data Interchange)

DICOM PS 3.11 Цифровое формирование изображений и передача информации в медицине. Профили приложений для хранения данных (DICOM PS 3.11, Digital Imaging and Communications in Medicine, Media Storage Application Profiles)

DICOM PS 3.14 Цифровое формирование изображений и передача информации в медицине. Стандартная функция просмотра в полутоновом режиме (DICOM PS 3.14, Digital Imaging and Communications in Medicine, Grayscale Standard Display Function)

DICOM PS 3.15 Цифровое формирование изображений и передача информации в медицине. Профили безопасности (DICOM PS 3.15, Digital Imaging and Communications in Medicine, Security Profiles)

HL7 CDA Здравоохранение седьмого уровня. Архитектура клинических документов (CDA) [HL7 CDA, Health Level Seven, Clinical Document Architecture (CDA)]

IETF RFC2045 (и все последующие) MIME — Многоцелевое расширение электронной почты (IETF RFC2045 et seq., MIME Multipurpose Internet Mail Extension)

IETF RFC2396 Универсальные коды ресурсов (URI). Универсальный синтаксис [IETF RFC2396, Uniform Resource Identifiers (URI): Generic Syntax]

IETF RFC2616 Протокол передачи гипертекста — HTTP/1.1 (IETF RFC2616, Hypertext Transfer Protocol — HTTP/1.1)

IETF RFC3240 Application/dicom MIME — Регистрация подтипов (IETF RFC3240, Application/dicom MIME Sub-type Registration)

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1 постоянный объект DICOM (DICOM persistent object): Экземпляр объекта данных, как указано в DICOM PS 3.3, которому был присвоен уникальный идентификатор в формате, определенном для уникального идентификатора (UID) экземпляра SOP в DICOM PS 3.3, и который был выбран в качестве объекта, надежно сохраняемого в течение определенного периода времени.

Примечание - В рамках стандарта DICOM постоянный объект DICOM описывается как экземпляр составной пары «действие-объект» (SOP).

3.2 клиентская веб-система (web client system): Система, использующая интернет-технологии (веб, электронная почта) для получения постоянных объектов DICOM от доступного через веб сервера DICOM по протоколу HTTP/HTTPs.

3.3 сервер DICOM, доступный через веб (web enabled DICOM server): Система, управляющая постоянными объектами DICOM и способная передать их по запросу от клиентской веб-системы.

3.4 веб-доступ к постоянным объектам DICOM (web access to DICOM persistent objects): Служба, позволяющая клиентской веб-системе получать перманентные объекты DICOM, управляемые доступным через веб сервером DICOM, по протоколу HTTP/HTTPs.

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

DICOM — цифровые изображения и связь в медицине;

HL7 — медицинский стандарт седьмого уровня;

HTML — язык гипертекстовой разметки;

HTTP — протокол передачи гипертекста;

HTTPs — протокол передачи гипертекста защищенный;

MIME — многоцелевые расширения электронной почты;

SOP — пара «действие-объект»;

UID — уникальный идентификатор DICOM;

URL/URI — унифицированный указатель/идентификатор ресурса;

XML — расширяемый язык разметки.

5 Требования к обмену данными

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

5.2 HTTP-запрос

5.2.1 Метод

Запрос по протоколу HTTP должен использовать метод GET, как определено в IETF RFC2616.

5.2.2 Параметры HTTP-запроса

Параметры компонента запроса-URI, направляемого на веб-сервер через HTTP-запрос методом GET, должны быть представлены в соответствии с IETF RFC2396.

Примечания

1 Другие компоненты запроса-URI зависят от конфигурации, например от местоположения и языка скрипта сервера DICOM, доступного через веб.

2 Средства, с помощью которых клиентская веб-система получает значения необходимых параметров для веб-доступа к объектам DICOM, не входят в сферу применения настоящего стандарта.

5.2.3 Список типов данных, поддерживаемых в ответе

Поле «Accept» запроса методом GET должно определять тип(ы) данных, воспринимаемых клиентской веб-системой. Эти типы данных должны включать, по крайней мере, элементы из списка типов MIME (см. IETF RFC2045), установленного в разделе 6, посвященном типам постоянных объектов DICOM.

Примечание - Обычно поле «Accept» посылается веб-клиентом как «/». Необязательный параметр задает тип(ы) MIME, предпочтительные для веб-клиента, как подмножество типов, определенных в поле «Accept».

5.2.4 Список кодировок, поддерживаемых в ответе

Поле «Accept-charset» запроса методом GET должно определять кодировку возвращаемого объекта. Если поле «Accept-charset» метода GET отсутствует или доступный через веб сервер DICOM не поддерживает данную кодировку, то кодировка ответа будет определяться по усмотрению доступного через веб сервера DICOM.

Примечание - Обычно пользователь веб-клиента не контролирует поле «Accept-charset». Необязательный параметр определяет кодировку, которая должна использоваться в возвращаемом объекте.

5.3 Ответ HTTP-сервера

5.3.1 Общая информация

Ответ должен быть представлен HTTP-сообщением, определенным в IETF RFC2616.

Примечание — Содержимое основной части сообщения меняется в соответствии с типом MEDIA, как это определено в 5.3.2.2 и 5.3.4.2.

5.3.2 Основная часть одиночного ответа части подтипа MIME DICOM

5.3.2.1 Тип MIME

Тип MIME должен быть «application/dicom», как это определено в IETF RFC3240 и DICOM PS 3.11.

5.3.2.2 Содержимое

Содержимое основной части должно быть в формате «Part 10 File», включая метазаголовок в соответствии с DICOM PS 3.10.

5.3.3 Синтаксис передачи

Возвращаемый объект DICOM должен быть закодирован с применением одного из синтаксисов передачи, указанного в параметре запроса синтаксиса передачи, как это определено в 7.2.12. По умолчанию синтаксис передачи принимается как «Explicit VR Little Endian».

Примечание - Подразумевается, что полученные изображения по умолчанию отправляются в несжатом виде.

5.3.4 Основная часть ответа, не соответствующего DICOM MIME-типу

5.3.4.1 Тип MIME

Тип MIME должен быть одним из типов MIME, который определен параметром contentType. Предпочтителен тип, наиболее подходящий для веб-клиента. В любом случае заданный тип должен быть совместим с полем «Accept» метода GET.

Примечание - Если необходимый тип содержимого не может быть обработан, то протокол HTTP возвращает сообщение об ошибке (406 — недопустимо).

5.3.4.2 Содержимое

Содержимое ответа должно включать единственную часть MIME, содержащую запрашиваемый объект.

Примечание - Включение в ответ множественных объектов не поддерживается настоящим стандартом. Параметры позволяют запросить только один объект. Большинство современных веб-клиентов способны получать единичные объекты из немногоэлементной основной части MIME и не поддерживают многоэлементные связанные или смешанные ответы.

6 Типы постоянных объектов

6.1 Общая информация

Особенности некоторых конкретных типов объектов определены в 6.2 - 6.5.

Во всех случаях классификация зависит от SOP-класса объектов, позволяя клиенту или приложению формировать HTML-страницу для клиента, чтобы определить требования к запросу до его поступления.

6.2 Объекты с однокадровыми изображениями

6.2.1 Доступные объекты

К этой категории относятся все экземпляры объектов классов SOP, определенных в DICOM PS 3.3, содержащие однокадровые изображения, экземпляры объектов многокадровых классов SOP, содержащие только один кадр, или экземпляры объектов, содержащие единственный кадр, доступный из экземпляров многокадровых классов SOP посредством параметра «frameNumber».

6.2.2 Ограничения типов MIME

Сервер должен быть способен посылать ответ для каждого из следующих типов MIME:

• application/dicom;
• image/jpeg.

Если параметр «contentType» отсутствует в запросе, то ответ должен содержать тип MIME image/jpeg при условии совместимости с полем «Accept» метода GET.

При возврате типа MIME image/jpeg изображение должно быть закодировано посредством применяемого для формата JPEG неиерархического непоследовательного алгоритма 8-битового кодирования Хаффмана с потерями в соответствии с ИСО/МЭК 10918-2:1995.

Примечание - Выбор типа image/jpeg в качестве установки по умолчанию для сплошных тоновых изображений является следствием его всеобщей поддержки веб-клиентами.

Сервер должен также поддерживать следующие типы MIME:

• image/gif;
• image/png;
• image/jp2.

Сервер может также поддерживать другие типы MIME.

6.3 Объекты с многокадровыми изображениями

6.3.1 Включенные объекты

К этой категории относятся все классы SOP, определенные в DICOM PS 3.3, являющиеся объектами с многокадровыми изображениями.

6.3.2 Ограничения типов MIME

Сервер должен быть способен посылать ответ типа MIME application/dicom.

Если параметр «contentType» отсутствует в запросе, то ответ должен содержать тип MIME application/dicom.

Сервер должен также поддерживать следующие типы MIME:

• video/mpeg;
• image/gif.

Сервер может также поддерживать другие типы MIME.

6.4 Текстовые объекты

6.4.1 Включенные объекты

К этой категории относятся все классы SOP, определенные в DICOM PS 3.3, содержащие модуль содержимого документа SR.

Примечание - К этой категории относятся все классы SOP, являющиеся документами SR, например повествовательный текст, структурированные отчеты, документы САПР, отчеты об измерениях и документы по выбору ключевых объектов.

6.4.2 Ограничения типов MIME

Сервер должен быть способен посылать ответ любого из следующих типов MIME:

• application/dicom;
• text/plain;
• text/html.

Если параметр contentType отсутствует в запросе или содержит только не поддерживаемые сервером типы MIME, то ответ должен содержать тип MIME text/html.

Рекомендуется, чтобы поддерживал также следующие типы MIME:

• text/xml;
• application/pdf;
• text/rtf;
• тип MIME «CDA», в соответствии с HL7 CDA, например application/x-hl7-cda-level-one+xml.

Сервер может также поддерживать другие типы MIME.

6.5 Другие объекты

6.5.1 Включенные объекты

Эта категория должна включать все объекты всех классов SOP, определенных в DICOM PS 3.3, которые не включены в категории, описанные в 6.2 - 6.4, и рассматриваются в DICOM PS 3.3 как классы постоянных объектов.

6.5.2 Ограничения типов MIME

Сервер должен быть способен посылать ответ типа MIME application/dicom.

Сервер может также поддерживать другие типы MIME.

Если параметр contentType отсутствует в запросе, то ответ должен содержать тип MIME application/dicom.

7 Параметры

7.1 Параметры, доступные для всех постоянных объектов DICOM

7.1.1 Общая информация

Параметры, определенные в 7.1.2 - 7.1.8, применимы ко всем поддерживаемым классам SOP DICOM.

Для идентификации объекта DICOM требуется только один UID, поскольку любой UID уникален глобально. Однако настоящий стандарт требует, чтобы в информационной модели DICOM были определены UID более высоких уровней (т.е. последовательность и исследование) для поддержки использования устройств DICOM, поддерживающих только базовую иерархическую (предпочтительнее, чем расширенную реляционную) модель запросов/ответов, которая требует, чтобы UID экземпляра исследования и UID экземпляра последовательности были определены при восстановлении экземпляра SOP в соответствии с DICOM PS 3.4.

7.1.2 Тип запроса

Тип осуществляемого запроса. Этот параметр является обязательным.

Параметр должен иметь имя «requestType».

Значением параметра должно быть «WADO».

Примечание - Этот параметр позволяет вводить другие типы запросов в будущем, используя аналогичный синтаксис.

7.1.3 Уникальный идентификатор исследования

UID экземпляра исследования соответствует DICOM PS 3.3. Этот параметр является обязательным.

Параметр должен иметь имя «studyUID».

Значение параметра должно быть закодировано в форме строки уникального идентификатора (UID) в соответствии с DICOM PS 3.5, за исключением того, что к строке не надо добавлять символ NULL, чтобы получить четное значение ее длины.

7.1.4 Уникальный идентификатор последовательности

UID экземпляра последовательности соответствует DICOM PS 3.3. Этот параметр является обязательным.

Параметр должен иметь имя «seriesUID».

Значение параметра должно быть закодировано в виде строки уникального идентификатора (UID) в соответствии с DICOM PS 3.5, за исключением того, что к строке не надо добавлять символ NULL, чтобы получить четное значение ее длины.

7.1.5 Уникальный идентификатор объекта

UID экземпляра SOP соответствует DICOM PS 3.3. Этот параметр является обязательным.

Параметр должен иметь имя «objectUID».

Значение параметра должно быть закодировано в виде строки уникального идентификатора (UID) в соответствии с DICOM PS 3.5, за исключением того, что к строке не надо добавлять символ NULL, чтобы получить четное значение ее длины.

7.1.6 Тип MIME-ответа

Тип(ы) MIME, желательные веб-клиенту для ответа от сервера, соответствуют IETF RFC2616. Этот параметр является необязательным.

Параметр должен иметь имя «contentType».

Значением параметра должен быть список типов MIME, разделенных символом «,», перечисленных в порядке предпочтения в соответствии с IETF RFC2616.

Веб-клиент должен предоставить список типов содержимого, которые он поддерживает, в поле «Accept» метода GET. Значением параметра запроса contentType должно быть одно из значений, указанных в этом поле.

Примечания

1 Обычно поле «Accept» пересылается веб-клиентом в виде «/», который совместим с любыми типами MIME.

2 Когда этот параметр отсутствует, тип содержимого ответа по умолчанию определяется в соответствии с ограничениями типов MIME в 6.2.2, 6.3.2, 6.4.2, 6.5.2.

7.1.7 Кодировка ответа

Набор символов, которыми должен быть закодирован возвращаемый объект, соответствует IETF RFC2616. Этот параметр является необязательным.

Параметр должен иметь имя «charset».

Значением параметра должен быть список наборов символов, разделенных символом «,», перечисленных в порядке предпочтения в соответствии с IETF RFC2616.

Веб-клиент может предоставить список наборов символов, которые он поддерживает, в поле «Accept-charset» метода GET. Если это поле существует, то значением параметра запроса «charset» должно быть одно из значений, указанных в этом поле.

Сервер может поддерживать или не поддерживать преобразование набора символов. Если преобразование набора символов поддерживается, то:

• текстовые объекты DICOM, полученные иначе, чем как тип MIME application/dicom (например, text/plain), могут быть возвращены закодированными в запрошенном наборе символов (преобразованного, если необходимо);
• объекты DICOM, полученные как тип MIME application/dicom, содержат все возвращенные строки в запрошенном наборе символов (преобразованные, если необходимо) и модифицированные специальным набором символов (0008, 0005) (если необходимо).

Перечень зарегистрированных IANA наборов символов определяет имена и многочисленные альтернативные имена для большинства наборов символов. Стандартным значением для использования в WADO является значение, отмеченное IANA как «предпочтительное для MIME». Если IANA не отмечено ни одно из альтернативных имен как «предпочтительное для MIME», то имя, используемое в DICOM, должно быть значением, используемым для WADO.

Примечание — В таблице D.1 приложения D представлено справочное отображение некоторых значений IANA в термины, определенные специальным набором символов DICOM.

7.1.8 Анонимизация объекта

Удаление всей информации, идентифицирующей пациента, из объекта DICOM, если этого не было сделано ранее, выполняется в соответствии с DICOM PS 3.15. Этот параметр является необязательным, и он должен использоваться только в случае, когда значением параметра «contentType» является application/dicom.

Параметр должен иметь имя «anonymize».

Значением параметра должно быть «yes».

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

Сервер должен вернуть УИП (UID) на новый экземпляр SOP, если содержимое объекта еще не было анонимизировано.

Примечания

1 Настоящий стандарт не вводит каких-либо требований в отношении безопасности. Не исключается, что информация, содержащаяся в объектах DICOM, идентифицирует пациента. Используемый протокол (т.е. HTTP) может быть заменен протоколом HTTPs, который является его расширением в отношении безопасности, для защиты информации при передаче. Исходная реализация DICOM определяет, предоставлять или нет доступ к конкретному объекту DICOM на основании своей политики или механизма обеспечения безопасности. Маловероятно, что сервер исполнит запрос от неизвестного пользователя (например, получившего доступ по протоколу HTTP), кроме случаев, когда запрос сделан по данным, не содержащим идентифицирующей пациента информации и санкционированным для публичного просмотра.

2 Анонимизация объекта, в частности, позволяет образовательным файловым системам или клиническим пробным приложениям предлагать доступ к оригинальным изображениям, хранящимся в PACS (телекоммуникационных службах персонального доступа), без раскрытия личности пациента с возможностью сохранения деидентифицированной копии оригинального изображения. За анонимизацию отвечает сервер. С целью сохранения конфиденциальности пациента, сервер, вероятно, откажется предоставлять анонимизированный экземпляр SOP неизвестному или неавторизованному лицу, за исключением случаев, когда сервер уверен, что экземпляр SOP не содержит идентифицирующую пациента информацию. Анонимизация может реализовываться, например, «затиранием» полей любых комментариев, содержащих персональную информацию, закодированную в пикселях или структурах более высокого уровня.

7.2 Параметры, относящиеся только к постоянным объектам DICOM с однокадровыми и многокадровыми изображениями

7.2.1 Общая информация

Эти параметры должны использоваться только при запросе объектов с однокадровыми или многокадровыми изображениями, определенных в 6.2 и 6.3 соответственно.

7.2.2 Аннотация к объекту

Аннотация к объекту извлекается и отображается в виде изображения. Этот параметр является необязательным. Он не должен использоваться, если значением параметра «contentType» является application/dicom или тип MIME не относится к изображению (например, text/*). Если этот параметр не присутствует у объекта с изображением, то аннотация не может быть добавлена к изображению.

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

Параметр должен иметь имя «annotation». Значением параметра является не пустой список, содержащий один или несколько из следующих элементов, разделенных символом «,»:

• «patient» для отображения на изображении информации о пациенте (например, имя пациента, дата рождения);
• «technique» для отображения технических характеристик изображения (например, номер изображения, дата обследования, расположение изображения).

Точные тип и представление аннотации определяются сервером. Аннотация записывается в пиксели возвращаемого изображения.

7.2.3 Число строк пикселей

Параметр должен иметь имя «rows».

Значение параметра должно быть выражено целым числом, обозначающим высоту возвращаемого изображения. Этот параметр является необязательным. Он не должен использоваться, если значением параметра «contentType» является application/dicom.

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

Значение параметра должно быть закодировано строкой с целочисленным значением (IS) в соответствии с DICOM PS 3.5.

7.2.4 Число столбцов пикселей

Параметр должен иметь имя «columns».

Значение параметра должно быть выражено целым числом, обозначающим ширину возвращаемого изображения. Этот параметр является необязательным. Он не должен использоваться, если значением параметра «contentType» является application/dicom.

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

Значение параметра должно быть закодировано строкой с целочисленным значением (IS) в соответствии с DICOM PS 3.5.

7.2.5 Область изображения

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

Этот параметр является необязательным.

Параметр должен иметь имя «region».

Он не должен использоваться, если значением параметра «contentType» является application/dicom.

Значение параметра должно быть выражено списком из четырех строк с положительными десятичными числами, разделенными символом «,» и определяющими возвращаемую область исходного изображения. Эти десятичные числа должны иметь значения в системе координат, нормализованной по отношению к размеру матрицы оригинального изображения, измеряемой строками и столбцами, в диапазоне от 0.0 до 1.0. Значения должны быть представлены в следующем порядке:

• координата x верхнего левого угла возвращаемой области; значение 0.0 соответствует первому столбцу матрицы изображения;
• координата y верхнего левого угла возвращаемой области; значение 0.0 соответствует верхней строке матрицы изображения;
• координата x правого нижнего угла области; значение 1.0 соответствует последнему столбцу матрицы изображения, а значение 0.0 запрещено;
• координата y правого нижнего угла области; значение 1.0 соответствует последней строке матрицы изображения, а значение 0.0 запрещено.

Примечание - Сервер может поддерживать или не поддерживать этот параметр.

Если этот параметр поддерживается, то размер возвращаемой матрицы изображения, соответствующей заданной области, должен соответствовать заданным нормализованным значениям координат, в противном случае должна быть возвращена полная матрица изображения. Если параметр «presentationUID» присутствует, то область следует выбирать после применения к изображению соответствующей формы презентации.

7.2.6 Центр окна изображения

Параметр должен иметь имя «windowCenter».

Данный параметр управляет яркостью изображения в соответствии с DICOM PS 3.3. Данный параметр является обязательным, если присутствует параметр «windowWidth». Он не должен использоваться, если присутствует параметр «presentationUID» или если значением параметра «contentType» является application/dicom.

Значение параметра должно быть закодировано строкой с десятичным значением (DS) в соответствии с DICOM PS 3.5.

7.2.7 Ширина окна изображения

Параметр должен иметь имя «windowWidth».

Данный параметр управляет контрастностью изображения в соответствии с DICOM PS 3.3. Данный параметр является обязательным, если присутствует параметр «windowCenter». Он не должен использоваться, если присутствует параметр «presentationUID» или если значением параметра «contentType» является application/dicom.

Значение параметра должно быть закодировано строкой с десятичным значением (DS) в соответствии с DICOM PS 3.5.

7.2.8 Номер кадра

Параметр должен иметь имя «frameNumber».

Данный параметр указывает, что должен быть возвращен одиночный кадр с данным номером из объекта с многокадровым изображением в соответствии с DICOM PS 3.3. Данный параметр является необязательным и должен игнорироваться в случае, если все объекты не являются многокадровыми. Он не должен использоваться, если значением параметра «contentType» является application/dicom.

Значение параметра должно быть закодировано строкой с целочисленным значением (IS) в соответствии с DICOM PS 3.5.

7.2.9 Качество изображения

Параметр должен иметь имя «imageQuality». Данный параметр является необязательным. Он не должен использоваться, если значением параметра «contentType» является application/dicom, за исключением ситуации, когда параметр «transferSyntax» присутствует и соответствует сжатию изображения с потерями.

Если запрошенный тип MIME относится к сжатому с потерями изображению (например, image/jpeg), то данный параметр определяет необходимое качество возвращаемого изображения в диапазоне от 1 до 100; значение 100 соответствует наилучшему качеству.

Значение параметра должно быть закодировано строкой с целочисленным значением (IS) в соответствии с DICOM PS 3.5.

Примечания

1 Декомпрессия и повторное сжатие могут ухудшить качество изображения, если исходное изображение уже подвергалось необратимому сжатию. В случае если изображение уже подвергалось сжатию с потерями в том же самом формате, что и запрашиваемый формат (например, jpeg), оно может быть отправлено как есть, т.е. без декомпрессии и повторного сжатия.

2 Конкретная интерпретация значения данного параметра оставлена на усмотрение реализации настоящего стандарта.

7.2.10 Уникальный идентификатор объекта с презентацией

Параметр должен иметь имя «presentationUID».

UID экземпляра SOP-объекта, хранящего форму презентации, должен быть применен к изображению. Данный параметр является необязательным. Он не должен использоваться, если значением параметра «contentType» является application/dicom.

Значение параметра должно быть закодировано как строка уникального идентификатора (UID) в соответствии с DICOM PS 3.5, за исключением того, что к строке не надо добавлять символ NULL, чтобы получить четную длину строки.

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

Если для указания размера презентации в форме презентации используется режим SCALE TO FIT или TRUE SIZE, то заданная в презентации отображаемая область должна быть масштабирована до размеров, заданных параметрами строки и столбца при их наличии, иначе отображаемая область, выбранная в форме презентации, будет возвращена без масштабирования.

Задаваемый в форме презентации режим TRUE SIZE не может быть реализован, поскольку маловероятно, чтобы физический размер пикселей, отображаемых веб-браузером, был известен. Если для указания размера презентации в форме презентации выбран режим MAGNIFY, то заданная в презентации отображаемая область должна быть увеличена (масштабирована), как это задано в форме презентации. Затем она будет обрезана, чтобы соответствовать размеру, заданному параметрами rows и columns при их наличии.

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

Хотя выход формы презентации определен в DICOM «P-значениях» (P-Values) (полутоновые значения, предназначенные для отображения на устройстве, калиброванном под полутоновую стандартную функцию отображения DICOM в соответствии с DICOM PS 3.14), полутоновое или цветное пространство возвращаемого по запросу изображения не определяется настоящим стандартом.

7.2.11 Уникальный идентификатор последовательности, содержащей объект с презентацией

Параметр должен иметь имя «presentationSeriesUID».

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

Значение параметра должно быть закодировано как строка уникального идентификатора (UID) в соответствии с DICOM PS 3.5, за исключением того, что к строке не надо добавлять символ NULL, чтобы получить четную длину строки.

Примечание - Как определено в DICOM, форма презентации будет находиться в том же исследовании, что и изображение, к которому она применяется.

7.2.12 UID синтаксиса передачи

Параметр должен иметь имя «transferSyntax».

Данный параметр должен использоваться с объектом с изображением DICOM в соответствии с DICOM PS 3.6. Данный параметр является необязательным. Он не должен использоваться, если значением параметра «contentType» не является application/dicom.

По умолчанию объекты DICOM возвращаются в кодировке «Explicit VR Little Endian». Не следует использовать кодировки «Implicit VR» или «Big Endian». Ответ должен, насколько это возможно, иметь запрошенный синтаксис передачи. Если нет возможности послать ответ с запрошенным синтаксисом передачи, то должен быть применен синтаксис несжатой передачи «Explicit VR Little Endian».

Значение параметра должно быть закодировано как строка уникального идентификатора (UID) в соответствии с DICOM PS 3.5, за исключением того, что к строке не надо добавлять символ NULL, чтобы получить четную длину строки.

(справочное)

A.1 Содержание

Доступ к содержимому информационного объекта обеспечивается заданием «ссылки», указывающей на конкретный постоянный объект DICOM посредством его URL/URI, и заданием UID экземпляра этого объекта DICOM и синтаксиса передачи, который следует применить.

Расширение на поиск объектов DICOM на сервере находится вне области применения настоящего стандарта. Различия между веб-доступом и поиском заключаются в основном в следующем:

• веб-доступ подразумевает получение объекта при двух возможных вариантах ответа: «Объект есть в наличии, и вы можете его получить» или «Объекта нет в наличии»; в действительности при отрицательном ответе будет передан «пустой» объект или сообщение об ошибке;
• поиск подразумевает запрос объектов при нечетко определенном ответе типа: «Имеется список потенциальных кандидатов, соответствующих Вашему запросу, — просмотрите предлагаемый список (возможно, пустой) ссылок на них».

A.2 Общий синтаксис

В общем синтаксисе настоящего стандарта соблюдены рекомендации URI IETF RFC2396. Он может быть представлен следующим образом:

://?

Этот синтаксис структурирован в соответствии с нормальной формой Бэкуса (BNF). Первое определение синтаксиса выглядит следующим образом:

1. URI-reference = [absoluteURI | relativeURI] [«#» fragment]

2. absoluteURI = scheme «:» (hier_part | opaque_part)

3. relativeURI = (net_path | abs_path | rel_path) [«?» query]

4. hier_part = (net_path | abs_path) [«?» query]

Целью настоящего стандарта является определение только запроса объекта независимо от самого постоянного объекта DICOM, но не других компонентов URL/URI, определяющих путь от клиентской веб-системы до доступной через веб-системы DICOM. Однако ожидается, что используемым типом схемы (при ее наличии) будет HTTP для обеспечения совместимости с веб-браузерами.

Данное определение запроса объекта должно полностью согласовываться с синтаксисом BNF, представленным в IETF RFC2396. В качестве компонента запроса зарезервированы символы «;», «/», «?», «:», «@», «&», «=», «+», «,» и «$». Запрос ограничен только единственной целью получения постоянных объектов DICOM через веб-доступ к ним.

Примечание - Управление различными кодами, возвращаемыми протоколом HTTP (например, «404 Not found»), определенными в IETF RFC2616.

Управляющие имена и значения удаляются. Пробелы заменяются символом «+», и затем удаляются зарезервированные символы, как описано в IETF RFC2396. Символы, не являющиеся буквами и цифрами, заменяются на «%HH» (знак процента и две шестнадцатеричные цифры, представляющие код ASCII символа). Конец строки представляется парой «CR LF» (т.е. «%0D%0A»).

Управляющие имена и значения помещаются в список для того, чтобы они могли быть отображены в документе. Имена отделяются от значений символом «=», а пары «имя/значение» отделяются друг от друга знаком «&».

A.3 Синтаксис компонента

Имеется следующее ограничение на параметры для веб-доступа к службе постоянных объектов DICOM, выраженное в синтаксисе BNF:

1. = parameter [«&» parameter]

2. parameter = name «=» value

3. name = nchars

4. value = nchars

5. nchars = *nchar

6. nchar = unreserved | escaped,

где «unreserved» и «escaped» определены в IETF RFC2396.

(справочное)

B.1 Получение простого изображения DICOM в формате JPEG

http://www.hospital-stmarco/radiology/wado.php?requestType=WADO

&studyUID=1.2.250.1.59.40211.12345678.678910

&seriesUID=1.2.250.1.59.40211.789001276.14556172.67789

&objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2

B.2 Получение SR DICOM в формате html

http://server234/script678.asp?requestType=WADO

&studyUID=1.2.250.1.59.40211.12345678.678910

&seriesUID=1.2.250.1.59.40211.789001276.14556172.67789

&objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2

&charset=UTF-8

B.3 Получение области изображения DICOM

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

https://aspradio/imageaccess.js?requestType=WADO

&studyUID=1.2.250.1.59.40211.12345678.678910

&seriesUID=1.2.250.1.59.40211.789001276.14556172.67789

&objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2

&contentType=image%2Fjp2;level=1,image%2Fjpeg;q=0.5

&annotation=patient, technique

&columns=400

&rows=300

&region=0.3,0.4,0.5,0.5

&windowCenter=-1000

&windowWidth=2500

B.4 Получение в виде типа MIME DICOM

Получение объекта изображения DICOM с использованием основного 8-битного синтаксиса передачи JPEG с потерями и деидентифицированного:

http://www.medical-webservice.st/RetrieveDocument?requestType=WADO

&studyUID=1.2.250.1.59.40211.12345678.678910

&seriesUID=1.2.250.1.59.40211.789001276.14556172.67789

&objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2

&contentType=application%2Fdicom

&anonymize=yes

&transferSyntax=1.2.840.10008.1.2.4.50

(справочное)

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

К типичным приложениям относятся:

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

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

(справочное)

В таблице D.1 представлено информационное отображение некоторых значений IANA на элементы, определенные наборами символов DICOM.

IANA	DICOM	Набор символов
ISO 8859-1	ISO_IR 100	Латинский #1
ISO 8859-2	ISO_IR 101	Латинский #2
ISO 8859-3	ISO_IR 109	Латинский #3
ISO 8859-4	ISO_IR 110	Латинский #4
ISO 8859-5	ISO_IR 144	Кириллический
ISO 8859-6	ISO_IR 127	Арабский
ISO 8859-7	ISO_IR 126	Греческий
ISO 8859-8	ISO_IR 138	Иврит
ISO 8859-9	ISO_IR 148	Латинский #5
TIS-620	ISO_IR 166	Тайский
ISO 2022-JP	ISO 2022 IR 87	Японский
ISO 2022-KR	ISO 2022 IR 149	Корейский
GB18030	GB18030	Китайский
UTF-8	ISO_IR 192	Юникод

СВЕДЕНИЯ О СООТВЕТСТВИИ ССЫЛОЧНЫХ МЕЖДУНАРОДНЫХ СТАНДАРТОВ

Обозначение ссылочного международного стандарта	Степень соответствия	Обозначение и наименование соответствующего национального стандарта
ИСО/МЭК 10918-2:1995	-	<*>
DICOM PS 3.3	-	<*>
DICOM PS 3.4	-	<*>
DICOM PS 3.5	-	<*>
DICOM PS 3.6	-	<*>
DICOM PS 3.7	-	<*>
DICOM PS 3.10	-	<*>
DICOM PS 3.11	-	<*>
DICOM PS 3.14	-	<*>
DICOM PS 3.15	-	<*>
HL7 CDA	-	<*>
IETF RFC2045	-	<*>
IETF RFC2396	-	<*>
IETF RFC2616	-	<*>
IETF RFC3240	-	<*>
<*> Соответствующий национальный стандарт отсутствует. До его утверждения рекомендуется использовать перевод на русский язык данного международного стандарта.

УДК 61:004:006.354	ОКС 35.240.80	П85	ОКСТУ 4002
Ключевые слова: здравоохранение, информатизация здоровья, сообщения, обмен информацией, веб-доступ, постоянные объекты DICOM

---