Содержание
- Уведомление и отказ от ответственности
- Предисловие
- 1. Область применения
- 2. Нормативные ссылки
- 3. Определения
- 4. Символы и сокращения
- 5. Соглашения
- 6. Соответствие
- 7. Обзор веб-сервисов DICOM (Информативное)
- 8. Общие аспекты веб-сервисов DICOM
-
- 8.1. Транзакции
- 8.2. Целевые ресурсы
- 8.3. Параметры запроса
-
- 8.3.1. Синтаксис параметров запроса
- 8.3.2. Использование параметров запроса
- 8.3.3. Параметры запроса согласования содержимого
- 8.3.4. Параметры поискового запроса
- 8.3.5. Параметры запроса отрисовки
-
- 8.3.5.1. Параметры запроса для отрисованных ресурсов
- 8.3.5.2. Параметры запроса для миниатюр
- 8.3.5.3. Параметры запроса для ресурсов отрисованного объёма MPR и ресурсов отрисованного 3D-объёма
-
- 8.3.5.3.1. Ссылка на входной объём
- 8.3.5.3.2. Совпадение
- 8.3.5.3.3. Метод отрисовки
- 8.3.5.3.4. Ориентация
- 8.3.5.3.5. Позиция точки наблюдения
- 8.3.5.3.6. Направление взгляда точки наблюдения
- 8.3.5.3.7. Направление вверх точки наблюдения
- 8.3.5.3.8. Толщина среза MPR
- 8.3.5.3.9. Диапазон поворота
- 8.3.5.3.10. Координаты точек объёмной кривой
- 8.3.5.3.11. Размер шага анимации
- 8.3.5.3.12. Частота анимации
- 8.3.5.3.13. Метаданные отрисованного объёма
- 8.4. Поля заголовков
- 8.5. Коды состояния
- 8.6. Полезные нагрузки
- 8.7. Типы медиа
-
- 8.7.1. Многочастевые типы медиа
- 8.7.2. Категории ресурсов DICOM
- 8.7.3. Наборы типов медиа DICOM
- 8.7.4. Типы медиа отрисованных ресурсов
- 8.7.5. Допустимые типы медиа
- 8.7.6. Параметр запроса Accept
- 8.7.7. Поле заголовка Accept
- 8.7.8. Выбранный тип медиа и синтаксис передачи
- 8.7.9. Поле заголовка Content-Type
- 8.8. Наборы символов
- 8.9. Транзакция извлечения возможностей
- 8.10. Уведомления
- 8.11. Безопасность и конфиденциальность
- 9. Сервис URI
-
- 9.1. Обзор
- 9.2. Соответствие
- 9.3. Обзор транзакций
- 9.4. Транзакция извлечения экземпляра DICOM
- 9.5. Транзакция извлечения отрисованного экземпляра
-
- 9.5.1. Запрос
-
- 9.5.1.1. Целевой ресурс
- 9.5.1.2. Параметры запроса
- 9.5.1.3. Заголовки запроса
- 9.5.1.4. Полезная нагрузка запроса
- 9.5.2. Поведение
- 9.5.3. Ответ
- 10. Сервис исследований и ресурсы
-
- 10.1. Обзор
- 10.2. Соответствие
- 10.3. Обзор транзакций
- 10.4. Транзакция извлечения
-
- 10.4.1. Запрос
- 10.4.2. Поведение
- 10.4.3. Ответ
-
- 10.4.3.1. Коды состояния
- 10.4.3.2. Заголовки ответа
- 10.4.3.3. Полезная нагрузка ответа
-
- 10.4.3.3.1. Полезная нагрузка ресурса экземпляров
- 10.4.3.3.2. Полезная нагрузка ресурса метаданных
- 10.4.3.3.3. Полезная нагрузка отрисованного ресурса
- 10.4.3.3.4. Полезная нагрузка ресурса миниатюр
- 10.4.3.3.5. Полезная нагрузка ресурса объёмных данных
- 10.4.3.3.6. Полезная нагрузка ресурса пиксельных данных
- 10.4.3.3.7. Полезная нагрузка ресурса отрисованного объёма
- 10.4.4. Типы медиа
- 10.4.5. Заявление о соответствии
- 10.5. Транзакция сохранения
- 10.6. Транзакция поиска
- 11. Сервис рабочего списка и ресурсы
-
- 11.1. Обзор
- 11.2. Соответствие
- 11.3. Обзор транзакций
- 11.4. Транзакция создания рабочего элемента
- 11.5. Транзакция извлечения рабочего элемента
- 11.6. Транзакция обновления рабочего элемента
- 11.7. Транзакция изменения состояния рабочего элемента
- 11.8. Транзакция отмены запроса
- 11.9. Транзакция поиска
- 11.10. Транзакция подписки
- 11.11. Транзакция отписки
- 11.12. Транзакция приостановки глобальной подписки
- 11.13. Отчёты о событиях рабочих элементов
- 12. Сервис экземпляров, не связанных с пациентом, и ресурсы
- 13. Сервис подтверждения сохранения и ресурсы
- 14. Сервис запланированных этапов процедуры модальности и ресурсы
- 15. Сервис выполненных этапов процедуры модальности и ресурсы
- A. Collected ABNF
- B. Examples (Informative)
-
- B.1. Извлечение простого изображения DICOM в JPEG
- B.2. Извлечение DICOM SR в HTML
- B.3. Извлечение области изображения DICOM
- B.4. Извлечение в виде типа медиа DICOM
- B.5. Запрос исследований за определённый день с ограничением количества результатов, начиная со смещения 0
- B.6. Запрос серий из определённого исследования, возвращаемые данные в JSON
- B.7. Запрос экземпляров из серии, возвращаемые данные в XML
- B.8. Извлечение экземпляра в формате DICOM
- B.9. Извлечение экземпляра как отрисованного изображения JPEG
- B.10. Извлечение экземпляра как объёмных данных
- B.11. Извлечение объекта изображения DICOM с использованием базового 8-битного синтаксиса передачи JPEG с потерями
- B.12. Отрисовка области изображения DICOM, преобразованного в JPEG2000, с вписанными в изображение аннотациями, содержащими имя пациента и техническую информацию, с использованием определённой области просмотра и оконной обработки
- B.13. Извлечение DICOM SR в формате HTML
- B.14. Извлечение DICOM SR в формате JSON (только метаданные)
- B.15. Проверка возможности извлечения метаданных в формате XML
- B.16. Извлечение метаданных в формате XML с использованием параметра "accept"
- B.17. Извлечение кадров DICOM как "octet-stream"
- B.18. Извлечение кадров DICOM, отрисованных в типе медиа GIF
- B.19. Извлечение миниатюры для серии в типе медиа JPEG
- B.20. Извлечение миниатюры для одного кадра в типе медиа PNG
- B.21. Сохранение одного экземпляра DICOM
- B.22. Сохранение нескольких экземпляров DICOM
- B.23. Сохранение нескольких файлов JPEG
- B.24. Получение всех рабочих элементов
- B.25. Отмена рабочего элемента
- B.26. Определение метода WADL для описания возможностей исходного сервера, поддерживающего поиск исследований
- B.27. Запрос подтверждения сохранения для нескольких экземпляров с JSON
- B.28. Запрос подтверждения сохранения для нескольких экземпляров с XML и ссылками на UID экземпляров исследования и серии
- B.29. Запрос подтверждения сохранения с составным HTTP-запросом для экземпляров из нескольких исследований
- B.30. Двунаправленный прокси для подтверждения сохранения
- B.31. Отрисовка серии как 3D-объёма
- B.32. Отрисовка многокадрового экземпляра как 3D-объёмного изображения
- B.33. Отрисовка исследования как MPR
- B.34. Отрисовка одной фазы многофазной серии как MIP
- B.35. Отрисовка объёмного состояния представления объёмной отрисовки
- B.36. Поиск запланированных этапов процедуры модальности с использованием типа медиа JSON
- B.37. Создание выполненного этапа процедуры модальности с использованием типа содержимого JSON
- B.38. Обновление выполненного этапа процедуры модальности с созданными данными изображения с использованием типа содержимого JSON
- B.39. Завершение выполненного этапа процедуры модальности с использованием типа содержимого JSON
- B.40. Извлечение выполненного этапа процедуры модальности с использованием типа медиа и типа содержимого JSON
- B.41. Двунаправленные прокси для поиска запланированных этапов процедуры модальности
- B.42. Двунаправленные прокси для управления выполненным этапом процедуры модальности
- C. Retired
- D. IANA Character Set Mapping
- E. Retired
- F. DICOM JSON Model
-
- F.1. Введение в JavaScript Object Notation (JSON)
- F.2. Модель DICOM JSON
- F.3. Преобразование в другие форматы DICOM
- F.4. Пример модели DICOM JSON
- F.5. Удалён
- G. WADL JSON Representation
- H. Capabilities Description
- I. Store Instances Response Module
- J. Storage Commitment Modules
- K. Rendered Volume Response Module
Список рисунков
- 7-1. Модель связи DICOM для веб-сервисов
- 8.1-1. Диаграмма взаимодействия транзакций
- 8.6-1. Соответствие между частями сообщений IOD и HTTP
- 13.1-1. Процесс сервиса подтверждения сохранения
- B.30-1. DIMSE-прокси подтверждения сохранения для исходного сервера DICOMweb
- B.30-2. DICOMweb-прокси подтверждения сохранения для DIMSE SCP
- B.41-1. DIMSE-прокси запланированных этапов процедуры модальности для исходного сервера DICOMweb
- B.41-2. DICOMweb-прокси запланированных этапов процедуры модальности для DIMSE SCP
- B.42.1-1. DIMSE-прокси создания MPPS для исходного сервера DICOMweb
- B.42.1-2. DICOMweb-прокси создания MPPS для DIMSE SCP
- B.42.2-1. DIMSE-прокси обновления MPPS для исходного сервера DICOMweb
- B.42.2-2. DICOMweb-прокси обновления MPPS для DIMSE SCP
- B.42.3-1. DIMSE-прокси извлечения MPPS для исходного сервера DICOMweb
- B.42.3-2. DICOMweb-прокси извлечения MPPS для DIMSE SCP
Список таблиц
- 5.1-1. ABNF для общих синтаксических значений
- 5.2-1. Заголовки запроса
- 5.2-2. Заголовки ответа
- 8.3.1-1. ABNF для параметра запроса
- 8.3.2-1. Использование параметров запроса
- 8.3.2-2. Пример таблицы параметров запроса
- 8.3.4-1. Синтаксис параметров запроса
- 8.3.5-1. Параметры запроса извлечения отрисованных ресурсов
- 8.3.5-2. Параметры запроса миниатюр
- 8.3.5-3. Параметры запроса извлечения отрисованного объёма
- 8.4.1-1. Поля заголовков согласования содержимого
- 8.4.2-1. Поля заголовков представления содержимого
- 8.4.3-1. Поля заголовков полезной нагрузки
- 8.5-1. Status Code Meaning
- 8.6.1-1. Поля заголовков составных частей
- 8.7.2-1. Категории ресурсов
- 8.7.3-1. Определение требований к типу медиа
- 8.7.3-2. UID синтаксисов передачи для типов медиа application/dicom
- 8.7.3-3. Типы медиа для метаданных
- 8.7.3-4. UID синтаксисов передачи для несжатых объёмных данных
- 8.7.3-5. Типы медиа и UID синтаксисов передачи для сжатых объёмных данных
- 8.7.4-1. Типы медиа отрисованных ресурсов по категориям ресурсов
- 8.7.8-1. Пример QValue типа медиа
- 8.9.1-1. Заголовки запроса
- 8.9.3-1. Status Code Meaning
- 8.9.3-2. Заголовки ответа
- 8.10.3-1. Транзакции подсистемы уведомлений
- 8.10.4-1a. Ресурсы транзакции открытия соединения для уведомлений
- 8.10.4-1. Заголовки запроса
- 8.10.4-2. Status Code Meaning
- 8.10.4-3. Заголовки ответа
- 9.1.2-1. Обязательные параметры запроса
- 9.1.2-2. Необязательные параметры запроса
- 9.4.1-1. Необязательные параметры запроса
- 9.4.1-2. Заголовки запроса
- 9.4.3-1. Status Code Meaning
- 9.4.3-2. Заголовки ответа
- 9.5.1-1. Параметры запроса
- 9.5.1-2. Заголовки запроса
- 9.5.3-1. Status Code Meaning
- 9.5.3-2. Заголовки ответа
- 10.1-1. Ресурсы и описания
- 10.1.2-1. Общие параметры запроса
- 10.3-1. Транзакции сервиса исследований
- 10.3-2. Ресурсы по транзакциям
- 10.4.1-1. Ресурсы экземпляров транзакции извлечения
- 10.4.1-2. Ресурсы метаданных транзакции извлечения
- 10.4.1-3. Отрисованные ресурсы транзакции извлечения
- 10.4.1-4. Ресурсы миниатюр транзакции извлечения
- 10.4.1.5-1. Ресурсы объёмных данных транзакции извлечения
- 10.4.1.6-1. Ресурсы пиксельных данных транзакции извлечения
- 10.4.1.7-1. Ресурсы отрисованного объёма MPR транзакции извлечения
- 10.4.1.8-1. Ресурсы отрисованного 3D-объёма транзакции извлечения
- 10.4.1-5. Параметры запроса по ресурсам
- 10.4.1-6. Заголовки запроса
- 10.4.3-1. Status Code Meaning
- 10.4.3-2. Заголовки ответа
- 10.4.4-1. Типы медиа по умолчанию, обязательные и необязательные
- 10.5.1-1. Ресурсы DICOM транзакции сохранения
- 10.5.1-2. Заголовки запроса
- 10.5.2-1. Преобразование типов медиа в синтаксисы передачи
- 10.5.3-1. Status Code Meaning
- 10.5.3-2. Заголовки ответа
- 10.5.4-1. Типы медиа по умолчанию, обязательные и необязательные
- 10.6.1-1. Ресурсы транзакции поиска
- 10.6.1-2. Описания ресурсов поиска
- 10.6.1-3. Типы поисковых ключей
- 10.6.1-4. Требуемые уровни IE по ресурсам
- 10.6.1-5. Обязательные атрибуты сопоставления
- 10.6.1.2.4-1. Требуемые уровни IE по ресурсам
- 10.6.1-6. Заголовки запроса
- 10.6.3-1. Status Code Meaning
- 10.6.3-2. Заголовки ответа
- 10.6.3-3. Полезная нагрузка ответа поиска ресурса исследования
- 10.6.3-4. Полезная нагрузка ответа поиска ресурсов серий
- 10.6.3-5. Полезная нагрузка ответа поиска ресурсов экземпляров
- 10.6.4-1. Типы медиа по умолчанию, обязательные и необязательные
- 11.1.1-1. Ресурсы, шаблоны URI и описания
- 11.1.1-2. Соответствие терминологии RESTful и DIMSE
- 11.1.2-1. Общие параметры запроса
- 11.1.3-1. Типы медиа по умолчанию, обязательные и необязательные
- 11.3-1. Методы сервиса рабочего списка и шаблоны ресурсов
- 11.4.1-1. Ресурсы транзакции создания
- 11.4.1-3. Заголовки запроса
- 11.4.3-1. Status Code Meaning
- 11.4.3-2. Заголовки ответа
- 11.5.1-1. Заголовки запроса
- 11.5.3-1. Status Code Meaning
- 11.5.3-2. Заголовки ответа
- 11.6.1-1. Заголовки запроса
- 11.6.3-1. Status Code Meaning
- 11.6.3-2. Заголовки ответа
- 11.7.2.1-1. Параметры запроса
- 11.7.1-1. Заголовки запроса
- 11.7.3-1. Status Code Meaning
- 11.7.3-2. Заголовки ответа
- 11.8.1-1. Заголовки запроса
- 11.8.3-1. Status Code Meaning
- 11.8.3-2. Заголовки ответа
- 11.9.1-1. Заголовки запроса
- 11.9.3-1. Status Code Meaning
- 11.9.3-2. Заголовки ответа
- 11.10.1-1. Ресурсы транзакции подписки
- 11.10.1-2. Параметры запроса по ресурсам
- 11.10.3-1. Status Code Meaning
- 11.10.3-2. Заголовки ответа
- 11.11.1-1. Ресурсы транзакции отписки
- 11.11.3-1. Status Code Meaning
- 11.11.3-2. Заголовки ответа
- 11.12.1-1. Ресурсы транзакции приостановки глобальной подписки
- 11.12.3-1. Status Code Meaning
- 11.12.3-2. Заголовки ответа
- 12.1.1-1. Категории ресурсов, шаблоны URI и описания
- 12.1.2-1. Общие параметры запроса
- 12.1.3-1. Типы медиа по умолчанию, обязательные и необязательные
- 12.2-1. Обязательные и необязательные транзакции
- 12.3-1. Транзакции сервиса NPI
- 12.3-2. Ресурсы по транзакциям
- 12.4.1-1. Retrieve Transaction Resources
- 12.4.1-2. Заголовки запроса
- 12.4.3-1. Status Code Meaning
- 12.4.3-2. Заголовки ответа
- 12.5.1-1. Ресурсы транзакции сохранения
- 12.5.1-2. Заголовки запроса
- 12.5.3-1. Status Code Meaning
- 12.5.3-2. Заголовки ответа
- 12.6.1-1. Ресурсы транзакции поиска
- 12.6.1-2. Атрибуты поиска ресурсов NPI
- 12.6.1-3. Заголовки запроса
- 12.6.3-1. Status Code Meaning
- 12.6.3-2. Заголовки ответа
- 13.1.1-1. Описания ресурсов сервиса подтверждения сохранения
- 13.1.2-1. Общие параметры запроса
- 13.1.3-1. Типы медиа по умолчанию, обязательные и необязательные
- 13.2-1. Обязательные и необязательные транзакции
- 13.3-1. Транзакции сервиса подтверждения сохранения
- 13.4.1-2. Заголовки запроса
- 13.4.3-1. Status Code Meaning
- 13.4.3-2. Заголовки ответа
- 13.5.1-2. Заголовки проверки результата
- 13.5.3-1. Status Code Meaning
- 14.1.1-1. Ресурсы, шаблоны URI и описания
- 14.1.2-1. Общие параметры запроса
- 14.1.3-1. Типы медиа по умолчанию, обязательные и необязательные
- 14.2-1. Обязательные и необязательные транзакции
- 14.3-1. Транзакции сервиса запланированных этапов процедуры модальности
- 14.3-2. Соответствие транзакций сервиса запланированных этапов процедуры модальности и операций DIMSE
- 14.4.1-1. Заголовки запроса
- 14.4.3-1. Status Code Meaning
- 14.4.3-2. Заголовки ответа
- 15.1.1-1. Описания ресурсов сервиса выполненных этапов процедуры модальности
- 15.1.2-1. Общие параметры запроса
- 15.1.3-1. Типы медиа по умолчанию, обязательные и необязательные
- 15.2-1. Обязательные и необязательные транзакции
- 15.3-1. Транзакции сервиса выполненных этапов процедуры модальности
- 15.3-2. Ресурсы по транзакциям
- 15.3-3. Соответствие транзакций сервиса выполненных этапов процедуры модальности и операций DIMSE
- 15.4.1-1. Заголовки запроса
- 15.4.3-1. Status Code Meaning
- 15.4.3-2. Заголовки ответа
- 15.5.1.2-1. Параметры запроса по ресурсам
- 15.5.1-1. Заголовки запроса
- 15.5.3-1. Status Code Meaning
- 15.5.3-2. Заголовки ответа
- 15.6.1-1. Заголовки запроса
- 15.6.3-1. Status Code Meaning
- 15.6.3-2. Заголовки ответа
- D-1. Отображение наборов символов IANA
- F.2.3-1. Соответствие типов данных VR DICOM типам JSON
- F.3.1-1. Соответствие XML и JSON
- H-1. Ресурсы и методы
- I.1-1. Атрибуты модуля ответа на сохранение экземпляров
- I.2-1. Значения причины предупреждения ответа на сохранение экземпляров
- I.2-2. Значения причины отказа ответа на сохранение экземпляров
- J.1-1. Модуль запроса подтверждения сохранения
- J.2-1. Модуль ответа подтверждения сохранения
- K.1-1. Атрибуты модуля ответа отрисованного объёма
Информация в настоящей публикации была признана технически обоснованной по консенсусу лиц, участвовавших в разработке и утверждении документа на момент его создания. Консенсус не обязательно означает единогласное согласие среди всех лиц, участвующих в разработке данного документа.
Стандарты и руководящие публикации NEMA, одной из которых является документ, содержащийся в настоящем издании, разрабатываются в рамках добровольного процесса разработки стандартов на основе консенсуса. Этот процесс объединяет добровольцев и/или выявляет мнения лиц, заинтересованных в теме, охватываемой данной публикацией. Хотя NEMA управляет процессом и устанавливает правила для обеспечения справедливости при достижении консенсуса, она не пишет документ и не проводит независимое тестирование, оценку или проверку точности или полноты какой-либо информации или обоснованности каких-либо суждений, содержащихся в её стандартах и руководящих публикациях.
NEMA отказывается от ответственности за любые телесные повреждения, имущественный или иной ущерб любого характера, будь то специальный, косвенный, последующий или компенсаторный, прямо или косвенно вытекающий из публикации, использования, применения или reliance на данный документ. NEMA отказывается и не даёт никаких гарантий, явных или подразумеваемых, относительно точности или полноты любой информации, опубликованной в данном документе, и отказывается и не гарантирует, что информация в данном документе будет отвечать каким-либо конкретным целям или потребностям. NEMA не берёт на себя обязательств по гарантированию производительности продуктов или услуг любого отдельного производителя или продавца на основании данного стандарта или руководства.
Публикуя и предоставляя доступ к данному документу, NEMA не берёт на себя оказание профессиональных или иных услуг для какого-либо лица или организации или от их имени, а также NEMA не берёт на себя выполнение каких-либо обязанностей, возложенных на какое-либо лицо или организацию перед третьими лицами. Любой использующий данный документ должен полагаться на собственное независимое суждение или, в зависимости от обстоятельств, обращаться за консультацией к компетентному специалисту для определения меры разумной осторожности в любой данной ситуации. Информация и другие стандарты по теме, охватываемой данной публикацией, могут быть получены из других источников, которые пользователь может пожелать проконсультировать для получения дополнительных мнений или информации, не охваченных данной публикацией.
NEMA не имеет полномочий и не берёт на себя контроль за соблюдением или обеспечение соблюдения содержания данного документа. NEMA не сертифицирует, не тестирует и не инспектирует продукты, конструкции или установки в целях безопасности или охраны здоровья. Любая сертификация или иное заявление о соответствии любой информации, касающейся безопасности или здоровья, содержащейся в данном документе, не может быть приписано NEMA и является исключительно ответственностью лица, проводящего сертификацию или делающего заявление.
Настоящий стандарт DICOM был разработан в соответствии с процедурами Комитета по стандартам DICOM.
Стандарт DICOM структурирован как многочастный документ с использованием руководящих принципов, установленных в [ISO/IEC Directives, Part 2].
PS3.1 следует использовать в качестве базовой ссылки для текущих частей настоящего Стандарта.
DICOM® является зарегистрированным товарным знаком National Electrical Manufacturers Association для её стандартных публикаций, относящихся к цифровой передаче медицинской информации, все права защищены.
HL7® является зарегистрированным товарным знаком Health Level Seven International, все права защищены.
PS3.18 определяет веб-сервисы (с использованием семейства протоколов HTTP) для управления и распределения информационных объектов DICOM (Digital Imaging and Communications in Medicine), таких как медицинские изображения, аннотации, отчёты и т.д., медицинским организациям, поставщикам услуг и пациентам. Термин DICOMweb™ используется для обозначения описанных здесь RESTful веб-сервисов.
Вопросы безопасности, включая управление доступом, авторизацию и аудит, выходят за рамки области применения PS3.18. См. PS3.15.
Следующие нормативные документы содержат положения, которые посредством ссылки в настоящем тексте составляют положения данной части DICOM. Для датированных ссылок последующие поправки или пересмотры любых из этих публикаций не применяются. Однако сторонам соглашений, основанных на данной части DICOM, рекомендуется изучить возможность применения самых последних изданий нормативных документов, указанных ниже. Для недатированных ссылок применяется самое последнее издание нормативного документа, на который дается ссылка. Члены ISO и IEC ведут реестры действующих на сегодняшний день международных стандартов.
2.1 Международная организация по стандартизации (ISO) и Международная электротехническая комиссия (IEC)
[ISO/IEC Directives, Part 2] 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] 1994. Information Processing Systems - Open Systems Interconnection - Basic Reference Model.
[ISO/IEC 10918-1] 1994. JPEG Standard for digital compression and encoding of continuous-tone still images. Part 1 - Requirements and implementation guidelines.
[ISO/IEC 10646] 2003. Information Technology - Universal Multiple-Octet Coded Character Set (UCS). ISO/IEC 10646-2003 is the same as Unicode Version 4.0, available at http://unicode.org .
[ISO 15076-1] 2005. Image technology colour management - Architecture, profile format, and data structure. Also available as ICC.1:2004-10 (Profile version 4.2.0.0), International Color Consortium, available at http://www.color.org/v4spec.xalter .
[ISO 15948] 2003. Information technology -- Computer graphics and image processing -- Portable Network Graphics (PNG): Functional specification. A Joint ISO/IEC International Standard and W3C Recommendation. Also available at: https://www.w3.org/TR/2003/REC-PNG-20031110/ .
[ISO/IEC 18181-1] 2022. Information technology - JPEG XL Image Coding System - Part 1 Core Coding System.
[ISO 22028-2] 2013. Photography and graphic technology - Extended colour encodings for digital image storage, manipulation and interchange - Part 2: Reference output medium metric RGB colour image encoding (ROMM RGB). http://www.iso.org/iso/catalogue_detail.htm?csnumber=56591 .
2.2 Целевая группа по инженерным вопросам Интернета (IETF) и Администрация присвоения имён в Интернете (IANA)
[IANA Character Sets] . Character Sets. http://www.iana.org/assignments/character-sets/character-sets.xhtml .
[IANA HTTP Status Code Registry] . Hypertext Transfer Protocol (HTTP) Status Code Registry. http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml .
[IANA Media Types] . Media Types. http://www.iana.org/assignments/media-types/media-types.xhtml .
[RFC822] August 1982. Standard for ARPA Internet Text Messages. http://tools.ietf.org/html/rfc822 .
[RFC1945] May 1996. Hypertext Transfer Protocol Version 1.0 (HTTP/1.0) . http://tools.ietf.org/html/rfc1945 .
[RFC2045] November 1996. Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. http://tools.ietf.org/html/rfc2045 .
[RFC2046] November 1996. Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. http://tools.ietf.org/html/rfc2046 .
[RFC2387] August 1998. The MIME Multipart/Related Content-type. http://tools.ietf.org/html/rfc2387 .
[RFC2818] May 2000. HTTP Over TLS. http://tools.ietf.org/html/rfc2818 .
[RFC2978] October 2000. IANA Charset Registration Procedures. http://tools.ietf.org/html/rfc2978 .
[RFC3240] February 2002. Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration. http://tools.ietf.org/html/rfc3240 .
[RFC3536] May 2003. Terminology Used in Internationalization in the IETF. http://tools.ietf.org/html/rfc3536 .
[RFC3745] April 2004. MIME Type Registrations for JPEG 2000 (ISO/IEC 15444). http://tools.ietf.org/html/rfc3745 .
[RFC3986] Uniform Resource Identifiers (URI): Generic Syntax. http://tools.ietf.org/html/rfc3986 .
[RFC4337] March 2006. MIME Type Registration for MPEG-4. http://tools.ietf.org/html/rfc4337 .
[RFC4648] October 2006. The Base16, Base32, and Base64 Data Encodings. http://tools.ietf.org/html/rfc4648 .
[RFC5234] January 2008. Augmented BNF for Syntax Specifications: ABNF. http://tools.ietf.org/html/rfc5234 .
[RFC6365] September 2011. Terminology Used in Internationalization in the IETF. http://tools.ietf.org/html/rfc6365 .
[RFC6338] August 2011. Definition of a Uniform Resource Name (URN) Namespace for the Schema for Academia (SCHAC). http://tools.ietf.org/html/rfc6338 .
[RFC6455] December 2011. The WebSocket Protocol. http://tools.ietf.org/html/rfc6455 .
[RFC6570] March 2012. URI Template. http://tools.ietf.org/html/rfc6570 .
[RFC6838] January 2013. Media Type Specifications and Registration Procedures. http://tools.ietf.org/html/rfc6838 .
[RFC7159] March 2014. The JavaScript Object Notation (JSON) Data Interchange Format. http://tools.ietf.org/html/rfc7159 .
[RFC7230] June 2014. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. http://tools.ietf.org/html/rfc7230 .
[RFC7231] June 2014. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. http://tools.ietf.org/html/rfc7231 .
[RFC7232] June 2014. Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests. http://tools.ietf.org/html/rfc7232 .
[RFC7233] June 2014. Hypertext Transfer Protocol (HTTP/1.1): Range Requests. http://tools.ietf.org/html/rfc7233 .
[RFC7234] June 2014. Hypertext Transfer Protocol (HTTP/1.1): Caching. http://tools.ietf.org/html/rfc7234 .
[RFC7235] June 2014. Hypertext Transfer Protocol (HTTP/1.1): Authentication. http://tools.ietf.org/html/rfc7235 .
[RFC7236] June 2014. Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations. http://tools.ietf.org/html/rfc7236 .
[RFC7237] June 2014. Initial Hypertext Transfer Protocol (HTTP) Method Registrations. http://tools.ietf.org/html/rfc7237 .
[RFC7405] December 2014. Case-Sensitive String Support in ABNF. http://tools.ietf.org/html/rfc7405 .
[RFC7525] May 2015. TLS Recommendations. http://tools.ietf.org/html/rfc7525 .
[RFC7540] May 2015. Hypertext Transfer Protocol Version 2 (HTTP/2). http://tools.ietf.org/html/rfc7540 .
[RFC8259] December 2017. The JavaScript Object Notation (JSON) Data Interchange Format. http://tools.ietf.org/html/rfc8259 .
[RFC9110] June 2022. HTTP Semantics. http://tools.ietf.org/html/rfc9110 .
2.3 Прочие ссылки
[Adobe RGB] 1998. 2005-05. Adobe RGB (1998) Color Image Encoding. http://www.adobe.com/digitalimag/pdfs/AdobeRGB1998.pdf .
[DCI DCSS] May 29, 2024. Digital Cinema System Specification. http://www.dcimovies.com/dci-specification .
[Display-P3] Display P3 Color Encoding. http://www.color.org/chardata/rgb/DisplayP3.xalter .
[Ekuan] Asynchronous Request-Reply pattern. 2022. http://learn.microsoft.com/en-us/azure/architecture/patterns/async-request-reply .
[Fielding] Architectural Styles and the Design of Network-based Software Architectures. 2000. http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf .
[FHIR Access Denied] . FHIR Security - Access Denied Response Handling. http://hl7.org/fhir/security.html#AccessDenied .
[IHE RAD TF-1] Integrating the Healthcare Enterprise Radiology Technical Framework Volume 1 Integration Profiles. http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol1.pdf .
[IHE RAD TF-2] Integrating the Healthcare Enterprise Radiology Technical Framework Volume 2 Transactions. http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf .
[MNG] Multiple-image Network Graphics. http://www.libpng.org/pub/mng .
[ONC Privacy Security Guide] . Guide to Privacy and Security of Electronic Health Information. http://www.healthit.gov/sites/default/files/pdf/privacy/privacy-and-security-guide.pdf .
[OWASP Information Leakage] . Top 10 2007 - Information Leakage and Improper Error Handling. http://www.owasp.org/index.php/Top_10_2007-Information_Leakage_and_Improper_Error_Handling .
[SMPTE RP 431-2:2011] 2011. D-Cinema Quality — Reference Projector and Environment. http://pub.smpte.org/latest/rp431-2/rp0431-2-2011.pdf .
[WADL] 31 August 2009. . Member Submission - Web Application Description Language. http://www.w3.org/Submission/wadl/ .
[Wikipedia REST] . Representational State Transfer. http://en.wikipedia.org/wiki/Representational_state_transfer .
Для целей данной части DICOM применяются следующие термины и определения.
3.1 Определения эталонной модели
В данной части Стандарта используются следующие термины, определённые в [ISO 7498-1]:
- Application Entity (AE)
-
См. [ISO 7498-1].
- Real-World Activity
-
См. [ISO 7498-1].
3.2 Определения введения и обзора DICOM
В данной части Стандарта используются следующие термины, определённые в PS3.1:
3.3 Обмен сообщениями DICOM
В данной части Стандарта используются следующие термины, определённые в PS3.7:
3.4 Определения информационных объектов DICOM
В данной части Стандарта используются следующие термины, определённые в PS3.3:
3.5 Соответствие DICOM
В данной части Стандарта используются следующие термины, определённые в PS3.2:
3.6 Структуры и кодирование данных DICOM
В данной части Стандарта используются следующие термины, определённые в PS3.5:
3.7 Определения класса служб DICOM
В данной части Стандарта используются следующие термины, определённые в PS3.4:
3.8 Определения протокола передачи гипертекста (HTTP/HTTPS)
В данной части Стандарта используются следующие термины, определённые в [RFC7230] Раздел 2.1 Client/Server Messaging:
3.9 Определения веб-сервисов
- Bulk Data
-
Объект, содержащий октетный поток, включающий одно или несколько полей значений (обычно содержащих большие данные, такие как Pixel Data), извлечённых из набора данных DICOM. См. Metadata.
Примечание
-
Октетный поток не включает тег атрибута, представление значения (Value Representation) или длину атрибута.
-
Для значения кадра атрибута Pixel Data, закодированного в инкапсулированном синтаксисе передачи (Encapsulated Transfer Syntax), он не включает таблицу базовых смещений (Basic Offset Table) и теги и длины элементов фрагмента потока Pixel Data Stream.
-
- Bulk Data URI
-
Унифицированный идентификатор ресурса (URI), ссылающийся на Bulk Data.
- DICOM Object
-
Экземпляр объекта данных, как определено в PS3.3, которому присвоен уникальный идентификатор в формате, указанном для SOP Instance UID в PS3.3, и который выбран как объект для безопасного сохранения в течение определённого периода времени. В стандарте DICOM объект DICOM обычно является экземпляром составного Service Object Pair (SOP).
- DICOM Resource
-
Один или несколько объектов DICOM, на которые ссылается URL.
- DIMSE Proxy
-
Исходный сервер (origin server), который отвечает на запросы веб-сервиса DICOM путём выполнения транзакций DIMSE на внутреннем сервере (backend server).
- Event Report
-
Набор данных, содержащий элементы, описывающие событие, произошедшее на исходном сервере (origin server). См. Раздел 11.12.
- Metadata
-
Набор данных DICOM, в котором ноль или более элементов (обычно содержащих большие данные, такие как Pixel Data) заменены на Bulk Data URI.
Примечание
Метаданные не включают элементы данных файловой метаинформации Группы 0002 (Group 0002 File Meta Information Data Elements), которые описывают, но не являются частью набора данных, согласно Разделу 7.1 в PS3.10.
- RESTful Web Service
-
Веб-сервис является RESTful, если он реализован с использованием архитектуры и принципов REST. См. https://en.wikipedia.org/wiki/Representational_state_transfer.
- Service
-
При использовании в данной части Стандарта термин Service означает набор транзакций и ресурсов, к которым эти транзакции применяются.
- sRGB
-
Стандартное цветовое пространство RGB, определённое в [IEC 61966-2.1].
- Status Report
-
Отчёт о состоянии (Status Report) — это информация, содержащаяся в полезной нагрузке ответа (response payload), описывающая предупреждения или ошибки, связанные с запросом.
- Subscriber
-
Создатель или владелец подписки (Subscription), обычно пользовательский агент (user agent).
- Target URI
-
URI, содержащийся в сообщении запроса. Он обозначает ресурс, являющийся целевым объектом запроса.
- Thumbnail
-
Изображение одного кадра (Frame), которое репрезентативно отражает содержимое исследования DICOM (Study), серии (Series), экземпляра (Instance) или кадра (Frame). Оно закодировано в формате Rendered Media Type. См. Раздел 8.7.4 и Раздел 10.4.4.
- Transaction
-
При использовании в данной части Стандарта термин Transaction означает пару сообщений HTTP/HTTPS запрос/ответ.
- UTF-8
-
Набор символов Unicode UTF-8, определённый в [ISO/IEC 10646].
3.10 Определения хранения на носителях и формата файлов DICOM:
В данной части Стандарта используются следующие термины, определённые в PS3.10:
Следующие символы и сокращения используются в этой части Стандарта.
- ABNF
- CRUDL
-
Create, Read, Update, Delete, List; базовые операции/действия над объектами
- DICOM
- HL7
- HTML
- HTTP
- HTTP/1.1
- HTTP/2
- HTTPS
- HTTPS/1.1
- HTTPS/2
- IETF
- IHE
- JSON
- MPPS
-
Служба Modality Performed Procedure Step. См. Приложение F документа PS3.4 .
- MWL
-
Служба Modality Worklist; разговорное название службы Basic Worklist. См. Приложение K документа PS3.4 .
- QIDO-RS
-
Запрос на идентификацию объектов DICOM с использованием RESTful-сервисов
- REST
-
Representational State Transfer, архитектура веб-сервисов. См. [Wikipedia REST] и [Fielding].
- RESTful
- SOP
- STOW-RS
- UID
- UPS
-
Служба Unified Procedure Step. См. Приложение CC документа PS3.4 .
- UPS-RS
- URI
-
Унифицированный идентификатор ресурса. См. [RFC3986].
- URL
-
Унифицированный указатель ресурса. См. [RFC3986].
- WADL
- WADO-RS
-
Веб-доступ к объектам DICOM с использованием RESTful-сервисов
- WADO-URI
- XML
В этом разделе определяются соглашения, используемые на протяжении всей остальной части Стандарта.
Синтаксис сообщений запроса и ответа для Транзакций определяется с использованием грамматики ABNF, используемой в [RFC7230], которая основана на ABNF, определённой в [RFC5234]. Эта часть Стандарта также использует расширения ABNF из [RFC7405], которое определяет префикс '%s' для обозначения строк, чувствительных к регистру.
Правила синтаксиса, определённые здесь, действительны для набора символов US-ASCII или наборов символов, являющихся надмножествами US-ASCII, например, Unicode UTF-8.
В ABNF, используемой для определения синтаксиса сообщений, применяются следующие соглашения:
-
Терминальные правила записываются в верхнем регистре. Например, 'SP' обозначает литеральный символ пробела US-ASCII (0x20), а 'CRLF' обозначает литеральные символы возврата каретки ASCII (0xD) и перевода строки (0xA).
-
Имена полей заголовка записываются с заглавной буквы, а кавычки, обозначающие литеральные строки для имён полей заголовка, опускаются. Имена полей заголовка — единственные имена с заглавной буквой, используемые в грамматике. См. [RFC7231] Раздел 1.2. Например:
Accept: media-type CRLF
"Accept:" media-type CRLF
В этой части Стандарта, как и в HTTP в целом, ресурсы идентифицируются URI [RFC3986]. Каждый сервис определяет управляемые им ресурсы и шаблоны URI, используемые для определения структуры URI, которые на них ссылаются.
В RFC по HTTP правила ABNF для obs-text и obs-fold обозначают «устаревшие» грамматические правила, присутствующие по историческим причинам. Эти правила не используются в определениях синтаксиса веб-сервисов DICOM.
См. Приложение A для объединённой ABNF веб-сервисов DICOM.
Таблица 5.1-1 определяет синтаксис некоторых общих правил, используемых при определении значений данных в этой части Стандарта.
Таблица 5.1-1. ABNF для общих синтаксических значений
int |
= [+ / -] 1*DIGIT ; An integer |
uint |
= 1*DIGIT ; An unsigned integer |
non-zero-digit |
= %31-39 |
pos-int |
= non-zero-digit *DIGIT ; An integer greater than zero |
decimal |
=int ["." uint] [("E" / "e") int]
; a fixed- or floating-point number with at most 16 characters |
string |
= %s 1*QCHAR ; A case sensitive string |
base64 |
; Use base64 defined in [RFC4648] Section 5 |
uid |
= uid-root 1*("." uid-part)
|
uid-root |
= "0" / "1" / "2" |
uid-part |
= "0" / pos-int |
Синтаксис шаблонов URI [RFC6570] был расширен для поддержки имён переменных, чувствительных к регистру. Это было сделано путём изменения правила varchar (см. [RFC6570] Раздел 2.3) следующим образом:
varchar = %x20-21 / %x23-7E / pct-encoded
ABNF была расширена правилом списка, которое используется для определения списков, разделённых запятыми. Оно не допускает пустых списков, пустых элементов списка или устаревших правил списка, определённых в [RFC7230] Раздел 7.
1#element = element *(OWS "," OWS element)
#element = 1#element
<n>#<m>element = element <n-1>*<m-1> (OWS "," OWS element)
n >= 1 and m > n
Эта часть Стандарта организована так, что новые сервисы могут добавляться как новые пронумерованные разделы в конце документа.
Требования к полям заголовка запроса описываются с использованием таблиц следующего вида:
Столбец «Имя» содержит имя поля заголовка HTTP, как определено в [RFC7230, RFC7231].
Столбец «Значение» определяет либо тип значения, либо конкретное значение, содержащееся в поле заголовка.
Столбец «Использование пользовательским агентом» определяет требования к пользовательскому агенту по предоставлению поля заголовка в запросе.
Столбец «Использование исходным сервером» определяет требования к исходному серверу по поддержке поля заголовка.
Содержимое столбцов «Использование» может быть:
Столбец «Описание» для условных полей заголовка запроса определяет условие наличия поля заголовка.
-
«Должен присутствовать, если <условие>» означает, что если <условие> истинно, то поле заголовка должно присутствовать; в противном случае оно не должно присутствовать.
-
«Может присутствовать в противном случае» добавляется к описанию, если поле заголовка может присутствовать, даже если условие не является истинным.
Требования к полям заголовка ответа описываются с использованием таблиц следующего вида:
Для полей заголовка ответа столбец «Использование» определяет требования к исходному серверу по предоставлению поля заголовка.
Реализация, заявляющая о соответствии этой части Стандарта, должна функционировать в соответствии со всеми её обязательными разделами.
Веб-сервисы DICOM используются для передачи составных экземпляров SOP (Composite SOP Instances). Все передаваемые составные экземпляры SOP должны соответствовать требованиям, указанным в других частях Стандарта.
Реализация может соответствовать веб-сервисам DICOM, поддерживая роль исходного сервера или пользовательского агента, либо обе роли для любого из сервисов, определённых в этой части Стандарта. Структура Заявлений о соответствии описана в PS3.2.
Реализация должна описать в своём Заявлении о соответствии реальную деятельность (Real-World Activity), связанную с использованием веб-сервисов DICOM, включая любые функции прокси между веб-сервисом и эквивалентным сервисом DIMSE.
Реализация должна описать в своём Заявлении о соответствии механизмы безопасности, используемые реализацией. См. Раздел 8.11.
Рисунок 5-1 документа PS3.1 представляет общую модель коммуникации Стандарта DICOM, которая охватывает как сетевое (онлайн) взаимодействие, так и обмен через носители информации (офлайн). Прикладные сущности могут использовать любой из следующих механизмов передачи:
-
DICOM Message Service и Upper Layer Service, обеспечивающие независимость от конкретной физической сетевой поддержки и протоколов связи, таких как TCP/IP,
-
DICOM Web Service API и HTTP Service, позволяющие использовать общие гипертекстовые и связанные протоколы для передачи сервисов DICOM,
-
Basic DICOM File Service, обеспечивающий доступ к носителям хранения данных независимо от конкретных форматов физических носителей и файловых структур, или
-
DICOM Real-Time Communication, обеспечивающий передачу метаданных DICOM в реальном времени на основе SMPTE и RTP.
PS3.18 описывает веб-сервисы DICOM, которые используют протоколы HTTP и HTTPS в качестве среды передачи, как показано на Рисунке 7-1.
Эта часть Стандарта определяет веб-сервисы DICOM. Каждый сервис позволяет пользовательскому агенту взаимодействовать с исходным сервером для управления набором ресурсов DICOM. Каждый веб-сервис DICOM работает с набором ресурсов и определяет набор Транзакций, которые действуют на эти ресурсы. Все Транзакции определены в виде пар сообщений HTTP-запрос/ответ.
При использовании в этой части Стандарта термин HTTP относится к семейству протоколов HTTP, включая: HTTP/1.1, HTTPS/1.1, HTTP/2 и HTTPS/2, как определено соответствующими RFC IETF, но не включает HTTP/1.0 или HTTPS/1.0. Стандарты HTTP являются нормативными для всех аспектов формата и передачи HTTP-сообщений.
Существует два общих типа веб-сервисов DICOM: URI и RESTful. Это различие основано на типе протокола веб-сервиса, используемом для спецификации ресурсов и транзакций.
Веб-сервис URI извлекает представления своих ресурсов, которыми являются составные экземпляры SOP (Instance). Сервис URI определяет две Транзакции, которые извлекают экземпляры в различных типах мультимедиа. Все транзакции URI используют компонент запроса URI в сообщении запроса для спецификации Транзакции.
Функциональность Транзакций веб-сервиса URI аналогична, но более ограничена, чем Транзакция Retrieve веб-сервиса Studies.
Каждый RESTful веб-сервис определяет набор ресурсов и Транзакции, которые могут быть применены к этим ресурсам.
Определённые RESTful веб-сервисы:
- Studies Web Service
-
Позволяет пользовательскому агенту управлять Исследованиями (Studies), хранящимися на исходном сервере.
- Worklist Web Service
-
Позволяет пользовательскому агенту управлять Рабочим списком (Worklist), содержащим рабочие элементы (Workitems), хранящиеся на исходном сервере.
- Non-Patient Instance Web Service
-
Позволяет пользовательскому агенту управлять экземплярами, не относящимися к пациенту (Non-Patient Instances), например, цветовыми палитрами, хранящимися на исходном сервере.
- Storage Commitment Service
-
Служба Storage Commitment позволяет пользовательскому агенту запрашивать безопасное хранение экземпляров на исходном сервере.
- Modality Scheduled Procedure Step Service
-
Служба Modality Scheduled Procedure Step позволяет пользовательскому агенту выполнять поиск запланированных этапов процедуры (Scheduled Procedure Steps).
- Modality Performed Procedure Step Service
-
Служба Modality Performed Procedure Step позволяет пользовательскому агенту сообщать о ходе выполнения этапов выполненной процедуры (Performed Procedure Steps).
В RESTful веб-сервисах ресурс — это абстрактный объект с типом, связанными данными, отношениями с другими ресурсами и набором методов, которые действуют на него. Ресурсы объединяются в коллекции. Коллекции сами также являются ресурсами. Каждая коллекция неупорядочена и содержит только один тип ресурса. Коллекции могут существовать глобально на верхнем уровне API, но также могут содержаться внутри ресурса. В последнем случае мы называем такие коллекции подколлекциями. Подколлекции обычно выражают отношение типа «содержится в».
Ресурсы DICOM, определённые в этой части Стандарта, обычно являются либо веб-сервисами DICOM, либо информационными объектами DICOM. Примеры включают Исследования (Studies), Серии (Series), Экземпляры (Instances), Рабочие списки (Worklists) и Рабочие элементы (Workitems).
Ресурсы DICOM группируются в коллекции и иерархии. Следующие ресурсы являются примерами коллекций:
Следующие ресурсы являются примерами иерархий:
Исходный сервер веб-сервиса DICOM управляет коллекцией ресурсов. Это может выполняться не напрямую; например, исходный сервер может действовать как прокси, преобразуя RESTful-запросы в DIMSE-запросы, а DIMSE-ответы в RESTful-ответы.
Ресурсы обычно создаются и/или доступны пользовательскими агентами.
Ресурс — это абстрактное понятие, которое конкретизируется посредством представления, представляющего собой объект данных, закодированный в виде потока октетов. Например, Исследование DICOM (абстрактное) может быть представлено последовательностью октетов, закодированных в выбранном типе мультимедиа. См. Раздел 8.7.3.
Тип мультимедиа (Media Type) описывает формат или кодировку представления. Примерами типов мультимедиа являются application/dicom, application/dicom+json, image/jpeg и text/html.
Ресурсы идентифицируются URI. Каждый сервис определяет управляемые им ресурсы и формат URI, используемых для ссылки на эти ресурсы. Формат URI определяется с использованием шаблонов URI. См. [RFC6570].
Этот раздел описывает детали и требования, общие для всех веб-сервисов, определённых в этой части Стандарта.
Пользовательский агент или исходный сервер, реализующий Сервис в этой части Стандарта, должен соответствовать Разделу 8, если иное не указано в спецификации этого Сервиса и его Транзакций.
Каждая Транзакция состоит из сообщения запроса и сообщения ответа, иногда называемых парой запрос/ответ. При использовании в этой части Стандарта термин «запрос» означает «сообщение запроса», а «ответ» означает «сообщение ответа», если явно не указано иное. Рисунок 8.1-1 представляет собой диаграмму взаимодействия, показывающую поток сообщений в Транзакции. При получении запроса исходный сервер обрабатывает его и возвращает ответ.
Запрос включает метод, URI целевого ресурса и поля заголовка. Он также может включать параметры запроса и полезную нагрузку.
Ответ включает код состояния, фразу причины, поля заголовка и может также включать полезную нагрузку.
Эта часть Стандарта использует ABNF, определённую в Разделе 5.1, для определения синтаксиса Транзакций.
Все сообщения запросов API веб-сервисов имеют следующий синтаксис:
method SP target-uri SP version CRLF
*(header-field CRLF)
CRLF
[payload]
method = "CONNECT" / "DELETE" / "GET" / "HEAD" / "OPTIONS" / "POST" / "PUT" |
|
SP= %x20 |
|
target-uri = "/" {/resource} {?parameters*}
|
Каждая Транзакция определяет шаблон URI для целевого ресурса. Шаблон определяет формат URI, которые ссылаются на целевой ресурс запроса. См. Раздел 8.1.1.2. |
version = ("HTTP" / "HTTPS") "/" ("1.1" / "2")
|
Версия протокола HTTP; одна из «HTTP/1.1», «HTTP/2», «HTTPS/1.1» или «HTTPS/2». |
CRLF = %x0D.0A |
Возврат каретки US-ASCII (%x0D), за которым следует перевод строки (%x0A). |
*(header-field CRLF) |
Ноль или более полей заголовка, каждое из которых завершается разделителем CRLF. |
[payload] = *OCTET / multipart-payload |
Необязательная полезная нагрузка, содержащая ноль или более 8-битных OCTET. |
Примечание
method, SP, version, CRLF, header-field и payload — все это продукты HTTP из [RFC7230] и [RFC7231]. Определения воспроизведены здесь для удобства.
Метод запроса — один из методов HTTP, таких как CONNECT, DELETE, GET, HEAD, OPTIONS, POST, PUT. См. [RFC7230] Раздел 4.
Целевой ресурс запроса определяется целевым URI, содержащимся в сообщении запроса. См. Раздел 8.2.
Параметры запроса содержатся в компоненте запроса (см. [RFC3986]) URI. Пользовательский агент может использовать параметры запроса для передачи параметров в запрос. См. Раздел 8.3.
Поля заголовка запроса используются для указания метаданных для запроса. Большинство запросов имеют одно или более полей заголовка согласования содержимого (см. Раздел 8.4.1). Если запрос имеет полезную нагрузку, запрос будет содержать соответствующие поля заголовка представления содержимого (см. Раздел 8.4.2) и полезной нагрузки (см. Раздел 8.4.3).
Полезная нагрузка запроса — это поток октетов, содержащий содержимое сообщения. См. Раздел 8.6. Наличие полезной нагрузки в запросе сигнализируется полем заголовка Content-Length или Transfer-Encoding.
Синтаксис ответного сообщения следующий:
version SP status-code SP reason-phrase CRLF
*(header-field CRLF)
CRLF
[payload]
status-code = 3DIGIT |
|
reason-phrase = *(HTAB / SP / VCHAR) |
Понятная человеку фраза, соответствующая статусу. Реализация может определять собственные фразы-причины. Синтаксис reason-phrase слегка изменён по сравнению с [RFC7230]; настоящая Часть Стандарта не разрешает устаревший текст (obs-text) в reason-phrase. |
Примечание
Продукция status-code взята из [RFC7230].
Исходный сервер должен всегда возвращать ответное сообщение.
Ответное сообщение должно всегда содержать допустимый трёхзначный код состояния. Раздел 8.5 определяет коды состояния, используемые Транзакциями. IANA ведёт реестр кодов состояния HTTP. См. [IANA HTTP Status Code Registry].
Поля заголовка ответа используются для указания метаданных ответа. Ответ будет содержать поля заголовка представления содержимого (см. Раздел 8.4.2) и полезной нагрузки (см. Раздел 8.4.3), соответствующие содержимому полезной нагрузки.
Полезная нагрузка ответа — это поток октетов, содержащий одно или несколько представлений. См. Раздел 8.6.
Транзакция обычно определяет два типа полезных нагрузок для ответного сообщения: полезную нагрузку успеха и полезную нагрузку отказа.
Полезная нагрузка ответа об отказе должна содержать отчёт о состоянии (Status Report), описывающий любые ошибки, предупреждения или другую полезную информацию.
Спецификации Транзакций определяют, какие типы ресурсов являются допустимыми Целевыми ресурсами для Транзакции, и определяют формат URI для Целевого ресурса (и Параметров запроса) с использованием шаблонов URI. URI Целевого ресурса называется Целевым URI. Спецификации Транзакций также определяют, какие типы ресурсов являются допустимыми ресурсами для ответа.
Целевой URI состоит из трёх компонентов: Базового URI, Пути целевого ресурса и Параметров запроса (которые часто являются необязательными).
Пробельные символы не допускаются в URI. Пробельные символы вокруг разрывов строк и сами разрывы строк следует удалить перед разбором URI. См. Приложение C в [RFC3986].
Наиболее общий шаблон Целевого URI:
target-uri = "/" {/resource} {?optional*}
или, если какие-либо Параметры запроса являются обязательными
target-uri = "/" {/resource} ?{required*}{&optional*}
"/" |
Символ косой черты ('/') используется для обозначения Базового URI. |
{/resource}
|
Шаблон URI для Пути целевого ресурса — относительного компонента пути, ссылающегося на Целевой ресурс. '/' в шаблоне указывает, что зарезервированные символы, такие как '/', могут использоваться в раскрытии шаблона. См. [RFC6570]. «/{/resource}» обозначает абсолютный URI Целевого ресурса на исходном сервере. |
{required*}
|
Шаблон URI для одного или нескольких обязательных параметров запроса. См. пример в Разделе 8.3.1. |
{&optional*}
|
Шаблон URI для нуля или более необязательных параметров запроса. См. пример в Разделе 8.3.1. |
Базовый URI Сервиса — это абсолютный URI, указывающий расположение исходного сервера, реализующего Сервис. Каждый Целевой URI, определённый настоящей Частью Стандарта, начинается с «/», что является сокращением, обозначающим Базовый URI Сервиса. Базовый URI может поддерживать более одного Сервиса.
Корневой путь Сервиса (Service Root Path) — это Базовый URI без компонентов Scheme и Authority.
Путь целевого ресурса — это относительный URI, указывающий путь к ресурсу от Базового URI Сервиса. Он задаётся шаблоном URI, использующим расширение пути {/var}, как определено в [RFC6570].
http://dicom.nema.org/service/studies/2.25.123456789/series/2.25.987654321
http://dicom.nema.org/service
/service
/studies/2.25.123456789/series/2.25.987654321
/studies/{study}/series/{series}
Параметры запроса указываются в компоненте запроса URI (см. [RFC3986] Раздел 3.4).
Компонент запроса URI запроса может использоваться только для указания одного или нескольких Параметров запроса. Эти параметры называются Параметрами запроса, чтобы отличать их от параметров полей заголовка или других типов параметров, которые могут содержаться в полезной нагрузке.
Параметры запроса задаются с использованием шаблона URI, использующего расширение формы запроса {?var} и стиль продолжения запроса {&var}, как определено в [RFC6570].
Если Целевой URI содержит «компонент запроса» (см. [RFC3986] Раздел 3.4), он должен содержать Параметры запроса, соответствующие синтаксису, определённому здесь.
Сервисы и Транзакции, определённые в других местах настоящей Части Стандарта, могут дополнительно уточнить правила qp-name и qp-value, определённые ниже.
[RFC3986] не допускает пустой компонент запроса, т.е. если в Целевом URI присутствует «?», то в URI должен быть хотя бы один Параметр запроса.
Исходный сервер может определять и поддерживать дополнительные Параметры запроса или дополнительные значения Параметров запроса для существующего Параметра запроса. Если исходный сервер определяет новые или расширяет существующие Параметры запроса, они должны быть задокументированы в Заявлении о соответствии (Conformance Statement) и, если сервис это поддерживает, в ответе Retrieve Capabilities.
Исходный сервер должен игнорировать любые неподдерживаемые Параметры запроса. Исходный сервер должен обработать запрос так, как если бы неподдерживаемые параметры отсутствовали, и может вернуть ответ, содержащий соответствующие предупреждения и/или сообщения об ошибках.
Если поддерживаемый Параметр запроса имеет недопустимое значение, исходный сервер должен вернуть ответ об ошибке 400 (Bad Request) и может включить полезную нагрузку, содержащую соответствующий Отчёт о состоянии.
Параметры запроса имеют следующий синтаксис:
query-parameters = "?" parameter *("&" parameter)
Каждый параметр после первого отделяется от следующего параметра символом «&». Каждый параметр имеет следующий синтаксис:
parameter = qp-name
/ qp-name "=" 1#qp-value
/ qp-name "=" 1#attribute
/ attribute
/ attribute "=" 1#qp-value
Имя qp-name чувствительно к регистру и начинается с буквенного символа или символа подчёркивания, за которым следует ноль или более буквенно-цифровых символов или символов подчёркивания «_»:
qp-name = %s 1*(ALPHA / "_") *(ALPHA / DIGIT / "_")
Имя qp-name само по себе (без значений) является допустимым Параметром запроса. За именем параметра qp-name может также следовать разделённый запятыми список одного или более значений qp-values или одного или более Атрибутов.
Значения qp-values чувствительны к регистру. Значение qp-value состоит из qp-символов, где qp-char — это множество допустимых символов компонента запроса, определённых [RFC3986], минус символы равенства («=»), амперсанда («&») и запятой («,»).
qp-value = %s DQUOTE 1*qp-char DQUOTE
qp-char = unreserved / pct-encoded / qp-special
qp-special = "!" / "$" / "'" / "(" / ")" / "*" / "+" / ";" /":" / "@" / "/" / "?"
Единственные видимые символы US-ASCII, не допускаемые в компоненте запроса стандартом [RFC3986] — это «#», «[», «]». Настоящая Часть Стандарта дополнительно запрещает «&», «=» и «,». Однако символы («#», «[», «]», «&», «=» и «,») могут быть включены в значения qp-values, если они закодированы в процентной кодировке.
Каждый Атрибут является либо simple-attribute, либо sequence-attribute:
attribute = simple-attribute / sequence-attribute
simple-attribute — это одиночный Тег элемента данных или Ключевое слово (см. Таблицу 6-1 «Реестр элементов данных DICOM» в PS3.6), которое не имеет VR типа SQ:
simple-attribute = keyword / tag keyword = %s DQUOTE 1*ALPHA *(ALPHA / DIGIT) DQUOTE tag = 8HEXDIG
Ключевые слова DICOM чувствительны к регистру; они должны начинаться с буквенного символа, за которым следует ноль или более буквенно-цифровых символов. См. PS3.6.
sequence-attribute — это два или более атрибута, разделённых символом точки («.»), при этом все атрибуты, кроме последнего, должны иметь VR типа SQ, а последний атрибут не должен иметь VR типа SQ.
sequence-attribute = (keyword / tag) *("." attribute)
Ниже приведены примеры допустимых значений attribute:
0020000D
StudyInstanceUID
00101002.00100020
OtherPatientIDsSequence.PatientID
00101002.00100024.00400032
OtherPatientIDsSequence.IssuerOfPatientIDQualifiersSequence.UniversalEntityID
Некоторые Параметры запроса имеют qp-name, являющийся атрибутом, и значение, представляющее собой разделённый запятыми список одного или более qp-values. Значения qp-values параметра-атрибута должны удовлетворять его Представлению значения (Value Representation) и Кратности значения (Value Multiplicity), как определено в PS3.5 и PS3.6, соответствующего атрибута.
В отличие от Представлений значений, определённых в PS3.5, Параметры запроса:
-
должны кодировать UID, как указано в PS3.5, за исключением того, что они не должны выравниваться до чётной длины
Синтаксис и семантика допустимых qp-names, qp-values и атрибутов определяются соответствующим Сервисом или Транзакцией; однако они должны соответствовать правилам данного Раздела.
Таблица 8.3.1-1 содержит собранный синтаксис Параметров запроса. Сервисы и Транзакции, определённые в других местах настоящей Части Стандарта, могут дополнительно уточнить правила qp-name, attribute и qp-value.
Все имена qp-names чувствительны к регистру.
Таблица 8.3.1-1. ABNF для параметра запроса
query-parameters |
= "?" parameter *("&" parameter)
|
parameter |
= qp-name; a name only / qp-name "=" 1#qp-value ; a name with one or more values / qp-name "=" 1#attribute; a name with one or more attributes / attribute; an attribute only / attribute "=" 1#qp-value ; an attribute with one or more values |
qp-name |
= %s (ALPHA / "_") *(ALPHA / DIGIT / "_") |
qp-value |
=int / uint / pos-int / decimal / float /string / base64 / uid / %s 1*qp-char/ %s DQUOTE 1*qp-special DQUOTE; See Раздел 5.1.1 |
qp-char |
= unreserved / pct-encoded |
qp-special |
= "!" / "$" / "'" / "(" / ") " / "*" / "+" / ";"/":" / "@" / "/" / "?"
|
simple-attribute |
= keyword / tag |
sequence-attribute |
= keyword *( "." attribute) / tag *( "." attribute ) |
keyword |
= %suppercase *( ALPHA / DIGIT ) |
uppercase |
=%x41-5A |
tag |
= 8HEXDIG |
Примечание
Синтаксис qp-values определён в Разделе 5.1.1.
Правило qp-char (символы параметра запроса), определённое выше, является правилом query из [RFC3986], которое определяет допустимые символы для компонента запроса, минус знак равенства («=»), запятая («,») и амперсанд («&»). Таким образом, правило qp-char — это правило VCHAR минус «#», «[», «]», «=», «&» и «,».
Все ключевые слова DICOM чувствительны к регистру. См. PS3.6.
Поддержка Параметров запроса реализацией является либо Обязательной, либо Необязательной. Каждый раздел Параметров запроса содержит таблицу, определяющую ключи Параметров запроса, значения и требования к использованию пользовательским агентом и исходным сервером. Таблица 8.3.2-1 определяет символы использования, типы и определения.
Таблица 8.3.2-2 показывает пример таблицы Параметров запроса.
Столбцы использования указывают Параметры запроса, которые пользовательский агент должен предоставить, а исходный сервер должен поддерживать.
Параметры, определённые в этом разделе, в первую очередь предназначены для использования в гиперссылках, т.е. URI, встроенных в документы, где Поля заголовка согласования содержимого (см. Раздел 8.3.3) недоступны.
Параметр запроса Accept имеет следующий синтаксис:
accept = accept-name "=" 1#(media-type [weight]) accept-name = %s"accept"
Параметр запроса Accept имеет тот же синтаксис, что и поле заголовка Accept (см. Раздел 8.4.3), за исключением того, что он не должен содержать подстановочные знаки (<type>/* или */*). См. Раздел 8.7.
Примечание
-
Обычное имя этого параметра — «accept»; однако URI-сервис использует accept-name «contentType». См. Раздел 9.1.2.2.1.
-
Префикс «%s» перед accept-name указывает, что это токен, чувствительный к регистру. См. [RFC7405].
Значение параметра — это разделённый запятыми список одного или более media-types.
Параметр запроса Accept не следует использовать, когда пользовательский агент может указать значения с помощью поля заголовка Accept.
Все Типы мультимедиа (Media Types), присутствующие в Параметре запроса Accept, должны быть совместимы с диапазоном медиа в поле заголовка Accept, явно или неявно через подстановочные знаки.
Примечание
Например, наличие image/jpeg в Параметре запроса Accept потребует, чтобы поле заголовка Accept включало одно или несколько из следующих значений: image/jpeg, image/* или */*.
Если ни один из Приемлемых типов мультимедиа (см. Раздел 8.7.5) не поддерживается исходным сервером, ответ исходного сервера должен быть в Типе мультимедиа по умолчанию для Категории ресурсов Целевого ресурса. Если для Целевого ресурса не определён Тип мультимедиа по умолчанию, ответ исходного сервера должен быть 406 (Not Acceptable) и может включать полезную нагрузку, содержащую соответствующий Отчёт о состоянии.
Если присутствует Тип мультимедиа DICOM, Типы мультимедиа, не относящиеся к DICOM, не должны присутствовать. Если присутствуют как DICOM, так и не-DICOM Типы мультимедиа, ответ должен быть 400 (Bad Request) и может включать полезную нагрузку, содержащую соответствующий Отчёт о состоянии.
Параметр запроса Character Set имеет следующий синтаксис:
character-set = "charset" "=" 1#(charset [weight])
Значение Параметра запроса Character Set — это разделённый запятыми список одного или более идентификаторов наборов символов. Он аналогичен полю заголовка Accept-Charset, за исключением того, что он не должен содержать подстановочные знаки. См. Раздел 8.8.
Примечание
Идентификаторы наборов символов, присутствующие в Параметре запроса character set, обычно имеют соответствующий идентификатор набора символов в поле заголовка Accept-Charset, явно или неявно через подстановочные знаки.
Если этот параметр имеет значение, которое не поддерживается, это значение должно быть проигнорировано.
Таблица 8.3.4-1 содержит синтаксис имён и значений параметров поиска, а также ссылку на раздел, где определено их значение. Поисковые Транзакции должны поддерживать эти параметры. ABNF для различных параметров поиска:
Таблица 8.3.4-1. Синтаксис параметров запроса
search |
= match / fuzzymatching / includefield / limit / offset / emptyvaluematching / multiplevaluematching |
|||
match |
; See attribute matching rules below |
|||
fuzzymatching |
= "fuzzymatching" "=" true / false |
|||
includefield |
= "includefield" "=" 1#attribute / "all" |
|||
limit |
= "limit" "=" uint ; Maximum number of results |
|||
offset |
= "offset" "=" uint ; Number of skipped results |
|||
emptyvaluematching |
= "emptyvaluematching" "=" true / false |
|||
multiplevaluematching |
= "multiplevaluematching" "=" true / false |
|||
Следующие разделы подробно описывают эти параметры.
Синтаксис Параметра запроса match должен быть следующим:
match = normal-match / uid-list-match
normal-match = 1*("&" attribute "=" value)
uid-list-match = 1*("&" attribute "=" 1#value)
attribute = (attribute-id) *("." attribute-id)
attribute-id = tag *("." tag) / keyword *("." keyword)
tag = 8HEXDIG
keyword= ;A keyword from Table 6-1 “Registry of DICOM Data Elements” in PS3.6.
Одна или несколько пар DICOM Атрибут/Значения задают критерии сопоставления для поиска.
Каждая поисковая Транзакция определяет, какие Атрибуты являются обязательными или разрешёнными.
Примечание
Атрибуты DICOM не следует путать с атрибутами XML. Теги и Ключевые слова для Атрибутов DICOM определены в Таблице 6-1 «Реестр элементов данных DICOM» в PS3.6.
Пары DICOM Атрибут/Значения должны удовлетворять следующим требованиям:
-
Каждый attribute-id должен быть Тегом элемента данных или Ключевым словом.
-
Каждый атрибут в Параметре запроса должен иметь единственное значение, если только соответствующий Атрибут DICOM не допускает сопоставление списка UID (см. Раздел C.2.2.2.2 в PS3.4 ), в этом случае значение представляет собой разделённый запятыми список UID.
-
Если тег представляет собой Частный элемент данных (Private Data Element), запрос также должен включать соответствующий элемент Private Creator (см. Раздел 7.8.1 в PS3.5 ).
-
Допустимые значения определяются типами сопоставления, разрешёнными для C-FIND для соответствующего атрибута. См. Раздел C.2.2.2 в PS3.4 . Все символы в значениях, не являющиеся qp-chars, должны быть закодированы в процентной кодировке. Все символы, не относящиеся к ASCII, должны быть закодированы в процентной кодировке. См. [RFC3986] для подробностей.
Следующие символы US-ASCII «#», «[», «]», «&», «=» и «,» должны быть закодированы в процентной кодировке в любом Параметре запроса.
Параметр запроса match соответствует Ключам сопоставления DIMSE (DIMSE Matching Keys). См. Раздел K.2.2.1.1 в PS3.4 .
Семантика сопоставления для каждого атрибута определяется типами сопоставления, разрешёнными для C-FIND. См. Раздел C.2.2.2 «Сопоставление атрибутов» в PS3.4.
Результаты сопоставления должны генерироваться в соответствии с Иерархическим методом поиска, описанным в Раздел C.4.1.3.1.1 «Иерархический метод поиска» в PS3.4.
Комбинированное сопоставление даты и времени должно выполняться, как указано в Раздел C.2.2.2.5 «Сопоставление диапазона» в PS3.4.
Примечание
Если исходный сервер действует как прокси для C-FIND SCP, который не поддерживает комбинированное сопоставление даты и времени, он должен выполнить запрос C-FIND, используя только дату, и отфильтровать любые результаты, выходящие за пределы диапазона времени, перед возвратом ответа.
Если Атрибут Timezone Offset From UTC (0008,0201) указан в запросе, даты и время в запросе должны интерпретироваться в указанном часовом поясе. См. Раздел C.4.1.1 в PS3.4 .
Единственный параметр указывает, следует ли выполнять нечёткое сопоставление имён персон.
Этот параметр является необязательным для пользовательского агента.
Этот параметр является необязательным для исходного сервера.
Если этот параметр отсутствует, его значение — «false».
fuzzymatching = "fuzzymatching" "=" ("true" / "false")
Если значение «false», поиск должен выполняться без нечёткого сопоставления.
Если значение «true» и исходный сервер поддерживает нечёткое сопоставление, поиск должен выполняться с нечётким сопоставлением Атрибутов имён персон, как указано в Раздел C.2.2.2.1.1 в PS3.4 и должен быть задокументирован в Заявлении о соответствии и, если сервис это поддерживает, в ответе Retrieve Capabilities.
Если значение «true» и исходный сервер не поддерживает нечёткое сопоставление, тогда:
-
Ответ должен содержать следующий заголовок HTTP Warning (см. [RFC7234] Раздел 5.5) :
Warning: 299 <service>: The fuzzymatching parameter is not supported. Only literal matching has been performed.
где <service> — это базовый URI для исходного сервера. Это может быть комбинация схемы, полномочий (authority) и пути.
-
Ответ может включать полезную нагрузку, содержащую соответствующий Отчёт о состоянии.
Параметр указывает Атрибуты, которые должны быть включены в ответ. Значение — либо разделённый запятыми список атрибутов, либо единственное ключевое слово «all», которое означает, что все доступные атрибуты объекта должны быть включены в ответ.
includefield = *("includefield" "=" (1#attribute / "all") )
Запрос может содержать один или несколько параметров include; однако, если присутствует параметр со значением «all», другие параметры includefield не должны присутствовать. Если атрибут является значением параметра includefield, это эквивалентно универсальному сопоставлению C-FIND (Universal matching) для этого атрибута. См. Раздел C.2.2.2.3 в PS3.4 .
Если параметр include представляет Частный элемент данных (Private Data Element), соответствующий элемент Private Creator должен быть указан как дополнительный параметр match (см. Раздел 7.8.1 в PS3.5 ).
Параметр запроса includefield соответствует Ключам возврата DIMSE (DIMSE Return Keys).
Следующие два параметра могут использоваться для разбиения на страницы ответа поиска, который может содержать больше совпадений, чем может быть удобно обработано.
offset = "offset" "=" uint
Единственный параметр указывает количество совпадений, которые исходный сервер должен пропустить перед первым возвращаемым совпадением. Значение параметра «offset» — это беззнаковое целое число (uint). Если этот Параметр запроса отсутствует, его значение по умолчанию равно 0.
limit = "limit" "=" uint
Единственный параметр указывает максимальное количество совпадений, которые исходный сервер должен вернуть в одном ответе. Значение параметра «limit» — это беззнаковое целое число. Если этот параметр отсутствует, его значение определяется, как указано в 8.3.4.4.1.
Запросы поиска должны быть идемпотентными, то есть два отдельных поисковых запроса с одним и тем же Целевым ресурсом, Параметрами запроса и Полями заголовка должны возвращать один и тот же упорядоченный список совпадений, если набор совпадений на исходном сервере не изменился.
Результаты, возвращённые в ответе, определяются следующим образом:
-
Если (results = 0), то совпадений нет, и должен быть возвращён ответ 200 (OK) с пустой полезной нагрузкой. Когда Приемлемый тип мультимедиа — application/dicom+json, пустая полезная нагрузка должна быть закодирована как пустой массив JSON ([]). Когда Приемлемый тип мультимедиа — application/dicom+xml, пустая полезная нагрузка должна быть закодирована как пустой корневой элемент NativeDicomModel.
Примечание
В предыдущих версиях Стандарта при отсутствии совпадений указывался ответ 204 (No Content). Ответ 204 не имеет тела сообщения, тогда как ответ 200 (OK) включает тело сообщения (которое может быть пустым). Ответ 200 (OK) с пустой полезной нагрузкой согласуется с другими сервисами DICOMweb и с [RFC9110], который рекомендует использовать 200, когда представление ответа описывает результат, даже если представление имеет нулевую длину.
-
В противном случае должен быть возвращён ответ 200 (OK) с полезной нагрузкой, содержащей результаты.
-
Если (remaining > 0), ответ должен содержать Поле заголовка Warning (см. [RFC7234] Раздел 5.5) содержащее следующее:
Warning: 299 <service>: There are <remaining> additional results that can be requested
Ответ может включать полезную нагрузку, содержащую соответствующий Отчёт о состоянии.
Если набор совпадающих результатов изменился из-за изменений в содержимом исходного сервера, упорядоченный список результатов может отличаться для последующих Транзакций с идентичными запросами, и результаты использования параметров «offset» и «limit» могут быть несогласованными.
Единственный параметр указывает, следует ли выполнять сопоставление пустых значений.
Этот параметр является необязательным для пользовательского агента.
Этот параметр является необязательным для исходного сервера.
Если этот параметр отсутствует, его значение — «false».
emptyvaluematching = "emptyvaluematching" "=" ("true" / "false")
Если значение «false», поиск должен выполняться без сопоставления пустых значений.
Если значение «true» и исходный сервер поддерживает сопоставление пустых значений, поиск должен выполняться с сопоставлением пустых значений Атрибутов, как указано в Раздел C.2.2.2.7 «Сопоставление пустых значений» в PS3.4 и должен быть задокументирован в Заявлении о соответствии и, если сервис это поддерживает, в ответе Retrieve Capabilities.
Если значение «true» и исходный сервер не поддерживает сопоставление пустых значений, тогда:
-
Ответ должен содержать следующий заголовок HTTP Warning (см. [RFC7234] Раздел 5.5):
Warning: 299 <service>: The emptyvaluematching parameter is not supported. Empty Value Matching has not been performed.
где <service> — это базовый URI для исходного сервера. Это может быть комбинация схемы, полномочий (authority) и пути.
-
Ответ может включать полезную нагрузку, содержащую соответствующий Отчёт о состоянии.
Единственный параметр указывает, следует ли выполнять множественное сопоставление значений.
Этот параметр является необязательным для пользовательского агента.
Этот параметр является необязательным для исходного сервера.
Если этот параметр отсутствует, его значение — «false».
multiplevaluematching = "multiplevaluematching" "=" ("true" / "false")
Если значение «false», поиск должен выполняться без множественного сопоставления значений.
Если значение «true» и исходный сервер поддерживает множественное сопоставление значений, поиск должен выполняться с множественным сопоставлением значений Атрибутов, как указано в Раздел C.2.2.2.8 «Множественное сопоставление значений» в PS3.4 и должен быть задокументирован в Заявлении о соответствии и, если сервис это поддерживает, в ответе Retrieve Capabilities.
Если значение «true» и исходный сервер не поддерживает множественное сопоставление значений, тогда:
-
Поиск должен выполняться без множественного сопоставления значений.
-
Ответ должен содержать следующий заголовок HTTP Warning (см. [RFC7234] Раздел 5.5):
Warning: 299 <service>: The multiplevaluematching parameter is not supported. Multiple Value Matching has not been performed.
где <service> — это базовый URI для исходного сервера. Это может быть комбинация схемы, полномочий (authority) и пути.
-
Ответ может включать полезную нагрузку, содержащую соответствующий Отчёт о состоянии.
Этот раздел определяет синтаксис и поведение Параметров запроса для запросов получения Отрисованных типов мультимедиа (Rendered Media Types).
Все Транзакции получения для Отрисованных типов мультимедиа должны поддерживать эти параметры.
Параметры запроса, определённые в этом разделе, задают различные преобразования отрисовки, которые должны быть применены к DICOM-изображениям, видео и тексту, содержащимся в родительском DICOM-ресурсе.
Следующие правила относятся ко всем параметрам, определённым в этом разделе:
-
Все параметры являются необязательными для пользовательского агента.
-
Эти параметры применяются только к ресурсам Single Frame Image, Multi-Frame Image, Video и Text. См. Раздел 8.7.2.
Набор преобразований, заданных параметрами в этом разделе, должен быть применён к изображениям так, как если бы параметры были Состоянием представления (Presentation State). Исходный сервер определяет представление других объектов, управляющих отображением изображений, таких как Структурированные отчёты или Объекты сегментации.
Преобразования Состояния представления применяются с использованием соответствующего конвейера отрисовки, указанного в Раздел N.2 «Последовательность преобразования пикселей» в PS3.4. Любые параметры Source Image Region применяются после любых параметров Состояния представления. Любые параметры Viewport применяются после любых параметров Source Image Region.
Даже если выходные данные изображения определены в P-Values (значения в оттенках серого, предназначенные для отображения на устройстве, откалиброванном по DICOM Grayscale Standard Display Function PS3.14), или содержат ICC-профиль, оттенки серого или цветовое пространство для отрисованного изображения не определяются настоящим Стандартом.
Таблица 8.3.5-1 показывает Параметры запроса, которые могут использоваться при запросе Отрисованного представления.
Таблица 8.3.5-1. Параметры запроса для отрисованного получения
accept |
Rendered Media Type |
||
annotation |
"patient" and/or "technique" |
||
charset |
character set token |
||
quality |
uint |
||
viewport |
vw, vh [, sx, sy, sw, sh ] |
||
viewport |
vw, vh |
||
window |
center, width, shape |
||
iccprofile |
"no", "yes", "srgb", "adobergb", "rommrgb" or "displayp3" |
Этот параметр указывает, что визуализированные изображения или видео будут иметь аннотации. Его имя — «annotation», а его значение — разделённый запятыми список из одного или нескольких ключевых слов. Он имеет следующий синтаксис:
annotation = %s"annotation=" 1#( %s"patient" / %s"technique" )
Если этот параметр отсутствует, аннотации не должны применяться.
Конвейеры визуализации изображений, указанные в PS3.4, требуют, чтобы аннотации применялись после применения всех остальных параметров и визуализации изображения или видео. Точный характер и представление аннотаций определяются исходным сервером и «впечатываются» в визуализированное содержимое.
Исходный сервер может поддерживать дополнительные ключевые слова, которые должны быть документированы в Заявлении о соответствии и, если служба это поддерживает, в ответе Retrieve Capabilities.
Если какое-либо из значений параметра не является ключевым словом или значения параметра отсутствуют, исходный сервер должен вернуть ответ 400 (Bad Request) и может включить полезную нагрузку, содержащую соответствующее сообщение об ошибке.
Исходный сервер должен игнорировать любые неподдерживаемые значения параметра. Если присутствуют неподдерживаемые значения, исходный сервер должен включить следующее поле заголовка:
Warning 299 <service>: The following annotation values are not supported: <values>
и может включить полезную нагрузку, содержащую соответствующее предупреждение.
Примечание
-
Точный характер и представление аннотации определяются исходным сервером. Аннотация впечатывается в пиксели визуализированного изображения.
-
Пользовательский агент, желающий большего контроля над аннотациями, может получить изображение, опуская параметр «annotation», отдельно получить метаданные и создать настраиваемые аннотации на изображении.
-
Пользовательский агент, желающий большего контроля над аннотациями, может получить изображение, опуская параметр «annotation», отдельно получить метаданные и создать настраиваемые аннотации на изображении.
-
Целевой ресурс уже может содержать «впечатанный» текст, который находится вне контроля этого параметра.
Параметр "quality" задаёт запрошенное качество визуализированных изображений или видео. Он имеет следующий синтаксис:
quality = %s"quality=" uint
Если значение этого параметра отсутствует или не является целым числом от 1 до 100 включительно, ответ должен быть 400 (Bad Request) и может включать полезную нагрузку, содержащую соответствующее сообщение об ошибке.
Параметр "quality" поддерживается только для типов носителей, допускающих сжатие с потерями.
Значение этого параметра определяется исходным сервером и должно быть документировано в Заявлении о соответствии и, если Служба это поддерживает, в ответе Retrieve Capabilities.
Примечание
-
Декомпрессия и повторное сжатие могут ухудшить качество изображения, если исходное изображение уже было необратимо сжато. Если изображение уже было сжато с потерями в том же формате, который требуется (например, jpeg), оно может быть отправлено как есть без декомпрессии и повторного сжатия.
-
Исходный сервер может проигнорировать параметр quality, если результирующее качество изображения было бы слишком низким.
Параметр "viewport" задаёт прямоугольную область исходного изображения(ий) или видео для обрезки и прямоугольную область, соответствующую размеру области просмотра пользовательского агента, до которой должно быть масштабировано обрезанное изображение или видео.
Синтаксис этого параметра для экземпляра Presentation State или Thumbnail:
%s"viewport=" vw "," vh
%s"viewport=" vw "," vh ["," [sx] "," [sy] "," [sw] "," [sh] ]
Исходный сервер должен обрезать исходные изображения или видео до области, заданной параметрами sx, sy, sw и sh. Затем он должен масштабировать исходное содержимое, сохраняя пропорции обрезанной области, пока ширина или высота визуализированного содержимого не совпадёт с шириной или высотой области просмотра, в зависимости от того, что позволяет избежать усечения. Иными словами, масштабирование области просмотра делает изображение(я) максимально большим в пределах области просмотра без переполнения области просмотра и без искажения изображения.
Если какое-либо из необязательных значений параметра отсутствует, должно использоваться значение по умолчанию. Отдельные значения могут быть опущены, но запятые между значениями должны присутствовать. Например:
viewport=512,512,,,512,512
Отсутствующие значения параметров sx и sy по умолчанию равны 0.
Если конечные значения опущены, то и конечные запятые должны быть опущены. Например:
viewport=1024,1024
Отсутствующие sx, sy, sw, sh получат свои значения по умолчанию, т. е. изображение(я) не должны обрезаться, т. е. визуализируется полное изображение.
Если параметр viewport отсутствует, визуализированное изображение(я) или видео не должны масштабироваться, т. е. визуализированное изображение(я) должно содержать ту же матрицу пикселей, что и исходное DICOM-изображение.
Если верно любое из следующего:
то ответ должен быть 400 (Bad Request) и может включать полезную нагрузку, содержащую соответствующий отчёт о статусе.
Примечание
Значения по умолчанию для sx и sy отличаются от значений по умолчанию в Specified Displayed Area в Presentation States, где используются целочисленные значения с верхним левым углом (1\1). См. Раздел C.10.4 в PS3.3 .
Параметр "window" управляет оконной обработкой изображений или видео, как определено в Раздел C.8.11.3.1.5 в PS3.3 . It has the following syntax:
%s"window=" center "," width "," function
Примечание
Они соответствуют значениям VOI LUT Function (0028,1056), записанным с разным регистром и пунктуацией. См. Раздел C.11.2.1.2 в PS3.3 .
Все три параметра должны присутствовать с допустимыми значениями.
Если какое-либо из значений параметра отсутствует или имеет неверный формат, исходный сервер должен вернуть ответ 400 (Bad Request) и может включить полезную нагрузку, содержащую соответствующее сообщение об ошибке.
Если Целевой Ресурс является Presentation State, этот параметр не должен использоваться. Если этот параметр присутствует, когда Целевой Ресурс является Presentation State, исходный сервер должен вернуть 400 (Bad Request).
Параметр "iccprofile" задаёт цветовые характеристики и включение ICC-профиля в визуализированные изображения. Он имеет следующий синтаксис:
%s"iccprofile=" 1#( %s"no" / %s"yes" / %s"srgb" / %s"adobergb" / %s"rommrgb" / %s"displayp3" )
|
указывает, что ICC-профиль не должен присутствовать в визуализированном изображении в ответе. |
|
|
указывает, что ICC-профиль должен присутствовать в визуализированном изображении в ответе, описывая его цветовые характеристики, если Тип Носителя поддерживает встроенные ICC-профили. |
|
|
указывает, что ICC-профиль sRGB должен присутствовать в изображении, если Тип Носителя поддерживает встроенные ICC-профили, и что пиксели визуализированного изображения в ответе должны быть преобразованы из их исходного цветового пространства и закодированы в цветовом пространстве sRGB [IEC 61966-2.1]. |
|
|
указывает, что ICC-профиль Adobe RGB должен присутствовать в изображении, если Тип Носителя поддерживает встроенные ICC-профили, и что пиксели визуализированного изображения в ответе должны быть преобразованы из их исходного цветового пространства и закодированы в цветовом пространстве Adobe RGB [Adobe RGB]. |
|
|
указывает, что ICC-профиль ROMM RGB должен присутствовать в изображении, если Тип Носителя поддерживает встроенные ICC-профили, и что пиксели визуализированного изображения в ответе должны быть преобразованы из их исходного цветового пространства и закодированы в цветовом пространстве ROMM RGB [ISO 22028-2]. |
|
|
указывает, что ICC-профиль Display-P3 должен присутствовать в изображении, если Тип Носителя поддерживает встроенные ICC-профили, и что пиксели визуализированного изображения в ответе должны быть преобразованы из их исходного цветового пространства и закодированы в цветовом пространстве Display-P3 [Display-P3] |
Когда этот параметр отсутствует:
ICC-профиль в изображении в ответе должен быть:
-
ICC-профилем цветового пространства, явно указанного параметром,
-
иначе — ICC-профиль, закодированный в исходном атрибуте DICOM ICC Profile (0028,2000), если таковой имеется, подходящий для выбранного кадра,
-
иначе — ICC-профиль, если таковой имеется, встроенный в сохранённое сжатое представление выбранного кадра,
-
иначе — по усмотрению исходного сервера, ICC-профиль общеизвестного цветового пространства, перечисленного в Раздел C.11.15.1.2 «Color Space» в PS3.3, подходящего для типа и источника изображения.
Если Тип Носителя не поддерживает встроенные ICC-профили:
Примечание
-
Этот параметр позволяет информации ICC-профиля присутствовать в изображении в ответе, чтобы пользовательский агент мог использовать её для локального управления цветом (например, браузер с поддержкой ICC-профилей может применять профиль при отображении визуализированного изображения в ответе).
-
Этот параметр предоставляет ограниченный механизм для запроса того, чтобы исходный сервер выполнил некоторое управление цветом. Он предоставляет названия общеизвестных цветовых пространств для визуализированного изображения в ответе. Он не предоставляет механизм для передачи произвольного ICC-профиля, такого как калибровочный профиль дисплея, поэтому он не освобождает пользовательский агент от необходимости выполнять собственную калибровку цвета и управление цветом.
-
ICC-профили теоретически могут быть велики по сравнению со сжатыми пиксельными данными одного кадра, поэтому пользовательский агент может указать значение параметра "no", получить значения атрибута DICOM ICC Profile (0028,2000), применимые к нескольким кадрам, из метаданных и объединить их самостоятельно.
-
ICC-профили встраиваются в визуализированные изображения типа image/jpeg в виде одного или нескольких блоков в сегментах маркеров APP2 с идентификатором "ICC_PROFILE", как определено в Приложении B [ISO 15076-1].
-
ICC-профили встраиваются в визуализированные изображения типа image/jp2 либо как профили JP2 Restricted, либо как JPX Full в соответствии с [ISO/IEC 15444-1] и [ISO/IEC 15444-2] соответственно; визуализированные изображения в ответе не подлежат запрету на включение JP2-блока в потоки сжатых данных JPEG 2000 в DICOM-изображениях.
-
ICC-профили встраиваются в визуализированные изображения типа image/png в блоке iCCP, как определено в [ISO 15948].
Если Целевой Ресурс является одиночным экземпляром Presentation State, этот экземпляр может содержать ссылки на одну или несколько Series, каждая из которых может содержать один или несколько Instances, каждый из которых может содержать один или несколько Кадров. Ответ должен вернуть визуализированные версии всех поддерживаемых Instances и Кадров, на которые ссылается экземпляр Presentation State.
Например, если экземпляр Presentation State
Если экземпляр Presentation State содержит Blending Sequence, то визуализированные изображения в ответе должны соответствовать кадрам входных данных, имеющим элемент Blending Sequence Item со значением Blending Position (0070,0405), равным UNDERLYING. См. Раздел C.11.14.1.1 «Blending Sequence» в PS3.3 .
Исходный сервер должен визуализировать все изображения, на которые ссылается Presentation State, в Допустимом Типе Носителя, используя конвейер визуализации, указанный в Раздел N.2 «Последовательность преобразования пикселей» в PS3.4.
Если в ответе более одного Кадра, они должны быть упорядочены по следующим критериям:
Если вышеизложенное не полностью определяет порядок кадров, исходный сервер должен устранить любую оставшуюся неоднозначность в порядке.
Если Целевой Ресурс является Presentation State и Если Presentation Size Mode равен SCALE TO FIT или TRUE SIZE, то отображаемая область, указанная в Presentation State, должна быть масштабирована с сохранением пропорций для соответствия размеру, заданному параметрами rows и columns, если они присутствуют; в противном случае отображаемая область, выбранная в состоянии представления, будет возвращена без масштабирования.
Примечание
-
Намерение режима TRUE SIZE в состоянии представления не может быть удовлетворено, поскольку физический размер пикселей, отображаемых веб-браузером, вряд ли известен. Если Presentation Size Mode в состоянии представления — MAGNIFY, отображаемая область, указанная в представлении, должна быть увеличена (масштабирована), как указано в состоянии представления. Затем она будет обрезана в соответствии с размером, заданным параметрами viewport, если они присутствуют.
-
Любые аннотации, относительные к Displayed Area и указанные в состоянии представления, визуализируются относительно Specified Displayed Area в состоянии представления, а не относительно размера возвращённого изображения.
Хотя выходные данные состояния представления определены в DICOM как P-Values (значения в градациях серого, предназначенные для отображения на устройстве, откалиброванном по DICOM Grayscale Standard Display Function PS3.14), шкала серого или цветовое пространство для изображений, возвращаемых запросом, не определяется настоящим стандартом.
Если Presentation State содержит ICC Profile Module, изображение(я) в ответе должно включать ICC-профиль, как указано в Раздел 8.3.5.1.5.
Исходный сервер должен отклонить запрос, если верно любое из следующего:
и исходный сервер должен вернуть ответ 400 (Bad Request) и может включить полезную нагрузку, содержащую соответствующее сообщение об ошибке.
Таблица 8.3.5-2 показывает параметры запроса, которые могут использоваться при запросе представления эскиза (Thumbnail).
Таблица 8.3.5-2. Параметры запроса для эскизов
accept |
Rendered Media Type |
||
charset |
character set token |
||
viewport |
vw, vh |
Параметр Viewport имеет только значения ширины и высоты. Если параметр viewport не предоставлен, исходный сервер определит размер эскиза (Thumbnail).
Параметры запроса, определённые в этом разделе, управляют созданием новых 3D- или MPR-изображений на основе объёмных данных, пересчитанных из Целевого Ресурса.
Следующие правила относятся ко всем параметрам, определённым в этом разделе:
Набор преобразований, заданный параметрами в этом разделе, должен быть применён к изображениям, как если бы параметры были Volumetric Presentation State, то есть в порядке, указанном применимым конвейером визуализации изображений, указанным в Раздел FF.2 PS3.4.
Таблица 8.3.5-3, «Параметры запроса для получения визуализированного объёма» показывает параметры запроса, которые могут использоваться при запросе визуализированного представления объёма (Rendered Volume Representation).
Таблица 8.3.5-3. Параметры запроса для получения визуализированного объёма
volumeinputreference |
uid or frame |
||
match |
; See attribute matching rules in Section 8.3.4.1 |
||
renderingmethod |
"volume_rendered", "maximum_ip", "minimum_ip" or "average_ip" |
||
orientation |
"a", "p", "r", "l", "h" or "f" |
Изображение (однокадровое или многокадровое) или Состояния объёмного представления |
|
viewpointposition |
px, py, pz |
Изображение (однокадровое или многокадровое) или Состояния объёмного представления |
|
viewpointlookat |
lx, ly, lz |
Изображение (однокадровое или многокадровое) или Состояния объёмного представления |
|
viewpointup |
ux, uy, uz |
Изображение (однокадровое или многокадровое) или Состояния объёмного представления |
|
mprslab |
st |
||
swivelrange |
sr |
||
volumetriccurvepoint |
px, py, pz |
||
animationstepsize |
ss |
||
animationrate |
rt |
||
renderedvolumetricmetadata |
"yes" |
Ресурсы Rendered MPR Volume и Rendered 3D Volume имеют два взаимоисключающих варианта для определения начальной ориентации повторно дискретизированных объёмных данных:
При использовании параметров анимации начальный кадр определяется параметрами ориентации. Параметры "swivelrange", "volumetriccurvepoint" и "animationstepsize" определяют последующие кадры. При анимации нескольких наборов временно связанных, пространственно совмещённых объёмных данных (например, многофазного исследования) исходный сервер определяет отображаемую фазу начального кадра.
Не существует параметра для управления типом проекции, используемой при рендеринге. Исходный сервер должен использовать ортографическую проекцию для ресурсов Rendered 3D Volume. См. Раздел C.11.30.1 в PS3.3.
Не существует параметра для явного управления полем обзора рендеринга, высотой MPR-вида или шириной MPR-вида (см. Раздел C.11.30 в PS3.3 и Раздел C.11.26 в PS3.3). Параметр "viewport" может использоваться для масштабирования возвращаемых данных. См. Раздел 8.3.5.1.3.
Параметр "volumeinputreference" идентифицирует экземпляр или кадр внутри экземпляра, из которого исходный сервер должен извлечь характеристики и идентифицировать дополнительные экземпляры или кадры в целевом ресурсе с теми же значениями этих характеристик. Пользовательский агент использует этот параметр для идентификации желаемого подмножества, когда целевой ресурс является надмножеством предполагаемых объёмных данных. Исходный сервер должен идентифицировать подмножество, соответствующее требованиям к входным объёмным данным для ресурсов Rendered MPR Volume и Rendered 3D Volume (см. Раздел C.11.23.1 в PS3.3).
Синтаксис этого параметра для многокадрового изображения:
%s" volumeinputreference =" uid "," frame
В противном случае он имеет вид:
%s" volumeinputreference =" uid
Примечание
uid
соответствует Referenced SOP Instance UID (0008,1155), а кадр соответствует Referenced Frame Number (0008,1160). См. Раздел 10.3 в PS3.3.
Исходный сервер должен создать объёмные данные из экземпляров или кадров, имеющих характеристики, идентичные ссылке на входные объёмные данные, на основе специфической для реализации логики.
Исходный сервер должен вернуть 400 (Bad Request) и может включить соответствующий отчёт о статусе, если верно любое из следующих условий:
Параметр "match" задаёт общие характеристики пар атрибут/значение DICOM для объёмных данных.
Когда пользовательский агент идентифицирует целевой ресурс, который является надмножеством предполагаемых объёмных данных, он может указать пары атрибут/значение, задающие критерии сопоставления для идентификации конкретных экземпляров или кадров в целевом ресурсе для повторной дискретизации в качестве объёмных данных. Результирующее подмножество должно соответствовать требованиям к входным объёмным данным для ресурсов Rendered MPR Volume и Rendered 3D Volume (см. Раздел C.11.23.1 в PS3.3).
См. Раздел 8.3.4.1 для синтаксиса этого параметра.
Пользовательский агент может включить следующие атрибуты в параметр:
Исходный сервер должен реконструировать объёмные данные, удовлетворяющие критериям входных объёмных данных.
Исходный сервер должен вернуть 400 (Bad Request) и может включить соответствующий отчёт о статусе, если верно любое из следующих условий:
Параметр "renderingmethod" задаёт алгоритм отображения, применяемый к объёмным данным.
%s"renderingmethod=" 1#( %s"volume_rendered" / %s"maximum_ip" / %s"minimum_ip" / %s"average_ip" )
Примечание
-
Эти значения соответствуют значениям с различной капитализацией атрибута Rendering Method (0070,120D). См. Раздел C.11.23 в PS3.3 и Раздел C.11.30 в PS3.3.
-
Не существует параметра для управления типом проекции, используемой при рендеринге. Ресурсы Rendered 3D Volume используют ортографическую проекцию. См. Рисунок C.11.30-1 в PS3.3.
-
Для ресурсов Rendered MPR Volume этот параметр описывает алгоритм отображения, применяемый, когда толщина среза превышает один воксель. Значение этого параметра обычно — average_ip.
Если параметр "renderingmethod" отсутствует, исходный сервер может применить метод рендеринга по умолчанию в зависимости от ресурса или, в качестве альтернативы, вернуть 400 (Bad Request) и может включить соответствующий отчёт о статусе.
Если целевой ресурс является состоянием объёмного представления, исходный сервер должен вернуть 400 (Bad Request) и может включить соответствующий отчёт о статусе.
Параметр "orientation" задаёт ориентацию пациента с точки зрения камеры для текущего объёмного 3D- или MPR-представления.
%s"orientation =" 1#( %s"a" / %s"p" / %s"r" / %s"l" / %s"h" / %s"f" )
a |
|
p |
|
r |
|
l |
|
h |
|
f |
Примечание
Эти значения соответствуют значениям с различной капитализацией атрибутов Patient Orientation (0020,0020) и Image Orientation (Patient) (0020,0037). См. Раздел C.7.6.1.1.1 в PS3.3 и Приложение A в PS3.17.
Если целевой ресурс является состоянием объёмного рендеринга и присутствуют любые параметры запроса ориентации, исходный сервер должен применить параметры запроса вместо атрибутов геометрии в Multi-Planar Reconstruction Geometry Module или Volume Render Geometry Module.
Примечание
Это предназначено для того, чтобы позволить пользователю корректировать ориентацию после просмотра начальной ориентации, определённой в состоянии объёмного представления.
Ориентация используется для выбора желаемой стандартной анатомической позиции отрисованного объёма. Например, "a" задаёт направление отрисованного объёма, наиболее точно совпадающее с передней плоскостью пациента. Углы обзора, выходящие за пределы стандартных ортогональных анатомических позиций, управляются параметрами ориентации камеры (т.е. "viewpointposition", "viewpointlookat" или "viewpointup").
Исходный сервер должен определить Viewpoint Position (0070,1603), Viewpoint LookAt Point (0070,1604) и Viewpoint Up Direction (0070,1605) на основе значения параметра "orientation".
Если присутствуют как параметр "orientation", так и любой из параметров ориентации камеры, исходный сервер должен вернуть 400 (Bad Request) и может включить соответствующий отчёт о статусе.
Параметр "viewpointposition" задаёт положение камеры в системе координат точки наблюдения (VCS). См. Раздел C.11.30.1 в PS3.3.
%s"viewpointposition =" px "," py "," pz
Примечание
Это соответствует атрибуту Viewpoint Position (0070,1603). См. Раздел C.11.30 в PS3.3.
Если целевой ресурс является состоянием объёмного представления и присутствуют любые параметры запроса ориентации, исходный сервер должен применить параметры запроса вместо атрибутов геометрии в Multi-Planar Reconstruction Geometry Module или Volume Render Geometry Module.
Любой или все параметры ориентации камеры могут быть включены. Если какой-либо из параметров запроса ориентации камеры отсутствует, исходный сервер может применить значение по умолчанию (например,
или вернуть 400 (Bad Request) и может включить соответствующий отчёт о статусе.
Параметр "viewpointlookat" задаёт точку, на которую смотрит камера, в системе координат точки наблюдения (VCS). См. Раздел C.11.30.1 в PS3.3.
%s"viewpointlookat =" lx "," ly "," lz
lx, ly and lz |
Точка направления взгляда точки наблюдения (т.е. точка, на которую смотрит камера). Точка (x,y,z) в VCS. |
Примечание
Это соответствует атрибуту Viewpoint LookAt Point (0070,1604). См. Раздел C.11.30 в PS3.3.
Если целевой ресурс является состоянием объёмного представления и присутствуют любые параметры запроса ориентации, исходный сервер должен применить параметры запроса вместо атрибутов геометрии в Multi-Planar Reconstruction Geometry Module или Volume Render Geometry Module.
Параметр "viewpointup" задаёт вертикальную ориентацию камеры в системе координат точки наблюдения (VCS). См. Раздел C.11.30.1 в PS3.3.
%s"viewpointup =" ux "," uy "," uz
ux, uy and uz |
Направление вверх точки наблюдения (т.е. направление, в котором указывает верх камеры). Вектор (x,y,z) в VCS. |
Примечание
Это соответствует атрибуту Viewpoint Up Direction (0070,1605). См. Раздел C.11.30 в PS3.3.
Если целевой ресурс является состоянием объёмного представления и присутствуют любые параметры запроса ориентации, исходный сервер должен применить параметры запроса вместо атрибутов геометрии в Multi-Planar Reconstruction Geometry Module или Volume Render Geometry Module.
Параметр "mprslab" задаёт толщину плоскости MPR. Этот параметр приводит к ортографическому рендерингу с заданной толщиной с использованием метода, определённого параметром "renderingmethod". См. Раздел C.11.26.1.1 в PS3.3 для получения дополнительной информации.
Синтаксис этого параметра для Rendered MPR Volume:
%s"mprslab =" st
Примечание
-
Это соответствует атрибуту MPR Slab Thickness (0070,1503). См. Раздел C.11.26 в PS3.3.
-
Толщина среза возвращаемых данных может не совпадать с запрошенной толщиной из-за размера вокселей целевого ресурса.
Если параметр "renderingmethod" отсутствует, исходный сервер может применить метод рендеринга по умолчанию в зависимости от ресурса и/или толщины среза или, в качестве альтернативы, вернуть 400 (Bad Request) и может включить соответствующий отчёт о статусе.
Если целевой ресурс является состоянием объёмного представления, исходный сервер должен вернуть 400 (Bad Request) и может включить соответствующий отчёт о статусе.
Параметр "swivelrange" задаёт угловой диапазон, в пределах которого отрисованный объём вращается вокруг оси поворота, которая определяется как ось, параллельная "viewpointup" и проходящая через "viewpointlookat". Отрисованный объём вращается вперёд-назад.
%s"swivelrange =" sr
Примечание
Это соответствует значению SWIVEL с различной капитализацией атрибута Presentation Animation Style (0070,1A01) и атрибуту Swivel Range (0070,1A06). См. Раздел C.11.29 в PS3.3 и Раздел FF.2.4.2 в PS3.4.
Исходный сервер должен создать анимацию с количеством кадров, равным значению Swivel Range, делённому на "animationstepsize".
Если параметр "swivelrange" присутствует, а параметр "animationrate" отсутствует, исходный сервер должен определить частоту анимации.
Если целевой ресурс является состоянием объёмного представления, исходный сервер должен вернуть 400 (Bad Request) и может включить соответствующий отчёт о статусе.
Параметр "volumetriccurvepoint" задаёт координаты точек на кривой анимации в опорной системе координат состояния объёмного представления, в мм. Для каждой точки кривой должна присутствовать одна тройка (x,y,z). Для анимации требуется как минимум две точки. См. Раздел C.11.29.1 в PS3.3.
%s"volumetriccurvepoint =" px "," py "," pz
Примечание
Это соответствует атрибуту Volumetric Curve Points (0070,150D). См. Раздел C.11.29 в PS3.3.
Исходный сервер должен создать анимацию с количеством кадров, равным общей длине объёмной кривой, делённой на "animationstepsize".
Если параметры "volumetriccurvepoint" присутствуют, а параметр "animationrate" отсутствует, исходный сервер должен определить частоту анимации.
Если целевой ресурс является состоянием объёмного представления, исходный сервер должен вернуть 400 (Bad Request) и может включить соответствующий отчёт о статусе.
Параметр "animationstepsize" задаёт расстояние между шагами анимации или кадрами в анимации объёмного рендеринга.
Для анимации поворота расстояние между шагами измеряется в градусах. Для объёмной кривой расстояние между шагами измеряется в мм вдоль кривой анимации.
%s"animationstepsize=" ss
Примечание
Это соответствует атрибуту Animation Step Size (0070,1A05). См. Раздел C.11.29 в PS3.3.
Исходный сервер должен создать анимацию с количеством кадров, равным одному из следующих значений:
Если параметр "animationstepsize" отсутствует и присутствует "swivelrange" или "volumetriccurvepoint", исходный сервер может применить размер шага анимации по умолчанию или, в качестве альтернативы, вернуть 400 (Bad Request) и может включить соответствующий отчёт о статусе.
Если целевой ресурс является состоянием объёмного представления, исходный сервер должен вернуть 400 (Bad Request) и может включить соответствующий отчёт о статусе.
Параметр "animationrate" задаёт частоту, с которой отображается анимированное 3D- или MPR-объёмное представление.
%s"animationrate=" rt
Примечание
-
Это соответствует Recommended Animation Rate (0070,1A03) в Разделе C.11.29 в PS3.3 и Разделе FF.2.4.2 в PS3.4.
-
Воспроизведение возвращаемых данных на клиенте может как достигать, так и не достигать запрошенной частоты анимации.
Если параметр "animationrate" отсутствует и присутствуют другие параметры анимации (например, "swivelrange", "animationstepsize" или "volumetriccurvepoint"), исходный сервер может применить частоту анимации по умолчанию или, в качестве альтернативы, вернуть 400 (Bad Request) и может включить соответствующий отчёт о статусе.
Если целевой ресурс является состоянием объёмного представления, исходный сервер должен вернуть 400 (Bad Request) и может включить соответствующий отчёт о статусе.
Параметр "renderedvolumetricmetadata" указывает, что полезная нагрузка ответа содержит только модуль ответа отрисованного объёма (Rendered Volume Response Module) с параметрами, применёнными исходным сервером для генерации объёмного рендеринга.
%s"renderedvolumetricmetadata =" "yes"
yes |
Указывает, что в полезной нагрузке ответа должен присутствовать только Rendered Volume Response Module. |
Исходный сервер должен вернуть полезную нагрузку ответа, содержащую Rendered Volume Response Module, как указано в Приложении K.
Примечание
Если этот параметр отсутствует, модуль ответа не запрашивается, и 2D-представление отрисованного объёма возвращается, как описано в Разделе 10.4.1.1.7 и Разделе 10.4.1.1.8.
Rendered Volume Response Module содержит полный набор параметров запроса, включая как те, что были указаны пользовательским агентом в запросе, так и те, что были определены исходным сервером.
Для любых двух запросов, у которых параметры запроса, целевой ресурс и поля заголовка идентичны, значения параметров запроса в модуле Rendered Volume Response Module, возвращаемом исходным сервером, должны быть идентичными.
Примечание
При повторении запроса на рендеринг ожидается, что исходный сервер предоставит согласованный результат. Необязательно, чтобы он был абсолютно идентичным.
Если целевой ресурс является состоянием объёмного представления, исходный сервер должен вернуть 400 (Bad Request) и может включить соответствующий отчёт о статусе.
В следующих разделах описаны важные поля заголовка, некоторые из которых имеют более строгие требования, чем те, что указаны в стандарте HTTP.
HTTP использует поля заголовка Accept и Content-Type для согласования содержимого и типизации данных. Типы медиа в поле заголовка Accept запроса определяют типы медиа, которые пользовательский агент считает приемлемыми в ответе. Тип медиа в поле заголовка Content-Type сообщения или части полезной нагрузки описывает формат представления, содержащегося в полезной нагрузке сообщения или её части.
Поля заголовка согласования содержимого в запросах позволяют пользовательскому агенту указать приемлемые представления для ответа. Таблица 8.4.1-1 содержит список полей заголовка согласования содержимого. Значения в этих полях применяются к любому содержимому ответа, включая представления целевого ресурса, представления ошибок или статуса обработки, а также, возможно, к различным текстовым строкам, которые могут появляться в рамках протокола HTTP. См. [RFC7231] Раздел 5.3.
Таблица 8.4.1-1. Поля заголовка согласования содержимого
|
Все запросы, ожидающие получить ответ с полезной нагрузкой, должны содержать поле заголовка Accept. См. Раздел 8.4.1.1. |
|||
|
Поле заголовка Accept-Charset может быть отправлено пользовательским агентом для указания того, какие кодировки символов приемлемы в содержимом ответа. См. [RFC7231] Раздел 5.3.3. |
|||
|
Поле заголовка Accept-Encoding может использоваться для указания кодировок содержимого (см. [RFC7231] Раздел 3.1.2.1) acceptable in the response. See [RFC7231] Раздел 5.3.4. |
|||
|
Поле заголовка Accept-Language может использоваться пользовательскими агентами для указания набора естественных языков, предпочитаемых в ответе. См. [RFC7231] Раздел 5.3.5. |
Пользовательские агенты используют поле заголовка Accept для указания приемлемых типов медиа для полезной нагрузки ответа. Поле заголовка Accept может использоваться для указания того, что полезная нагрузка ответа специально ограничена набором желаемых типов медиа. Оно имеет следующий синтаксис:
Accept = "Accept:" #( media-range [accept-params] )
media-range = ("*/*"
/ (type "/" "*")
/ (type "/" subtype)
) *(OWS ";" OWS accept-params)
accept-params = weight *(accept-ext)
Большинство запросов имеют поле заголовка Accept, содержащее разделённый запятыми список одного или нескольких диапазонов медиа. Диапазон медиа расширяет тип медиа подстановочными знаками (*/* или type/*) и параметрами, которые не определены для типов медиа. См. [RFC7231] Раздел 5.3.2 for details.
Например, если пользовательский агент готов принять любой тип медиа в ответе, он должен включить */* в качестве значения поля заголовка Accept.
Многие поля заголовка согласования содержимого используют параметр веса, называемый "q" (без учёта регистра), для назначения относительного "веса" предпочтению для соответствующего типа содержимого.
Типам медиа в заголовке Accept можно задать приоритет с помощью весов.
weight = OWS ";" OWS "q=" qvalue
qvalue = ("0" ["." 0*3DIGIT])
/ ("1" ["." 0*3("0")])
Этот вес часто называют "значением качества" или "qvalue". См. [RFC7231] Раздел 5.3.1.
Все запросы, которые могут получить ответ, содержащий полезную нагрузку, должны предоставлять поле заголовка Accept.
См. Раздел 8.7.5 для получения информации о приемлемых типах медиа.
Многие типы медиа, особенно типы text/*, определяют параметр "charset", задающий кодировку символов для представления. См. [RFC7231] Раздел 3.1.1.2.
Типы медиа DICOM определяют параметр "charset". См. Раздел 8.7.3.5.3.
application/dicom; charset=ISO-8859-1
См. Раздел 8.8.1 для получения информации о приемлемых кодировках символов.
Тип медиа в поле заголовка Content-Type сообщения или части полезной нагрузки описывает формат представления, содержащегося в полезной нагрузке или её части.
Когда сообщение имеет полезную нагрузку, поля заголовка представления содержимого предоставляют метаданные, описывающие, как интерпретировать представление(я), содержащиеся в полезной нагрузке. Таблица 8.4.2-1 описывает поля заголовка представления содержимого и требования к использованию (обязательный, условный или необязательный) для случаев, когда они должны присутствовать.
Таблица 8.4.2-1. Поля заголовка представления содержимого
|
Задаёт тип медиа представления, содержащегося в полезной нагрузке. Если сообщение имеет полезную нагрузку, оно должно иметь поле заголовка Content-Type, задающее тип медиа полезной нагрузки. См. [RFC7231] Раздел 3.1.1.5. |
|||
|
Задаёт кодирования содержимого, применённые к представлению (помимо тех, что заложены в типе медиа), и, следовательно, какое декодирование необходимо применить для получения представления в типе медиа, указанном в Content-Type. См. [RFC7230] Раздел 3.1.2.2. Content-Encoding позволяет выполнять сжатие, шифрование и/или аутентификацию представлений. Должно присутствовать, если к представлению в полезной нагрузке было применено кодирование содержимого. |
|||
|
Задаёт естественный язык(и) целевой аудитории, используемый(ые) в представлении. См. [RFC7231] Раздел 3.1.3.2. |
|||
|
Содержит URL, ссылающийся на конкретный ресурс, соответствующий представлению в полезной нагрузке. Должно присутствовать, если полезная нагрузка содержит представление ресурса. |
Поля заголовка полезной нагрузки содержат метаданные, описывающие полезную нагрузку, а не представление, которое она содержит. Таблица 8.4.3-1 описывает поля заголовка полезной нагрузки и требования к использованию (обязательный, условный или необязательный) для случаев, когда они должны присутствовать.
Таблица 8.4.3-1. Поля заголовка полезной нагрузки
|
Задаёт десятичное число октетов в полезной нагрузке. Если ответное сообщение имеет полезную нагрузку и не имеет поля заголовка Transfer-Encoding, оно должно иметь поле заголовка Content-Length, задающее длину полезной нагрузки в октетах (байтах). Не должно присутствовать, если сообщение имеет поле заголовка Transfer-Encoding. В противном случае должно присутствовать, даже если размер полезной нагрузки равен нулю. |
|||
|
Задаёт диапазон частичного представления, содержащегося в полезной нагрузке. См. [RFC7233] Раздел 4.2. Поле заголовка Content-Range отправляется в однопартийном ответе 206 (Partial Content) для указания частичного диапазона выбранного представления, enclosed как полезная нагрузка сообщения. Оно отправляется в каждой части многопартийного ответа 206 для указания диапазона, заключённого в каждой части тела. Оно отправляется в ответах 416 (Range Not Satisfiable) для предоставления информации о выбранном представлении. |
|||
|
See [RFC7230] Раздел 3.3.1. Должно присутствовать, если к полезной нагрузке применены кодирования передачи (transfer-encodings). |
Каждое ответное сообщение содержит код состояния.
Наиболее часто используемые коды состояния HTTP перечислены в Таблице 8.5-1. Большинство этих кодов подробно описаны в [RFC7231]. IANA поддерживает реестр кодов состояния HTTP [IANA HTTP Status Code Registry], содержащий полный список зарегистрированных кодов состояния.
Таблица 8.5-1. Значения кодов состояния
|
Класс кодов состояния 2xx (Успешные) указывает на то, что запрос клиента был успешно получен, понят и принят. |
||
|
Все представления целевого ресурса содержатся в полезной нагрузке. См. [RFC7231] Раздел 6.3.1. |
||
|
Запрос выполнен, и в результате был создан один или несколько новых ресурсов. См. [RFC7231] Раздел 6.3.2. |
||
|
Запрос принят для обработки, но обработка не завершена. Полезная нагрузка этого ответа должна содержать отчёт о статусе. [RFC7231] Раздел 6.3.3. Пользовательский агент может проверить соответствующие ресурсы для определения статуса в более позднее время. |
||
|
Запрос был успешным, но вложенная полезная нагрузка была изменена из ответа 200 (OK) исходного сервера преобразующим прокси-сервером. См. [RFC7230] Раздел 5.7.2 and [RFC7230] [RFC7231] Раздел 6.3.4. |
||
|
Сервер успешно выполнил запрос, и нет дополнительного содержимого для отправки в теле полезной нагрузки ответа. Это должен быть ответ, когда содержимое успешно загружено и ответ не имеет полезной нагрузки. Например, этот код состояния используется в ответе на запрос условного извлечения (Conditional Retrieve), когда целевой ресурс не был изменён. См. [RFC7231] Раздел 6.3.5. |
||
|
Сервер выполнил запрос и желает, чтобы пользовательский агент сбросил "представление документа", которое вызвало отправку запроса, к его исходному состоянию, полученному от исходного сервера. |
||
|
Класс кодов состояния 3xx (Перенаправление) указывает на то, что пользовательскому агенту необходимо предпринять дальнейшие действия для выполнения запроса. |
||
|
Исходный сервер назначил целевому ресурсу новый постоянный URI, указанный в поле заголовка Location. Этот статус обычно требуется, когда ресурс был перемещён с одного сервиса на другой, например, во время миграции. |
||
|
Исходный сервер перенаправляет пользовательский агент на другой ресурс, указанный URI в поле заголовка Location, который предоставит ответ на исходный запрос. |
||
|
Исходный сервер получил условный запрос GET или HEAD, который привёл бы к ответу 200 (OK), если бы не тот факт, что условие оказалось ложным. |
||
|
Класс кодов состояния 4xx (Ошибка клиента) указывает на то, что пользовательский агент допустил ошибку. Для всех этих кодов ошибок исходный сервер должен вернуть полезную нагрузку, содержащую пояснение ошибки и информацию о том, является ли это временным или постоянным условием, за исключением ответа на запрос HEAD. |
||
|
Сервер не может или не будет обрабатывать запрос из-за того, что воспринимается как ошибка клиента (например, неправильный синтаксис запроса, недопустимый запрос). |
||
|
Запрос не был выполнен, так как не содержит действительных учётных данных аутентификации для сервиса или целевого ресурса. Сервер, формирующий ответ 401, должен отправить поле заголовка WWW-Authenticate ([RFC7235] Раздел 4.1) containing at least one challenge applicable to the server or Target Resource. |
||
|
Исходный сервер понял запрос, но отказался его авторизовать (например, авторизованный пользователь с недостаточными привилегиями). Если учётные данные аутентификации были предоставлены в запросе, сервер считает их недостаточными для предоставления доступа. Исходный сервер может ответить 404 (Not Found), если ему не разрешено использовать этот код состояния. |
||
|
Исходный сервер не нашёл представления для целевого ресурса или не желает раскрывать, что оно существует. Это может быть временным условием. Если исходный сервер знает, что ресурс был удалён, должен быть возвращён код состояния 410 (Gone) вместо 404. |
||
|
Метод в запросе известен исходному серверу, но не поддерживается целевым сервисом или ресурсом. Исходный сервер должен включить поле заголовка Allow в ответ 405, содержащее список методов, поддерживаемых в настоящее время целевым сервисом или ресурсом. |
||
|
Целевой ресурс не имеет представления, которое было бы приемлемо для пользовательского агента согласно полям заголовка согласования содержимого в запросе, и сервер не желает предоставлять представление по умолчанию. Исходный сервер должен возвращать полезные данные, перечисляющие доступные типы носителей и соответствующие идентификаторы ресурсов. |
||
|
Запрос не может быть выполнен из-за конфликта с текущим состоянием целевого ресурса. Этот код используется в ситуациях, когда пользовательский агент может разрешить конфликт и повторно отправить запрос. Исходный сервер должен возвращать полезные данные, содержащие достаточно информации, чтобы пользовательский агент мог распознать источник конфликта. В контексте DICOM этот код может означать, что исходный сервер не смог сохранить ни одного экземпляра из-за конфликта в запросе (например, неподдерживаемый SOP Class или несоответствие экземпляров). |
||
|
Доступ к целевому ресурсу больше недоступен на исходном сервере, и это состояние, вероятно, является постоянным. Если исходный сервер не знает или не имеет возможности определить, является ли состояние постоянным, вместо него следует использовать код состояния 404 (Not Found). |
||
|
Исходный сервер отказывается принять запрос, так как поле заголовка Content-Length не было указано. |
||
|
Сервер отказывается обрабатывать запрос, поскольку полезные данные запроса больше, чем сервер готов или способен обработать. |
||
|
Сервер отказывается обслуживать запрос, поскольку цель запроса (request-target) ([RFC7230] Раздел 5.3) длиннее, чем сервер готов интерпретировать. |
||
|
Исходный сервер не поддерживает Content-Type в полезных данных запроса. Эта ошибка обычно возникает, когда пользовательский агент пытается создать или обновить ресурс. Исходный сервер должен возвращать полезные данные, перечисляющие доступные типы носителей и соответствующие идентификаторы ресурсов. |
||
|
Класс кодов состояния 5xx (Server Error) указывает на то, что сервер знает об ошибке или не способен выполнить запрошенный метод. Для всех этих кодов ошибок сервер должен отправлять пояснение ситуации ошибки и того, является ли она временной или постоянной, за исключением ответов на запрос HEAD. |
||
|
Сервер столкнулся с непредвиденным состоянием, которое помешало ему выполнить запрос. |
||
|
Сервер не поддерживает функциональность, необходимую для выполнения запроса. В контексте DICOM этот код состояния должен использоваться для ошибок «SOP Class Not Supported». |
||
|
Исходный сервер в настоящее время не может обработать запрос из-за временной перегрузки или планового обслуживания, которые, вероятно, будут устранены после некоторой задержки. |
||
|
Исходный сервер не поддерживает или отказывается поддерживать основную версию HTTP, которая использовалась в сообщении запроса. |
||
Примечание
Код состояния 206 ранее (ошибочно) использовался для указания того, что была сохранена лишь часть полезных данных, и ранее (ошибочно) использовался для запросов диапазона на уровне приложения.
Когда веб-сервер определяет, что пользовательский агент не должен получать определённую информацию, веб-сервер должен тщательно выбирать код состояния и содержимое отчёта о состоянии. Например, локальная политика может предписывать веб-службе возвращать код состояния 404 (Not Found), а не 401 (Unauthorized), чтобы не позволить пользовательскому агенту сделать вывод о существовании ресурса. Код состояния и полезные данные ответа должны контролироваться политикой и контекстом, что обеспечивает баланс между удобством использования возвращаемого результата и надлежащей защитой. См. также [FHIR Access Denied] и [OWASP Information Leakage].
Как сообщения запроса, так и сообщения ответа могут иметь тела сообщений. Тело сообщения (при его наличии) HTTP-сообщения используется для передачи полезных данных сообщения. Тело сообщения идентично полезным данным, если к ним не применено кодирование содержимого, как описано в [RFC7230] Разделе 3.3.1. В этой Части Стандарта термин «полезные данные» (payload) используется для обозначения тела сообщения до применения к нему какого-либо кодирования содержимого.
Сообщение может иметь или не иметь полезных данных. Полезные данные могут быть пустыми; то есть их длина равна нулю. Если сообщение не имеет полезных данных, то оно не должно содержать ни поля заголовка Transfer-Encoding, ни Content-Length. Если сообщение имеет полезные данные, к которым применено кодирование передачи (transfer-coding), то оно должно содержать поле заголовка Transfer-Encoding. Если сообщение имеет полезные данные, к которым не применено кодирование передачи, то оно должно содержать поле заголовка Content-Length.
Любое сообщение, содержащее полезные данные, должно иметь соответствующее представление содержимого (Content Representation) [RFC7231] Раздел 3.1 и поля заголовка полезных данных (Payload Header Fields) [RFC7231] Раздел 3.3.
Полезные данные содержат представления. Полезные данные могут быть односоставными (single part) или многосоставными (multipart).
Поле заголовка Content-Type сообщения содержит тип носителя, включающий multipart/related, если полезные данные являются многосоставными, в противном случае полезные данные являются односоставными.
Сообщение с односоставными полезными данными содержит одно представление, которое описывается полями заголовка представления содержимого (см. Раздел 8.4.3), содержащимися в заголовке сообщения.
Сообщение с односоставными полезными данными должно содержать поле заголовка Content-Type с односоставным типом носителя (см. Раздел 8.7.3).
Односоставные полезные данные могут быть запрошены с помощью HTTP-запроса Range [RFC7233]. Если это поддерживается сервером, ответ должен соответствовать стандартному ответу HTTP Range [RFC7233].
Примечание
Односоставные полезные данные применимы только для запросов, возвращающих ровно один элемент. Такие ответы могут быть также закодированы как многосоставные полезные данные с одним элементом, как определено в Таблице 10.4.4-1.
Сообщение с многосоставными полезными данными содержит ноль или более представлений. Каждое представление помещается в отдельную часть.
Сообщение с многосоставными полезными данными должно содержать поле заголовка Content-Type с многосоставным типом носителя.
Тип носителя корневого представления (см. [RFC2387]) может быть задан полем заголовка Content-Type сообщения. Если параметр root не указан, корневым представлением является первое представление в полезных данных.
Каждая часть в многосоставных полезных данных должна начинаться с разделительной строки (boundary), за которой следует поле заголовка Content-Type с односоставным типом носителя (см. Раздел 8.7.3), а затем другие поля, как указано в Таблице 8.6.1-1. См. также Рисунок 8.6-1. Могут быть включены и другие поля заголовка.
Примечание
-
Понимание природы закодированного ресурса Bulk Data может зависеть от соответствующей ссылки Metadata на bulkdataURI и не обязательно неявно следует из поля заголовка Content-Type.
-
An HTTP Range [RFC7233] request may be used with Multipart payloads, but the range applies to the entire response, including the multipart markers. In order for the response to be valid across requests, the ordering of items and the choice of multipart separator must remain the same.
Content-Location используется для идентификации конкретного ресурса (например, вплоть до уровня конкретного кадра, экземпляра или URI Bulk Data), представленного в этой части. Это позволяет получателю полезных данных различать части, например, когда каждая часть содержит разный кадр запрошенного многостраничного экземпляра.
Примечание
Table 8.6.1-1. Multipart Header Fields
|
Должен присутствовать, если полезные данные ответа не имеют кодирования передачи (transfer encoding) |
|||
|
Должен присутствовать, если полезные данные ответа содержат представление ресурса. См. [RFC7231] Раздел 3.1.4.2. |
|||
|
See [RFC7231] Раздел 7.1.2. |
См. Раздел 8.7.1 и [RFC7231].
Ниже приведён пример шаблона многосоставного сообщения запроса или ответа, содержащего многосоставные полезные данные:
request-line / response-line
Content-Type: multipart-media-type CRLF
Content-Location: "/" {/url} CRLF
*(header-field CRLF)
CRLF
multipart-payload
Поле заголовка Content-Type должно иметь многосоставный тип носителя (multipart media-type). Например:
Content-Type: multipart/related; type=DQUOTE root-media-type DQUOTE; boundary="---boundary---"
multipart-media-type |
— это тип носителя, определённый в [RFC2387]. |
root-media-type |
— это односоставный тип носителя, задающий тип носителя корня (root), обычно первой части, в полезных данных. Если значение параметра type и content-type корневой части тела различаются, поведение пользовательского агента не определено. |
boundary |
задаёт строку, выступающую в качестве границы между частями сообщения. |
Если многосоставные полезные данные содержат представления Metadata (см. Раздел 8.7.3.3.1) и Bulk Data (см. Раздел 8.7.3.3.2), то все части сообщения Metadata, ссылающиеся на часть Bulk Data, должны предшествовать указанной части Bulk Data. Content-Location части Bulk Data должен содержать соответствующий BulkDataURI, используемый в ссылающихся Metadata.
Рисунок 8.6-1 показывает соответствие между представлением IOD и многосоставными полезными данными.
Синтаксис многосоставных полезных данных:
multipart-payload = 1*(DASH boundary CRLF part CRLF) DASH boundary DASH
DASH = "--"
boundary = 0*69(bchar / SP) bchar
bchar = DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" ; The legal boundary characters
/ "," / "-" / "." / "/" / ":" / "=" / "?"
part = Content-Type: media-type CRLF
Content-Location: url CRLF
(Content-Length: uint CRLF / Transfer-Encoding: encoding CRLF)
[Content-Description: text CRLF]
*(header-field CRLF)
CRLF
part-payload
part-payload = *OCTET
Например, если разделителем (boundary) является «++++», то полезные данные сообщения, содержащие три части, будут структурированы следующим образом:
--++++CRLF
Content-Type: media-type CRLF
Content-Location: url CRLF
(Content-Length: uint CRLF / Transfer-Encoding: encoding CRLF)
[Content-Description: {description} CRLF]
CRLF
payload CRLF
--++++CRLF
Content-Type: media-type CRLF
. . .
payload CRLF
--++++CRLF
Content-Type: media-type CRLF
. . .
payload CRLF
--++++--
Все объекты DICOM определяются Определениями информационных объектов (Information Object Definitions, IOD). См. PS3.3. Представления ресурсов DICOM — это кодирования информационных объектов DICOM в октетные потоки.
Каждый IOD имеет связанный набор атрибутов, которые определяют семантические понятия. Каждый атрибут имеет:
-
ключевое слово (Keyword), идентифицирующее атрибут с помощью токена
-
тип (Type), указывающий, является ли атрибут обязательным или необязательным
-
представление значения (Value Representation), определяющее тип данных значения(ий) атрибута
-
мультипликативность значения (Value Multiplicity), задающая количество значений, которые может иметь атрибут
Элемент данных (Data Element) — это конкретное представление атрибута. См. PS3.5. Каждый элемент данных имеет:
Каждый экземпляр содержит элементы данных (Data Elements), представляющие атрибуты уровней пациента, исследования, серии и экземпляра IOD. Например, если ресурс серии содержит 12 экземпляров, то транзакция, извлекающая эту серию, будет содержать представление серии и её 12 экземпляров в определённом типе носителя, и каждый экземпляр будет иметь атрибуты уровней пациента, исследования, серии и экземпляра.
В этой Части Стандарта определяются три различных представления ресурсов DICOM, которые могут быть закодированы в типы носителей DICOM: экземпляры (Instances), Metadata и Bulk Data.
Типы носителей DICOM и соответствующие им представления определены в Разделе 8.7.3. Другие типы носителей, используемые в этой Части Стандарта, определены в Разделе 8.7.4.
Веб-службы DICOM поддерживают только представления с явными представлениями значений (Explicit Value Representations). Неявные представления значений (Implicit Value Representations) (см. Раздел 7.1.3 «Data Element Structure with Implicit VR» в PS3.5) не должны использоваться.
Отчёт о состоянии (Status Report) — это описание предупреждений или ошибок, с которыми столкнулся исходный сервер при обработке запроса. Содержимое должно быть ясным и кратким. Если запрос не включает допустимый тип носителя (Acceptable Media Type), отчёт о состоянии должен использовать тип носителя по умолчанию для категории текстовых ресурсов (Text Resource Category) — text/html.
Типы носителей являются основой как для согласования содержимого, так и для типизации данных полезных данных сообщений. Каждая служба PS3.18 и/или транзакция определяет типы носителей и связанные с ними представления, которые являются типами по умолчанию, обязательными и необязательными.
Тип носителя также указывает, содержат ли полезные данные одно представление (односоставные) или несколько представлений (многосоставные). Многосоставные полезные данные определены только для RESTful API. См. Раздел 8.6.1.2 и Раздел 10.4.3.
Типы носителей — это идентификаторы, используемые для определения формата данных представления. HTTP использует типы носителей в полях заголовка Content-Type и Accept для обеспечения открытой и расширяемой типизации данных и согласования типов. Синтаксис типов носителей:
media-type = type "/" subtype *(OWS ";" OWS mt-parameter)
type = token subtype = token mt-parameter = mtp-name "=" mtp-value mtp-name = token mtp-value = (token / quoted-string)
За 'type/subtype' могут следовать параметры в виде пар «имя "=" значение».
Токены type, subtype и mtp-name нечувствительны к регистру, однако чувствительность к регистру значений параметров зависит от семантики имени параметра. Наличие или отсутствие параметра может иметь значение для обработки типа носителя в зависимости от его определения в реестре типов носителей.
mtp-value может передаваться как токен или как строка в кавычках (quoted-string). Значения в кавычках и без кавычек эквивалентны.
Типы носителей определены в [RFC7231] Разделе 3.1.1.1.
IANA ведёт реестр типов носителей [IANA Media Types].
Многие типы носителей задают параметр кодировки символов (character set).
Примечание
Термин «MIME Type» не является синонимом «Media Type». Типы MIME определены в Multipurpose Internet Mail Extensions [RFC2045] и используются почтовыми программами. Типы носителей (Media Types) определены в Media Type Specifications and Registration Procedures [RFC6838].
Некоторые службы, определённые в этой Части Стандарта, поддерживают многосоставные типы носителей [RFC2387]. Синтаксис:
multipart-media-type = "multipart" "/" subtype *(OWS ";" OWS parameter)
Тип носителя application/multipart-related используется RESTful-службами. Его синтаксис:
multipart-related = "multipart/related"
OWS ";" OWS "type" "=" (media-type / DQUOTE media-type DQUOTE)
OWS ";" OWS "boundary" "=" boundary
[related-parameters]
boundary ; See Section 8.6.1.2.1
bchar = bchar-nospace / SP
bchar-nospace = DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" / "," / "-"
/ "." / "/" / ":" / "=" / "?" "/" / ":" / "=" / "?"
related-parameters = [";" "start" "=" cid]
[";" "start-info" "=" cid-list]
cid-list = cid cid-list
cid = token / quoted-string
Параметр «type» является обязательным. Он содержит тип носителя «корневой» (root) части тела. Согласно [RFC2387] он не должен содержать кавычек, однако в целях исторической совместимости и для соответствия примерам [RFC2387] он может содержать кавычки.
Примечание
Наблюдалось, что некоторые исходные серверы дают сбой при наличии кавычек, а другие могут давать сбой при их отсутствии, поэтому пользовательские агенты могут обрабатывать такие сбои, пробуя альтернативный шаблон.
cid — это идентификатор содержимого. Он должен быть уникальным для каждой части многосоставного сообщения.
Обычно параметры «start» и «start-info» не указываются, а «корневым» (root) является первая часть тела.
Таблица 8.7.2-1 определяет категории ресурсов, соответствующие различным SOP Class. В следующих разделах каждая категория ресурсов сопоставляется с соответствующими типами носителей DICOM и визуализированными типами носителей.
Table 8.7.2-1. Resource Categories
|
Эта категория включает все ресурсы, которые:
|
|
|
Эта категория включает все ресурсы, которые являются экземплярами SOP Class хранения многостраничных изображений (Multi-frame image storage SOP Class), не относятся к видео и содержат более одного кадра. |
|
|
Эта категория включает все ресурсы, которые содержат более одного кадра и: |
|
|
Эта категория включает все ресурсы, которые содержат:
|
|
|
Эта категория включает все ресурсы, не вошедшие в вышеперечисленные категории, например сигналы (waveforms). |
Примечание
Категория ресурса не зависит от синтаксиса передачи (Transfer Syntax), используемого для собственного кодирования или возврата ресурса. В частности, если синтаксис передачи является одним из синтаксисов передачи JPIP (для которых данные пикселей не включаются в возвращаемые объекты, а вместо этого URL-адрес провайдера JPIP для получения данных пикселей присутствует в Metadata), категория ресурса всё равно будет «Однокадровое изображение» (Single Frame Image) или «Многокадровое изображение» (Multi-Frame Image), а не «Текст» (Text) или «Другое» (Other).
В этом разделе определяются типы носителей, используемые для представления экземпляров DICOM, Metadata и Bulk Data. Он описывает:
-
Параметры типа носителя и синтаксиса передачи для экземпляров DICOM PS3.10
-
Параметры типов носителей и синтаксисов передачи для Bulk Data
-
Синтаксис типов носителей DICOM, включая их параметры синтаксиса передачи (Transfer Syntax) и кодировки символов
-
Значение допустимых синтаксисов передачи (Acceptable Transfer Syntaxes) и выбранного синтаксиса передачи (Selected Transfer Syntax)
Типы носителей, определённые в этом разделе, отличаются от тех, в которые могут быть визуализированы экземпляры DICOM (они определены в Разделе 8.7.4); некоторые из тех же типов носителей используются как для визуализированного содержимого, так и для Bulk Data.
В зависимости от службы типы носителей могут быть односоставными или многосоставными и могут иметь обязательные или необязательные параметры синтаксиса передачи и/или кодировки символов.
Синтаксисы передачи Implicit VR Little Endian (1.2.840.10008.1.2) и Explicit VR Big Endian (1.2.840.10008.1.2.2 — Retired) не должны использоваться с веб-службами.
Если параметр синтаксиса передачи для типа носителя DICOM не указан в запросе или ответе, синтаксис передачи в ответе должен быть тем, который указан как значение по умолчанию для комбинации категории ресурса и типа носителя в Таблице 8.7.3-2, Таблице 8.7.3-4 или Таблице 8.7.3-5, если только исходный сервер не имеет доступа к данным пикселей только в форме сжатия с потерями либо в форме сжатия без потерь или инкапсулированного несжатого вида такой длины, что они не могут быть закодированы в синтаксисе передачи Explicit VR Little Endian.
Table 8.7.3-1 specifies the definition of Media Type requirement terms used in the tables in this section.
Table 8.7.3-1. Definition of Media Type Requirement
|
Исходный сервер должен возвращать этот тип носителя, если ни один из допустимых типов носителей (см. Раздел 8.7.5) не поддерживается. Исходный сервер должен поддерживать этот тип носителя. |
||
Таблица 8.7.3-2, Таблица 8.7.3-3, Таблица 8.7.3-4 и Таблица 8.7.3-5 определяют типы носителей, используемые для кодирования различных представлений экземпляров DICOM. Эти типы носителей применяются ко всем категориям ресурсов и имеют кодирования по умолчанию для элементов данных изображений и видео, содержащихся в экземплярах.
Тип носителя application/dicom задаёт представление экземпляров, закодированных в формате файлов DICOM, указанном в Разделе 7 «DICOM File Format» в PS3.10.
Примечание
Исходный сервер может заполнить файловую метаинформацию (File Meta Information) PS3.10 идентификацией исходного, отправляющего и принимающего AE-заголовков и адресами представления (Presentation Addresses), как описано в Разделе 7.1 в PS3.10 , или эти атрибуты могут остаться неизменными с момента получения объектов исходным сервером. Пользовательский агент, сохраняющий объекты, полученные в ответе, может заполнить или принудительно изменить эти атрибуты на основе собственных сведений об оконечных точках, участвующих в транзакции, чтобы они точно идентифицировали последнюю транзакцию хранения.
Таблица 8.7.3-2 определяет комбинации UID синтаксиса передачи по умолчанию и необязательные для каждой категории ресурсов DICOM (см. Таблицу 8.7.2-1). Тип носителя по умолчанию для категории ресурса должен возвращаться, когда исходный сервер не поддерживает ни один из допустимых типов носителей, если только исходный сервер не имеет доступа к данным пикселей только в форме сжатия с потерями либо в форме сжатия без потерь или инкапсулированного несжатого вида такой длины, что они не могут быть закодированы в синтаксисе передачи Explicit VR Little Endian.
Table 8.7.3-2. Transfer Syntax UIDs for application/dicom Media Types
Таблица 8.7.3-3 определяет типы носителей (Media Types), которые могут использоваться для кодирования представлений метаданных для служб URI и RESTful. Только службы RESTful поддерживают представления метаданных.
Таблица 8.7.3-3. Типы носителей для метаданных
|
Кодирует экземпляры как XML Infosets, определённые в Native DICOM Model, описанной в PS3.19. |
|||
|
Кодирует экземпляры в формате JSON, определённом в Приложении F. |
Представления bulk data поддерживаются только службами RESTful. Существует две категории bulk data: несжатые и сжатые.
Выбранный тип носителя (Selected Media Type) будет типом носителя по умолчанию для категории ресурса, когда исходный сервер не поддерживает ни один из допустимых типов носителей, как описано в Разделе 8.7.8, за исключением случая, когда исходный сервер имеет доступ к пиксельным данным только в форме сжатия с потерями или к пиксельным данным в форме сжатия без потерь или инкапсулированного несжатого формата, имеющего такую длину, что они не могут быть закодированы в синтаксисе передачи Explicit VR Little Endian.
Исходный сервер может поддерживать дополнительные синтаксисы передачи.
Если параметр синтаксиса передачи типа носителя не указан, должен использоваться синтаксис передачи Explicit VR Little Endian "1.2.840.10008.1.2.1", за исключением случая, когда исходный сервер имеет доступ к пиксельным данным только в форме сжатия с потерями или к пиксельным данным в форме сжатия без потерь или инкапсулированного несжатого формата, имеющего такую длину, что они не могут быть закодированы в синтаксисе передачи Explicit VR Little Endian.
Примечание
В таблицах этого раздела нет записей для службы URI, поскольку они не поддерживают отдельное получение bulk data.
В зависимости от выбранного типа носителя, пиксельные данные ресурса в категории Single Frame Image кодируются в:
В зависимости от выбранного типа носителя, пиксельные данные ресурса в категории Multi-Frame Image кодируются в:
В зависимости от выбранного типа носителя, пиксельные данные ресурса в категории Video кодируются в:
Таблица 8.7.3-4 определяет тип носителя по умолчанию и UID синтаксисов передачи по категориям ресурсов (см. Таблицу 8.7.2-1), которые могут использоваться с несжатыми bulk data для служб RESTful. Несжатые bulk data кодируются как поток несжатых байтов (октетов) в порядке байтов Little Endian.
Примечание
-
Это то же кодирование, что определено в PS3.19 для возвращаемого значения вызова getData() для несжатых bulk data.
-
В много кадровом изображении (Multi-Frame Image) со значением Bits Allocated (0028,0100), равным 1, которое не сжато, отдельные кадры не выравниваются (не дополняются), поэтому последовательные биты упаковываются в байты или слова в формате Native, как описано в Разделе 8.2 «Кодирование в формате Native или Encapsulated» в PS3.5. Это означает, что если в ответе должны быть закодированы только выбранные кадры много кадрового изображения, каждый кадр должен быть извлечён из пиксельных данных много кадрового изображения и последовательно объединён в ответе без выравнивания в начале первого байта ответа и без выравнивания между последовательными закодированными кадрами в ответе. Т.е. все потоки битов, специфичные для кадров, кодируются последовательно без выравнивания в начале или между ними.
-
Только несжатые bulk data могут быть возвращены с типом носителя application/octet-stream. Специфические типы носителей, отличные от application/octet-stream, определены для каждого вида сжатых bulk data в Разделе 8.7.3.3.2. Это означает, что если параметр шаблона синтаксиса передачи ("transfer-syntax=*") включён с типом носителя в запросе, он применяется только к несжатым синтаксисам передачи.
Примечание
Несмотря на то, что синтаксисом передачи является Explicit VR Little Endian, представление значения (Value Representation) фактически не кодируется в начале потока октетов. Представление значения содержится в метаданных, которые ссылаются на bulk data. По этой причине синтаксис передачи Implicit VR Little Endian не указан в этой таблице.
Если поддерживается Encapsulated Uncompressed Explicit VR Little Endian, ответ включает поток октетов без разделителей фрагментов. Т.е. поток октетов декапсулируется перед передачей.
Сжатые bulk data содержат только сжатый поток октетов без разделителей фрагментов.
Таблица 8.7.3-5 определяет комбинации типов носителей и UID синтаксисов передачи по умолчанию и дополнительных для каждой категории ресурсов (см. Таблицу 8.7.2-1) сжатых bulk data для служб RESTful.
Примечание
-
Некоторые имена синтаксисов передачи включают текст о синтаксисе передачи по умолчанию (Default Transfer Syntax), однако это относится к их роли в транзакциях DIMSE, а не к значению по умолчанию для служб RESTful (которое указано в столбце RESTful таблицы).
-
Столбец типа носителя отражает кодирование данных, но не включает расширенные дескрипторы типа носителя, такие как "multipart/related", которые описывают дополнительную упаковку закодированных данных.
Эти типы носителей могут использоваться для получения bulk data, таких как изображения или видео, закодированных в определённом синтаксисе передачи.
Примечание
-
Эти типы носителей не используются для несжатых bulk data, для которых использование application/octet-stream указано в Разделе 8.7.3.3.1. Сжатые bulk data никогда не передаются с использованием application/octet-stream.
-
Если параметр шаблона синтаксиса передачи ("transfer-syntax=*") включён с типом носителя в запросе, он применяется только к сжатым синтаксисам передачи, соответствующим указанному типу носителя.
-
Если запрашивается специфичный для изображений шаблонный тип носителя "image/*", то исходный сервер не получает информации для принятия решения о том, какое сжатое кодирование (если таковое имеется) следует вернуть.
Подробная информация об упаковке сжатых bulk data в полезные нагрузки однопоточные (single part) или составные (multipart) приведена в Разделе 8.6.1.
Таблица 8.7.3-5. Типы носителей и UID синтаксисов передачи для сжатых bulk data
Исходный сервер может поддерживать дополнительные синтаксисы передачи.
Для типов носителя image/jpeg и синтаксисов передачи изображение может как включать, так и не включать сегмент маркера JFIF. Изображение может как включать, так и не включать сегменты маркеров APP2 с идентификатором "ICC_PROFILE". От исходного сервера не требуется добавлять сегмент маркера JFIF или копировать значение атрибута ICC Profile (0028,2000), если оно присутствует, в сегменты маркеров APP2 в потоке сжатых данных. См. Раздел 8.2.1 «Сжатие изображений JPEG» в PS3.5.
Для типов носителя image/jp2 и image/jpx и синтаксисов передачи изображение не включает сегмент маркера jp2. См. Раздел 8.2.4 «Сжатие изображений JPEG 2000» в PS3.5 и Раздел A.4.4 «Сжатие изображений JPEG 2000» в PS3.5
Сжатые пиксельные данные много кадрового изображения кодируются как отдельные кадры. Например, каждый кадр много кадрового изображения JPEG 2000 будет закодирован отдельно как представление image/jp2, а не как единое представление video/mj2 ([RFC3745]) или application/octet-stream. См. Раздел 8.6.1.2 для получения подробной информации о том, как несколько представлений могут быть упакованы в составную полезную нагрузку.
Пиксельные данные видео кодируются как единое представление видео. Например, все кадры видео MPEG-4 будут закодированы как единое представление video/mp4 ([RFC4337]).
Примечание
-
Ресурс на исходном сервере может быть закодирован в синтаксисе передачи Deflated Explicit VR Little Endian (1.2.840.10008.1.2.1.99). В этом случае исходный сервер может распаковать его (inflate), а затем преобразовать в допустимый синтаксис передачи (Acceptable Transfer Syntax). Заголовок Content-Encoding со значением 'deflate' не может использоваться для передачи дефлированных байтов без изменений, поскольку требуемая File Meta Information из PS3.10 не включена в дефлированные байты, а Content-Encoding применяется ко всему multipart-потоку, а не к каждой его части отдельно.
Ресурс на исходном сервере может быть закодирован в синтаксисе передачи Deflated Image Frame Compression (1.2.840.10008.1.2.8.1). В этом случае исходный сервер может вернуть сжатый поток битов, если это допустимый синтаксис передачи, или исходный сервер может распаковать его (inflate), а затем преобразовать в допустимый синтаксис передачи. Кроме того, если пользовательский агент допускает заголовок Content-Encoding со значением 'deflate', то дефлированные байты для ответа с одной частью (single part) могут быть переданы после добавления контейнера zlib в соответствии с [RFC7230] Раздел 4.2.2, но параметр синтаксиса передачи в ответе должен быть Explicit VR Little Endian Transfer Syntax.
-
Многие типы носителей, используемые для сжатых пиксельных данных (Pixel Data), передаваемых как значения bulk data, также используются как типы носителей потребительских форматов. Веб-браузер может не иметь возможности отображать закодированные данные напрямую, даже если некоторые из этих же типов носителей также используются для кодирования отрендеренных пиксельных данных. См. Раздел 8.7.4.
Например, типом носителя для значений bulk data без потерь 16-битных JPEG [ISO/IEC 10918-1] закодированных пиксельных данных является "image/jpeg" — тот же тип носителя, что может использоваться для 8-битных JPEG [ISO/IEC 10918-1] закодированных пиксельных данных, независимо от того, извлечены ли они как bulk data или отрендерены. Параметр синтаксиса передачи в заголовке Content-Type полезен для индикации различия.
-
Ранее были определены экспериментальные типы носителей "image/x-dicom-rle" и "image/x-jls", поэтому исходным серверам и пользовательским агентам следует учитывать это при взаимодействии со старыми реализациями. Они были заменены стандартными типами носителей "image/dicom-rle" и "image/jls" соответственно.
Синтаксис передачи по умолчанию для объектов DICOM, содержащихся в полезной нагрузке, должен быть Explicit VR Little Endian Uncompressed "1.2.840.10008.1.2.1". Если синтаксис передачи не указан в сообщении, должен использоваться синтаксис передачи по умолчанию, за исключением случая, когда исходный сервер имеет доступ к пиксельным данным только в форме сжатия с потерями или к пиксельным данным в форме сжатия без потерь или инкапсулированного несжатого формата, имеющего такую длину, что они не могут быть закодированы в синтаксисе передачи Explicit VR Little Endian.
Примечание
-
Это отличается от синтаксиса передачи по умолчанию, определённого в Разделе 10.1 «Синтаксис передачи DICOM по умолчанию» в PS3.5, которым является Implicit VR Little Endian.
-
Каждый исходный сервер обязан иметь возможность преобразовать любой набор данных (Data Set), который он собирается вернуть, в синтаксис передачи Explicit VR Little Endian, независимо от формы, в которой он изначально получил или сохранил набор данных, за исключением случаев, когда декомпрессированные пиксельные данные слишком велики для кодирования в синтаксисе передачи Explicit VR Little Endian или были получены в форме сжатия с потерями. В случае пиксельных данных со сжатием с потерями исходному серверу разрешается возвращать синтаксис передачи со сжатием с потерями, соответствующий полученной форме с потерями. В случае пиксельных данных со сжатием без потерь или инкапсулированных несжатых пиксельных данных, которые слишком велики для кодирования в синтаксисе передачи Explicit VR Little Endian, исходному серверу разрешается возвращать любой соответствующий синтаксис передачи со сжатием без потерь или инкапсулированный несжатый синтаксис передачи, не обязательно тот, в котором изображение было получено, в качестве альтернативы синтаксису передачи Explicit VR Little Endian.
-
При перекодировании в синтаксис передачи Explicit VR Little Endian для кодирования элементов данных (Data Elements) с явным VR, значение длины которых превышает 65534 (216-2) (FFFEH, наибольшее чётное беззнаковое 16-битное число), но которые определены как имеющие 16-битное поле длины явного VR, может потребоваться VR типа UN. См. Раздел 6.2.2 в PS3.5 .
Implicit VR Little Endian или Explicit VR Big Endian не должны использоваться.
Требования к кодированию полезной нагрузки ответа определены в Разделе 8.7.8.
Примечание
Синтаксисом передачи может быть один из синтаксисов передачи JPIP; в этом случае возвращаемые объекты будут содержать URL поставщика JPIP для получения пиксельных данных.
Исходный сервер может поддерживать дополнительные синтаксисы передачи.
Синтаксис использования типов носителей в DICOM:
dicom-media-type = (dcm-singlepart / dcm-multipart) [dcm-parameters]
dcm-singlepart = dcm-mt-name
dcm-multipart ;see Section 8.7.3.5.1
dcm-parameters = transfer-syntax-mtp ;see Section 8.7.3.5.2
/ charset-mtp;see Section 8.7.3.5.3
dcm-mt-name = dicom / dicom-metadata / bulkdata / pixeldata ;DICOM Media Type name
dicom = "application/dicom"
dicom-metadata = dicom-xml / dicom-json
dicom-xml = "application/dicom+xml"
dicom-json = "application/dicom+json"
bulkdata = octet-stream / pixeldata
octet-stream = "application/octet-stream"
pixeldata = image-pixel / video-pixel
rendered = image-pixel / video-pixel
image-pixel = "image/jpeg" / "image/dicom-rle" / "image/jls" / "image/jp2" / "image/jpx" / "image/jphc" / "image/jxl"
video-pixel = "video/mpeg" / "video/mp4" / "video/H265"
Все типы носителей, используемые в DICOM, могут иметь параметр синтаксиса передачи, но его использование может быть ограничено службой, для которой они используются.
Примечание
Типы носителей application/dicom+xml и application/dicom+json могут иметь параметр синтаксиса передачи для указания кодирования данных base64.
Все типы носителей, используемые в DICOM, могут иметь параметр набора символов, но его использование может быть ограничено службой, для которой они используются.
Синтаксис multipart-типов носителей:
dcm-multipart = "multipart/related"
OWS ";" OWS "type" "=" dcm-mp-mt-name
OWS ";" OWS "boundary=" boundary
[dcm-parameters]
[related-parameters]
dcm-mp-mt-name = dicom-mt-name / rendered
См. Раздел 8.6.1.2.1 для определения boundary и related-parameters.
Каждый multipart-тип носителя должен включать параметр "type", который определяет тип носителя частей, и должен также включать параметр "boundary", который задаёт строку границы, используемую для разделения частей. Например:
Accept: multipart/related; type="application/octet-stream",
multipart/related; type="image/*"; boundary=**,
multipart/related; type="video/*"; boundary=**
Для заданного типа носителя DICOM может быть указано одно значение параметра синтаксиса передачи, но его использование может быть ограничено службой, для которой оно используется.
RESTful исходные серверы должны поддерживать параметр синтаксиса передачи.
Параметры типа носителя синтаксиса передачи запрещены в запросах и ответах службы URI.
transfer-syntax-mtp = OWS ";" OWS %s"transfer-syntax=" ts-value
ts-value = transfer-syntax-uid / "*"
transfer-syntax-uid ; a UID from Table A-1 “UID Values” in PS3.6 with a UID Type of Transfer Syntax
Значением параметра синтаксиса передачи может быть либо UID синтаксиса передачи, либо токен "*".
Например, чтобы указать, что 1.2.840.10008.1.2.4.50 является допустимым синтаксисом передачи, заголовок Accept может быть:
Accept: application/dicom; transfer-syntax=1.2.840.10008.1.2.4.50
Тип носителя DICOM может иметь только один параметр синтаксиса передачи, и он должен иметь только одно значение.
Примечание
Согласно [RFC6838] Спецификациям типов носителей и процедурам регистрации, указание конкретного параметра более одного раза является ошибкой. Если приемлемо несколько синтаксисов передачи, в заголовке Accept может быть указано более одного типа носителя с различными значениями параметра q для выражения предпочтения. Например, чтобы указать, что 1.2.840.10008.1.2.4.50 и 1.2.840.10008.1.2.4.57 являются допустимыми, но 1.2.840.10008.1.2.4.50 предпочтительнее, заголовок Accept может быть:
Accept: multipart/related; type="application/dicom";transfer-syntax=1.2.840.10008.1.2.4.50;boundary=**,
multipart/related; type="application/dicom";transfer-syntax=1.2.840.10008.1.2.4.57;q=0.5;boundary=**
Шаблонное значение "*" указывает, что пользовательский агент принимает любой синтаксис передачи. Это позволяет, например, исходному серверу ответить без необходимости перекодирования существующего представления в новый синтаксис передачи или ответить синтаксисом передачи Explicit VR Little Endian независимо от сохранённого синтаксиса передачи, за исключением случая, когда исходный сервер имеет доступ к пиксельным данным только в форме сжатия с потерями или к пиксельным данным в форме сжатия без потерь, имеющим такую длину, что они не могут быть закодированы в синтаксисе передачи Explicit VR Little Endian.
Примечание
Шаблонное значение применяется только к тем синтаксисам передачи, которые соответствуют указанному типу носителя. Например, только несжатые синтаксисы передачи входят в область применения для application/octet-stream, и только соответствующие сжатые синтаксисы передачи входят в область применения для image/* или более специфичных подтипов типа носителя image.
Если исходный сервер поддерживает параметр синтаксиса передачи, он должен поддерживать шаблонное значение.
Исходные серверы, поддерживающие параметр синтаксиса передачи, должны указать в своём заявлении о соответствии (Conformance Statement) те значения параметра синтаксиса передачи, которые поддерживаются в ответе.
Пользовательские агенты, поддерживающие параметр синтаксиса передачи, должны указать в своём заявлении о соответствии те значения параметра синтаксиса передачи, которые могут быть предоставлены в запросе.
Все типы носителей DICOM могут иметь один параметр набора символов, который должен иметь только одно значение, определяющее допустимый набор символов для ответа.
charset-mtp = OWS ";" OWS %s"charset" "=" charset
Все типы носителей DICOM имеют набор символов по умолчанию — UTF-8. См. Раздел 8.8 для подробной информации о наборах символов.
Параметр запроса Transfer Syntax (Transfer Syntax Query Parameter) задаёт разделённый запятыми список из одного или нескольких UID синтаксисов передачи, как определено в PS3.6.
transfer-syntax-qp = %s"transferSyntax" "=" (1#transfer-syntax-uid / "*")
Этот параметр запроса используется только службой URI.
Службы RESTful указывают синтаксис передачи в параметре запроса "accept" (см. Раздел 8.3.3.1) и не используют параметр запроса Transfer Syntax.
Каждый тип носителя DICOM в Acceptable Media Types имеет допустимый синтаксис передачи (Acceptable Transfer Syntax), который явно указан или имеет значение по умолчанию.
В зависимости от службы, допустимый синтаксис передачи для типа носителя DICOM может быть указан в:
-
Параметре типа носителя Transfer Syntax, содержащемся в параметре запроса Accept (см. Раздел 8.3.3.1)
-
Параметре типа носителя Transfer Syntax, содержащемся в заголовке Accept
-
Параметре запроса Transfer Syntax (см. Раздел 8.7.3.5)
Экземпляры DICOM (DICOM Instances) могут быть преобразованы процессом рендеринга в типы носителей, не являющиеся типами DICOM. Это может быть полезно для их отображения или обработки с помощью программ, не поддерживающих DICOM, таких как браузеры.
Например, экземпляр, содержащий:
-
изображение, может быть преобразован в типы носителей image/jpeg, image/jph, image/jxl, image/png или image/gif.
-
много кадровое изображение (Multi-frame Image) в синтаксисе передачи без потерь может быть преобразовано в типы носителей video/mpeg, video/mp4, video/H265 или image/jxl.
-
структурированный отчёт (Structured Report) может быть преобразован в типы носителей text/html, text/plain или application/pdf.
Примечание
Отрендеренные типы носителей (Rendered Media Types) обычно являются типами носителей потребительских форматов. Некоторые из тех же типов носителей, не являющихся типами DICOM, также используются как типы носителей bulk data, т.е. для кодирования bulk data, извлечённых из инкапсулированных пиксельных данных (Encapsulated Pixel Data) (используемых со сжатыми синтаксисами передачи), без применения процесса рендеринга. См. Раздел 8.7.3.3.
Рендеринг состояний представления (Presentation States) описан в Разделе 8.3.5.1.
Исходные серверы должны поддерживать рендеринг экземпляров различных категорий ресурсов в отрендеренные типы носителей, как указано в Таблице 8.7.4-1.
Когда возвращается тип носителя image/jpeg, изображение должно быть закодировано с использованием процесса кодирования JPEG baseline lossy 8-bit Huffman non-hierarchical non-sequential, определённого в [ISO/IEC 10918-1].
Когда возвращается тип носителя image/jph, изображение должно быть закодировано с наличием JP2 box.
Примечание
Это представление отличается от хранимых HTJ2K синтаксисов передачи, которые не содержат JP2 box.
Исходный сервер может поддерживать дополнительные отрендеренные типы носителей, которые должны быть документированы в заявлении о соответствии (Conformance Statement) и, если служба это поддерживает, в ответе Retrieve Capabilities.
Параметр типа носителя Transfer Syntax не разрешён для отрендеренных типов носителей.
Термин «допустимые типы носителей» (Acceptable Media Types) обозначает типы носителей, которые приемлемы для пользовательского агента в ответе. Допустимые типы носителей — это те, что указаны в:
Ответом на запрос без заголовка Accept должен быть 406 (Not Acceptable). Наличие параметра запроса Accept не устраняет необходимости в заголовке Accept. Подробности см. в Разделе 8.3.3.1.
Допустимые типы носителей должны быть либо типами носителей DICOM, либо отрендеренными типами носителей, но не обоими одновременно. Если допустимые типы носителей содержат как типы DICOM, так и отрендеренные типы, исходный сервер должен вернуть 400 (Bad Request).
Пользовательский агент может указать относительную степень предпочтения типов носителей, будь то в параметре запроса Accept или в заголовке Accept, используя параметр веса (weight). См. [RFC7231] Раздел 5.3.1.
weight = OWS ";" OWS "q=" qvalue
qvalue = ("0" ["." 0*3DIGIT]) / ("1" ["." 0*3("0") ])
Если параметр "q" отсутствует, значение qvalue по умолчанию равно 1.
Параметр запроса Accept может использоваться для указания допустимых типов носителей. См. Раздел 8.7.5.
Заголовок Accept используется для указания типов носителей, приемлемых для пользовательского агента. Он имеет следующий синтаксис:
Accept = 1#(media-range [weight])
Значение заголовка Accept должно быть разделённым запятыми списком из одного или нескольких диапазонов носителей (media ranges), приемлемых в ответе. См. [RFC7231] Раздел 5.3.2.
Диапазон носителей (media range) — это либо тип носителя, либо шаблон (wildcard). Шаблоны используют звёздочку ("*") для группировки типов носителей в диапазоны, при этом <type>/* обозначает все подтипы данного типа, а */* обозначает все типы носителей. Например, диапазон носителей image/* соответствует image/jpeg, который является типом носителя по умолчанию для категории ресурсов Single Frame Image, а text/* соответствует text/html, который является типом носителя по умолчанию для категории ресурсов Text. DICOM указывает, что диапазон носителей */* соответствует типу носителя по умолчанию для категории ресурсов целевого объекта. Если для категории ресурсов не определён тип носителя по умолчанию, приемлем любой тип носителя из этой категории ресурсов.
Если ответ может содержать полезную нагрузку, заголовок Accept должен присутствовать в запросе.
Если исходный сервер получает запрос без заголовка Accept, но ответ может содержать полезную нагрузку, он должен вернуть 406 (Not Acceptable).
Любые значения заголовка Accept, включая параметры типа носителя, которые являются недопустимыми или не поддерживаются, должны игнорироваться исходным сервером.
Выбор типа носителя и синтаксиса передачи исходным сервером взаимосвязаны.
Выбранный тип носителя (Selected Media Type) — это тип носителя, выбранный исходным сервером для представления в полезной нагрузке ответа. Типы носителей в параметре запроса Accept и диапазоны носителей в заголовке Accept должны быть отдельно приоритизированы в соответствии с правилами, определёнными в [RFC7231] Разделе 5.3.1.
Для составных полезных нагрузок (multipart payloads) выбранный тип носителя определяется независимо для каждой части сообщения в ответе.
Выбранный тип носителя каждой части сообщения зависит от категории ресурсов экземпляра и допустимых типов носителей для этой категории ресурсов.
Выбранный тип носителя определяется следующим образом:
-
Выбрать представление с типом носителя наивысшего приоритета, поддерживаемым для этой категории в параметре запроса Accept.
-
Если ни один тип носителя в параметре запроса Accept не поддерживается, выбрать тип носителя наивысшего приоритета, поддерживаемый для этой категории в заголовке Accept, если таковой имеется.
-
В противном случае выбрать тип носителя по умолчанию для категории, если заголовок Accept содержит диапазон носителей-шаблон, соответствующий категории, если таковой имеется.
Примечание
-
Если выбранный тип носителя — Explicit VR Little Endian, а пиксельные данные сжаты и при распаковке имеют такую длину, что не могут быть помещены в Value Field, исходный сервер ответит 406 (Not Acceptable), и пользовательский агент может повторить запрос с другим набором допустимых типов носителей.
-
При перекодировании в синтаксис передачи Explicit VR Little Endian для кодирования элементов данных (Data Elements) с явным VR, значение длины которых превышает 65534 (216-2) (FFFEH, наибольшее чётное беззнаковое 16-битное число), но которые определены как имеющие 16-битное поле длины явного VR, может потребоваться VR типа UN. См. Раздел 6.2.2 «Представление значения Unknown (UN)» в PS3.5.
Для набора типов носителей в параметре запроса Accept (шаг 2 выше) или для набора диапазонов носителей в заголовке Accept (шаг 3 выше) тип носителя наивысшего приоритета определяется следующим образом:
-
Присвоить qvalue, равный 1, любому элементу набора, у которого его нет.
-
Присвоить каждому представлению, поддерживаемому исходным сервером, qvalue наиболее специфичного типа носителя, которому оно соответствует.
-
Выбрать представление с наивысшим qvalue. При равенстве исходный сервер определяет, какое из них возвращается.
Например, рассмотрим исходный сервер, который получает запрос со следующим заголовком Accept:
Accept: text/*; q=0.5, text/html; q=0.4, text/html; level=1, text/html; level=2; q=0.7,
image/png, */*; q=0.4
Предположим, что для ресурса, указанного в запросе, исходный сервер поддерживает представления для следующих типов носителей:
text/html (regular, level 1 and level 2)
text/rtf
text/plain
text/x-latex
Этим типам носителей присвоены следующие значения qvalue на основе указанных выше диапазонов носителей:
Хотя "image/png" было присвоено значение qvalue по умолчанию 1.0, оно не входит в число поддерживаемых типов носителей для этого ресурса и поэтому не указано.
Выбранный тип носителя — 'text/html; level=1', поскольку это поддерживаемый тип носителя в категории Text с наивысшим qvalue.
Выбранный синтаксис передачи (Selected Transfer Syntax) — это синтаксис передачи, выбранный исходным сервером для кодирования отдельной части сообщения в ответе.
Исходный сервер должен сначала определить выбранный тип носителя, как определено в Разделе 8.7.8, а затем определить выбранный синтаксис передачи.
Если выбранный тип носителя был указан в параметре запроса Accept, выбранный синтаксис передачи определяется следующим образом:
-
Выбрать значение параметра Transfer Syntax выбранного типа носителя, если таковое имеется;
-
В противном случае выбрать значение Transfer Syntax в параметре запроса Transfer Syntax, если таковое имеется;
-
В противном случае выбрать синтаксис передачи по умолчанию (см. Таблицу 8.7.3-2, Таблицу 8.7.3-4 или Таблицу 8.7.3-5) для выбранного типа носителя.
Если выбранный тип носителя был указан в заголовке Accept, выбранный синтаксис передачи определяется следующим образом:
Заголовок Content-Type указывает тип носителя полезной нагрузки. Он должен присутствовать только при наличии полезной нагрузки, а любые параметры типа носителя должны указывать кодирование соответствующей части сообщения.
В частности, тип носителя DICOM, используемый в качестве значения заголовка Content-Type, должен иметь ноль или один параметр Transfer Syntax (см. Раздел 8.7.3.5.2), и ноль или один параметр charset (см. Раздел 8.7.3.5.3), который соответствует кодировке символов соответствующей части сообщения.
Content-Type: dicom-media-type +transfer-syntax-mtp +charset-mtp
Если возникает конфликт между синтаксисом передачи, указанным в типе носителя, и синтаксисом передачи, указанным в атрибуте File Meta Information Transfer Syntax UID (0002,0010), последний имеет приоритет.
HTTP использует имена наборов символов для указания или согласования кодировки символов текстового содержимого в представлениях [RFC6365] Раздел 3.3.
Наборы символов могут быть идентифицированы с использованием значения из столбца IANA Preferred MIME Name в [IANA Character Sets].
Наборы символов также могут быть идентифицированы с использованием определённых терминов DICOM (DICOM Defined Terms) для набора символов (см. Приложение D, Раздел C.12.1.1.2 в PS3.3 и Раздел 6.1.2.3 «Кодирование наборов символов» в PS3.5), которые должны быть строками в кавычках, поскольку они содержат символ пробела (' ').
charset = token / defined-term / DQUOTE defined-term DQUOTE
token |
Нечувствительное к регистру имя набора символов из Preferred MIME Name в реестре IANA Character Set Registry. |
defined-term |
Исходный сервер должен поддерживать имя набора символов "UTF-8" для транзакции RESTful Retrieve Rendered, но не обязан поддерживать определённый термин DICOM "ISO_IR 192". Некоторые определённые термины DICOM для наборов символов содержат символы пробела и должны заключаться в двойные кавычки в заголовках HTTP и кодироваться процентами (percent encoded) в URI.
Заявление о соответствии (Conformance Statement) должно документировать все поддерживаемые наборы символов. Ответ Retrieve Capabilities для всех служб RESTful также должен документировать все поддерживаемые наборы символов.
Запрос без параметра запроса Character Set или заголовка Accept-Charset означает, что пользовательский агент принимает любой набор символов в ответе.
Приложение D содержит сопоставление некоторых определённых терминов (Defined Terms) атрибута Specific Character Set (0008,0005) с токенами наборов символов IANA.
Термин «допустимые наборы символов» (Acceptable Character Sets) обозначает наборы символов, которые приемлемы для пользовательского агента в ответе. Допустимые наборы символов — это те, что указаны в:
Когда допустимые наборы символов содержат список из одного или нескольких определённых терминов (Defined Terms), они должны быть упорядочены пользовательским агентом, как указано в Разделе C.12.1.1.2 «Specific Character Set» в PS3.3 и Разделе 6.1.2.3 «Кодирование наборов символов» в PS3.5. Это особенно важно для наборов символов ISO 2022.
Любые значения charset, которые являются недопустимыми или не поддерживаются, должны игнорироваться исходным сервером.
См. Раздел 8.3.3.2 .
Типы носителей DICOM принимают параметры набора символов (charset). См. Раздел 8.7.3.5.3.
Многие другие типы носителей также принимают параметры набора символов (charset). См. [IANA Media Types].
Поле заголовка Accept-Charset имеет следующий синтаксис:
Accept-Charset = 1#(charset [weight]) / ("*" [weight])
Пользовательский агент может предоставить список приемлемых наборов символов (Acceptable Character Sets) в поле заголовка Accept-Charset запроса. Его значение представляет собой разделенный запятыми список одного или нескольких наборов символов и/или подстановочного значения ("*").
Значения поля заголовка Accept-Charset упорядочиваются по приоритету с помощью параметра weight.
Если подстановочный знак ("*") отсутствует, то любые наборы символов, явно не упомянутые в поле заголовка, считаются "неприемлемыми" для клиента.
Если тип мультимедиа (Media Type) определяет параметр "charset", он должен включаться вместе с типом мультимедиа в поле заголовка Accept, а не в поле заголовка Accept-Charset.
Исходный сервер должен определить выбранный набор символов (Selected Character Set) следующим образом:
-
Выбрать первый поддерживаемый набор символов из параметра(ов) "charset" выбранного типа мультимедиа.
-
В противном случае выбрать поддерживаемый набор символов с наивысшим приоритетом из параметра запроса character-set.
-
В противном случае выбрать поддерживаемый набор символов с наивысшим приоритетом из поля заголовка Accept-Charset.
-
В противном случае, если выбранный тип мультимедиа имеет поддерживаемый набор символов по умолчанию, выбрать его.
Визуализированные представления (rendered representations), возвращаемые в ответе, должны содержать все строки в выбранном наборе символов.
Если набор символов, в котором закодирован целевой ресурс (Target Resource), не совпадает с выбранным набором символов:
Примечание
Если пользовательский агент предпочитает выполнить преобразование самостоятельно, а не поручать его исходному серверу:
-
Пользовательский агент может опустить поле заголовка Accept-Charset или отправить подстановочный знак "*"
-
Пользовательский агент может перекодировать набор символов, заменяя все неизвестные символы соответствующим заменителем. Например:
-
Вопросительный знак ("?") или другой аналогичный символ, указывающий на неизвестный символ.
-
Соответствующую кодовую точку Unicode для символа, представленную как "U+xxxx".
-
Четыре символа "\nnn", где "nnn" — это 3-значное восьмеричное представление каждого байта (см. Раздел 6.1.2.3 «Кодирование репертуаров символов» в PS3.5).
-
Эта транзакция извлекает описание возможностей (Capabilities Description) (см. Приложение H), которое представляет собой машиночитаемое описание служб(ы), реализованных исходным сервером. Все RESTful-службы, определенные в этой части стандарта, должны реализовывать эту транзакцию.
Целевым ресурсом (Target Resource) для этой транзакции является исходный сервер. Ответ содержит описание возможностей (Capabilities Description), которое описывает транзакции, ресурсы, представления и т. д., поддерживаемые службой(ами).
Запрос должен иметь следующий синтаксис:
OPTIONS SP / SP version CRLF
Accept: 1#media-type CRLF
*(header-field CRLF)
CRLF
Целевым ресурсом для этой транзакции является базовый URI ("/") для службы. См. Раздел 8.2.
Исходный сервер должен вернуть описание возможностей (Capabilities Description), как определено в Приложении H, в приемлемом типе мультимедиа.
version SP status-code SP reason-phrase CRLF
[Content-Type: media-type CRLF]
[(Content-Length: uint) / (Transfer-Encoding: encoding) CRLF]
*(header-field CRLF)
CRLF
[payload / status-report]
Таблица 8.9.3-1 показывает некоторые общие коды состояния, соответствующие этой транзакции. См. также Раздел 8.5 для получения дополнительных кодов состояния.
Таблица 8.9.3-1. Значение кодов состояния
Таблица 8.9.3-2. Поля заголовка ответа
См. также Раздел 8.4.
Ответ об успехе должен содержать полезную нагрузку с описанием возможностей (Capabilities Description) в выбранном типе мультимедиа. Описание возможностей должно соответствовать требованиям и структуре, определенным в Приложении H.
Полезная нагрузка ответа о сбое может содержать отчет о состоянии (Status Report), описывающий любые сбои, предупреждения или другую полезную информацию.
Реализация должна документировать в Заявлении о соответствии (Conformance Statement), поддерживает ли она уведомления или нет. Если служба поддерживает уведомления, она должна описать, как открываются соединения WebSocket.
Любая служба, поддерживающая уведомления (Notifications), должна поддерживать следующие транзакции:
Таблица 8.10.3-1. Транзакции подсистемы уведомлений
Эта транзакция создает соединение между пользовательским агентом и исходным сервером, по которому исходный сервер может отправлять отчеты о событиях (Event Reports) пользовательскому агенту.
Примечание
Исходный сервер может играть роль пользовательского агента при обмене данными с другим исходным сервером.
Соединение использует протокол WebSocket. Соединение может использовать тот же TCP-порт, что и HTTP-соединение, но это отдельные соединения.
См. [RFC6455] для получения подробной информации о протоколе WebSocket.
Существует более одного способа установить соединение WebSocket. Исходный сервер, соответствующий [RFC6455] и поддерживающий подписки на уведомления RESTful-служб, должен как минимум поддерживать запросы на открытие WebSocket через HTTP-соединения, имеющие следующий синтаксис:
GET SP / subscribers/{requester} SP version CRLF
Host: host CRLF
Upgrade: "WebSocket" CRLF
Connection: "Upgrade" CRLF
Origin: url CRLF
Sec-WebSocket-Key: nonce CRLF
Sec-WebSocket-Protocol: protocols CRLF
Sec-WebSocket-Version: "13" CRLF
*(<header-field> CRLF)
CRLF
Исходный сервер может поддерживать другие методы открытия соединения WebSocket, которые следует включить в Заявление о соответствии и ответ Retrieve Capabilities.
Исходный сервер должен поддерживать ресурсы, перечисленные в Таблице 8.10.4-1a.
Таблица 8.10.4-1 показывает использование полей заголовка запроса для открытия соединения WebSocket через http/https.
Подробные сведения о значениях полей заголовка запроса и других методах открытия соединения WebSocket см. в [RFC6455].
При получении этого запроса исходный сервер должен открыть и поддерживать соединение для уведомлений WebSocket между собой и пользовательским агентом, и использовать его для отправки уведомлений в виде отчетов о событиях (Event Report) для подписок, связанных с {requester}.
Если соединение в какой-либо момент прерывается, пользовательский агент может восстановить его, повторив эту транзакцию.
Ответ должен иметь следующий синтаксис:
version SP status-code SP reason-phrase CRLF
Upgrade: "WebSocket" CRLF
Connection: "Upgrade" CRLF
Sec-WebSocket-Accept: response-key CRLF
Sec-WebSocket-Protocol: protocol CRLF
*(header-field CRLF)
CRLF
Таблица 8.10.4-2 показывает некоторые общие коды состояния, соответствующие этой транзакции. См. также Раздел 8.5 для получения дополнительных кодов состояния.
Исходный сервер использует эту транзакцию для уведомления пользовательского агента о событиях (Events).
Эта транзакция отправляет уведомление, содержащее отчет о событии (Event Report), через установленное соединение для уведомлений от исходного сервера пользовательскому агенту. В отличие от большинства транзакций, эта транзакция инициируется исходным сервером.
Эта транзакция соответствует действию DIMSE N-EVENT-REPORT.
Каждая служба может определять события (Events) и соответствующие сообщения отчетов о событиях и их содержимое, связанные с ее ресурсами.
Запрос должен использовать протокол передачи кадров данных WebSocket.
Кадры данных должны иметь код операции (opcode) "%x1" (текст).
Данные полезной нагрузки кадра данных должны представлять собой DICOM JSON Data Set, содержащий атрибуты отчета о событии (Event Report).
Примечание
-
Протокол WebSocket в настоящее время не поддерживает согласование содержимого, поэтому невозможно одновременно поддерживать как XML-, так и JSON-кодирование сообщений отчета о событии.
-
Если отчеты о событиях проксируются в DIMSE N-EVENT-отчеты, идентификатор сообщения Message ID (0000,0110) должен управляться прокси-сервером.
Весьма вероятно, что DICOM-объекты содержат защищенную медицинскую информацию (Protected Health Information). Правила конфиденциальности в США (HIPAA), Европе (GDPR) и других регионах требуют, чтобы персональные идентификационные данные оставались конфиденциальными. Ответственность за соблюдение применимых нормативных требований к безопасности и конфиденциальности несут лица, реализующие и развертывающие стандарт DICOM.
См., например, [ONC Privacy Security Guide].
Некоторые типы изображений, такие как визуализированные объемы (rendered volumes) или исходные срезы, из которых они создаются, могут содержать распознаваемые визуальные признаки.
Формат файлов DICOM PS3.10 имеет аспекты безопасности, которые применяются при каждом использовании формата файлов DICOM PS3.10. См. Раздел 7.5 в PS3.10 .
Служба URI, также известная как WADO-URI, позволяет пользовательскому агенту извлекать представления Экземпляров с использованием HTTP.
Служба URI не определяет ресурсы в форме пути целевого ресурса, такого как {/resource}. Целевой URI каждой Транзакции является ссылкой на базовый URI ("/"), а целевой ресурс идентифицируется с использованием значений параметров запроса. Ресурсами для Службы URI являются Экземпляры Составных SOP-классов хранения, определенных в PS3.4.
Параметры запроса, указанные в этом Разделе, могут использоваться с Транзакциями Retrieve DICOM Instance или Retrieve Rendered Instance и применяются ко всем поддерживаемым SOP-классам.
Исходный сервер должен поддерживать параметры запроса, как требуется в Таблице 9.1.2-1.
Пользовательский агент должен предоставлять в запросе параметры запроса, как требуется в Таблице 9.1.2-1.
Параметры запроса могут располагаться в любом порядке.
См. Раздел 8.3.
Примечание
Для идентификации SOP-экземпляра требуется только SOP Instance UID, поскольку любой UID является глобально уникальным. Однако Стандарт требует, чтобы UID более высоких уровней в информационной модели DICOM (т.е. Series и Study) были указаны, чтобы поддерживать использование DICOM-устройств, которые поддерживают только базовую иерархическую (а не расширенную реляционную) модель Query/Retrieve, требующую определения Study Instance UID и Series Instance UID при извлечении Экземпляра, как определено в PS3.4.
requestType = %s"requestType=" token
token = "WADO"
Этот параметр указывает, что это запрос службы URI. Имя параметра должно быть "requestType", а значение должно быть "WADO".
Если значение отличается от "WADO" и исходный сервер не поддерживает это значение, ответ должен быть 400 (Bad Request) и может включать полезную нагрузку, содержащую соответствующее сообщение об ошибке.
study = %s"studyUID=" uid
series = %s"seriesUID=" uid
Параметры, определенные в этом разделе, являются необязательными для всех URI-запросов.
См. Раздел 8.3.
Параметр запроса Accept указывает приемлемые типы носителей для полезной нагрузки ответа. См. Раздел 8.7.5. Чувствительное к регистру имя параметра — "contentType". Его синтаксис:
accept = %s"contentType=" dicom / 1#rendered-media-type
Значение этого параметра, если оно присутствует, должно быть либо application/dicom, либо одним или несколькими из типов визуализированных носителей.
Параметры типа носителя DICOM transfer-syntax и набора символов запрещены в запросе. Если какой-либо из них присутствует, ответ должен быть 400 (Bad Request) и может включать полезную нагрузку, содержащую соответствующее сообщение об ошибке.
См. Раздел 8.7.5 относительно других ошибок, связанных с этим параметром.
charset-qp = %s"charset=" 1#(charset [weight])
Значением этого параметра является разделенный запятыми список одного или нескольких идентификаторов наборов символов. См. Раздел 8.8.1.
