ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

Информатизация здоровья

СООБЩЕНИЯ И ОБМЕН ИНФОРМАЦИЕЙ

Веб-доступ к постоянным объектам DICOM

ISO 17432:2004

Health Informatics — Messages and communication — Web access to DICOM

persistent objects (IDT)

Издание официальное

Москва

Стандартинформ

2010

Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании», а правила применения национальных стандартов Российской Федерации — ГОСТ Р 1.0-2004 «Стандартизация в Российской Федерации. Основные положения»

Сведения о стандарте

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»).

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

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

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

© Стандартинформ,2010

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

ГОСТ Р ИСО 17432-2009

Содержание

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

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

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

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

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

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

5.2    НТТР-запрос.....................................................3

5.3    Ответ НТТР-сервера................................................4

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

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

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

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

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

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

7    Параметры.........................................................5

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

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

и многокадровыми изображениями..........................................7

Приложение А (справочное) Синтаксис передачи URL/URI...........................11

Приложение В (справочное) Примеры.........................................12

Приложение С (справочное) Приложения......................................13

Приложение D (справочное) Отображение значений IANA............................14

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

национальным стандартам Российской Федерации.....................15

Введение

Стандарт 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 и форматам ответа сервера будут, по необходимости, разработаны в будущем.

IV

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информатизация здоровья

СООБЩЕНИЯ И ОБМЕН ИНФОРМАЦИЕЙ

Веб-доступ к постоянным объектам DICOM

Health informatics. Messages and communication. Web access to DICOM persistent objects

Дата введения — 2010—07—01

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, и который был выбран в качестве объекта. надежно сохраняемого в течение определенного периода времени.

Примечание — 8 рамках стандарта 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 Унифицированный указатель/идентификатор ресурса Расширяемый язык разметки

2

ГОСТ Р ИСО 17432-2009

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

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

Взаимодействие должно осуществляться, как показано на рисунке 1.

Сервер DICOM с поддержкой веб

I

I

5.2 НТТР-запрос

5.2.1    Метод

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

5.2.2    Параметры НТТР-запроса

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

Примечания

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

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

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

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

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

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

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

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

3

5.3 Ответ НТТР-сервера

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 должен быть «applicalion/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.

4

ГОСТ РИСО 17432—2009

Примечание — Выбор типа 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», в соответствии c 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.

5

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

7.1.2    Тип запроса

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

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

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

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

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

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

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

Значение параметра должно быть закодировано в форме строки уникального идентификатора (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» должно быть одно из значений, указанных в этом поле.