PS3.4

DICOM PS3.4 2026b - Service Class Specifications

DICOM Standards Committee

Публикация DICOM®


Содержание

Уведомление и отказ от ответственности
Предисловие
1. Область и сфера применения
2. Нормативные ссылки
Библиография
3. Определения
Глоссарий
4. Символы и сокращения
5. Соглашения
5.1. Модель «сущность-связь»
5.1.1. Сущность
5.1.2. Связь
5.2. Последовательности
5.3. Значения статуса ответа
5.4. Спецификация использования
5.4.1. Использование сервисов DIMSE
5.4.2. Использование атрибутов в нормализованных сервисах
5.4.2.1. DIMSE-сервис N-CREATE, N-SET, N-ACTION
5.4.2.2. DIMSE-сервис N-GET, N-EVENT-REPORT
5.4.2.3. Другие требования
6. Информационная модель DICOM
6.1. Определение информационного объекта
6.1.1. Композитный IOD
6.1.2. Нормализованный IOD
6.2. Атрибуты
6.3. Сервисы онлайн-коммуникации и хранения на носителях
6.3.1. Сервисы DIMSE-C
6.3.2. Сервисы DIMSE-N
6.4. Группа сервисов DIMSE
6.5. Класс пары сервис-объект (SOP)
6.5.1. Нормализованные и композитные классы SOP
6.6. Согласование ассоциации
6.7. Спецификация класса сервиса
7. Модель реального мира DICOM
8. Использование кодированных записей в спецификациях сервисов
A. Класс сервиса верификации
A.1. Обзор
A.1.1. Область применения
A.2. Поведение SCU/SCP
A.3. Группа сервисов DIMSE-C
A.4. Класс SOP верификации
A.5. Согласование ассоциации
A.6. Соответствие
A.6.1. Соответствие, поддерживающее роль SCU
A.6.2. Соответствие, поддерживающее роль SCP
A.6.3. Заявление о соответствии
B. Класс сервиса хранения
B.1. Обзор
B.1.1. Область применения
B.1.2. Определение сервиса
B.2. Поведение
B.2.1. Поведение SCU
B.2.2. Поведение SCP
B.2.3. Статусы
B.3. Согласование ассоциации
B.3.1. Расширенное согласование
B.3.1.1. Информация о классе сервиса для приложения (A-ASSOCIATE-RQ)
B.3.1.2. Информация о классе сервиса для приложения (A-ASSOCIATE-AC)
B.3.1.3. UID класса сервиса (A-ASSOCIATE-RQ)
B.3.1.4. Связанные общие классы SOP (A-ASSOCIATE-RQ)
B.4. Соответствие
B.4.1. Соответствие в качестве SCP
B.4.1.1. Уровни поддержки хранения
B.4.1.2. Поддержка дополнительных классов SOP
B.4.1.3. Принудительное изменение атрибутов
B.4.1.4. Уровни поддержки цифровой подписи
B.4.2. Соответствие в качестве SCU
B.4.2.1. Резервное поведение SCU
B.4.3. Требования к заявлению о соответствии
B.4.3.1. Заявление о соответствии для SCU
B.4.3.2. Заявление о соответствии для SCP
B.4.4. Специализированное соответствие
B.4.4.1. Идентификация специализированного класса SOP
B.4.4.2. Специализированное определение информационного объекта
B.5. Стандартные классы SOP
B.5.1. Специализация для стандартных классов SOP
B.5.1.1. Классы SOP хранения цифровых рентгеновских изображений
B.5.1.2. Классы SOP хранения цифровых маммографических рентгеновских изображений
B.5.1.3. Классы SOP хранения цифровых внутриротовых рентгеновских изображений
B.5.1.4. Классы SOP хранения состояния программного представления
B.5.1.5. Классы SOP хранения структурированных отчётов
B.5.1.6. Класс SOP хранения расширенных МР-изображений и хранения преобразованных устаревших расширенных МР-изображений
B.5.1.7. Класс SOP хранения расширенных КТ-изображений и хранения преобразованных устаревших расширенных КТ-изображений
B.5.1.8. Класс SOP хранения цветных расширенных МР-изображений
B.5.1.9. Базовый структурированный дисплей
B.5.1.10. Классы SOP хранения шаблонов имплантатов
B.5.1.11. Класс SOP хранения результатов офтальмологических осевых измерений
B.5.1.12. Класс SOP хранения результатов расчёта ИОЛ
B.5.1.13. Классы SOP хранения внутрисосудистых ОКТ-изображений
B.5.1.14. Класс SOP хранения карт толщины офтальмологических структур
B.5.1.15. Класс SOP хранения расширенных ПЭТ-изображений и хранения преобразованных устаревших расширенных ПЭТ-изображений
B.5.1.16. Классы SOP хранения расширенных ПЭТ-изображений
B.5.1.17. Класс SOP хранения карт топографии роговицы
B.5.1.18. Классы SOP хранения проекционных рентгеновских изображений молочной железы
B.5.1.19. Классы SOP хранения состояния плоского объёмного представления MPR
B.5.1.20. Классы SOP хранения результатов оценки содержимого
B.5.1.21. Классы SOP хранения протоколов выполненных процедур КТ и XA
B.5.1.22. Класс SOP хранения необработанных данных
B.5.1.23. Классы SOP расширенных много кадровых изображений
B.5.1.24. Классы SOP хранения состояния объёмного представления объёмного рендеринга
B.5.1.25. Классы SOP хранения сегментации
B.6. Устаревшие стандартные классы SOP
C. Класс сервиса запросов/извлечения
C.1. Обзор
C.1.1. Область применения
C.1.2. Соглашения
C.1.3. Информационная модель запросов/извлечения
C.1.4. Определение сервиса
C.2. Определение информационной модели запросов/извлечения
C.2.1. Определение модели «сущность-связь»
C.2.2. Определение атрибутов
C.2.2.1. Типы атрибутов
C.2.2.1.1. Уникальные ключи
C.2.2.1.2. Обязательные ключи
C.2.2.1.3. Необязательные ключи
C.2.2.2. Сопоставление атрибутов
C.2.2.2.1. Сопоставление по одиночному значению
C.2.2.2.1.1. Атрибуты с VR типа PN
C.2.2.2.1.2. Атрибуты с VR типа AE, CS, LO, LT, PN, SH, ST, UC, UR и UT
C.2.2.2.1.3. Атрибуты с VR типа DA, DT или TM
C.2.2.2.1.4. Атрибуты с VR типа DS или IS
C.2.2.2.2. Сопоставление по списку UID
C.2.2.2.3. Универсальное сопоставление
C.2.2.2.4. Сопоставление по подстановочным знакам
C.2.2.2.5. Сопоставление по диапазону
C.2.2.2.5.1. Сопоставление по диапазону атрибутов с VR типа DA
C.2.2.2.5.2. Сопоставление по диапазону атрибутов с VR типа TM
C.2.2.2.5.3. Сопоставление по диапазону атрибутов с VR типа DT
C.2.2.2.5.4. Общие правила сопоставления по диапазону
C.2.2.2.6. Сопоставление последовательностей
C.2.2.2.7. Сопоставление пустых значений
C.2.2.2.8. Сопоставление множественных значений
C.2.2.3. Сопоставление многозначных атрибутов сущностей
C.3. Стандартные информационные модели запросов/извлечения
C.3.1. Информационная модель запросов/извлечения с корнем «Пациент»
C.3.2. Информационная модель запросов/извлечения с корнем «Исследование»
C.3.3. Информационная модель запросов/извлечения только «Пациент/Исследование» (устаревшая)
C.3.4. Дополнительные атрибуты запросов/извлечения
C.3.5. Создание нового экземпляра для преобразования расширенных многокадровых изображений
C.4. Группы сервисов DIMSE-C
C.4.1. Операция C-FIND
C.4.1.1. Параметры сервиса C-FIND
C.4.1.1.1. UID класса SOP
C.4.1.1.2. Приоритет
C.4.1.1.3. Идентификатор
C.4.1.1.3.1. Структура идентификатора запроса
C.4.1.1.3.2. Структура идентификатора ответа
C.4.1.1.4. Статус
C.4.1.2. Поведение SCU сервиса C-FIND
C.4.1.2.1. Базовое поведение SCU
C.4.1.2.2. Расширенное поведение SCU
C.4.1.2.2.1. Реляционные запросы
C.4.1.2.2.2. Преобразование расширенных многокадровых изображений
C.4.1.3. Поведение SCP сервиса C-FIND
C.4.1.3.1. Базовое поведение SCP
C.4.1.3.1.1. Иерархический метод поиска
C.4.1.3.2. Расширенное поведение SCP
C.4.1.3.2.1. Реляционные запросы
C.4.1.3.2.2. Реляционный метод поиска
C.4.1.3.2.3. Преобразование расширенных многокадровых изображений
C.4.2. Операция C-MOVE
C.4.2.1. Параметры сервиса C-MOVE
C.4.2.1.1. UID класса SOP
C.4.2.1.2. Приоритет
C.4.2.1.3. Назначение перемещения
C.4.2.1.4. Идентификатор
C.4.2.1.4.1. Структура идентификатора запроса
C.4.2.1.4.2. Структура идентификатора ответа
C.4.2.1.5. Статус
C.4.2.1.6. Количество оставшихся подопераций
C.4.2.1.7. Количество завершённых подопераций
C.4.2.1.8. Количество неудачных подопераций
C.4.2.1.9. Количество подопераций с предупреждениями
C.4.2.2. Поведение SCU сервиса C-MOVE
C.4.2.2.1. Базовое поведение SCU
C.4.2.2.2. Расширенное поведение SCU
C.4.2.2.2.1. Реляционное извлечение
C.4.2.2.2.2. Преобразование расширенных многокадровых изображений
C.4.2.3. Поведение SCP сервиса C-MOVE
C.4.2.3.1. Базовое поведение SCP
C.4.2.3.2. Расширенное поведение SCP
C.4.2.3.2.1. Реляционное извлечение
C.4.2.3.2.2. Преобразование расширенных многокадровых изображений
C.4.3. Операция C-GET
C.4.3.1. Параметры сервиса C-GET
C.4.3.1.1. UID класса SOP
C.4.3.1.2. Приоритет
C.4.3.1.3. Идентификатор
C.4.3.1.3.1. Структура идентификатора запроса
C.4.3.1.3.2. Структура идентификатора ответа
C.4.3.1.4. Статус
C.4.3.1.5. Количество оставшихся подопераций
C.4.3.1.6. Количество завершённых подопераций
C.4.3.1.7. Количество неудачных подопераций
C.4.3.1.8. Количество подопераций с предупреждениями
C.4.3.2. Поведение SCU сервиса C-GET
C.4.3.2.1. Базовое поведение SCU
C.4.3.2.2. Расширенное поведение SCU
C.4.3.2.2.1. Реляционное извлечение
C.4.3.2.2.2. Преобразование расширенных многокадровых изображений
C.4.3.3. Поведение SCP сервиса C-GET
C.4.3.3.1. Базовое поведение SCP
C.4.3.3.2. Расширенное поведение SCP
C.4.3.3.2.1. Реляционное извлечение
C.4.3.3.2.2. Преобразование расширенных многокадровых изображений
C.5. Согласование ассоциации
C.5.1. Согласование ассоциации для классов SOP C-FIND
C.5.1.1. Расширенное согласование класса SOP
C.5.1.1.1. Структура подэлемента расширенного согласования класса SOP (A-ASSOCIATE-RQ)
C.5.1.1.2. Структура подэлемента расширенного согласования класса SOP (A-ASSOCIATE-AC)
C.5.2. Согласование ассоциации для классов SOP C-MOVE
C.5.2.1. Расширенное согласование класса SOP
C.5.2.1.1. Структура подэлемента расширенного согласования класса SOP (A-ASSOCIATE-RQ)
C.5.2.1.2. Структура подэлемента расширенного согласования класса SOP (A-ASSOCIATE-AC)
C.5.3. Согласование ассоциации для классов SOP C-GET
C.5.3.1. Расширенное согласование класса SOP
C.6. Определения классов SOP
C.6.1. Группа классов SOP с корнем «Пациент»
C.6.1.1. Информационная модель запросов/извлечения с корнем «Пациент»
C.6.1.1.1. Модель E/R
C.6.1.1.2. Уровень пациента
C.6.1.1.3. Уровень исследования
C.6.1.1.4. Уровень серии
C.6.1.1.5. Уровень экземпляра композитного объекта
C.6.1.1.5.1. Последовательность альтернативного представления
C.6.1.1.5.2. UID доступного синтаксиса передачи SOP
C.6.1.1.6. Область применения команд C-GET и C-MOVE и подопераций
C.6.1.2. Требования соответствия
C.6.1.2.1. Соответствие SCU
C.6.1.2.1.1. Соответствие SCU сервиса C-FIND
C.6.1.2.1.2. Соответствие SCU сервиса C-MOVE
C.6.1.2.1.3. Соответствие SCU сервиса C-GET
C.6.1.2.2. Соответствие SCP
C.6.1.2.2.1. Соответствие SCP сервиса C-FIND
C.6.1.2.2.2. Соответствие SCP сервиса C-MOVE
C.6.1.2.2.3. Соответствие SCP сервиса C-GET
C.6.1.3. Классы SOP
C.6.2. Группа классов SOP с корнем «Исследование»
C.6.2.1. Информационная модель запросов/извлечения с корнем «Исследование»
C.6.2.1.1. Модель E/R
C.6.2.1.2. Уровень исследования
C.6.2.1.3. Уровень серии
C.6.2.1.4. Уровень экземпляра композитного объекта
C.6.2.1.5. Область применения команд Get и Move и подопераций
C.6.2.2. Требования соответствия
C.6.2.2.1. Соответствие SCU
C.6.2.2.1.1. Соответствие SCU сервиса C-FIND
C.6.2.2.1.2. Соответствие SCU сервиса C-MOVE
C.6.2.2.1.3. Соответствие SCU сервиса C-GET
C.6.2.2.2. Соответствие SCP
C.6.2.2.2.1. Соответствие SCP сервиса C-FIND
C.6.2.2.2.2. Соответствие SCP сервиса C-MOVE
C.6.2.2.2.3. Соответствие SCP сервиса C-GET
C.6.2.3. Классы SOP
C.6.3. Группа классов SOP только «Пациент/Исследование» (устаревшая)
C.6.4. Класс SOP запросов к репозиторию
C.6.4.1. Дополнительные атрибуты информационной модели запросов
C.6.4.1.1. Ключ записи
C.6.4.1.2. Удалено из оперативного использования
C.6.4.1.3. Последовательность доступа к набору файлов и последовательность доступа к файлу
C.6.4.1.4. Последовательность метаданных и последовательность обновлённых метаданных
C.6.4.2. Атрибуты идентификатора запроса к репозиторию
C.6.4.3. Коды статуса
C.6.4.4. Поведение SCU сервиса C-FIND
C.6.4.5. Поведение SCP сервиса C-FIND
C.6.4.5.1. Ключ записи
C.6.4.5.2. Максимальное количество записей и неполный ответ
C.6.4.5.3. Ключ предыдущей записи и последующий ответ
C.6.4.5.4. Сущности, удалённые из оперативного использования
C.6.4.5.5. Последовательность доступа к набору файлов и последовательность доступа к файлу
C.6.4.6. Требования соответствия
C.6.4.6.1. Соответствие SCU сервиса C-FIND
C.6.4.6.2. Соответствие SCP сервиса C-FIND
C.6.4.7. Классы SOP
D. Класс сервиса уведомления о содержании исследования (устаревший)
E. Класс сервиса управления пациентами (устаревший)
F. Классы SOP этапов процедуры
F.1. Обзор
F.1.1. Область применения (устаревшая)
F.1.2. Функциональная модель управления исследованием (устаревшая)
F.1.3. Информационная модель управления исследованием (устаревшая)
F.1.4. Состояния управления исследованием (устаревшие)
F.1.5. Состояния управления выполненным этапом процедуры модальности
F.1.6. Состояния управления запланированным этапом процедуры общего назначения (устаревшие)
F.1.7. Состояния управления выполненным этапом процедуры общего назначения (устаревшие)
F.2. Обзор соответствия
F.2.1. Согласование ассоциации
F.3. Класс SOP отдельного управления исследованием (устаревший)
F.4. Класс SOP управления компонентами исследования (устаревший)
F.5. Мета-класс SOP управления исследованием (устаревший)
F.6. Соответствие специализированного класса SOP (устаревшее)
F.7. Класс SOP выполненного этапа процедуры модальности
F.7.1. Группа сервисов DIMSE
F.7.2. Операции
F.7.2.1. Создание экземпляра SOP выполненного этапа процедуры модальности
F.7.2.1.1. Спецификация подмножества выполненного этапа процедуры модальности
F.7.2.1.2. Пользователь класса сервиса
F.7.2.1.3. Поставщик класса сервиса
F.7.2.1.4. Коды статуса
F.7.2.2. Установка информации о выполненном этапе процедуры модальности
F.7.2.2.1. Спецификация подмножества IOD выполненного этапа процедуры модальности
F.7.2.2.2. Пользователь класса сервиса
F.7.2.2.3. Поставщик класса сервиса
F.7.2.2.4. Коды статуса
F.7.3. UID класса SOP выполненного этапа процедуры модальности
F.7.4. Требования соответствия
F.7.4.1. Соответствие SCU
F.7.4.1.1. Операции
F.7.4.2. Соответствие SCP
F.7.4.2.1. Операции
F.8. Класс SOP извлечения выполненного этапа процедуры модальности
F.8.1. Группа сервисов DIMSE
F.8.2. Операции
F.8.2.1. Получение информации о выполненном этапе процедуры
F.8.2.1.1. Спецификации подмножества IOD извлечения выполненного этапа процедуры модальности
F.8.2.1.2. Пользователь класса сервиса
F.8.2.1.3. Поставщик класса сервиса
F.8.2.1.4. Коды статуса
F.8.3. UID класса SOP извлечения выполненного этапа процедуры модальности
F.8.4. Требования соответствия
F.8.4.1. Соответствие SCU
F.8.4.1.1. Операции
F.8.4.2. Соответствие SCP
F.8.4.2.1. Операции
F.9. Класс SOP уведомления о выполненном этапе процедуры модальности
F.9.1. Группа сервисов DIMSE
F.9.2. Уведомления
F.9.2.1. Получение уведомления о событии выполненного этапа процедуры модальности
F.9.2.2. Предоставление уведомления о событии выполненного этапа процедуры модальности
F.9.2.3. Коды статуса
F.9.3. UID класса SOP уведомления о выполненном этапе процедуры модальности
F.9.4. Требования соответствия
F.9.4.1. Соответствие SCU
F.9.4.1.1. Уведомления
F.9.4.2. Соответствие SCP
F.9.4.2.1. Уведомления
F.10. Класс SOP запланированного этапа процедуры общего назначения (устаревший)
F.11. Класс SOP выполненного этапа процедуры общего назначения (устаревший)
G. Класс сервиса управления результатами
H. Класс сервиса управления печатью
H.1. Область применения
H.2. Модель управления печатью
H.2.1. Модель потока данных управления печатью
H.2.1.1. Глобальная модель потока данных
H.2.1.2. Преобразования оттенков серого
H.2.1.2.1. Преобразования, зависящие от модальности и пользователя
H.2.1.2.2. Полярность
H.2.1.2.3. LUT представления
H.2.2. Структура класса сервиса управления печатью
H.2.3. Классы SOP управления печатью
H.2.4. Спецификации использования
H.2.5. Категории кодов статуса
H.3. Соответствие управления печатью
H.3.1. Область применения
H.3.2. Мета-классы SOP управления печатью
H.3.2.1. Описание
H.3.2.2. Определения мета-классов SOP
H.3.2.2.1. Базовый мета-класс SOP управления печатью в оттенках серого
H.3.2.2.2. Базовый мета-класс SOP управления цветной печатью
H.3.2.2.3. Ссылочный мета-класс SOP управления печатью в оттенках серого (устаревший)
H.3.2.2.4. Ссылочный мета-класс SOP управления цветной печатью (устаревший)
H.3.2.2.5. Мета-класс SOP управления печатью с извлечением сохранённых данных (устаревший)
H.3.3. Необязательные классы SOP
H.3.3.1. Описание
H.3.3.2. Список необязательных классов SOP
H.3.4. Заявление о соответствии
H.4. Определения классов SOP управления печатью
H.4.1. Класс SOP базового сеанса плёнки
H.4.1.1. Описание IOD
H.4.1.2. Группа сервисов DIMSE
H.4.1.2.1. N-CREATE
H.4.1.2.1.1. Атрибуты
H.4.1.2.1.2. Статус
H.4.1.2.1.3. Поведение
H.4.1.2.2. N-SET
H.4.1.2.2.1. Атрибуты
H.4.1.2.2.2. Статус
H.4.1.2.2.3. Поведение
H.4.1.2.3. N-DELETE
H.4.1.2.3.1. Статус
H.4.1.2.3.2. Поведение
H.4.1.2.4. N-ACTION
H.4.1.2.4.1. Атрибуты
H.4.1.2.4.2. Статус
H.4.1.2.4.3. Поведение
H.4.1.3. Определение и UID класса SOP
H.4.2. Класс SOP базового блока плёнки
H.4.2.1. Описание IOD
H.4.2.2. Группа сервисов DIMSE
H.4.2.2.1. N-CREATE
H.4.2.2.1.1. Атрибуты
H.4.2.2.1.2. Статус
H.4.2.2.1.3. Поведение
H.4.2.2.2. N-SET
H.4.2.2.2.1. Атрибуты
H.4.2.2.2.2. Статус
H.4.2.2.2.3. Поведение
H.4.2.2.3. N-DELETE
H.4.2.2.3.1. Поведение
H.4.2.2.3.2. Статус
H.4.2.2.4. N-ACTION
H.4.2.2.4.1. Атрибуты
H.4.2.2.4.2. Статус
H.4.2.2.4.3. Поведение
H.4.2.3. Определение и UID класса SOP
H.4.3. Классы SOP блока изображений
H.4.3.1. Класс SOP базового блока изображений в оттенках серого
H.4.3.1.1. Описание IOD
H.4.3.1.2. Группа сервисов DIMSE
H.4.3.1.2.1. N-SET
H.4.3.1.2.1.1. Атрибуты
H.4.3.1.2.1.2. Статус
H.4.3.1.2.1.3. Поведение
H.4.3.1.3. Определение и UID класса SOP
H.4.3.2. Класс SOP базового блока цветных изображений
H.4.3.2.1. Описание IOD
H.4.3.2.2. Группа сервисов DIMSE
H.4.3.2.2.1. N-SET
H.4.3.2.2.1.1. Атрибуты
H.4.3.2.2.1.2. Статус
H.4.3.2.2.1.3. Поведение
H.4.3.2.3. Определение и UID класса SOP
H.4.3.3. Ссылочный класс SOP блока изображений (устаревший)
H.4.4. Класс SOP базового блока аннотаций
H.4.4.1. Описание IOD
H.4.4.2. Группа сервисов DIMSE
H.4.4.2.1. N-SET
H.4.4.2.1.1. Атрибуты
H.4.4.2.1.2. Статус
H.4.4.2.1.3. Поведение
H.4.4.3. Определение и UID класса SOP
H.4.5. Класс SOP задания печати
H.4.5.1. Описание IOD
H.4.5.2. Группа сервисов DIMSE
H.4.5.2.1. N-EVENT-REPORT
H.4.5.2.1.1. Атрибуты
H.4.5.2.1.2. Поведение
H.4.5.2.1.3. Статус
H.4.5.2.2. N-GET
H.4.5.2.2.1. Атрибуты
H.4.5.2.2.2. Поведение
H.4.5.2.2.3. Статус
H.4.5.3. Информация о статусе выполнения
H.4.5.4. Определение и UID класса SOP
H.4.6. Класс SOP принтера
H.4.6.1. Описание IOD
H.4.6.2. Группа сервисов DIMSE
H.4.6.2.1. N-EVENT-REPORT
H.4.6.2.1.1. Атрибуты
H.4.6.2.1.2. Поведение
H.4.6.2.1.3. Статус
H.4.6.2.2. N-GET
H.4.6.2.2.1. Атрибуты
H.4.6.2.2.2. Поведение
H.4.6.2.2.3. Статус
H.4.6.3. Информация о статусе принтера
H.4.6.4. Определение и UID класса SOP
H.4.6.5. Зарезервированные идентификаторы
H.4.7. Класс SOP блока VOI LUT (устаревший)
H.4.8. Класс SOP блока наложения изображений (устаревший)
H.4.9. Класс SOP LUT представления
H.4.9.1. Описание информационного объекта
H.4.9.1.1. Отображение P-значений в оптическую плотность
H.4.9.2. Группа сервисов DIMSE
H.4.9.2.1. N-CREATE
H.4.9.2.1.1. Атрибуты
H.4.9.2.1.1.1. Дескриптор LUT
H.4.9.2.1.2. Статус
H.4.9.2.1.3. Поведение
H.4.9.2.2. N-DELETE
H.4.9.2.2.1. Статус
H.4.9.2.2.2. Поведение
H.4.9.2.4. Определение и UID класса SOP
H.4.10. Класс SOP запроса печати с извлечением (устаревший)
H.4.11. Класс SOP извлечения конфигурации принтера
H.4.11.1. Описание IOD
H.4.11.2. Группа сервисов DIMSE
H.4.11.2.2. N-GET
H.4.11.2.2.1. Атрибуты
H.4.11.2.2.2. Поведение
H.4.11.2.2.3. Статус
H.4.11.3. Определение и UID класса SOP
H.4.11.4. Зарезервированные идентификаторы
H.4.12. Базовый класс SOP блока наложения изображения печати (устаревший)
H.5. Согласование ассоциации
H.6. Пример сеанса SCU управления печатью (информативное)
H.6.1. Простой пример
H.6.2. Расширенный пример (устаревший)
H.7. Пример мета-класса SOP запроса pull-печати (информативное)
H.8. Примеры наложений (информативное)
I. Класс сервиса хранения на носителях
I.1. Обзор
I.1.1. Область применения
I.1.2. Определение сервиса
I.2. Поведение
I.2.1. Поведение FSC
I.2.2. Поведение FSR
I.2.3. Поведение FSU
I.3. Соответствие
I.3.1. Соответствие в качестве FSC
I.3.2. Соответствие в качестве FSR
I.3.3. Соответствие в качестве FSU
I.3.4. Требования к заявлению о соответствии
I.3.5. Стандартное расширенное, специализированное и частное соответствие
I.4. Классы SOP хранения на носителях
I.4.1. Специализация для стандартных классов SOP (устаревшая)
I.5. Устаревшие стандартные классы SOP
J. Класс сервиса фиксации хранения
J.1. Обзор
J.1.1. Область применения
J.1.2. Обзор моделей
J.2. Обзор соответствия
J.2.1. Согласование ассоциации
J.3. Класс SOP push-модели фиксации хранения
J.3.1. Группа сервисов DIMSE
J.3.2. Операции
J.3.2.1. Запрос фиксации хранения
J.3.2.1.1. Информация о действии
J.3.2.1.1.1. Атрибуты идентификатора набора файлов на носителе хранения
J.3.2.1.1.2. Атрибут последовательности ссылок на выполненный этап процедуры (устаревший)
J.3.2.1.1.3. Ссылка на экземпляр SOP
J.3.2.1.2. Поведение пользователя класса сервиса
J.3.2.1.3. Поведение поставщика класса сервиса
J.3.2.1.4. Коды статуса
J.3.3. Уведомления
J.3.3.1. Результат фиксации хранения
J.3.3.1.1. Информация о событии
J.3.3.1.1.1. Атрибут заголовка AE извлечения
J.3.3.1.1.2. Атрибуты идентификатора набора файлов на носителе хранения
J.3.3.1.2. Поведение поставщика класса сервиса
J.3.3.1.3. Поведение пользователя класса сервиса
J.3.3.1.4. Коды статуса
J.3.4. UID класса SOP push-модели фиксации хранения
J.3.5. Зарезервированный идентификатор push-модели фиксации хранения
J.3.6. Требования к соответствию
J.3.6.1. Соответствие SCU
J.3.6.1.1. Операции
J.3.6.1.2. Уведомления
J.3.6.2. Соответствие SCP
J.3.6.2.1. Операции
J.3.6.2.2. Уведомления
J.4. Класс SOP pull-модели фиксации хранения (устаревший)
J.5. Примеры фиксации хранения (информативное)
K. Класс сервиса базового управления списком работ
K.1. Обзор
K.1.1. Область применения
K.1.2. Соглашения
K.1.3. Информационная модель списка работ
K.1.4. Определение сервиса
K.2. Определение информационной модели списка работ
K.2.1. Определение модели «сущность-связь»
K.2.2. Определение атрибутов
K.2.2.1. Типы атрибутов
K.2.2.1.1. Атрибуты ключа сопоставления
K.2.2.1.1.1. Обязательные атрибуты ключа сопоставления
K.2.2.1.1.2. Необязательные атрибуты ключа сопоставления
K.2.2.1.2. Атрибуты ключа возврата
K.2.2.2. Сопоставление атрибутов
K.2.2.3. Сопоставление нескольких значений
K.3. Информационная модель списка работ
K.4. Группа сервисов DIMSE-C
K.4.1. Операция C-FIND
K.4.1.1. Параметры сервиса C-FIND
K.4.1.1.1. UID класса SOP
K.4.1.1.2. Приоритет
K.4.1.1.3. Идентификатор
K.4.1.1.3.1. Структура идентификатора запроса
K.4.1.1.3.2. Структура идентификатора ответа
K.4.1.1.4. Статус
K.4.1.2. Поведение SCU сервиса C-FIND
K.4.1.3. Поведение SCP сервиса C-FIND
K.4.1.3.1. Метод поиска по «списку работ»
K.5. Согласование ассоциации
K.5.1. Расширенное согласование класса SOP
K.5.1.1. Структура субэлемента расширенного согласования класса SOP (A-ASSOCIATE-RQ)
K.5.1.2. Структура субэлемента расширенного согласования класса SOP (A-ASSOCIATE-AC)
K.6. Определения классов SOP
K.6.1. Класс SOP списка работ модальности
K.6.1.1. Обзор класса SOP списка работ модальности
K.6.1.2. Информационная модель списка работ модальности
K.6.1.2.1. Модель E/R
K.6.1.2.2. Атрибуты списка работ модальности
K.6.1.3. Требования к соответствию
K.6.1.3.1. Соответствие SCU
K.6.1.3.2. Соответствие SCP
K.6.1.4. Класс SOP
K.6.2. Класс SOP списка работ общего назначения (устаревший)
K.7. Примеры использования списка работ модальности (информативное)
K.8. Пример списка работ общего назначения (информативное) (устаревший)
L. Класс сервиса управления очередью
M. Обработка идентифицирующих параметров (информативное)
N. Классы SOP хранения состояния программного представления
N.1. Обзор
N.1.1. Область применения
N.2. Последовательность преобразования пикселей
N.2.1. Преобразования в оттенках серого
N.2.1.1. LUT модальности
N.2.1.2. Маска
N.2.1.3. VOI LUT
N.2.1.4. LUT представления
N.2.2. Цветовые преобразования
N.2.2.1. Преобразование пространства подключения профиля
N.2.2.2. Белая точка (информативное)
N.2.3. Общие пространственные преобразования и преобразования аннотаций
N.2.3.1. Затвор
N.2.3.2. Аннотация до пространственного преобразования
N.2.3.3. Пространственное преобразование
N.2.3.4. Аннотация после пространственного преобразования
N.2.4. Преобразования смешивания
N.2.4.1. Базовые пиксели изображения
N.2.4.2. Наложенные пиксели изображения
N.2.4.3. Операция смешивания
N.2.4.4. Преобразование в пространство подключения профиля
N.2.5. Преобразования в оттенках серого для ангиографии
N.2.5.1. Маска
N.2.5.2. Повышение резкости краёв
N.2.6. Расширенные преобразования смешивания
N.3. Поведение SCP
N.4. Соответствие
N.4.1. Заявление о соответствии для SCU
N.4.2. Заявление о соответствии для SCP
O. Классы SOP хранения структурированных отчётов
O.1. Обзор
O.2. Поведение SCU и SCP класса SOP хранения структурированных отчётов
O.2.1. Поведение SCU
O.2.1.1. Классы SOP CAD SR
O.2.1.2. Класс SOP расширяемого SR
O.2.2. Поведение SCP
O.2.2.1. Классы SOP CAD SR
O.2.2.2. Класс SOP расширяемого SR
O.3. Изменение содержимого документа SR
O.4. Соответствие
O.4.1. Заявление о соответствии для SCU
O.4.1.1. Классы SOP CAD SR
O.4.1.2. Классы SOP ультразвукового SR
O.4.2. Заявление о соответствии для SCP
O.4.2.1. Классы SOP CAD SR
O.4.2.2. Класс SOP расширяемого SR
P. Класс сервиса регистрации событий приложения
P.1. Обзор
P.1.1. Область применения
P.1.2. Определение сервиса
P.2. Определение класса SOP регистрации процедурных событий
P.2.1. Группа сервисов DIMSE
P.2.2. Операция
P.2.2.1. Информация о действии
P.2.2.1.1. Атрибуты сопоставления исследования
P.2.2.1.2. UID системы координат синхронизации
P.2.2.1.3. Ограничения на атрибуты модуля содержимого документа SR
P.2.2.2. Поведение пользователя класса сервиса
P.2.2.3. Поведение поставщика класса сервиса
P.2.2.4. Коды статуса
P.2.2.5. Ответ на действие
P.2.3. UID класса SOP регистрации процедурных событий
P.2.4. Идентификация экземпляра регистрации процедурных событий
P.2.5. Требования к соответствию
P.2.5.1. Соответствие SCU
P.2.5.2. Соответствие SCP
P.3. Определение класса SOP регистрации введения веществ
P.3.1. Группа сервисов DIMSE
P.3.2. Операция
P.3.2.1. Информация о действии регистрации журнала введения веществ
P.3.2.2. Поведение пользователя класса сервиса
P.3.2.3. Поведение поставщика класса сервиса
P.3.2.4. Коды статуса
P.3.3. UID класса SOP регистрации введения веществ
P.3.4. UID экземпляра регистрации введения веществ
P.3.5. Требования к соответствию
P.3.5.1. Соответствие SCU
P.3.5.2. Соответствие SCP
Q. Класс сервиса запроса релевантной информации о пациенте
Q.1. Обзор
Q.2. Группа сервисов DIMSE-C
Q.2.1. Операция C-FIND
Q.2.1.1. Параметры сервиса C-FIND
Q.2.1.1.1. UID класса SOP
Q.2.1.1.2. Приоритет
Q.2.1.1.3. Идентификатор
Q.2.1.1.3.1. Структура идентификатора запроса
Q.2.1.1.3.2. Структура идентификатора ответа
Q.2.1.1.3.3. Шаблоны релевантной информации о пациенте
Q.2.1.1.4. Статус
Q.3. Согласование ассоциации
Q.4. Сервис DIMSE-C C-FIND
Q.4.1. Соглашения
Q.4.2. Определение сервиса
Q.4.3. Классы SOP информационной модели релевантной информации о пациенте
Q.4.3.1. Информационная модель релевантной информации о пациенте
Q.4.3.1.1. Модель E/R
Q.4.3.1.2. Атрибуты релевантной информации о пациенте
Q.4.3.1.2.1. Описания атрибутов релевантной информации о пациенте
Q.4.3.2. Требования к соответствию
Q.4.3.2.1. Соответствие SCU
Q.4.3.2.2. Соответствие SCP
Q.4.3.3. Классы SOP
Q.5. Пример запроса релевантной информации о пациенте (информативное)
R. Класс сервиса уведомления о доступности экземпляра
R.1. Обзор
R.1.1. Область применения
R.2. Обзор соответствия
R.3. Класс SOP уведомления о доступности экземпляра
R.3.1. Группа сервисов DIMSE
R.3.2. Операции
R.3.2.1. N-CREATE экземпляр SOP уведомления о доступности экземпляра
R.3.2.1.1. Атрибуты
R.3.2.1.2. Пользователь класса сервиса
R.3.2.1.3. Поставщик класса сервиса
R.3.2.1.4. Коды статуса
R.3.3. UID класса SOP уведомления о доступности экземпляра
R.3.4. Требования к соответствию
R.3.4.1. Соответствие SCU
R.3.4.1.1. Операции
R.3.4.2. Соответствие SCP
R.3.4.2.1. Операции
S. Класс сервиса управления созданием носителя
S.1. Обзор
S.1.1. Область применения
S.2. Обзор соответствия
S.2.1. Согласование ассоциации
S.3. Класс SOP управления созданием носителя
S.3.1. Группа сервисов DIMSE
S.3.2. Операции
S.3.2.1. Создание запроса на создание носителя
S.3.2.1.1. Атрибуты
S.3.2.1.1.1. Атрибуты набора файлов на носителе хранения
S.3.2.1.1.2. Запрошенный профиль приложения носителя
S.3.2.1.1.3. Последовательность значков изображения
S.3.2.1.1.4. Маркировка
S.3.2.1.1.5. Утилизация носителя
S.3.2.1.1.6. Разрешение разбиения носителя
S.3.2.1.1.7. Включение объектов, не относящихся к DICOM
S.3.2.1.1.8. Включение приложения отображения
S.3.2.1.1.9. Разрешение сжатия с потерями
S.3.2.1.2. Поведение пользователя класса сервиса
S.3.2.1.3. Поведение поставщика класса сервиса
S.3.2.1.4. Коды статуса
S.3.2.2. Инициация создания носителя
S.3.2.2.1. Информация о действии
S.3.2.2.1.1. Приоритет
S.3.2.2.2. Поведение пользователя класса сервиса
S.3.2.2.3. Поведение поставщика класса сервиса
S.3.2.2.4. Коды статуса
S.3.2.3. Отмена создания носителя
S.3.2.3.1. Информация о действии
S.3.2.3.2. Поведение пользователя класса сервиса
S.3.2.3.3. Поведение поставщика класса сервиса
S.3.2.3.4. Коды статуса
S.3.2.4. Получение результата создания носителя
S.3.2.4.1. Атрибуты
S.3.2.4.2. Пользователь класса сервиса
S.3.2.4.3. Поставщик класса сервиса
S.3.2.4.4. Коды статуса
S.3.3. UID класса SOP управления созданием носителя
S.4. Требования к соответствию
S.4.1. Соответствие SCU
S.4.1.1. Операции
S.4.2. Соответствие SCP
S.4.2.1. Операции
T. Класс сервиса хранения протоколов развески
U. Класс сервиса запросов/извлечения протоколов развески
U.1. Обзор
U.1.1. Область применения
U.1.2. Соглашения
U.1.3. Информационная модель запросов/извлечения
U.1.4. Определение сервиса
U.2. Определение информационной модели протоколов развески
U.3. Информационная модель протоколов развески
U.4. Группы сервисов DIMSE-C
U.4.1. Операция C-FIND
U.4.2. Операция C-MOVE
U.4.3. Операция C-GET
U.5. Согласование ассоциации
U.6. Определения классов SOP
U.6.1. Информационная модель протоколов развески
U.6.1.1. Модель E/R
U.6.1.2. Атрибуты протоколов развески
U.6.1.3. Требования к соответствию
U.6.1.3.1. Соответствие SCU
U.6.1.3.1.1. Соответствие SCU сервиса C-FIND
U.6.1.3.1.2. Соответствие SCU сервиса C-MOVE
U.6.1.3.1.3. Соответствие SCU сервиса C-GET
U.6.1.3.2. Соответствие SCP
U.6.1.3.2.1. Соответствие SCP сервиса C-FIND
U.6.1.3.2.2. Соответствие SCP сервиса C-MOVE
U.6.1.3.2.3. Соответствие SCP сервиса C-GET
U.6.1.4. Классы SOP
V. Класс сервиса запроса введения веществ
V.1. Обзор
V.1.1. Область применения
V.1.2. Соглашения
V.1.3. Информационная модель запроса введения веществ
V.1.4. Определение сервиса
V.2. Определение информационной модели запроса введения веществ
V.2.1. Определение модели «сущность-связь»
V.2.2. Определение атрибутов
V.2.2.1. Типы атрибутов
V.2.2.1.1. Атрибуты ключа сопоставления
V.2.2.1.1.1. Обязательные атрибуты ключа сопоставления
V.2.2.1.1.2. Необязательные атрибуты ключа сопоставления
V.2.2.1.2. Атрибуты ключа возврата
V.2.2.2. Сопоставление атрибутов
V.3. Информационные модели запроса
V.4. Группа сервисов DIMSE-C
V.4.1. Операция C-FIND
V.4.1.1. Параметры сервиса C-FIND
V.4.1.1.1. UID класса SOP
V.4.1.1.2. Приоритет
V.4.1.1.3. Идентификатор
V.4.1.1.3.1. Структура идентификатора запроса
V.4.1.1.3.2. Структура идентификатора ответа
V.4.1.1.4. Статус
V.4.1.2. Поведение SCU сервиса C-FIND
V.4.1.3. Поведение SCP сервиса C-FIND
V.4.1.3.1. Метод поискового запроса
V.5. Согласование ассоциации
V.6. Определения классов SOP
V.6.1. Класс SOP запроса характеристик продукта
V.6.1.1. Обзор класса SOP запроса характеристик продукта
V.6.1.2. Информационная модель запроса характеристик продукта
V.6.1.2.1. Модель E/R
V.6.1.2.2. Атрибуты запроса характеристик продукта
V.6.1.3. Требования к соответствию
V.6.1.3.1. Соответствие SCU
V.6.1.3.2. Соответствие SCP
V.6.1.4. Класс SOP
V.6.2. Класс SOP запроса одобрения вещества
V.6.2.1. Обзор класса SOP запроса одобрения вещества
V.6.2.2. Информационная модель запроса одобрения вещества
V.6.2.2.1. Модель E/R
V.6.2.2.2. Атрибуты запроса одобрения вещества
V.6.2.2.3. Ответы запроса одобрения вещества
V.6.2.3. Требования к соответствию
V.6.2.3.1. Соответствие SCU
V.6.2.3.2. Соответствие SCP
V.6.2.4. Класс SOP
W. Класс сервиса хранения цветовых палитр
X. Класс сервиса запросов/извлечения цветовых палитр
X.1. Обзор
X.1.1. Область применения
X.1.2. Соглашения
X.1.3. Информационная модель запросов/извлечения
X.1.4. Определение сервиса
X.2. Определение информационной модели цветовых палитр
X.3. Информационная модель цветовых палитр
X.4. Группы сервисов DIMSE-C
X.4.1. Операция C-FIND
X.4.2. Операция C-MOVE
X.4.3. Операция C-GET
X.5. Согласование ассоциации
X.6. Определения классов SOP
X.6.1. Информационная модель цветовых палитр
X.6.1.1. Модель E/R
X.6.1.2. Атрибуты цветовых палитр
X.6.1.3. Требования к соответствию
X.6.1.3.1. Соответствие SCU
X.6.1.3.1.1. Соответствие SCU сервиса C-FIND
X.6.1.3.1.2. Соответствие SCU сервиса C-MOVE
X.6.1.3.1.3. Соответствие SCU сервиса C-GET
X.6.1.3.2. Соответствие SCP
X.6.1.3.2.1. Соответствие SCP сервиса C-FIND
X.6.1.3.2.2. Соответствие SCP сервиса C-MOVE
X.6.1.3.2.3. Соответствие SCP сервиса C-GET
X.6.1.4. Классы SOP
Y. Класс сервиса извлечения с корнем композитного экземпляра
Y.1. Обзор
Y.1.1. Область применения
Y.1.2. Информационная модель извлечения с корнем композитного экземпляра
Y.1.3. Определение сервиса
Y.2. Определение информационной модели извлечения с корнем композитного экземпляра
Y.2.1. Определение модели «сущность-связь»
Y.2.2. Определение атрибутов
Y.3. Стандартная информационная модель извлечения с корнем композитного экземпляра
Y.3.1. Информационная модель с корнем композитного экземпляра
Y.3.2. Построение и интерпретация ключей диапазона кадров
Y.3.2.1. Определения списка кадров
Y.3.2.1.1. Простой список кадров
Y.3.2.1.2. Вычисляемый список кадров
Y.3.2.1.3. Диапазон времени
Y.3.3. Создание нового экземпляра на уровне кадра
Y.4. Группы сервисов DIMSE-C
Y.4.1. Операция C-MOVE
Y.4.1.1. Параметры сервиса C-MOVE
Y.4.1.1.1. UID класса SOP
Y.4.1.1.2. Приоритет
Y.4.1.1.3. Идентификатор
Y.4.1.1.3.1. Структура идентификатора запроса
Y.4.1.1.4. Статус
Y.4.1.1.5. Количество оставшихся подопераций
Y.4.1.1.6. Количество выполненных подопераций
Y.4.1.1.7. Количество неудачных подопераций
Y.4.1.1.8. Количество подопераций с предупреждением
Y.4.1.2. Поведение SCU сервиса C-MOVE
Y.4.1.2.1. Базовое поведение SCU
Y.4.1.2.2. Расширенное поведение SCU
Y.4.1.3. Поведение SCP сервиса C-MOVE
Y.4.1.3.1. Базовое поведение SCP
Y.4.1.3.2. Расширенное поведение SCP
Y.4.2. Операция C-GET
Y.4.2.1. Параметры сервиса C-GET
Y.4.2.1.1. UID класса SOP
Y.4.2.1.2. Приоритет
Y.4.2.1.3. Идентификатор
Y.4.2.1.3.1. Структура идентификатора запроса
Y.4.2.1.4. Статус
Y.4.2.1.5. Количество оставшихся подопераций
Y.4.2.1.6. Количество выполненных подопераций
Y.4.2.1.7. Количество неудачных подопераций
Y.4.2.1.8. Количество подопераций с предупреждением
Y.4.2.2. Поведение SCU сервиса C-GET
Y.4.2.2.1. Базовое поведение SCU
Y.4.2.2.2. Расширенное поведение SCU
Y.4.2.3. Поведение SCP сервиса C-GET
Y.4.2.3.1. Базовое поведение SCP
Y.4.2.3.2. Расширенное поведение SCP
Y.5. Согласование ассоциации
Y.5.1. Согласование ассоциации для классов SOP C-MOVE и C-GET
Y.5.1.1. Расширенное согласование класса SOP
Y.5.1.1.1. Структура субэлемента расширенного согласования класса SOP (A-ASSOCIATE-RQ)
Y.5.1.1.2. Структура субэлемента расширенного согласования класса SOP (A-ASSOCIATE-AC)
Y.6. Определения классов SOP
Y.6.1. Группа классов SOP с корнем композитного экземпляра
Y.6.1.1. Информационная модель только извлечения с корнем композитного экземпляра
Y.6.1.1.1. Модель E/R
Y.6.1.1.2. Уровень композитного экземпляра
Y.6.1.1.3. Уровень кадра
Y.6.1.1.4. Область применения команд C-MOVE или C-GET и подопераций
Y.6.1.2. Требования к соответствию
Y.6.1.2.1. Соответствие SCU
Y.6.1.2.1.1. Соответствие SCU сервиса C-MOVE
Y.6.1.2.1.2. Соответствие SCU сервиса C-GET
Y.6.1.2.2. Соответствие SCP
Y.6.1.2.2.1. Соответствие SCP сервиса C-MOVE
Y.6.1.2.2.2. Соответствие SCP сервиса C-GET
Y.6.1.3. Классы SOP
Z. Класс сервиса извлечения композитного экземпляра без объемных данных
Z.1. Обзор
Z.1.1. Область применения
Z.1.2. Информационная модель извлечения композитного экземпляра без объемных данных
Z.1.3. Не включённые атрибуты
Z.1.4. Определение сервиса
Z.2. Определение информационной модели извлечения композитного экземпляра без объемных данных
Z.2.1. Определение модели «сущность-связь»
Z.2.2. Определение атрибутов
Z.3. Стандартная информационная модель извлечения композитного экземпляра без объемных данных
Z.3.1. Информационная модель извлечения композитного экземпляра без объемных данных
Z.4. Группы сервисов DIMSE-C
Z.4.1. Не используется
Z.4.2. Операция C-GET
Z.4.2.1. Параметры службы C-GET
Z.4.2.1.1. UID SOP-класса
Z.4.2.1.2. Приоритет
Z.4.2.1.3. Идентификатор
Z.4.2.1.3.1. Структура идентификатора запроса
Z.4.2.1.4. Состояние
Z.4.2.1.5. Количество оставшихся подопераций
Z.4.2.1.6. Количество завершённых подопераций
Z.4.2.1.7. Количество неудачных подопераций
Z.4.2.1.8. Количество подопераций с предупреждением
Z.4.2.2. Поведение SCU C-GET и SCP C-STORE
Z.4.2.2.1. Базовое поведение SCU
Z.4.2.2.2. Расширенное поведение SCU
Z.4.2.3. Поведение SCP C-GET и SCU C-STORE
Z.4.2.3.1. Базовое поведение SCP
Z.4.2.3.2. Расширенное поведение SCP
Z.5. Согласование ассоциации
Z.5.1. Согласование ассоциации для SOP-классов C-GET
Z.6. Определения SOP-классов
Z.6.1. Группа SOP-классов извлечения составных экземпляров без массивов данных
Z.6.1.1. Информационная модель извлечения составных экземпляров без массивов данных
Z.6.1.1.1. Модель E/R
Z.6.1.1.2. Уровень составного экземпляра
Z.6.1.1.3. Область применения команд C-GET и подопераций
Z.6.1.2. Требования к соответствию
Z.6.1.2.1. Соответствие SCU
Z.6.1.2.2. Соответствие SCP
Z.6.1.3. SOP-классы
AA. SOP-классы хранения офтальмологических рефракционных измерений
AA.1. Область применения
AA.2. Поведение SCP
BB. Классы служб запроса/извлечения шаблонов имплантатов
BB.1. Обзор
BB.1.1. Область применения
BB.1.2. Условные обозначения
BB.1.3. Информационная модель запроса/извлечения
BB.1.4. Определение службы
BB.2. Определения информационных моделей шаблонов имплантатов
BB.3. Информационные модели шаблонов имплантатов
BB.4. Группы служб DIMSE-C
BB.4.1. Операция C-FIND
BB.4.1.1. Поведение пользователя класса службы
BB.4.1.2. Поведение поставщика класса службы
BB.4.2. Операция C-MOVE
BB.4.3. Операция C-GET
BB.5. Согласование ассоциации
BB.6. Определения SOP-классов
BB.6.1. Информационная модель шаблонов имплантатов
BB.6.1.1. Модели E/R
BB.6.1.2. Атрибуты шаблонов имплантатов
BB.6.1.2.1. Атрибуты базового шаблона имплантата
BB.6.1.2.2. Атрибуты шаблона сборки имплантата
BB.6.1.2.3. Атрибуты группы шаблонов имплантатов
BB.6.1.3. Требования к соответствию
BB.6.1.3.1. Соответствие SCU
BB.6.1.3.1.1. Соответствие SCU C-FIND
BB.6.1.3.1.2. Соответствие SCU C-MOVE
BB.6.1.3.1.3. Соответствие SCU C-GET
BB.6.1.3.2. Соответствие SCP
BB.6.1.3.2.1. Соответствие SCP C-FIND
BB.6.1.3.2.2. Соответствие SCP C-MOVE
BB.6.1.3.2.3. Соответствие SCP C-GET
BB.6.1.4. SOP-классы
CC. Служба и SOP-классы единого этапа процедуры
CC.1. Обзор
CC.1.1. Состояния единого этапа процедуры
CC.2. Группы служб DIMSE
CC.2.1. Изменение состояния UPS (N-ACTION)
CC.2.1.1. Информация о действии
CC.2.1.2. Поведение пользователя класса службы
CC.2.1.3. Поведение поставщика класса службы
CC.2.1.4. Коды состояния
CC.2.2. Запрос отмены UPS (N-ACTION)
CC.2.2.1. Информация о действии
CC.2.2.2. Поведение пользователя класса службы
CC.2.2.3. Поведение поставщика класса службы
CC.2.2.4. Коды состояния
CC.2.3. Подписка/отписка на получение отчётов о событиях UPS (N-ACTION)
CC.2.3.1. Информация о действии
CC.2.3.2. Поведение пользователя класса службы
CC.2.3.3. Поведение поставщика класса службы
CC.2.3.3.1. Глобальная подписка с фильтрацией
CC.2.3.4. Коды состояния
CC.2.4. Сообщение об изменении состояния UPS (N-EVENT-REPORT)
CC.2.4.1. Информация отчёта о событии
CC.2.4.2. Поведение пользователя класса службы
CC.2.4.3. Поведение поставщика класса службы
CC.2.4.4. Коды состояния
CC.2.5. Создание единого этапа процедуры (N-CREATE)
CC.2.5.1. Спецификация атрибутов единого этапа процедуры
CC.2.5.1.1. Требования к конечному состоянию UPS
CC.2.5.1.2. Макросы UPS
CC.2.5.1.3. Требования к службе атрибутов UPS
CC.2.5.1.3.1. UID SOP-класса UPS
CC.2.5.1.3.2. Последовательность выполненных процедур единого этапа процедуры
CC.2.5.2. Поведение пользователя класса службы
CC.2.5.3. Поведение поставщика класса службы
CC.2.5.4. Коды состояния
CC.2.6. Установка информации единого этапа процедуры (N-SET)
CC.2.6.1. Спецификация подмножества IOD единого этапа процедуры
CC.2.6.2. Поведение пользователя класса службы
CC.2.6.3. Поведение поставщика класса службы
CC.2.6.4. Коды состояния
CC.2.7. Получение информации единого этапа процедуры (N-GET)
CC.2.7.1. Спецификация подмножества IOD единого этапа процедуры
CC.2.7.2. Поведение пользователя класса службы
CC.2.7.3. Поведение поставщика класса службы
CC.2.7.4. Коды состояния
CC.2.8. Поиск единого этапа процедуры (C-FIND)
CC.2.8.1. Операция
CC.2.8.1.1. Модель E/R
CC.2.8.1.2. Параметры службы C-FIND
CC.2.8.1.2.1. UID SOP-класса
CC.2.8.1.2.2. Приоритет
CC.2.8.1.3. Идентификатор
CC.2.8.1.3.1. Структура идентификатора запроса
CC.2.8.1.3.2. Структура идентификатора ответа
CC.2.8.2. Поведение пользователя класса службы
CC.2.8.3. Поведение поставщика класса службы
CC.2.8.3.1. Метод поиска рабочего списка
CC.2.8.4. Коды состояния
CC.3. SOP-классы UPS
CC.3.1. UID классов служб и SOP-классов
CC.3.1.1. Следствия DIMSE для UPS (Информативное)
CC.3.1.2. UID глобальной подписки на экземпляры
CC.3.2. Согласование ассоциации
CC.4. Требования к соответствию
CC.4.1. Соответствие SCU
CC.4.1.1. Операции
CC.4.2. Соответствие SCP
CC.4.2.1. Операции
DD. Классы служб верификации RT-аппарата
DD.1. Область применения
DD.2. Модель верификации RT-аппарата
DD.2.1. Поток данных верификации RT-аппарата
DD.3. Определения SOP-классов верификации аппарата
DD.3.1. Описание IOD
DD.3.2. Группа служб DIMSE
DD.3.2.1. N-CREATE и N-SET
DD.3.2.1.1. Атрибуты
DD.3.2.1.1.1. Модификаторы пучка
DD.3.2.1.2. Состояние
DD.3.2.1.3. Поведение
DD.3.2.1.3.1. N-CREATE
DD.3.2.1.3.2. N-SET
DD.3.2.2. N-GET
DD.3.2.2.1Verification. Макрос атрибута селектора параметров
DD.3.2.2.2. Атрибуты
DD.3.2.2.3. Состояние
DD.3.2.2.4. Поведение
DD.3.2.3. N-ACTION
DD.3.2.3.1. Атрибуты
DD.3.2.3.2. Состояние
DD.3.2.3.3. Поведение
DD.3.2.4. N-DELETE
DD.3.2.4.1. Атрибуты
DD.3.2.4.2. Состояние
DD.3.2.4.3. Поведение
DD.3.2.5. N-EVENT-REPORT
DD.3.2.5.1. Атрибуты
DD.3.2.5.2. Состояние
DD.3.2.5.3. Поведение
EE. Класс службы управления системой отображения
EE.1. Область применения
EE.2. SOP-класс системы отображения
EE.2.1. Описание IOD
EE.2.2. Группа служб DIMSE
EE.2.2.1. N-GET
EE.2.2.1.1. Атрибуты
EE.2.2.1.1.1. Макросы подсистемы отображения
EE.2.2.1.1.2. Требования к атрибутам N-GET системы отображения
EE.2.2.1.2. Поведение SCU
EE.2.2.1.3. Поведение SCP
EE.2.3. Определения SOP-классов и UID
EE.2.4. Зарезервированные идентификаторы
EE.3. Соответствие
EE.3.1. Заявление о соответствии
FF. SOP-классы хранения состояний объёмного представления
FF.1. Обзор
FF.1.1. Область применения
FF.2. Процессы преобразования объёма
FF.2.1. Объёмные преобразования
FF.2.1.1. Объёмные преобразования планарного MPR
FF.2.1.2. Объёмные преобразования объёмного рендеринга
FF.2.1.2.1. Конвейеры объёмного рендеринга
FF.2.1.2.2. Компонент объёмного рендеринга
FF.2.1.2.3. Компонент графической проекции
FF.2.2. Объёмные входные данные, регистрация и кадрирование
FF.2.3. Отображение состояния объёмного представления
FF.2.3.1. Обзор отображения состояния объёмного представления
FF.2.3.2. Описание компонентов отображения
FF.2.3.2.1. Компоненты классификации
FF.2.3.2.2. Компоненты композиции
FF.2.3.3. Внутренняя структура компонентов
FF.2.3.3.1. Внутренняя структура компонентов классификации
FF.2.3.3.2. Внутренняя структура RGB- и RGBA-компонентов композиции
FF.2.4. Дополнительные объёмные аспекты
FF.2.4.1. Аннотации в состояниях объёмного представления
FF.2.4.2. Объёмная анимация
FF.2.4.2.1. Анимация входной последовательности
FF.2.4.2.2. Анимация последовательности представления
FF.2.4.2.3. Анимация Crosscurve
FF.2.4.2.4. Анимация пролёта
FF.2.4.2.5. Анимация вращения
FF.2.5. Макет отображения
FF.3. Поведение SCP
FF.4. Соответствие
FF.4.1. Заявление о соответствии для SCU
FF.4.2. Заявление о соответствии для SCP
GG. Класс службы хранения непациентных объектов
GG.1. Обзор
GG.1.1. Область применения
GG.1.2. Определение службы
GG.2. Согласование ассоциации
GG.3. SOP-классы
GG.4. Поведение
GG.4.1. Пользователь класса службы
GG.4.2. Поставщик класса службы
GG.5. Требования к заявлению о соответствии
GG.5.1. Требования к соответствию SCU
GG.5.2. Требования к соответствию SCP
GG.6. Поведение приложения для стандартных SOP-классов
GG.6.1. SOP-класс хранения протокола размещения
GG.6.1.1. Создатель экземпляра
GG.6.1.2. Приложение отображения
GG.6.2. SOP-класс хранения цветовой палитры
GG.6.2.1. Создатель экземпляра
GG.6.2.2. Приложение отображения
GG.6.3. SOP-классы хранения шаблонов
GG.6.4. SOP-класс хранения протокола определённой процедуры CT и XA
GG.6.5. SOP-класс хранения утверждения протокола
GG.6.6. SOP-класс хранения инвентаризации
GG.6.6.1. Создатель экземпляра
HH. Классы служб запроса/извлечения протоколов определённых процедур
HH.1. Обзор
HH.1.1. Область применения
HH.1.2. Условные обозначения
HH.1.3. Информационная модель запроса/извлечения
HH.1.4. Определение службы
HH.2. Определения информационных моделей протоколов определённых процедур
HH.3. Информационные модели протоколов определённых процедур
HH.4. Группы служб DIMSE-C
HH.4.1. Операция C-FIND
HH.4.1.1. Поведение пользователя класса службы
HH.4.1.2. Поведение поставщика класса службы
HH.4.2. Операция C-MOVE
HH.4.3. Операция C-GET
HH.5. Согласование ассоциации
HH.6. Определения SOP-классов
HH.6.1. Информационная модель протоколов определённых процедур
HH.6.1.1. Модели E/R
HH.6.1.2. Атрибуты протоколов определённых процедур
HH.6.1.3. Требования к соответствию
HH.6.1.3.1. Соответствие SCU
HH.6.1.3.1.1. Соответствие SCU C-FIND
HH.6.1.3.1.2. Соответствие SCU C-MOVE
HH.6.1.3.1.3. Соответствие SCU C-GET
HH.6.1.3.2. Соответствие SCP
HH.6.1.3.2.1. Соответствие SCP C-FIND
HH.6.1.3.2.2. Соответствие SCP C-MOVE
HH.6.1.3.2.3. Соответствие SCP C-GET
HH.6.1.4. SOP-классы
II. Классы служб запроса/извлечения утверждений протоколов
II.1. Обзор
II.1.1. Область применения
II.1.2. Условные обозначения
II.1.3. Информационная модель запроса/извлечения
II.1.4. Определение службы
II.2. Определения информационных моделей утверждений протоколов
II.3. Информационные модели утверждений протоколов
II.4. Группы служб DIMSE-C
II.4.1. Операция C-FIND
II.4.1.1. Поведение пользователя класса службы
II.4.1.2. Поведение поставщика класса службы
II.4.2. Операция C-MOVE
II.4.3. Операция C-GET
II.5. Согласование ассоциации
II.6. Определения SOP-классов
II.6.1. Информационная модель утверждений протоколов
II.6.1.1. Модели E/R
II.6.1.2. Атрибуты утверждений протоколов
II.6.1.3. Требования к соответствию
II.6.1.3.1. Соответствие SCU
II.6.1.3.1.1. Соответствие SCU C-FIND
II.6.1.3.1.2. Соответствие SCU C-MOVE
II.6.1.3.1.3. Соответствие SCU C-GET
II.6.1.3.2. Соответствие SCP
II.6.1.3.2.1. Соответствие SCP C-FIND
II.6.1.3.2.2. Соответствие SCP C-MOVE
II.6.1.3.2.3. Соответствие SCP C-GET
II.6.1.4. SOP-классы
JJ. Класс службы запроса/извлечения инвентаризации
JJ.1. Обзор
JJ.1.1. Область применения
JJ.1.2. Условные обозначения
JJ.1.3. Определение службы
JJ.2. Информационная модель Q/R инвентаризации
JJ.2.1. Модель E-R
JJ.2.2. Атрибуты информационной модели Q/R инвентаризации
JJ.3. Группы служб DIMSE-C
JJ.3.1. Операция C-FIND
JJ.3.2. Операция C-MOVE
JJ.3.3. Операция C-GET
JJ.4. Определения SOP-классов
JJ.4.1. SOP-классы
JJ.4.2. Требования к соответствию
JJ.4.2.1. Соответствие SCU
JJ.4.2.1.1. Соответствие SCU C-FIND
JJ.4.2.1.2. Соответствие SCU C-MOVE
JJ.4.2.1.3. Соответствие SCU C-GET
JJ.4.2.2. Соответствие SCP
JJ.4.2.2.1. Соответствие SCP C-FIND
JJ.4.2.2.2. Соответствие SCP C-MOVE
JJ.4.2.2.3. Соответствие SCP C-GET
KK. Класс службы управления хранилищем
KK.1. Обзор
KK.1.1. Сценарии использования
KK.1.2. SOP-классы
KK.1.2.1. Группа служб DIMSE
KK.1.2.2. Определения информационных объектов
KK.1.3. Протокол службы
KK.1.3.1. Согласование ассоциации
KK.1.3.2. Операции и уведомления
KK.2. SOP-класс создания инвентаризации
KK.2.1. Обзор
KK.2.1.1. Состояния производства инвентаризации
KK.2.2. Операции
KK.2.2.1. Информация о действии
KK.2.2.1.1. Область последовательности инвентаризации
KK.2.2.1.2. Уровень инвентаризации
KK.2.2.2. Поведение пользователя класса службы
KK.2.2.3. Поведение поставщика класса службы
KK.2.3. Уведомления
KK.2.3.1. Информация о событии
KK.2.3.1.1. Инвентаризация завершена с экземплярами
KK.2.3.2. Поведение поставщика класса службы
KK.2.3.3. Поведение пользователя класса службы
KK.2.4. Соответствие
KK.2.4.1. Соответствие SCU
KK.2.4.1.1. Операции
KK.2.4.1.2. Уведомления
KK.2.4.2. Соответствие SCP
KK.2.4.2.1. Операции
KK.2.4.2.2. Уведомления

Список рисунков

5-1. Соглашение об объектах
5-2. Соглашение о связях
6-1. Основные структуры информационной модели DICOM
C.5-1. Пример ролей SCU/SCP подоперации
C.5-2. Пример согласования извлечения (C-GET)
C.6-1. E-R-диаграмма информационной модели запроса/извлечения на уровне пациента
C.6-2. E-R-диаграмма информационной модели запроса/извлечения на уровня исследования
H.2-1. Модель потока данных управления печатью
H.2-2. Модель потока данных управления печатью
H.2-3. Структура класса службы управления печатью
H.2-4. Конфигурации для печати на нескольких принтерах
K.6-1. E-R-диаграмма информационной модели рабочего списка модальности
N.2-1. Модели преобразования полутоновых и цветных изображений
N.2-2. Общая модель пространственного преобразования и аннотаций
N.2-3. Модель преобразования наложения полутонового на цветное
N.2.5-1. Модель преобразования полутоновых изображений XA/XRF
N.2.6-1. Применение цвета и порога
N.2.6-2. Наложение переднего плана
N.2.6-3. Равное наложение
Q.4-1. E/R-модель релевантной информации о пациенте
U.6-1. E-R-диаграмма информационной модели протокола размещения
V.6-1. E-R-диаграмма характеристик продукта
V.6-2. E-R-диаграмма утверждения вещества
X.6-1. E-R-диаграмма информационной модели цветовой палитры
Y.6-1. E-R-диаграмма информационной модели извлечения на уровне корня составных экземпляров
Z.3.1-1. E-R-диаграмма информационной модели извлечения без массивов данных
BB.6-1. E-R-диаграмма информационной модели шаблонов имплантатов
BB.6-2. E-R-диаграмма информационной модели шаблонов сборки имплантатов
BB.6-3. E-R-диаграмма информационной модели группы шаблонов имплантатов
CC.1.1-1. Диаграмма состояний единого этапа процедуры
CC.2.8-1. E-R-диаграмма единого этапа процедуры
DD.2-1. Поток данных RT-верификации
EE.1-1. Поток данных управления системой отображения
FF.2-1. Конвейер планарного MPR полутонового объёма
FF.2-2. Конвейер композиции планарного MPR объёма
FF.2.1.2.1-1. Конвейер объёмного рендеринга
FF.2.1.2.1-2. Сегментированный конвейер объёмного рендеринга
FF.2.1.2.1-3. Многократный конвейер объёмного рендеринга
FF.2-3. Один вход -> RGBA-компонент
FF.2-4. Два входа ->RGBA-компонент
FF.2-5. RGB-компонент композиции
FF.2.3.2.2-2. RGBA-компонент композиции
FF.2-6. Внутренняя структура компонента «Один вход -> RGBA»
FF.2-7. Внутренняя структура компонента «Два входа -> RGBA»
FF.2-8. Внутренняя структура RGB-компонента композиции
FF.2.3.3.2-1. Внутренняя структура RGB-компонента композиции с непрозрачностью
FF.3.2-1. Анимация входной последовательности
FF.3.2-2. Анимация последовательности представления
FF.3.2-3. Анимация Crosscurve
FF.2.4.2.4-1. Анимация пролёта
HH.6-1. E-R-диаграмма информационной модели протоколов определённых процедур
II.6-1. E-R-диаграмма информационной модели утверждений протоколов
JJ.2-1. E-R-диаграмма информационной модели Q/R инвентаризации
KK.2-1. Состояния производства инвентаризации и переходы состояний

Список таблиц

8-1a. Расширенный макрос кодируемых записей SCU/SCP с поддержкой SCU, поддержкой ключа сопоставления и обязательным значением
8-1b. Базовый макрос кодируемых записей SCU/SCP с поддержкой SCU, поддержкой ключа сопоставления и обязательным значением
8-2a. Расширенный макрос кодируемых записей с опциональной поддержкой ключа сопоставления и опциональным значением
8-2b. Базовый макрос кодируемых записей с опциональной поддержкой ключа сопоставления и опциональным значением
8-3a. Расширенный макрос кодируемых записей SCU/SCP без поддержки SCU и без поддержки ключа сопоставления
8-3b. Базовый макрос кодируемых записей SCU/SCP без поддержки SCU и без поддержки ключа сопоставления
8-4a. Расширенный макрос кодируемых записей с опциональной поддержкой ключа сопоставления и обязательным значением
8-4b. Базовый макрос кодируемых записей с опциональной поддержкой ключа сопоставления и обязательным значением
8-5a. Расширенный макрос кодируемых записей SCU/SCP без поддержки SCU и опциональным значением для SCP
8-5b. Базовый макрос кодируемых записей SCU/SCP без поддержки SCU и опциональным значением для SCP
B.2-1. Значения состояния ответа C-STORE
B.3-1. Информация приложения класса службы (A-ASSOCIATE-RQ)
B.3-2. Информация приложения класса службы (A-ASSOCIATE-AC)
B.3-3. Стандартные и связанные общие SOP-классы
B.4-1. Атрибуты, подлежащие принудительному преобразованию
B.5-1. Стандартные SOP-классы
B.6-1. Снятые стандартные SOP-классы
C.1.2-1. Соглашения о типах ключей для информационных моделей запроса/извлечения
C.3-1. Дополнительные атрибуты запроса/извлечения
C.3.5-1. Преобразования SOP-классов для конкретных модальностей
C.4-1. Значения состояния ответа C-FIND
C.4-2. Значения состояния ответа C-MOVE
C.4-3. Значения состояния ответа C-GET
C.5-1. Подэлемент расширенного согласования SOP-класса (поле информации приложения класса службы) - A-ASSOCIATE-RQ
C.5-2. Подэлемент расширенного согласования SOP-класса (поле информации приложения класса службы) - A-ASSOCIATE-AC
C.5-3. Подэлемент расширенного согласования SOP-класса (поле информации приложения класса службы) - A-ASSOCIATE-RQ
C.5-4. Подэлемент расширенного согласования SOP-класса (поле информации приложения класса службы) - A-ASSOCIATE-AC
C.6.1-1. Значения уровня запроса/извлечения на уровне пациента
C.6-1. Атрибуты уровня пациента для информационной модели запроса/извлечения на уровне пациента
C.6-2a. Расширенный макрос ключей значения кода с опциональными ключами
C.6-2b. Базовый макрос ключей значения кода с опциональными ключами
C.6-2. Ключи уровня исследования для информационной модели запроса/извлечения на уровне пациента
C.6-3. Атрибуты уровня серии для информационной модели запроса/извлечения на уровне пациента
C.6-4. Ключи уровня составных экземпляров объектов для информационной модели запроса/извлечения на уровне пациента
C.6.1.3-1. SOP-классы для запроса/извлечения на уровне пациента
C.6.2-1. Значения уровня запроса/извлечения на уровне исследования
C.6-5. Ключи уровня исследования для информационной модели запроса/извлечения на уровне исследования
C.6.2.3-1. SOP-классы для запроса/извлечения на уровне исследования
C.6.4.1-1. Дополнительные ключи для запроса к репозиторию
C.6.4.2-1. Дополнительные атрибуты идентификатора запроса к репозиторию
C.6.4.3-1. Дополнительные значения состояния запроса к репозиторию
C.6.4.7-1. SOP-классы для запроса к репозиторию
F.1-3. Состояния выполненного этапа процедуры модальности
F.1-4. Диаграмма переходов состояний выполненного этапа процедуры модальности
F.7.1-1. Группа служб DIMSE, применимая к выполненному этапу процедуры модальности
F.7.2-1a. Расширенный макрос значения кода выполненного этапа процедуры модальности без N-SET
F.7.2-1b. Простой макрос значения кода выполненного этапа процедуры модальности без N-SET
F.7.2-1c. Расширенный макрос значения кода выполненного этапа процедуры модальности с N-SET, обязательным значением
F.7.2-1d. Простой макрос значения кода выполненного этапа процедуры модальности с N-SET, обязательным значением
F.7.2-1e. Расширенный макрос значения кода выполненного этапа процедуры модальности с N-SET, опциональным значением
F.7.2-1f. Простой макрос значения кода выполненного этапа процедуры модальности с N-SET, опциональным значением
F.7.2-1. Атрибуты N-CREATE, N-SET и конечного состояния SOP-класса выполненного этапа процедуры модальности
F.7.2-2. Значения состояния ответа N-SET
F.8.1-1. Группа служб DIMSE, применимая к извлечению выполненного этапа процедуры модальности
F.8.2-1. Атрибуты N-GET SOP-класса извлечения выполненного этапа процедуры модальности
F.8.2-2. Значения состояния ответа N-GET
F.9.1-1. Группа служб DIMSE, применимая к уведомлению выполненного этапа процедуры модальности
F.9.2-1. Информация о событии уведомления выполненного этапа процедуры
H.3.2.2.1-1. SOP-классы базового метасправочника SOP управления полутоновой печатью
H.3.2.2.2-1. SOP-классы базового метасправочника SOP управления цветной печатью
H.3.3.2-1. Список опциональных SOP-классов для базовых метасправочников SOP управления печатью
H.4-1. Группа служб DIMSE, применимая к базовому сеансу плёнки
H.4-2. Список атрибутов N-CREATE
H.4.1.2.1.2-1. Значения состояния для SOP-класса базового сеанса плёнки
H.4-3. Аргументы N-ACTION
H.4-4. Значения состояния SOP-класса
H.4-5. Группа служб DIMSE, применимая к базовому блоку плёнки
H.4-6. Список атрибутов N-CREATE
H.4.2.2.1.2-1. Значения состояния для SOP-класса базового блока плёнки
H.4-7. Атрибуты N-SET
H.4-8. Аргументы N-ACTION
H.4-9. Значения состояния
H.4.3.1.2-1. Группа служб DIMSE, применимая к базовому блоку полутонового изображения
H.4-10. Атрибуты N-SET
H.4.3.1.2.1.2-1. Значения состояния для SOP-класса базового блока полутонового изображения
H.4.3.2.2-1. Группа служб DIMSE, применимая к базовому блоку цветного изображения
H.4-11. Атрибуты N-SET
H.4.3.2.2.1.2-1. Значения состояния для SOP-класса базового блока цветного изображения
H.4.4.2-1. Группа служб DIMSE, применимая к базовому блоку аннотаций
H.4-13. Атрибуты N-SET
H.4.5.2-1. Группа служб DIMSE, применимая к заданию печати
H.4-14. Информация о событии уведомления
H.4-15. Атрибуты N-GET
H.4.6.2-1. Группа служб DIMSE, применимая к принтеру
H.4-16. Информация о событии уведомления
H.4-17. Атрибуты N-GET
H.4.9.2-1. Группа служб DIMSE, применимая к LUT представления
H.4-23. Список атрибутов N-CREATE
H.4.9.2.1.2-1. Значения состояния для SOP-класса LUT представления
H.4.11.2-1. Группа служб DIMSE, применимая к извлечению конфигурации принтера
H.4-26. Атрибуты N-GET
I.3-1. Разрешённые комбинации ролей
I.4-1. Стандартные SOP-классы хранения на носителях
J.3.1-1. Группа служб DIMSE, применимая к модели принудительного подтверждения хранения
J.3-1. Запрос подтверждения хранения - информация о действии
J.3-2. Результат подтверждения хранения - информация о событии
K.4-1. Значения состояния ответа C-FIND
K.5.1-1. Подэлемент расширенного согласования SOP-класса (поле информации приложения класса службы) - A-ASSOCIATE-RQ
K.5.1-2. Подэлемент расширенного согласования SOP-класса (поле информации приложения класса службы) - A-ASSOCIATE-AC
K.6-1. Атрибуты для информационной модели рабочего списка модальности
K.6-1a. Атрибуты для идентификатора C-FIND рабочего списка модальности
K.6.1.4-1. SOP-класс рабочего списка модальности
N.2.5.1-1. Краткое описание предоставления функции LUT для вычитания
P.2-1. Группа служб DIMSE, применимая к регистрации процедурных событий
P.2-2. Информация о действии регистрации процедурных событий
P.2-3. Состояние ответа
P.2-4. Ответ на действие регистрации процедурных событий
P.3-1. Группа служб DIMSE, применимая к регистрации введения веществ
P.3-2. Информация N-ACTION регистрации введения веществ
P.3-3. Состояние ответа
Q.2-1. Значения состояния ответа C-FIND
Q.4-1. Атрибуты для модели релевантной информации о пациенте
Q.4-2. Дополнительные атрибуты идентификатора C-FIND
Q.4-3. SOP-классы для модели релевантной информации о пациенте
R.3.1-1. Группа служб DIMSE, применимая к уведомлению о доступности экземпляров
R.3.2-1. Атрибуты N-CREATE SOP-класса уведомления о доступности экземпляров
S.3.1-1. Группа служб DIMSE, применимая к управлению созданием носителей
S.3.2.1.1-1. Управление созданием носителей - атрибуты N-CREATE
S.3.2.2.4-1. Значения состояния SOP-класса
S.3.2.2.1-1. Запрос создания носителя - информация о действии
S.3.2.3.1-1. Запрос создания носителя - информация о действии
S.3.2.3.4-1. Состояния ответа
S.3.2.4.1-1. Атрибуты N-GET SOP-класса управления созданием носителей
S.3.2.4.4-1. Состояния ответа
U.6-1. Атрибуты для информационной модели протокола размещения
U.6.1.4-1. SOP-классы протокола размещения
V.4-1. Значения состояния ответа C-FIND
V.6-1. Атрибуты для информационной модели запроса характеристик продукта
V.6.1.4-1. SOP-классы запроса характеристик продукта
V.6-2. Атрибуты для информационной модели запроса утверждений веществ
V.6.2.4-1. SOP-классы запроса утверждений веществ
X.6-1. Атрибуты для информационной модели цветовой палитры
X.6.1.4-1. SOP-классы цветовой палитры
Y.4-1. Значения состояния ответа C-MOVE для извлечения на уровне корня составных экземпляров
Y.4-2. Значения состояния ответа C-GET для извлечения на уровне корня составных экземпляров
Y.5.1-1. Подэлемент расширенного согласования SOP-класса (поле информации приложения класса службы) - A-ASSOCIATE-RQ
Y.5.1-2. Подэлемент расширенного согласования SOP-класса (поле информации приложения класса службы) - A-ASSOCIATE-AC
Y.6.1-1. Значения уровня извлечения на уровне корня составных экземпляров
Y.6-1. Ключи уровня составного экземпляра для информационной модели извлечения на уровне корня составных экземпляров
Y.6-2. Ключи уровня кадра для информационной модели извлечения на уровне корня составных экземпляров
Y.6.1.3-1. SOP-классы извлечения на уровне корня составных экземпляров
Z.1-1. Атрибуты, не включаемые в отправляемые экземпляры
Z.4-1. Значения состояния ответа C-GET для извлечения составных экземпляров без массивов данных
Z.6.1-1. Значение уровня извлечения составных экземпляров без массивов данных
Z.6-1. Ключи уровня составного экземпляра для информационной модели извлечения составных экземпляров без массивов данных
Z.6.1.3-1. SOP-классы извлечения составных экземпляров без массивов данных
BB.6-1. Атрибуты для информационной модели шаблонов имплантатов
BB.6-2. Атрибуты для информационной модели шаблонов сборки имплантатов
BB.6-3. Атрибуты для информационной модели группы шаблонов имплантатов
BB.6.1.4-1. SOP-классы шаблонов имплантатов
CC.1.1-1. Состояния единого этапа процедуры (UPS)
CC.1.1-2. Таблица переходов состояний единого этапа процедуры
CC.2-1. Группа служб DIMSE, применимая к UPS Push
CC.2-2. Группа служб DIMSE, применимая к UPS Pull
CC.2-3. Группа служб DIMSE, применимая к UPS Watch
CC.2-4. Группа служб DIMSE, применимая к событиям UPS
CC.2-5. Группа служб DIMSE, применимая к запросу UPS
CC.2.1-1. Изменение состояния UPS - информация о действии
CC.2.1-2. Значения состояния ответа N-ACTION [для изменения состояния UPS]
CC.2.2-1. Запрос отмены UPS - информация о действии
CC.2.2-2. Значения состояния ответа N-ACTION [для запроса отмены UPS]
CC.2.3-1. Подписка/отписка на получение отчётов о событиях UPS - информация о действии
CC.2.3-2. Таблица переходов состояний подписки UPS
CC.2.3-3. Значения состояния ответа N-ACTION [для подписки/отписки на получение отчётов о событиях UPS]
CC.2.4-1. Сообщение об изменении состояния UPS - информация отчёта о событии
CC.2.5-1. Коды конечного состояния
CC.2.5-2a. Макрос последовательности кодов UPS
CC.2.5-2b. Макрос элемента содержимого UPS
CC.2.5-2c. Макрос ссылочных экземпляров и доступа
CC.2.5-2d. Макрос иерархического идентификатора HL7V2
CC.2.5-2f. Макрос ссылок на экземпляры SOP
CC.2.5-2g. Макрос хранения
CC.2.5-2h. Макрос квалификаторов эмитента идентификатора пациента
CC.2.5-3. Атрибуты N-CREATE/N-SET/N-GET/C-FIND SOP-класса UPS
CC.2.5-4. Значения состояния ответа N-CREATE [для создания единого этапа процедуры]
CC.2.6-1. Значения состояния ответа N-SET [для установки информации единого этапа процедуры]
CC.2.7-1. Значения состояния ответа N-GET [для получения информации единого этапа процедуры]
CC.2.8-2. Значения состояния ответа C-FIND [для поиска единого этапа процедуры]
DD.3.2-1. Группа служб DIMSE, применимая к верификации аппарата
DD.3.2.1-1. Список атрибутов N-CREATE и N-SET - SOP-класс верификации обычного RT-аппарата
DD.3.2.1-2. Список атрибутов N-CREATE и N-SET - SOP-класс верификации ионного RT-аппарата
DD.3.2.1.2-1. Значения состояния N-CREATE SOP-класса верификации ионного RT-аппарата
DD.3.2.1.2-2. Значения состояния N-SET SOP-класса верификации ионного RT-аппарата
DD.3.2.2.1-1. Макрос атрибута селектора параметров верификации
DD.3.2.2.2-1. Список атрибутов N-GET - SOP-класс верификации обычного RT-аппарата и SOP-класс верификации ионного RT-аппарата
DD.3.2.2.3-1. Значения состояния N-GET SOP-классов верификации обычного и ионного RT-аппарата
DD.3.2.3-1. Информация о событии действия
DD.3.2.3-2. Значения состояния N-ACTION SOP-классов верификации обычного и ионного RT-аппарата
DD.3.2.5-1. Информация о событии уведомления
EE.2.2-1. Группа служб DIMSE, применимая к системе отображения
EE.2.2.1-1. Макрос контекста результата таблицы
EE.2.2.1-2. Атрибуты N-GET системы отображения
GG.3-1. Стандартные SOP-классы
GG.4-1. Значения состояния ответа C-STORE
HH.6-1. Атрибуты для информационной модели протоколов определённых процедур
HH.6.1.4-1. SOP-классы протоколов определённых процедур
II.6-1. Атрибуты для информационной модели утверждений протоколов
II.6.1.4-1. SOP-классы утверждений протоколов
JJ.2-1. Атрибуты для информационной модели Q/R инвентаризации
JJ.4-1. SOP-классы службы Q/R инвентаризации
JJ.4-2. Дополнительные возвращаемые атрибуты FIND инвентаризации
KK.1-1. Группа служб DIMSE, применимая к управлению хранилищем
KK.1-2. SOP-классы службы управления хранилищем
KK.1-3. UID экземпляра SOP управления хранилищем
KK.2-1. Запросы создания инвентаризации - информация о действии
KK.2.2.3-1. Значения состояния ответа N-ACTION
KK.2-2. Ответы создания инвентаризации - информация о событии

Уведомление и отказ от ответственности

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

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

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

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

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

Предисловие

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

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

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

HL7® и CDA® являются зарегистрированными товарными знаками Health Level Seven International, все права защищены.

SNOMED®, SNOMED Clinical Terms®, SNOMED CT® являются зарегистрированными товарными знаками International Health Terminology Standards Development Organisation (IHTSDO), all rights reserved.

LOINC® является зарегистрированным товарным знаком Regenstrief Institute, Inc, все права защищены.

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

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

  • семантическое описание действий из определения класса сервиса

  • группу операций и уведомлений сервиса DIMSE, применимых к описанию класса сервиса

  • один или более функционально связанных классов Service-Object Pair (SOP), которые поддерживаются определением класса сервиса и могут выполняться между равноправными прикладными сущностями DICOM

  • связь каждого класса Service-Object Pair (SOP) с применимыми Определениями информационных объектов, указанными в PS3.3.

Для каждого определения класса сервиса в данной Части не указывается:

  • любая необходимая информация для семантического описания IOD

  • связи с ассоциированными объектами реального мира, относящимися к IOD

  • Атрибуты, описывающие характеристики IOD

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

  • PS3.3 Information Object Definitions определяет набор Определений информационных объектов, к которым могут быть применены сервисы, определённые в данной Части

  • PS3.5 Data Structure and Semantics определяет кодирование данных, используемое в протоколе DIMSE при применении к IOD, определённым в данной Части

  • PS3.6 Data Dictionary содержит индекс по Тегу всех Атрибутов IOD, определённых в данной Части. Этот индекс включает Представление значения и Кратность значения для каждого Атрибута

  • PS3.7 Message Exchange Protocol определяет сервисы и протокол DIMSE, которые могут быть применены к IOD, определённым в данной Части.

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

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

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

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

[RFC3986] IETF. Uniform Resource Identifiers (URI): Generic Syntax. http://tools.ietf.org/html/rfc3986 .

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

[RFC7230] IETF. June 2014. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. http://tools.ietf.org/html/rfc7230 .

[Porter and Duff 1984] Computer Graphics. Porter, Thomas and Duff, Tom. 1984. 18. 3. 253-259. “Compositing Digital Images”. doi:10.1145/800031.808606 http://keithp.com/~keithp/porterduff/p253-porter.pdf .

[ISO 19980] ISO. 2012. second edition. Ophthalmic instruments - Corneal topographers.

[IHE RAD TF-1] IHE International. 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] IHE International. Integrating the Healthcare Enterprise Radiology Technical Framework Volume 2 Transactions. http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf .

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

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

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

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

Application Entity

См. [ISO 7498-1].

Service

См. [ISO 7498-1].

Application Entity Title (AET)

См. [ISO 7498-1].

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

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

Primitive

См. [ISO/TR 8509].

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

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

Attribute

См. Attribute в PS3.1 .

Command

См. Command в PS3.1 .

Data Dictionary

См. Data Dictionary в PS3.1 .

Information Object

См. Information Object в PS3.1 .

Message

См. Message в PS3.1 .

Service-Object Pair Class (SOP Class)

См. Service-Object Pair Class в PS3.1 .

3.4 Определения сервиса верхнего уровня DICOM

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

DICOM Upper Layer Service

См. DICOM Upper Layer Service в PS3.8 .

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

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

Элемент службы сообщений DICOM (DIMSE)

См. Элемент службы сообщений DICOM в PS3.7 .

DIMSE-N Services

См. DIMSE-N Services в PS3.7 .

DIMSE-C Services

См. DIMSE-C Services в PS3.7 .

DIMSE Service Group (DSG)

См. DIMSE Service Group в PS3.7 .

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

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

Attribute Tag

См. Attribute Tag в PS3.3 .

Blending Presentation State

См. Blending Presentation State в PS3.3 .

Composite IOD

См. Composite IOD в PS3.3 .

DICOM Application Model

См. DICOM Application Model в PS3.3 .

DICOM Information Model

См. DICOM Information Model в PS3.3 .

Functional Group

См. Functional Group в PS3.3 .

Information Object Definition (IOD)

См. Information Object Definition в PS3.3 .

Module

См. Module в PS3.3 .

Normalized IOD

См. Normalized IOD в PS3.3 .

Presentation State

См. Presentation State в PS3.3 .

3.7 Соответствие DICOM

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

Conformance Statement

См. Conformance Statement в PS3.2 .

Standard SOP Class

См. Standard SOP Class в PS3.2 .

Specialized SOP Class

См. Specialized SOP Class в PS3.2 .

Standard Extended SOP Class

См. Standard Extended SOP Class в PS3.2 .

Private SOP Class

См. Private SOP Class в PS3.2 .

Standard Attribute

См. Standard Attribute в PS3.2 .

Private Attribute

См. Private Attribute в PS3.2 .

3.8 Структуры и кодирование данных DICOM

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

Data Element

См. Data Element в PS3.5 .

Data Set

См. Data Set в PS3.5 .

Default Character Repertoire

См. Default Character Repertoire в PS3.5 .

QUOTATION MARK

См. QUOTATION MARK в PS3.5 .

Unique Identifier (UID)

См. Unique Identifier в PS3.5 .

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

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

Classic Image Storage SOP Class

Класс SOP хранения изображений, который определяется IOD, сохраняющим одиночный кадр и определяющим большинство Атрибутов в Data Set верхнего уровня.

Combined Print Image

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

Enhanced Image Storage SOP Class

Класс SOP хранения изображений, который определяется IOD, сохраняющим множество кадров и определяющим большинство Атрибутов в Functional Group Sequences.

Legacy Converted Enhanced Image Storage SOP Class

Специализированный для модальности класс SOP хранения изображений Enhanced, который определяется IOD, определяющим только типовые Functional Group Sequences, не требующим информации, отсутствующей в экземплярах класса Classic Image Storage SOP Class, и предназначенным для хранения преобразованных экземпляров класса Classic Image Storage SOP Class, когда недостаточно информации для использования класса True Enhanced Image Storage SOP Class.

Meta Service-Object Pair Class (Meta SOP Class)

Заранее определённый набор классов SOP, который может быть ассоциирован под единым SOP с целью согласования использования набора с помощью одного элемента.

Non-Patient Object

Экземпляр SOP, который соответствует информационной модели Composite Instance IOD, указанной в PS3.3, но не имеет сущности Patient Information в качестве корня. Экземпляры SOP Non-Patient Object могут по-прежнему содержать связанную с пациентом идентифицируемую информацию, например, экземпляры SOP Inventory

Performed Procedure Step SOP Class

Любой класс SOP, кодирующий сведения о выполнении этапа процедуры.

Performed Procedure Step SOP Instance

Экземпляр класса Performed Procedure Step SOP Class. Следует отметить, что все экземпляры UPS являются экземплярами класса UPS Push SOP Class, который способен кодировать сведения о выполнении этапа процедуры (в дополнение к сведениям о запланированном этапе процедуры) и, таким образом, квалифицируется как экземпляр класса Performed Procedure Step SOP Class.

Preformatted Grayscale Image

Изображение, в котором все аннотации, графика и преобразования оттенков серого (включая VOI LUT), ожидаемые в печатаемом изображении, были вшиты или применены до отправки на SCP. Это отображаемое изображение, в котором полярность предполагаемого отображения задаётся атрибутом Photometric Interpretation (0028,0004).

Preformatted Color Image

Изображение, в котором все аннотации, графика и преобразования цвета, ожидаемые в печатаемом изображении, были вшиты или применены до отправки на SCP.

Real-World Activity

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

Real-World Object

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

Related General SOP Class

Класс SOP, который связан с другим классом SOP как более обобщённый с точки зрения поведения, определённого в Стандарте, и который может использоваться для идентичного кодирования экземпляра с теми же Атрибутами и значениями, за исключением SOP Class UID. В частности, это может быть класс SOP, из которого выведен Specialized SOP Class (см. PS3.2).

Service Class User (SCU)

Роль, которую играет прикладная сущность DICOM (DIMSE-Service-User), инициирующая операции и выполняющая уведомления в конкретной Ассоциации.

Service Class Provider (SCP)

Роль, которую играет прикладная сущность DICOM (DIMSE-Service-User), выполняющая операции и инициирующая уведомления в конкретной Ассоциации.

Service Class

Совокупность классов SOP и/или Meta SOP Classes, связанных тем, что они описываются совместно для выполнения единого приложения.

Service-Object Pair Instance (SOP Instance)

Конкретное воплощение информационного объекта, которым управляет прикладная сущность DICOM и над которым могут выполняться операции в контексте связи, определённом конкретным набором сервисов DIMSE (по сети или на носителях обмена). Экземпляр SOP сохраняется за пределами контекста своего обмена.

True Enhanced Image Storage SOP Class

Специализированный для модальности класс SOP хранения изображений Enhanced, который определяется IOD, определяющим специализированные для модальности Functional Group Sequences, Атрибуты и наборы значений, и предназначен для создания устройствами съёма.

3.10 Значения пикселей, не зависящие от устройства

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

P-Value

См. P-Value в PS3.3 .

Profile Connection Space Value (PCS-Value)

См. Profile Connection Space Value в PS3.3 .

3.11 Определения HTTP

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

origin server

См. [RFC7230].

user agent

См. [RFC7230].

3.12 Определения структурированных отчётов

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

Content Item

См. Content Item в PS3.3 .

Content Tree

См. Content Tree в PS3.3 .

3.13 Определения кодов и контролируемой терминологии

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

Coding Scheme

См. Coding Scheme в PS3.16 .

4 Условные обозначения и сокращения

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

ACR

Американский колледж радиологии

ASCII

Американский стандартный код обмена информацией

AE

Прикладная сущность

ANSI

Американский национальный институт стандартов

CDS

Поддержка клинических решений

CEN TC251

Comité Européen de Normalisation - Технический комитет 251 - Медицинская информатика

Chest CAD

Компьютерное вспомогательное обнаружение и/или компьютерное вспомогательное диагностирование для рентгенографии органов грудной клетки

DICOM

Цифровая визуализация и коммуникации в медицине

DIMSE

Элемент сервиса сообщений DICOM

DIMSE-C

Элемент сервиса сообщений DICOM — Composite

DIMSE-N

Элемент сервиса сообщений DICOM — Normalized

HL7

Health Level 7

IE

Информационная сущность

IEEE

Институт инженеров электротехники и электроники

IOD

Определение информационного объекта

IS

Информационная система

ISO

Международная организация по стандартизации

JIRA

Японская ассоциация производителей медицинского визуализационного и радиологического оборудования

JPIP

Интерактивный протокол JPEG 2000

MAR

Карта назначения лекарственных препаратов

MPPS

Этап выполненной процедуры модальности

NEMA

Национальная ассоциация производителей электрооборудования

OSI

Взаимодействие открытых систем

SCP

Service Class Provider

SCU

Service Class User

SOP

Service-Object Pair

UID

Unique Identifier

5 Соглашения

5.1 Модель «сущность-связь»

5.1.1 Сущность

Сущность используется в модели «сущность-связь» (E-R) для представления объекта реального мира, класса объектов реального мира или представления данных DICOM (таких как IOD или Module). Сущность изображается в виде прямоугольника в данной Части стандарта DICOM, как показано на Рисунке 5-1.

Entity Convention

Figure 5-1. Соглашение для сущности


5.1.2 Связь

Связь, определяющая отношение между сущностями, изображается в данном Стандарте в виде ромба, как показано на Рисунке 5-2.

Relationship Convention

Figure 5-2. Соглашение для связи


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

  1. (a = 1, b = 1) — одна исходная сущность связана с одной целевой сущностью

  2. (a = 1, b = 0-n) — одна исходная сущность связана с нулём или более целевыми сущностями

  3. (a = 1, b = 1-n) — одна исходная сущность связана с одной или более целевыми сущностями

  4. (a = 1-n, b = 1) — одна или более исходных сущностей связаны с одной целевой сущностью

  5. (a = 1-n, b = 0-n) — одна или более исходных сущностей связаны с нулём или более целевыми сущностями

  6. (a = 1-n, b = 1-n) — одна или более исходных сущностей связаны с одной или более целевыми сущностями

В связи, где (a = 1-n, b = 1-n), значения исходной и целевой мощностей могут различаться. Значение "n" просто обозначает одну или более.

Примечание

DICOM добавил использование стрелок к соглашениям по диаграммам E-R, часто применяемым в другой литературе. Это было сделано во избежание возможности вывода неверной связи, которая может возникнуть при чтении связи в обратном порядке по сравнению с предполагаемым. Например, связь «Кошка ловит мышь» может быть прочитана как «Мышь ловит кошку», если стрелки отсутствуют.

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

5.2 Последовательности

Некоторые таблицы в данной Части стандарта DICOM обозначают последовательность элементов (Sequence of Items) с использованием символа: '>'.

В Приложении A '>' используется для обозначения «последовательности модулей» (Sequence of Modules). Вложенные последовательности модулей обозначаются '>>'. В Приложении B и Приложении C '>' используется для обозначения «последовательности атрибутов» (Sequence of Attributes). См. PS3.5 для полной спецификации того, как должны кодироваться последовательности элементов.

Примечание

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

5.3 Значения статуса ответа

Некоторые таблицы в данной Части стандарта DICOM обозначают зависящий от реализации код состояния ответа с использованием символа 'xx' или 'xxx' как части кода.

Примечание

Каждый символ 'x' может быть заменён реализацией на шестнадцатеричную цифру в диапазоне от 0 до F.

5.4 Спецификация использования

Базовыми блоками классов SOP являются модули и сервисы DIMSE. Сервисы DIMSE, связанные с классом SOP, могут быть обязательными (M) или необязательными (U). Использование может различаться для SCU и SCP. Использование задаётся парой букв: первая указывает использование для SCU, вторая — использование для SCP.

5.4.1 Использование сервисов DIMSE

Значение и поведение спецификации использования для сервисов DIMSE:

M/M

SCU должен поддерживать сервис DIMSE, но не обязан использовать его в Ассоциации. SCP должен поддерживать сервис DIMSE.

U/M

SCU может поддерживать и использовать сервис DIMSE. SCP должен поддерживать сервис DIMSE.

U/U

SCU может поддерживать и использовать сервис DIMSE. SCP может поддерживать сервис DIMSE. Если SCP не поддерживает сервис DIMSE, используемый SCU, он должен вернуть статус Failure.

5.4.2 Использование атрибутов в нормализованных сервисах

Модули и их использование в композитных IOD определены в PS3.3. Нормализованные IOD также строятся из модулей, но использование указывается на уровне атрибутов в данной Части стандарта DICOM. Следующая спецификация использования применяется ко всем атрибутам нормализованных IOD, если она не заменена спецификацией использования в конкретной спецификации класса SOP.

Термин «получать» означает следующее: значение должно быть сохранено; при определённых обстоятельствах (например, при принудительном преобразовании) возвращаемое значение могло измениться.

5.4.2.1 Сервис DIMSE N-CREATE, N-SET, N-ACTION

Следующие требования применяются при указании использования сервисов DIMSE N-CREATE, N-SET, N-ACTION.

Используемые в таблице ниже условные обозначения:

Требования к атрибутам SCU

Обязательно

SCU должен передать атрибут с командой.

Необязательно

SCU может как передавать, так и не передавать атрибут с командой.

Не допускается

SCU не должен передавать атрибут с командой.

Содержимое атрибутов SCU

Допускается

Атрибут нулевой длины допускается.

Допускается

Атрибут нулевой длины не допускается.

Поведение SCP

Обязательно

SCP должен поддерживать получение атрибута с командой.

Обязательно со значением по умолчанию

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

Необязательно

SCP может как поддерживать, так и не поддерживать получение атрибута с командой.

Не допускается

SCP не должен поддерживать получение данного атрибута с командой.

SCU

SCP

Использование

Требование

Нулевая длина

Требование

1/1

Обязательно

Не допускается

Обязательно

2/1

Обязательно

Допускается

Обязательно со значением по умолчанию

2/2

Обязательно

Допускается

Обязательно

3/1

Необязательно

Не допускается

Обязательно

3/2

Необязательно

Не допускается

Необязательно

3/3

Необязательно

Не допускается

Необязательно

-/-

Не допускается

Не допускается

Не допускается

Если SCU не передаёт атрибут, обязательный для SCU, SCP должен ответить кодом состояния Failure 0120H «Missing Attribute».

Если SCU передаёт значение нулевой длины для обязательного атрибута, когда нулевая длина не допускается, SCP должен ответить кодом состояния Failure 0121H «Missing Attribute Value».

5.4.2.2 Сервис DIMSE N-GET, N-EVENT-REPORT

Следующие требования применяются при указании использования сервисов DIMSE N-GET, N-EVENT-REPORT.

Используемые в таблице ниже условные обозначения:

Поведение SCU

Необязательно

SCU может запрашивать атрибут.

Не допускается

SCU не должен запрашивать получение атрибута.

Примечание

«Не допускается» часто используется для атрибутов, являющихся частью атрибута-последовательности (Sequence Attribute). В этих случаях зачастую можно запросить содержимое всей последовательности целиком, но не отдельные атрибуты внутри последовательности.

Поведение SCP

Обязательно

SCP должен поддерживать получение атрибута.

Необязательно

SCP может как поддерживать, так и не поддерживать получение атрибута.

Содержимое атрибутов SCP

Допускается

Атрибут нулевой длины допускается и может быть возвращён.

Не допускается

Атрибут нулевой длины не допускается и не будет возвращён.

SCU

SCP

Использование

Требование

Требование

Нулевая длина

3/1

Необязательно

Обязательно

Не допускается

3/2

Необязательно

Обязательно

Допускается

3/3

Необязательно

Необязательно

Не допускается

-/1

Не допускается

Обязательно

Не допускается

-/2

Не допускается

Обязательно

Допускается

-/3

Не допускается

Необязательно

Не допускается

Если поддержка атрибута со стороны SCP является необязательной и SCP не поддерживает атрибут, и атрибут запрашивается SCU, SCP должен ответить кодом состояния Failure 0106H «Invalid Attribute Value» или 0116H «Attribute Value out of range».

5.4.2.3 Прочие требования

Если тип использования SCP модифицируется символом «C» (например, 3/1C), указанная выше спецификация должна быть изменена, чтобы включить требование о том, что SCP должен поддерживать атрибут при выполнении указанного условия.

Для всех операций N-CREATE, N-SET, N-GET, N-DELETE, N-ACTION и N-EVENT-REPORT класс SOP передаётся в примитиве запроса в атрибуте Affected SOP Class UID (0000,0002). Атрибут SOP Class UID (0008,0016) не должен присутствовать в Data Set.

Для операций N-CREATE и уведомлений N-EVENT-REPORT экземпляр SOP передаётся в атрибуте Affected SOP Instance UID (0000,1000). Атрибут SOP Instance UID (0008,0018) не должен присутствовать в Data Set.

Примечание

В некоторых классах сервиса определение класса SOP может переопределять общее положение PS3.7, разрешающее указывать или опускать SOP Instance UID в примитиве запроса N-CREATE, и требовать, чтобы SCU был ответственен за указание SOP Instance UID.

Для операций N-SET, N-GET, N-ACTION и N-DELETE экземпляр SOP передаётся в атрибуте Requested SOP Instance UID (0000,1001). Атрибут SOP Instance UID (0008,0018) не должен присутствовать в Data Set.

6 Информационная модель DICOM

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

6.1 Определение информационного объекта

Определение информационного объекта (IOD) — это объектно-ориентированная абстрактная модель данных, используемая для спецификации информации об объектах реального мира. IOD предоставляет взаимодействующим прикладным сущностям общее представление обмениваемой информации.

Major Structures of DICOM Information Model

Figure 6-1. Основные структуры информационной модели DICOM


IOD не представляет конкретный экземпляр объекта реального мира, а скорее класс объектов реального мира, обладающих одинаковыми свойствами. IOD, используемый для представления единственного класса объектов реального мира, называется нормализованным информационным объектом (Normalized Information Object). IOD, содержащий информацию о связанных объектах реального мира, называется композитным информационным объектом (Composite Information Object).

6.1.1 Композитный IOD

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

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

Примечание

  1. Фактическая передача экземпляров IOD осуществляется через экземпляры SOP.

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

Композитные IOD определены в PS3.3.

6.1.2 Нормализованный IOD

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

При передаче экземпляра нормализованного IOD контекст для этого экземпляра фактически не обменивается. Вместо этого контекст предоставляется через использование указателей на связанные экземпляры нормализованных IOD.

Нормализованные IOD определены в PS3.3.

6.2 Атрибуты

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

Атрибуты кодируются как элементы данных (Data Elements) с использованием правил, концепций представления значения (Value Representation) и кратности значения (Value Multiplicity), указанных в PS3.5. Для конкретных элементов данных представление значения и кратность значения элементов данных указаны в словаре данных в PS3.6.

6.3 Сервисы сетевой передачи и хранения на носителях

При сетевой передаче сервисы DIMSE и веб-сервисы позволяют прикладной сущности DICOM инициировать операцию или уведомление через сеть или интерфейс точка-точка. Сервисы DIMSE определены в PS3.7, а веб-сервисы определены в PS3.18.

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

Сервисы хранения на носителях рассматриваются в PS3.10.

6.3.1 Сервисы DIMSE-C

Сервисы DIMSE-C — это сервисы, применимые только к композитному IOD. DIMSE-C предоставляет только сервисы операций.

6.3.2 Сервисы DIMSE-N

Сервисы DIMSE-N — это сервисы, применимые только к нормализованному IOD. DIMSE-N предоставляет как сервисы операций, так и сервисы уведомлений.

6.4 Группа сервисов DIMSE

Группа сервисов DIMSE (DIMSE Service Group) указывает одну или более операций/уведомлений, определённых в PS3.7, применимых к IOD.

Группы сервисов DIMSE определены в данной Части стандарта DICOM, в спецификации класса Service-Object Pair Class.

6.5 Класс Service-Object Pair (SOP)

Определения классов SOP в PS3.4 содержат правила и семантику, которые могут ограничивать использование сервисов в группе сервисов DIMSE или атрибутов IOD. PS3.10 и PS3.18 содержат правила и семантику, которые могут ограничивать атрибуты IOD или использование сервисов в сервисах хранения на носителях и веб-сервисах соответственно.

Выбор классов SOP используется прикладными сущностями для установления согласованного набора возможностей для поддержки их взаимодействия с классами SOP на основе сервисов DIMSE. Это согласование выполняется во время установления Ассоциации, как описано в PS3.7. Расширенное согласование (Extended Negotiation) позволяет прикладным сущностям дополнительно договориться о конкретных параметрах в рамках класса SOP.

Примечание

  1. Класс SOP, как он определён в информационной модели DICOM, эквивалентен в терминологии ISO/OSI классу управляемого объекта (Managed Object Class). Читатели, знакомые с объектно-ориентированной терминологией, узнают в операциях (и уведомлениях) класса SOP методы класса объекта.

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

6.5.1 Нормализованные и композитные классы SOP

DICOM определяет два типа классов SOP — нормализованные и композитные. Для сервисов DIMSE нормализованные классы SOP определяются как объединение нормализованного IOD и набора сервисов DIMSE-N, тогда как композитные классы SOP определяются как объединение композитного IOD и набора сервисов DIMSE-C. Сервисы хранения на носителях поддерживают только композитные IOD, а веб-сервисы поддерживают как нормализованные, так и композитные классы SOP.

6.6 Согласование Ассоциации

Установление Ассоциации — это первая фаза взаимодействия между равноправными DICOM-совместимыми прикладными сущностями. Прикладные сущности должны использовать установление Ассоциации для согласования того, какие классы SOP могут быть обменены и как эти данные будут кодироваться.

Согласование Ассоциации определено в PS3.7.

6.7 Спецификация класса сервиса

Спецификация класса сервиса (Service Class Specification) определяет группу из одного или более классов SOP, связанных с конкретной функцией, которая должна быть выполнена взаимодействующими прикладными сущностями. Спецификация класса сервиса также определяет правила, позволяющие реализациям заявлять некоторый заранее определённый уровень соответствия одному или более классам SOP. Приложения могут соответствовать сетевым классам SOP как Service Class User (SCU), Service Class Provider (SCP), пользовательский агент или исходный сервер, а классам SOP для обмена на носителях — как File Set Creator (FSC), File Set Reader (FSR) или File Set Updater (FSU).

Спецификации классов сервиса определены в данной Части стандарта DICOM.

Примечание

Сетевое взаимодействие между равноправными прикладными сущностями основано на «клиент-серверной модели». SCU или пользовательский агент выступает в роли «клиента», а SCP или исходный сервер — в роли «сервера». Для сервисов на основе DIMSE роли SCU/SCP определяются во время установления Ассоциации.

7 Модель реального мира DICOM

Представление DICOM о реальном мире, определяющее соответствующие объекты реального мира и их связи в рамках области стандарта DICOM, описано в разделе «Модель реального мира DICOM» в PS3.3.

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

8 Использование кодированных записей в спецификациях сервисов

Макросы в данном разделе определяют использование атрибутов, соответствующих кодированным записям (Coded Entries), как определено Table 8.8-1 Code Sequence Macro Attributes in PS3.3 .

Не все использования применяют все столбцы этих макросов. Только столбцы с именами, совпадающими с именами столбцов вызывающей таблицы, используются в вызывающей таблице. Например, в одних случаях релевантен только «Использование (SCU/SCP)»; в других — используются только столбцы «Тип ключа сопоставления» и «Тип возвращаемого ключа».

Таблица 8-1a. Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением


Таблица 8-1b. Базовый макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением

Имя атрибута

Тег

Использование (SCU/SCP)

Тип ключа сопоставления

Тип ключа возврата

Code Value

(0008,0100)

1C/1C

Должно присутствовать, если длина значения кода составляет 16 символов или менее, и значение кода не является URN или URL.

RC

Обязательно, если длина значения кода составляет 16 символов или менее, и значение кода не является URN или URL.

1C

Должно присутствовать, если длина значения кода составляет 16 символов или менее, и значение кода не является URN или URL.

Coding Scheme Designator

(0008,0102)

1C/1C

Должно присутствовать, если присутствует Code Value (0008,0100) или Long Code Value (0008,0119). Может присутствовать в остальных случаях.

RC

Обязательно, если присутствует Code Value (0008,0100) или Long Code Value (0008,0119). Может присутствовать в остальных случаях.

1C

Должно присутствовать, если присутствует Code Value (0008,0100) или Long Code Value (0008,0119). Может присутствовать в остальных случаях.

Coding Scheme Version

(0008,0103)

1C/1C

Обязательно, если значение Coding Scheme Designator (0008,0102) присутствует и недостаточно для однозначной идентификации Code Value (0008,0100), Long Code Value (0008,0119) или URN Code Value (0008,0120). Не должно присутствовать, если Coding Scheme Designator (0008,0102) отсутствует. Может присутствовать в остальных случаях.

RC

Обязательно, если значение Coding Scheme Designator (0008,0102) присутствует и недостаточно для однозначной идентификации Code Value (0008,0100), Long Code Value (0008,0119) или URN Code Value (0008,0120). Не должно присутствовать, если Coding Scheme Designator (0008,0102) отсутствует. Может присутствовать в остальных случаях.

1C

Обязательно, если значение Coding Scheme Designator (0008,0102) присутствует и недостаточно для однозначной идентификации Code Value (0008,0100), Long Code Value (0008,0119) или URN Code Value (0008,0120). Не должно присутствовать, если Coding Scheme Designator (0008,0102) отсутствует. Может присутствовать в остальных случаях.

Code Meaning

(0008,0104)

1/1

-

1

Long Code Value

(0008,0119)

1C/1C

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода не является URN или URL.

RC

Обязательно, если Code Value (0008,0100) отсутствует, и значение кода не является URN или URL.

1C

Обязательно, если Code Value (0008,0100) отсутствует, и значение кода не является URN или URL.

URN Code Value

(0008,0120)

1C/1C

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода является URN или URL.

RC

Обязательно, если Code Value (0008,0100) отсутствует, и значение кода является URN или URL.

1C

Обязательно, если Code Value (0008,0100) отсутствует, и значение кода является URN или URL.

Mapping Resource

(0008,0105)

3/3

-

3

Mapping Resource UID

(0008,0118)

3/3

-

3

Context Group Version

(0008,0106)

3/3

-

3

Context Group Extension Flag

(0008,010B)

3/3

-

3

Context Group Local Version

(0008,0107)

3/3

-

3

Context Group Extension Creator UID

(0008,010D)

3/3

-

3


Таблица 8-2a. Расширенный макрос кодированной записи с необязательной поддержкой ключа сопоставления и необязательным значением

Имя атрибута

Тег

Тип ключа сопоставления

Тип возвращаемого ключа

Включает Таблица 8-2b «Базовый макрос кодированной записи с необязательной поддержкой ключа сопоставления и необязательным значением»

Equivalent Code Sequence

(0008,0121)

O

3

>Include Таблица 8-2b «Базовый макрос кодированной записи с необязательной поддержкой ключа сопоставления и необязательным значением»


Таблица 8-2b. Базовый макрос кодированной записи с необязательной поддержкой ключа сопоставления и необязательным значением

Имя атрибута

Тег

Тип ключа сопоставления

Тип возвращаемого ключа

Code Value

(0008,0100)

O

1C

Должно присутствовать, если длина значения кода составляет 16 символов или менее, и значение кода не является URN или URL.

Coding Scheme Designator

(0008,0102)

O

1C

Должно присутствовать, если присутствует Code Value (0008,0100) или Long Code Value (0008,0119).

Coding Scheme Version

(0008,0103)

OC

Может присутствовать только если значение Coding Scheme Designator (0008,0102) присутствует и недостаточно для однозначной идентификации Code Value (0008,0100), Long Code Value (0008,0119) или URN Code Value (0008,0120).

3

Применимо только если значение Coding Scheme Designator (0008,0102) присутствует и недостаточно для однозначной идентификации Code Value (0008,0100), Long Code Value (0008,0119) или URN Code Value (0008,0120).

Code Meaning

(0008,0104)

O

3

Long Code Value

(0008,0119)

O

1C

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода не является URN или URL.

URN Code Value

(0008,0120)

O

1C

Должно присутствовать только если Code Value (0008,0100) отсутствует, и значение кода является URN или URL.

Mapping Resource

(0008,0105)

O

3

Mapping Resource UID

(0008,0118)

O

3

Context Group Version

(0008,0106)

O

3

Context Group Extension Flag

(0008,010B)

O

3

Context Group Local Version

(0008,0107)

O

3

Context Group Extension Creator UID

(0008,010D)

O

3


Таблица 8-3a. Расширенный макрос кодированной записи SCU/SCP без поддержки SCU и без поддержки ключа сопоставления

Имя атрибута

Тег

Использование (SCU/SCP)

Тип ключа сопоставления

Тип возвращаемого ключа

Включает Таблица 8-3b «Базовый макрос кодированной записи SCU/SCP без поддержки SCU и без поддержки ключа сопоставления»

Equivalent Code Sequence

(0008,0121)

-/3

-

>Include Таблица 8-3b «Базовый макрос кодированной записи SCU/SCP без поддержки SCU и без поддержки ключа сопоставления»


Таблица 8-3b. Базовый макрос кодированной записи SCU/SCP без поддержки SCU и без поддержки ключа сопоставления

Имя атрибута

Тег

Использование (SCU/SCP)

Тип ключа сопоставления

Тип возвращаемого ключа

Code Value

(0008,0100)

-/1C

Должно присутствовать, если длина значения кода составляет 16 символов или менее, и значение кода не является URN или URL.

-

1C

Должно присутствовать, если длина значения кода составляет 16 символов или менее, и значение кода не является URN или URL.

Coding Scheme Designator

(0008,0102)

-/1C

Должно присутствовать, если присутствует Code Value (0008,0100) или Long Code Value (0008,0119). Может присутствовать в остальных случаях.

-

1C

Должно присутствовать, если присутствует Code Value (0008,0100) или Long Code Value (0008,0119). Может присутствовать в остальных случаях.

Coding Scheme Version

(0008,0103)

-/1C

Обязательно, если значение Coding Scheme Designator (0008,0102) присутствует и недостаточно для однозначной идентификации Code Value (0008,0100), Long Code Value (0008,0119) или URN Code Value (0008,0120). Не должно присутствовать, если Coding Scheme Designator (0008,0102) отсутствует. Может присутствовать в остальных случаях.

-

1C

Должно присутствовать, если значение Coding Scheme Designator (0008,0102) присутствует и недостаточно для однозначной идентификации Code Value (0008,0100), Long Code Value (0008,0119) или URN Code Value (0008,0120). Не должно присутствовать, если Coding Scheme Designator (0008,0102) отсутствует. Может присутствовать в остальных случаях.

Code Meaning

(0008,0104)

-/1

-

1

Long Code Value

(0008,0119)

-/1C

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода не является URN или URL.

-

1C

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода не является URN или URL.

URN Code Value

(0008,0120)

-/1C

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода является URN или URL.

-

1C

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода является URN или URL.

Mapping Resource

(0008,0105)

-/3

-

3

Mapping Resource UID

(0008,0118)

-/3

-

3

Context Group Version

(0008,0106)

-/3

-

3

Context Group Extension Flag

(0008,010B)

-/3

-

3

Context Group Local Version

(0008,0107)

-/3

-

3

Context Group Extension Creator UID

(0008,010D)

-/3

-

3


Таблица 8-4a. Расширенный макрос кодированной записи с необязательной поддержкой ключа сопоставления и обязательным значением

Имя атрибута

Тег

Тип ключа сопоставления

Тип возвращаемого ключа

Включает Таблица 8-4b «Базовый макрос кодированной записи с необязательной поддержкой ключа сопоставления и обязательным значением»

Equivalent Code Sequence

(0008,0121)

O

3

>Include Таблица 8-4b «Базовый макрос кодированной записи с необязательной поддержкой ключа сопоставления и обязательным значением»


Таблица 8-4b. Базовый макрос кодированной записи с необязательной поддержкой ключа сопоставления и обязательным значением

Имя атрибута

Тег

Тип ключа сопоставления

Тип возвращаемого ключа

Code Value

(0008,0100)

O

1C

Должно присутствовать, если длина значения кода составляет 16 символов или менее, и значение кода не является URN или URL.

Coding Scheme Designator

(0008,0102)

O

1C

Должно присутствовать, если присутствует Code Value (0008,0100) или Long Code Value (0008,0119). Может присутствовать в остальных случаях.

Coding Scheme Version

(0008,0103)

RC

Обязательно, если значение Coding Scheme Designator (0008,0102) присутствует и недостаточно для однозначной идентификации Code Value (0008,0100), Long Code Value (0008,0119) или URN Code Value (0008,0120). Не должно присутствовать, если Coding Scheme Designator (0008,0102) отсутствует. Может присутствовать в остальных случаях.

1C

Должно присутствовать, если значение Coding Scheme Designator (0008,0102) присутствует и недостаточно для однозначной идентификации Code Value (0008,0100), Long Code Value (0008,0119) или URN Code Value (0008,0120). Не должно присутствовать, если Coding Scheme Designator (0008,0102) отсутствует. Может присутствовать в остальных случаях.

Code Meaning

(0008,0104)

O

1

Long Code Value

(0008,0119)

O

1C

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода не является URN или URL.

URN Code Value

(0008,0120)

O

1C

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода является URN или URL.

Mapping Resource

(0008,0105)

O

3

Mapping Resource UID

(0008,0118)

O

3

Context Group Version

(0008,0106)

O

3

Context Group Extension Flag

(0008,010B)

O

3

Context Group Local Version

(0008,0107)

O

3

Context Group Extension Creator UID

(0008,010D)

O

3


Таблица 8-5a. Расширенный макрос кодированной записи SCU/SCP без поддержки SCU и с необязательным значением для SCP

Имя атрибута

Тег

Использование (SCU/SCP)

Включает Таблица 8-5b «Базовый макрос кодированной записи SCU/SCP без поддержки SCU и с необязательным значением для SCP»

Equivalent Code Sequence

(0008,0121)

-/3

>Include Таблица 8-5b «Базовый макрос кодированной записи SCU/SCP без поддержки SCU и с необязательным значением для SCP»


Таблица 8-5b. Базовый макрос кодированной записи SCU/SCP без поддержки SCU и с необязательным значением для SCP

Имя атрибута

Тег

Использование (SCU/SCP)

Code Value

(0008,0100)

-/1C

Должно присутствовать, если длина значения кода составляет 16 символов или менее, и значение кода не является URN или URL.

Coding Scheme Designator

(0008,0102)

-/1C

Должно присутствовать, если присутствует Code Value (0008,0100) или Long Code Value (0008,0119). Может присутствовать в остальных случаях.

Coding Scheme Version

(0008,0103)

-/1C

Может присутствовать, если значение Coding Scheme Designator (0008,0102) присутствует и недостаточно для однозначной идентификации Code Value (0008,0100), Long Code Value (0008,0119) или URN Code Value (0008,0120). Не должно присутствовать, если Coding Scheme Designator (0008,0102) отсутствует. Может присутствовать в остальных случаях.

Code Meaning

(0008,0104)

-/3

Long Code Value

(0008,0119)

-/1C

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода не является URN или URL.

URN Code Value

(0008,0120)

-/1C

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода является URN или URL.

Mapping Resource

(0008,0105)

-/3

Mapping Resource UID

(0008,0118)

-/3

Context Group Version

(0008,0106)

-/3

Context Group Extension Flag

(0008,010B)

-/3

Context Group Local Version

(0008,0107)

-/3

Context Group Extension Creator UID

(0008,010D)

-/3


A Класс сервиса верификации

A.1 Обзор

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

Класс сервиса верификации определяет сервис, который проверяет связь на уровне приложений между равноправными DICOM AE. Эта верификация выполняется в установленной ассоциации с использованием сервиса C-ECHO DIMSE-C.

A.2 Поведение SCU/SCP

DICOM AE, поддерживающий роль SCU SOP класса верификации, запрашивает верификацию связи с удалённым DICOM AE. Этот запрос выполняется с использованием примитива запроса C-ECHO. Удалённый DICOM AE, поддерживающий роль SCP SOP класса верификации, выдаёт примитив ответа C-ECHO. При получении подтверждения C-ECHO, SCU определяет, что верификация завершена. См. PS3.7 для спецификации примитивов C-ECHO.

A.3 Группа сервисов DIMSE-C

Сервис C-ECHO DIMSE-C должен быть механизмом, используемым для проверки связи между равноправными DICOM AE. Сервис C-ECHO и параметры протокола должны быть обязательными, как определено в PS3.7.

A.4 SOP класс верификации

SOP класс верификации состоит из сервиса C-ECHO DIMSE-C. Связанное определение информационного объекта не определяется. UID SOP класса должен быть "1.2.840.10008.1.1".

Специализированные SOP классы и/или мета-SOP классы не должны определяться для SOP класса верификации.

A.5 Согласование ассоциации

Установление ассоциации является первой фазой любого сеанса связи между равноправными DICOM AE. Следующие правила согласования применяются к DICOM AE, которые поддерживают SOP класс верификации:

  • Инициатор ассоциации (роль SCU верификации) в запросе A-ASSOCIATE должен передавать абстрактный синтаксис в контексте представления для SOP класса верификации. Имя абстрактного синтаксиса должно быть эквивалентно UID SOP класса верификации.

  • Акцептор ассоциации (роль SCP верификации) в ответе A-ASSOCIATE должен принять абстрактный синтаксис в контексте представления для поддерживаемого SOP класса верификации.

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

A.6 Соответствие

A.6.1 Соответствие, поддерживающее роль SCU

Реализации, соответствующие роли SCU SOP класса верификации, должны отвечать следующим требованиям:

  • Требования к сервису C-ECHO, как определено группой сервисов DIMSE, Раздел A.3

  • Правила согласования ассоциации, как определено в Раздел A.5

A.6.2 Соответствие, поддерживающее роль SCP

Реализации, соответствующие роли SCP SOP класса верификации, должны отвечать следующим требованиям:

  • Правила операции C-ECHO, как определено группой сервисов DIMSE, Раздел A.3

  • Правила согласования ассоциации, как определено в Раздел A.5

A.6.3 Заявление о соответствии

Реализация может соответствовать SOP классу верификации как SCU, SCP или обоим. Заявление о соответствии должно быть в формате, определённом в PS3.2.

B Класс сервиса хранения

B.1 Обзор

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

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

Определения информационных объектов для экземпляров, передаваемых в рамках класса сервиса хранения, должны соответствовать информационной модели Composite Instance IOD, описанной в PS3.3, и включать как минимум информационные сущности Patient, Study и Series.

B.1.2 Определение сервиса

Две равноправные DICOM AE реализуют SOP класс класса сервиса хранения, одна из которых выступает в роли SCU, а другая — в роли SCP. SOP классы класса сервиса хранения реализуются с использованием сервиса C-STORE DIMSE-C. Сервис C-STORE описан в PS3.7. Успешное завершение C-STORE имеет следующую семантику:

  • Как SCU, так и SCP поддерживают тип информации, подлежащей хранению.

  • Информация сохраняется на некотором носителе.

  • В течение определённого периода времени информация может быть доступна.

Примечание

  1. Поддержка SOP классов хранения не обязательно включает поддержку SOP классов класса сервиса Query/Retrieve. То, каким образом может осуществляться доступ к информации, зависит от реализации. Требуется лишь, чтобы существовал некоторый метод доступа. Этот метод может требовать выполнения зависящей от реализации операции на SCP класса сервиса хранения. Длительность хранения также зависит от реализации и описывается в заявлении о соответствии SCP. SOP классы хранения предназначены для использования в различных условиях: например, для передачи изображений от модальностей на рабочие станции или в архивы, для передачи изображений из архивов на рабочие станции или обратно на модальности, для передачи обработанных изображений с рабочих станций в архивы и т.д.

  2. Для синтаксисов передачи JPIP Referenced Pixel Data передача может привести к сохранению неполной информации, поскольку данные пикселей могут быть частично или полностью переданы посредством иного механизма по усмотрению SCP.

B.2 Поведение

В данном разделе рассматривается поведение SCU и SCP для SOP классов класса сервиса хранения. C-STORE DIMSE-C сервис должен быть механизмом, используемым для передачи SOP экземпляров между равноправными DICOM AE, как описано в PS3.7.

B.2.1 Поведение SCU

SCU инициирует сервис C-STORE DIMSE с SOP экземпляром, который удовлетворяет требованиям соответствующего IOD. SCU должен распознавать статус сервиса C-STORE и предпринимать соответствующие действия при успехе или неудаче сервиса.

Примечание

Соответствующее действие зависит от реализации. Требуется, чтобы SCU различал успешные и неуспешные ответы C-STORE. Соответствующие действия могут различаться в зависимости от приложения и описываются в заявлении о соответствии SCU.

B.2.2 Поведение SCP

SCP SOP класса хранения выступает в роли выполняющего DIMSE-сервис-пользователя для сервиса C-STORE. Путём успешного выполнения этого сервиса SCP указывает, что SOP экземпляр был успешно сохранён.

B.2.3 Статусы

Таблица B.2-1 определяет конкретные значения кодов статуса, которые могут быть возвращены в ответе C-STORE. Общие значения кодов статуса и поля, связанные со значениями кодов статуса, для сервиса C-STORE DIMSE определены в PS3.7.

Таблица B.2-1. Значения статуса ответа C-STORE

Статус сервиса

Дополнительное значение

Коды статуса

Связанные поля

Отказ

Отклонено: нехватка ресурсов

A7xx

(0000,0902)

Ошибка: набор данных не соответствует SOP классу

A9xx

(0000,0901)

(0000,0902)

Ошибка: невозможно понять

Cxxx

(0000,0901)

(0000,0902)

Предупреждение

Принудительное изменение элементов данных

B000

(0000,0901)

(0000,0902)

Набор данных не соответствует SOP классу

B007

(0000,0901)

(0000,0902)

Элементы отброшены

B006

(0000,0901)

(0000,0902)

Успех

Успех

0000

Нет


Некоторые коды статуса отказа зависят от реализации.

Реализация SCP должна назначать конкретные коды статуса отказа, заменяя каждый символ 'x' шестнадцатеричной цифрой в диапазоне от 0 до F. Реализация SCP, желающая различать причины в пределах одного значения отказа, должна назначать этим причинам конкретные значения кодов статуса в допустимом диапазоне, указанном в Таблице B.2-1.

Реализация SCU должна распознавать любой код статуса отказа в диапазоне значений, указанном в Таблице B.2-1, как индикатор значения отказа, указанного в таблице. Не требуется, чтобы реализация SCU различала конкретные коды статуса в пределах допустимого диапазона.

B.3 Согласование ассоциации

SCU и SCP SOP классов хранения работают с SOP экземплярами, специфичными для SOP класса. Они могут использовать подэлемент SOP Class Extended Negotiation Sub-Item, определённый в PS3.7. Этот подэлемент позволяет DICOM AE обмениваться прикладной информацией, специфичной для спецификаций SOP класса. Это достигается путём определения поля Service-class-application-information.

SCU могут использовать подэлемент SOP Class Common Extended Negotiation Sub-Item, определённый в PS3.7. Этот подэлемент позволяет DICOM AE обмениваться информацией о природе SOP классов.

Согласование подэлементов SOP Class Extended Negotiation Sub-Item и SOP Class Common Extended Negotiation Sub-Item является необязательным для SOP классов хранения.

Следующие правила согласования применяются ко всем DICOM SOP классам и специализированным SOP классам класса сервиса хранения.

Инициатор ассоциации (роль Storage SCU) в запросе A-ASSOCIATE должен передать:

  • один абстрактный синтаксис в контексте представления для каждого поддерживаемого SOP класса класса сервиса хранения

  • необязательно, один подэлемент SOP Class Extended Negotiation Sub-Item для каждого поддерживаемого SOP класса класса сервиса хранения

  • необязательно, один подэлемент SOP Class Common Extended Negotiation Sub-Item для каждого поддерживаемого SOP класса класса сервиса хранения

Акцептор ассоциации (роль Storage SCP) в запросе A-ASSOCIATE должен принять:

  • один абстрактный синтаксис в контексте представления для каждого поддерживаемого SOP класса класса сервиса хранения

  • необязательно, один подэлемент SOP Class Extended Negotiation Sub-Item для каждого поддерживаемого SOP класса класса сервиса хранения

B.3.1 Расширенное согласование

Во время установления ассоциации реализации могут обмениваться информацией о своих соответствующих возможностях, как описано в PS3.7 и PS3.8. SCU и SCP могут использовать структуру подэлемента SOP Class Extended Negotiation Sub-Item, как описано в Разделе D.3.3.5 в PS3.7 для обмена информацией об уровне соответствия и поддерживаемых параметрах. SCU могут использовать подэлемент SOP Class Common Extended Negotiation Sub-Item, определённый в Разделе D.3.3.6 в PS3.7 для обмена информацией о природе SOP классов.

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

B.3.1.1 Service-Class-Application-Information (A-ASSOCIATE-RQ)

Подэлемент SOP Class Extended Negotiation Sub-Item состоит из последовательности обязательных полей, как определено в PS3.7. Таблица B.3-1 показывает формат поля Service-class-application-information подэлемента SOP Class Extended Negotiation Sub-Item для SOP классов класса сервиса хранения в A-ASSOCIATE-RQ.

Таблица B.3-1. Service-Class-Application-Information (A-ASSOCIATE-RQ)

Байты элемента

Имя поля

Описание поля

1

Уровень поддержки хранения

Это байтовое поле определяет поддерживаемый уровень хранения инициатора ассоциации. Оно должно быть закодировано как беззнаковое двоичное целое и должно использовать одно из следующих значений:

0 - SCP уровня хранения 0

1 - SCP уровня хранения 1

2 - SCP уровня хранения 2

3 - Н/Д — инициатор ассоциации является только SCU

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

2

Зарезервировано

Это зарезервированное поле должно отправляться со значением 00H, но не проверяться на это значение при получении.

3

Уровень поддержки цифровой подписи

SCP уровня хранения 2 может дополнительно определить своё поведение в этом байтовом поле.

0 - Уровень подписи не указан, AE является только SCU, или AE не является SCP уровня хранения 2

1 - Уровень подписи 1

2 - Уровень подписи 2

3 - Уровень подписи 3

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

4

Зарезервировано

Это зарезервированное поле должно отправляться со значением 00H, но не проверяться на это значение при получении.

5

Принудительное изменение элементов

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

0 - не изменяет принудительно никакие элементы данных

1 - может принудительно изменять элементы данных

2 - Н/Д — инициатор ассоциации является только SCU

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

6

Зарезервировано

Это зарезервированное поле должно отправляться со значением 00H, но не проверяться на это значение при получении.


B.3.1.2 Service-Class-Application-Information (A-ASSOCIATE-AC)

Подэлемент SOP Class Extended Negotiation Sub-Item состоит из последовательности обязательных полей, как определено в PS3.7. Таблица B.3-2 показывает формат поля Service-class-application-information подэлемента SOP Class Extended Negotiation Sub-Item для SOP классов класса сервиса хранения в A-ASSOCIATE-AC.

Таблица B.3-2. Service-Class-Application-Information (A-ASSOCIATE-AC)

Байты элемента

Имя поля

Описание поля

1

Уровень поддержки хранения

Это байтовое поле определяет поддерживаемый уровень хранения акцептора ассоциации. Оно должно быть закодировано как беззнаковое двоичное целое и должно использовать одно из следующих значений:

0 - SCP уровня хранения 0

1 - SCP уровня хранения 1

2 - SCP уровня хранения 2

3 - Н/Д — акцептор ассоциации является только SCU

Если расширенное согласование не поддерживается, инициатор ассоциации не должен делать никаких предположений о возможностях акцептора ассоциации на основании данного расширенного согласования.

2

Зарезервировано

Это зарезервированное поле должно отправляться со значением 00H, но не проверяться на это значение при получении.

3

Уровень поддержки цифровой подписи

SCP уровня 2 может дополнительно определить своё поведение в этом байтовом поле.

0 - Уровень подписи не указан, AE является только SCU, или AE не является SCP уровня хранения 2

1 - Уровень подписи 1

2 - Уровень подписи 2

3 - Уровень подписи 3

Если расширенное согласование не поддерживается, инициатор ассоциации не должен делать никаких предположений о возможностях акцептора ассоциации на основании данного расширенного согласования.

4

Зарезервировано

Это зарезервированное поле должно отправляться со значением 00H, но не проверяться на это значение при получении.

5

Принудительное изменение элементов

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

0 - не изменяет принудительно никакие элементы данных

1 - может принудительно изменять элементы данных

2 - Н/Д — акцептор ассоциации является только SCU

Если расширенное согласование не поддерживается, инициатор ассоциации не должен делать никаких предположений о возможностях акцептора ассоциации на основании данного расширенного согласования.

6

Зарезервировано

Это зарезервированное поле должно отправляться со значением 00H, но не проверяться на это значение при получении.


B.3.1.3 Service Class UID (A-ASSOCIATE-RQ)

Подэлемент SOP Class Common Extended Negotiation Sub-Item позволяет SCU передать UID класса сервиса для каждого предложенного SOP класса.

UID класса сервиса хранения должен быть "1.2.840.10008.4.2".

B.3.1.4 Related General SOP Classes (A-ASSOCIATE-RQ)

Ограниченный набор стандартных SOP классов в классе сервиса хранения определён как имеющий один или несколько связанных общих SOP классов (Related General SOP Classes). Связанные общие SOP классы могут быть переданы с использованием SOP Class Common Extended Negotiation во время установления ассоциации, как определено в PS3.7. Таблица B.3-3 определяет, какие стандартные SOP классы участвуют в этом механизме. Если стандартный SOP класс не указан в этой таблице, связанные общие SOP классы не должны включаться в подэлемент Related Storage SOP Class Extended Negotiation Sub-Item.

Примечание

Специализированные SOP классы, определённые реализацией (см. PS3.2), класса сервиса хранения могут передавать связанный общий SOP класс.

Таблица B.3-3. Стандартные и связанные общие SOP классы

Имя SOP класса

Имя связанного общего SOP класса

12-lead ECG Waveform Storage

General ECG Waveform Storage

General 32-bit ECG Waveform Storage

General ECG Waveform Storage

General 32-bit ECG Waveform Storage

Digital Mammography X-Ray Image Storage - For Presentation

Digital X-Ray Image Storage - For Presentation

Digital Mammography X-Ray Image Storage - For Processing

Digital X-Ray Image Storage - For Processing

Digital Intra-Oral X-Ray Image Storage - For Presentation

Digital X-Ray Image Storage - For Presentation

Digital Intra-Oral X-Ray Image Storage - For Processing

Digital X-Ray Image Storage - For Processing

Basic Text SR Storage

Enhanced SR Storage

Comprehensive SR Storage

Comprehensive 3D SR Storage

Extensible SR Storage

Enhanced SR Storage

Comprehensive SR Storage

Comprehensive 3D SR Storage

Extensible SR Storage

Comprehensive SR Storage

Comprehensive 3D SR Storage

Extensible SR Storage

Comprehensive 3D SR Storage

Extensible SR Storage

Procedure Log Storage

Enhanced SR Storage

Comprehensive SR Storage

Comprehensive 3D SR Storage

Extensible SR Storage

Simplified Adult Echo SR Storage

Enhanced SR Storage

Comprehensive SR Storage

Comprehensive 3D SR Storage

Extensible SR Storage

X-Ray Radiation Dose SR Storage

Enhanced SR Storage

Comprehensive SR Storage

Comprehensive 3D SR Storage

Extensible SR Storage

Radiopharmaceutical Radiation Dose SR Storage

Enhanced SR Storage

Comprehensive SR Storage

Comprehensive 3D SR Storage

Extensible SR Storage

Patient Radiation Dose SR Storage

Enhanced SR Storage

Comprehensive SR Storage

Comprehensive 3D SR Storage

Extensible SR Storage

Enhanced X-Ray Radiation Dose SR Storage

Enhanced SR Storage

Comprehensive SR Storage

Comprehensive 3D SR Storage

Extensible SR Storage

Acquisition Context SR Storage

Enhanced SR Storage (см. примечание)

Comprehensive SR Storage (см. примечание)

Comprehensive 3D SR Storage

Extensible SR Storage

Spectacle Prescription Report Storage

Enhanced SR Storage

Macular Grid Thickness and Volume Report Storage

Enhanced SR Storage

Enhanced CT Image Storage

Legacy Converted Enhanced CT Image Storage

Enhanced MR Image Storage

Legacy Converted Enhanced MR Image Storage

Enhanced PET Image Storage

Legacy Converted Enhanced PET Image Storage


Примечание

Acquisition Context SR может быть закодирован как Enhanced или Comprehensive SR только в том случае, если он не содержит стереотактических координат (SCOORD3D).

B.4 Соответствие

Реализация, соответствующая SOP классам хранения, должна удовлетворять следующим требованиям:

  • требованиям сервиса C-STORE, как определено в Разделе B.2

  • требованиям к ассоциации, как определено в Разделе B.3

Примечание

Не определено никаких требований к поведению SCU или SCP, помимо указанных в данном разделе. В частности, SCP SOP классов хранения может не придавать никакого значения конкретной ассоциации или ассоциациям, по которым запрашиваются операции C-STORE, а также порядку выполнения операций C-STORE в рамках ассоциации. На операции, которые SCU может выполнять во время любой конкретной ассоциации, не накладывается никаких ограничений, кроме определённых во время согласования ассоциации. SCP не должен ожидать, что SCU будет выполнять операции C-STORE в определённом порядке.

Аналогично, закрытию ассоциации не придаётся никакой семантики, такой как завершение исследования (Study) или выполненного этапа процедуры (Performed Procedure Step).

B.4.1 Соответствие в роли SCP

B.4.1.1 Уровни поддержки хранения

Для SCP, заявляющего о соответствии SOP классам хранения, определены три уровня поддержки хранения:

  • Уровень хранения 0 (Local) указывает, что определяемое пользователем подмножество атрибутов SOP экземпляра будет сохранено, а все остальные будут отброшены. Это подмножество атрибутов должно быть определено в заявлении о соответствии разработчика.

  • Уровень хранения 1 (Base) указывает, что все атрибуты Type 1 и Type 2, определённые в IOD, связанном с SOP классом, будут сохранены и могут быть доступны. Все остальные элементы данных могут быть отброшены. SCP может, но не обязан проверять, что атрибуты SOP экземпляра соответствуют требованиям IOD.

  • Уровень хранения 2 (Full) указывает, что все атрибуты Type 1, Type 2 и Type 3, определённые в информационном определении объекта (IOD), связанном с SOP классом, а также любые стандартные расширенные атрибуты (включая приватные атрибуты), включённые в SOP экземпляр, будут сохранены и могут быть доступны. SCP может, но не обязан проверять, что атрибуты SOP экземпляра соответствуют требованиям IOD.

Примечание

SCP уровня хранения 2 может отбрасывать (не сохранять) атрибуты Type 3, которые пусты (имеют нулевую длину и не содержат значения), поскольку значение пустого атрибута Type 3 совпадает с отсутствием атрибута. См. определение "Type 3 Optional Data Elements" в PS3.5.

B.4.1.2 Поддержка дополнительных SOP классов

SCP, заявляющий о соответствии уровню поддержки Storage Level 2 (Full) класса сервиса хранения, может принять любое согласование контекста представления для SOP класса, указывающего класс сервиса хранения во время SOP Class Common Extended Negotiation (см. Раздел B.3.1.3), без указания соответствия этому SOP классу в своём заявлении о соответствии.

Примечание

  1. SCP может поддерживать хранение всех SOP классов класса сервиса хранения, сохраняя все атрибуты как SCP уровня хранения 2.

  2. Это расширенное согласование позволяет SCP определить, что приватный SOP класс в предложенном контексте представления следует семантике класса сервиса хранения, и может быть обработан соответствующим образом.

SCP, заявляющий о соответствии уровню поддержки Storage Level 2 (Full) связанного общего SOP класса, может принять любое согласование контекста представления для SOP класса, указывающего этот связанный общий SOP класс во время SOP Class Common Extended Negotiation, без указания соответствия этому специализированному SOP классу в своём заявлении о соответствии.

Примечание

  1. Термин "специализированный" в этом разделе используется в общем смысле и включает как специализированные SOP классы, определённые реализацией, так и стандартные SOP классы, указанные в Таблице B.3-3.

  2. SCP может обрабатывать экземпляры таких специализированных SOP классов с использованием семантики связанного общего SOP класса, но сохраняя все дополнительные (потенциально Type 1 или 2) атрибуты как SCP уровня хранения 2.

  3. SCP, имеющий доступ к текущему содержимому Таблицы B.5-1, может использовать его для определения принятия предложенных контекстов представления SOP классов. Это позволяет SCP, даже без расширенного согласования, идентифицировать все стандартные SOP классы класса сервиса хранения. Доступ к Таблице B.5-1 может осуществляться приватным образом или через публикацию PS3 на веб-сайте Комитета по стандартам DICOM. Это обеспечивает автоматизированную альтернативу ручному редактированию таблицы поддерживаемых SOP классов хранения.

B.4.1.3 Принудительное изменение атрибутов

При любом уровне поддержки хранения SCP класса сервиса хранения может изменять значения определённых атрибутов для принудительного приведения SOP экземпляра к модели запроса SCP. Атрибуты, которые могут быть изменены, показаны в Таблице B.4-1.

Таблица B.4-1. Атрибуты, подлежащие принудительному изменению

Имя атрибута

Тег

Patient ID

(0010,0020)

Issuer of Patient ID

(0010,0021)

Other Patient IDs Sequence

(0010,1002)

Study Instance UID

(0020,000D)

Series Instance UID

(0020,000E)


SCP класса сервиса хранения может изменять значения атрибутов последовательности кодов (Code Sequence Attributes) для преобразования из одной схемы кодирования (Coding Scheme) в другую. Это включает замену устаревших значений Coding Scheme Designator (0008,0102) или Code Value (0008,0100) на действующие в настоящее время значения.

Если SCP выполняет такое изменение, он должен вернуть ответ C-STORE со статусом Warning (предупреждение).

Примечание

  1. Изменение этих атрибутов может потребоваться, если SCP также является SCP SOP классов Query/Retrieve. Эти SOP классы описаны в настоящем стандарте. Например, МР-сканер может быть реализован для генерации Study Instance UID для изображений, полученных на МР. При отправке этих изображений в архив, поддерживающий HIS/RIS, архив может изменить UID исследования, назначенный исследованию PACS. Механизм, с помощью которого выполняется это принудительное изменение, зависит от реализации.

  2. SCP может, например, преобразовать устаревшие Code Values со значением Coding Scheme Designator "99SDM", "SNM3" или "SRT" в соответствующие значения SCT Code Values и использовать обозначение схемы кодирования "SCT" в соответствии с соглашениями DICOM для SNOMED (см. PS3.16).

  3. Изменение атрибутов, которые могут использоваться для ссылки на SOP экземпляр другим SOP экземпляром (таких как атрибуты Study Instance UID и Series Instance UID), сделает эту ссылку недействительной. Изменение этих атрибутов настоятельно не рекомендуется.

  4. Другие атрибуты могут быть изменены/исправлены SCP SOP класса хранения.

  5. Изменение атрибутов может повлиять на цифровые подписи, ссылающиеся на содержимое SOP экземпляра.

B.4.1.4 Уровни поддержки цифровой подписи

Для SCP, заявляющего о соответствии уровню Storage Level 2 (Full), определены три уровня поддержки цифровой подписи:

  • На уровне подписи 1 SCP может не сохранять цифровые подписи и не заменять их.

  • На уровне подписи 2 SCP не сохраняет целостность входящих цифровых подписей, но проверяет цифровые подписи сохраняемых SOP экземпляров, принимает зависящие от реализации меры для обеспечения целостности сохраняемых данных и добавляет заменяющие цифровые подписи перед отправкой SOP экземпляров в другое место.

  • На уровне подписи 3 SCP сохраняет целостность входящих цифровых подписей (т.е. является битово-сохраняющим и сохраняет и извлекает все атрибуты независимо от того, определены ли они в IOD).

B.4.2 Соответствие в роли SCU

SCU должен генерировать только запросы C-STORE с SOP экземплярами, которые соответствуют требованиям IOD, связанного с SOP классом.

B.4.2.1 Резервное поведение SCU

Во время согласования ассоциации приложение может предложить специализированный SOP класс и его связанный общий SOP класс в отдельных контекстах представления как Storage SCU. Если акцептор ассоциации отклоняет контекст представления специализированного SOP класса, но принимает контекст представления связанного общего SOP класса, приложение может отправлять экземпляры специализированного SOP класса как экземпляры связанного общего SOP класса. При таком резервном поведении SOP Class UID экземпляра должен быть UID связанного общего SOP класса, а любая специальная семантика, связанная со специализированным SOP классом, может быть утеряна; SOP Instance UID должен остаться неизменным.

Примечание

SCU может включить SOP Class UID исходного предполагаемого специализированного SOP класса в атрибут Original Specialized SOP Class UID (0008,001B) экземпляра, отправленного под связанным общим SOP классом. В некоторых случаях, например, когда все промежуточные приложения хранения являются SCP уровня хранения 2, это может позволить конечному получателю экземпляра восстановить его как экземпляр IOD специализированного SOP класса. Однако такое преобразование не гарантируется.

B.4.3 Требования к заявлению о соответствии

Реализация может соответствовать SOP классу класса сервиса хранения в роли SCU, SCP или обеих. Заявление о соответствии должно быть в формате, определённом в PS3.2.

B.4.3.1 Заявление о соответствии для SCU

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

  • Должно быть описано поведение SCU в случае успешного статуса ответа C-STORE.

  • Должно быть описано поведение SCU в каждом случае неуспешного статуса ответа C-STORE.

  • Поведение SCU в случае получения статуса Warning (предупреждение) в ответ на операцию C-STORE.

  • Поддерживается ли расширенное согласование.

  • Должны быть перечислены необязательные элементы, которые могут быть включены в SOP экземпляры хранения для каждого поддерживаемого IOD.

  • Стандартные и приватные функциональные группы (Functional Groups), которые могут быть включены в SOP экземпляры хранения для каждого много кадрового IOD (Multi-frame IOD), поддерживающего функциональные группы.

  • Должно быть описано поведение SCU в случае операции C-STORE с использованием синтаксиса передачи со ссылочными данными пикселей, такого как JPIP Referenced Pixel Data Transfer Syntax. Это включает длительность действия ссылки

B.4.3.2 Заявление о соответствии для SCP

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

  • Должен быть указан уровень поддержки хранения, как определено в Разделе B.4.1.

  • Должен быть указан уровень поддержки цифровой подписи, как определено в Разделе B.4.1.

  • Должны быть перечислены необязательные атрибуты, которые будут отброшены (если таковые имеются), для каждого поддерживаемого IOD.

  • Должны быть указаны механизмы, с помощью которых динамически поддерживаются дополнительные SOP классы, как определено в Разделе B.4.1.2.

  • Заявление о соответствии должно документировать политику в отношении атрибута Lossy Image Compression (0028,2110).

  • Должно быть описано поведение SCP в случае успешной операции C-STORE. Это включает следующее:

    • метод доступа к сохранённому SOP экземпляру

    • длительность хранения

  • Должно быть описано значение каждого случая неуспешного статуса ответа C-STORE, а также соответствующее действие по восстановлению.

  • Должно быть описано значение каждого случая предупреждающего статуса ответа C-STORE, а также соответствующее действие.

  • Если SCP выполняет принудительное изменение каких-либо атрибутов, это должно быть указано, а условия, при которых это может произойти, должны быть описаны.

B.4.4 Специализированное соответствие

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

Реализации разрешается соответствовать как специализации стандартного SOP класса в роли SCU, SCP или обеих. Заявление о соответствии должно быть в формате, определённом в PS3.2.

B.4.4.1 Идентификация специализированного SOP класса

Любая реализация, которая специализирует стандартный SOP класс, должна определить свою специализацию как алломорфный подкласс (Allomorphic subclass) стандартного SOP класса. Как таковая, специализация должна иметь свою собственную уникальную идентификацию SOP класса.

Заявление о соответствии должно включать заявление об идентификации SOP класса, как определено в PS3.2, декларирующее SOP Name и SOP Class UID, которые идентифицируют специализированный SOP класс. SOP Name не гарантирует уникальность (если только разработчик не решит зарегистрировать его авторским правом), но предоставляется для неформальной идентификации SOP класса. SOP Class UID должен однозначно идентифицировать специализированный SOP класс и соответствовать требованиям к UID DICOM, указанным в PS3.5.

B.4.4.2 Специализированное определение информационного объекта

Стандартный SOP класс может быть специализирован путём поддержки дополнительных приватных атрибутов. Заявление о соответствии должно описывать эти специализации и должно быть оформлено, как определено в PS3.2.

B.5 Стандартные SOP классы

SOP классы в классе сервиса хранения идентифицируют Composite IOD, подлежащие хранению. Таблица B.5-1 определяет стандартные SOP классы.

Таблица B.5-1. Стандартные SOP классы

Имя SOP класса

SOP Class UID

Спецификация IOD (определена в PS3.3)

Специализация

Computed Radiography Image Storage

1.2.840.10008.5.1.4.1.1.1

Computed Radiography Image IOD

Digital X-Ray Image Storage - For Presentation

1.2.840.10008.5.1.4.1.1.1.1

Digital X-Ray Image IOD

B.5.1.1

Digital X-Ray Image Storage - For Processing

1.2.840.10008.5.1.4.1.1.1.1.1

Digital X-Ray Image IOD

B.5.1.1

Digital Mammography X-Ray Image Storage - For Presentation

1.2.840.10008.5.1.4.1.1.1.2

Digital Mammography X-Ray Image IOD

B.5.1.2

Digital Mammography X-Ray Image Storage - For Processing

1.2.840.10008.5.1.4.1.1.1.2.1

Digital Mammography X-Ray Image IOD

B.5.1.2

Digital Intra-Oral X-Ray Image Storage - For Presentation

1.2.840.10008.5.1.4.1.1.1.3

Digital Intra-Oral X-Ray Image IOD

B.5.1.3

Digital Intra-Oral X-Ray Image Storage - For Processing

1.2.840.10008.5.1.4.1.1.1.3.1

Digital Intra-Oral X-Ray Image IOD

B.5.1.3

CT Image Storage

1.2.840.10008.5.1.4.1.1.2

CT Image IOD

Enhanced CT Image Storage

1.2.840.10008.5.1.4.1.1.2.1

Enhanced CT Image IOD

B.5.1.7

B.5.1.23

Legacy Converted Enhanced CT Image Storage

1.2.840.10008.5.1.4.1.1.2.2

Legacy Converted Enhanced CT Image IOD

B.5.1.7

B.5.1.23

Ultrasound Multi-frame Image Storage

1.2.840.10008.5.1.4.1.1.3.1

Ultrasound Multi-frame Image IOD

MR Image Storage

1.2.840.10008.5.1.4.1.1.4

MR Image IOD

Enhanced MR Image Storage

1.2.840.10008.5.1.4.1.1.4.1

Enhanced MR Image IOD

B.5.1.6

B.5.1.23

MR Spectroscopy Storage

1.2.840.10008.5.1.4.1.1.4.2

MR Spectroscopy IOD

Enhanced MR Color Image Storage

1.2.840.10008.5.1.4.1.1.4.3

Enhanced MR Color Image IOD

B.5.1.8

B.5.1.23

Legacy Converted Enhanced MR Image Storage

1.2.840.10008.5.1.4.1.1.4.4

Legacy Converted Enhanced MR Image IOD

B.5.1.6

B.5.1.23

Ultrasound Image Storage

1.2.840.10008.5.1.4.1.1.6.1

Ultrasound Image IOD

Enhanced US Volume Storage

1.2.840.10008.5.1.4.1.1.6.2

Enhanced US Volume IOD

Photoacoustic Image Storage

1.2.840.10008.5.1.4.1.1.6.3

Photoacoustic Image IOD

Secondary Capture Image Storage

1.2.840.10008.5.1.4.1.1.7

Secondary Capture Image IOD

Multi-frame Single Bit Secondary Capture Image Storage

1.2.840.10008.5.1.4.1.1.7.1

Multi-frame Single Bit Secondary Capture Image IOD

Multi-frame Grayscale Byte Secondary Capture Image Storage

1.2.840.10008.5.1.4.1.1.7.2

Multi-frame Grayscale Byte Secondary Capture Image IOD

Multi-frame Grayscale Word Secondary Capture Image Storage

1.2.840.10008.5.1.4.1.1.7.3

Multi-frame Grayscale Word Secondary Capture Image IOD

Multi-frame True Color Secondary Capture Image Storage

1.2.840.10008.5.1.4.1.1.7.4

Multi-frame True Color Secondary Capture Image IOD

12-lead ECG Waveform Storage

1.2.840.10008.5.1.4.1.1.9.1.1

12-Lead ECG IOD

General ECG Waveform Storage

1.2.840.10008.5.1.4.1.1.9.1.2

General ECG IOD

Ambulatory ECG Waveform Storage

1.2.840.10008.5.1.4.1.1.9.1.3

Ambulatory ECG IOD

General 32-bit ECG Waveform Storage

1.2.840.10008.5.1.4.1.1.9.1.4

General 32-bit ECG IOD

Hemodynamic Waveform Storage

1.2.840.10008.5.1.4.1.1.9.2.1

Hemodynamic Waveform IOD

Cardiac Electrophysiology Waveform Storage

1.2.840.10008.5.1.4.1.1.9.3.1

Basic Cardiac Electrophysiology Waveform IOD

Basic Voice Audio Waveform Storage

1.2.840.10008.5.1.4.1.1.9.4.1

Basic Voice Audio Waveform IOD

General Audio Waveform Storage

1.2.840.10008.5.1.4.1.1.9.4.2

General Audio Waveform IOD

Arterial Pulse Waveform Storage

1.2.840.10008.5.1.4.1.1.9.5.1

Arterial Pulse Waveform IOD

Respiratory Waveform Storage

1.2.840.10008.5.1.4.1.1.9.6.1

Respiratory Waveform IOD

Multi-channel Respiratory Waveform Storage

1.2.840.10008.5.1.4.1.1.9.6.2

Multi-channel Respiratory Waveform IOD

Routine Scalp Electroencephalogram Waveform Storage

1.2.840.10008.5.1.4.1.1.9.7.1

Routine Scalp Electroencephalogram IOD

Electromyogram Waveform Storage

1.2.840.10008.5.1.4.1.1.9.7.2

Electromyogram IOD

Electrooculogram Waveform Storage

1.2.840.10008.5.1.4.1.1.9.7.3

Electrooculogram IOD

Sleep Electroencephalogram Waveform Storage

1.2.840.10008.5.1.4.1.1.9.7.4

Sleep Electroencephalogram IOD

Body Position Waveform Storage

1.2.840.10008.5.1.4.1.1.9.8.1

Body Position Waveform IOD

Waveform Presentation State Storage

1.2.840.10008.5.1.4.1.1.9.100.1

Waveform Presentation State IOD

Waveform Acquisition Presentation State Storage

1.2.840.10008.5.1.4.1.1.9.100.2

Waveform Acquisition Presentation State IOD

Grayscale Softcopy Presentation State Storage

1.2.840.10008.5.1.4.1.1.11.1

Grayscale Softcopy Presentation State IOD

Color Softcopy Presentation State Storage

1.2.840.10008.5.1.4.1.1.11.2

Color Softcopy Presentation State IOD

Pseudo-Color Softcopy Presentation State Storage

1.2.840.10008.5.1.4.1.1.11.3

Pseudo-Color Softcopy Presentation State IOD

Blending Softcopy Presentation State Storage

1.2.840.10008.5.1.4.1.1.11.4

Blending Softcopy Presentation State IOD

XA/XRF Grayscale Softcopy Presentation State Storage

1.2.840.10008.5.1.4.1.1.11.5

XA/XRF Grayscale Softcopy Presentation State IOD

Grayscale Planar MPR Volumetric Presentation State Storage

1.2.840.10008.​5.​1.​4.​1.​1.​11.​6

Planar MPR Volumetric Presentation State IOD

B.5.1.19

Compositing Planar MPR Volumetric Presentation State Storage

1.2.840.10008.​5.​1.​4.​1.​1.​11.​7

Planar MPR Volumetric Presentation State IOD

B.5.1.19

Advanced Blending Presentation State Storage

1.2.840.10008.5.1.4.1.1.11.8

Advanced Blending Presentation State IOD

Volume Rendering Volumetric Presentation State Storage

1.2.840.10008.5.1.4.1.1.11.9

Volume Rendering Volumetric Presentation State IOD

B.5.1.24

Segmented Volume Rendering Volumetric Presentation State Storage

1.2.840.10008.5.1.4.1.1.11.10

Volume Rendering Volumetric Presentation State IOD

B.5.1.24

Multiple Volume Rendering Volumetric Presentation State Storage

1.2.840.10008.5.1.4.1.1.11.11

Volume Rendering Volumetric Presentation State IOD

B.5.1.24

Variable Modality LUT Softcopy Presentation State Storage

1.2.840.10008.5.1.4.1.1.11.12

Variable Modality LUT Softcopy Presentation State IOD

X-Ray Angiographic Image Storage

1.2.840.10008.5.1.4.1.1.12.1

X-Ray Angiographic Image IOD

Enhanced XA Image Storage

1.2.840.10008.5.1.4.1.1.12.1.1

Enhanced XA Image IOD

X-Ray Radiofluoroscopic Image Storage

1.2.840.10008.5.1.4.1.1.12.2

X-Ray Radiofluoroscopic Image IOD

Enhanced XRF Image Storage

1.2.840.10008.5.1.4.1.1.12.2.1

Enhanced XRF Image IOD

X-Ray 3D Angiographic Image Storage

1.2.840.10008.5.1.4.1.1.13.1.1

X-Ray 3D Angiographic Image IOD

X-Ray 3D Craniofacial Image Storage

1.2.840.10008.5.1.4.1.1.13.1.2

X-Ray 3D Craniofacial Image IOD

Breast Tomosynthesis Image Storage

1.2.840.10008.5.1.4.1.1.13.1.3

Breast Tomosynthesis Image IOD

Breast Projection X-Ray Image Storage - For Presentation

1.2.840.10008.5.1.4.1.1.13.1.4

Breast Projection X-Ray Image IOD

B.5.1.18

Breast Projection X-Ray Image Storage - For Processing

1.2.840.10008.5.1.4.1.1.13.1.5

Breast Projection X-Ray Image IOD

B.5.1.18

Intravascular Optical Coherence Tomography Image Storage - For Presentation

1.2.840.10008.5.1.4.1.1.14.1

Intravascular Optical Coherence Tomography Image IOD

B.5.1.13

Intravascular Optical Coherence Tomography Image Storage - For Processing

1.2.840.10008.5.1.4.1.1.14.2

Intravascular Optical Coherence Tomography Image IOD

B.5.1.13

Nuclear Medicine Image Storage

1.2.840.10008.5.1.4.1.1.20

Nuclear Medicine Image IOD

Parametric Map Storage

1.2.840.10008.5.1.4.1.1.30

Parametric Map IOD

Raw Data Storage

1.2.840.10008.5.1.4.1.1.66

Raw Data IOD

B.5.1.22

Spatial Registration Storage

1.2.840.10008.5.1.4.1.1.66.1

Spatial Registration IOD

Spatial Fiducials Storage

1.2.840.10008.5.1.4.1.1.66.2

Spatial Fiducials IOD

Deformable Spatial Registration Storage

1.2.840.10008.5.1.4.1.1.66.3

Deformable Spatial Registration IOD

Segmentation Storage

1.2.840.10008.5.1.4.1.1.66.4

Segmentation IOD

B.5.1.25

Surface Segmentation Storage

1.2.840.10008.5.1.4.1.1.66.5

Surface Segmentation IOD

Tractography Results Storage

1.2.840.10008.5.1.4.1.1.66.6

Tractography Results IOD

Label Map Segmentation Storage

1.2.840.10008.5.1.4.1.1.66.7

Segmentation IOD

B.5.1.25

Height Map Segmentation Storage

1.2.840.10008.5.1.4.1.1.66.8

Height Map Segmentation IOD

Real World Value Mapping Storage

1.2.840.10008.5.1.4.1.1.67

Real World Value Mapping IOD

Surface Scan Mesh Storage

1.2.840.10008.5.1.4.1.1.68.1

Surface Scan Mesh IOD

Surface Scan Point Cloud Storage

1.2.840.10008.5.1.4.1.1.68.2

Surface Scan Point Cloud IOD

VL Endoscopic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.1

VL Endoscopic Image IOD

Video Endoscopic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.1.1

Video Endoscopic Image IOD

VL Microscopic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.2

VL Microscopic Image IOD

Video Microscopic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.2.1

Video Microscopic Image IOD

VL Slide-Coordinates Microscopic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.3

VL Slide-Coordinates Microscopic Image IOD

VL Photographic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.4

VL Photographic Image IOD

Video Photographic Image Storage

1.2.840.10008.5.1.4.1.1.77.1.4.1

Video Photographic Image IOD

Ophthalmic Photography 8 Bit Image Storage

1.2.840.10008.5.1.4.1.1.77.1.5.1

Ophthalmic Photography 8 Bit Image IOD

Ophthalmic Photography 16 Bit Image Storage

1.2.840.10008.5.1.4.1.1.77.1.5.2

Ophthalmic Photography 16 Bit Image IOD

Stereometric Relationship Storage

1.2.840.10008.5.1.4.1.1.77.1.5.3

Stereometric Relationship IOD

Ophthalmic Tomography Image Storage

1.2.840.10008.5.1.4.1.1.77.1.5.4

Ophthalmic Tomography Image IOD

Wide Field Ophthalmic Photography Stereographic Projection Image Storage

1.2.840.10008.5.1.4.1.1.77.1.5.5

Wide Field Ophthalmic Photography Stereographic Projection Image IOD

Wide Field Ophthalmic Photography 3D Coordinates Image Storage

1.2.840.10008.5.1.4.1.1.77.1.5.6

Wide Field Ophthalmic Photography 3D Coordinates Image IOD

Ophthalmic Optical Coherence Tomography En Face Image Storage

1.2.840.10008.5.1.4.1.1.77.1.5.7

Ophthalmic Optical Coherence Tomography En Face Image IOD

Ophthalmic Optical Coherence Tomography B-scan Volume Analysis Storage

1.2.840.10008.5.1.4.1.1.77.1.5.8

Ophthalmic Optical Coherence Tomography B-scan Volume Analysis IOD

VL Whole Slide Microscopy Image Storage

1.2.840.10008.5.1.4.1.1.77.1.6

VL Whole Slide Microscopy Image IOD

Dermoscopic Photography Image Storage

1.2.840.10008.5.1.4.1.1.77.1.7

Dermoscopic Photography Image IOD

Confocal Microscopy Image Storage

1.2.840.10008.5.1.4.1.1.77.1.8

Confocal Microscopy Image IOD

Confocal Microscopy Tiled Pyramidal Image Storage

1.2.840.10008.5.1.4.1.1.77.1.9

Confocal Microscopy Tiled Pyramidal Image IOD

Lensometry Measurements Storage

1.2.840.10008.5.1.4.1.1.78.1

Lensometry Measurements IOD

Autorefraction Measurements Storage

1.2.840.10008.5.1.4.1.1.78.2

Autorefraction Measurements IOD

Keratometry Measurements Storage

1.2.840.10008.5.1.4.1.1.78.3

Keratometry Measurements IOD

Subjective Refraction Measurements Storage

1.2.840.10008.5.1.4.1.1.78.4

Subjective Refraction Measurements IOD

Visual Acuity Measurements Storage

1.2.840.10008.5.1.4.1.1.78.5

Visual Acuity Measurements IOD

Spectacle Prescription Report Storage

1.2.840.10008.5.1.4.1.1.78.6

Spectacle Prescription Report IOD

B.5.1.5

Ophthalmic Axial Measurements Storage

1.2.840.10008.5.1.4.1.1.78.7

Ophthalmic Axial Measurements IOD

B.5.1.11

Intraocular Lens Calculations Storage

1.2.840.10008.5.1.4.1.1.78.8

Intraocular Lens Calculations IOD

Macular Grid Thickness and Volume Report

1.2.840.10008.5.1.4.1.1.79.1

Macular Grid Thickness and Volume Report IOD

B.5.1.5

Ophthalmic Visual Field Static Perimetry Measurements Storage

1.2.840.10008.5.1.4.1.1.80.1

Ophthalmic Visual Field Static Perimetry Measurements IOD

Ophthalmic Thickness Map Storage

1.2.840.10008.5.1.4.1.1.81.1

Ophthalmic Thickness Map IOD

B.5.1.14

Corneal Topography Map Storage

1.2.840.10008.5.1.4.1.1.82.1

Corneal Topography Map IOD

B.5.1.17

Basic Text SR Storage

1.2.840.10008.5.1.4.1.1.88.11

Basic Text SR IOD

B.5.1.5

Enhanced SR Storage

1.2.840.10008.5.1.4.1.1.88.22

Enhanced SR IOD

B.5.1.5

Comprehensive SR Storage

1.2.840.10008.5.1.4.1.1.88.33

Comprehensive SR IOD

B.5.1.5

Comprehensive 3D SR Storage

1.2.840.10008.5.1.4.1.1.88.34

Comprehensive 3D SR IOD

B.5.1.5

Extensible SR Storage

1.2.840.10008.5.1.4.1.1.88.35

Extensible SR IOD

B.5.1.5

Procedure Log Storage

1.2.840.10008.5.1.4.1.1.88.40

Procedure Log IOD

B.5.1.5

Mammography CAD SR Storage

1.2.840.10008.5.1.4.1.1.88.50

Mammography CAD SR IOD

B.5.1.5

Key Object Selection Document Storage

1.2.840.10008.5.1.4.1.1.88.59

Key Object Selection Document IOD

Chest CAD SR Storage

1.2.840.10008.5.1.4.1.1.88.65

Chest CAD SR IOD

B.5.1.5

X-Ray Radiation Dose SR Storage

1.2.840.10008.5.1.4.1.1.88.67

X-Ray Radiation Dose SR IOD

B.5.1.5

Radiopharmaceutical Radiation Dose SR Storage

1.2.840.10008.5.1.4.1.1.88.68

Radiopharmaceutical Radiation Dose SR IOD

B.5.1.5

Colon CAD SR Storage

1.2.840.10008.5.1.4.1.1.88.69

Colon CAD SR IOD

B.5.1.5

Implantation Plan SR Storage

1.2.840.10008.5.1.4.1.1.88.70

Implantation Plan SR Document IOD

B.5.1.5

Acquisition Context SR Storage

1.2.840.10008.5.​1.​4.​1.​1.​88.​71

Acquisition Context SR IOD

B.5.1.5

Simplified Adult Echo SR Storage

1.2.840.10008.5.​1.​4.​1.​1.​88.​72

Simplified Adult Echo SR IOD

B.5.1.5

Patient Radiation Dose SR Storage

1.2.840.10008.5.​1.​4.​1.​1.​88.​73

Patient Radiation Dose SR IOD

B.5.1.5

Planned Imaging Agent Administration SR Storage

1.2.840.10008.5.​1.​4.​1.​1.​88.​74

Planned Imaging Agent Administration SR IOD

B.5.1.5

Performed Imaging Agent Administration SR Storage

1.2.840.10008.5.​1.​4.​1.​1.​88.​75

Performed Imaging Agent Administration SR IOD

B.5.1.5

Enhanced X-Ray Radiation Dose SR Storage

1.2.840.10008.5.​1.​4.​1.​1.​88.​76

Enhanced X-Ray Radiation Dose SR IOD

B.5.1.5

Waveform Annotation SR Storage

1.2.840.10008.5.​1.​4.​1.​1.​88.​77

Waveform Annotation SR IOD

B.5.1.5

Content Assessment Results Storage

1.2.840.10008.5.1.4.1.1.90.1

Content Assessment Results IOD

B.5.1.20

Microscopy Bulk Simple Annotations Storage

1.2.840.10008.5.1.4.1.1.91.1

Microscopy Bulk Simple Annotations IOD

Encapsulated PDF Storage

1.2.840.10008.5.1.4.1.1.104.1

Encapsulated PDF IOD

Encapsulated CDA Storage

1.2.840.10008.5.1.4.1.1.104.2

Encapsulated CDA IOD

Encapsulated STL Storage

1.2.840.10008.5.1.4.1.1.104.3

Encapsulated STL IOD

Encapsulated OBJ Storage

1.2.840.10008.5.1.4.1.1.104.4

Encapsulated OBJ IOD

Encapsulated MTL Storage

1.2.840.10008.5.1.4.1.1.104.5

Encapsulated MTL IOD

Positron Emission Tomography Image Storage

1.2.840.10008.5.1.4.1.1.128

Positron Emission Tomography Image IOD

Enhanced PET Image Storage

1.2.840.10008.5.1.4.1.1.130

Enhanced PET Image IOD

B.5.1.16

B.5.1.23

Legacy Converted Enhanced PET Image Storage

1.2.840.10008.5.1.4.1.1.128.1

Legacy Converted Enhanced PET Image IOD

B.5.1.23

Basic Structured Display Storage

1.2.840.10008.5.1.4.1.1.131

Basic Structured Display IOD

B.5.1.9

CT Performed Procedure Protocol Storage

1.2.840.10008.5.1.4.1.1.200.2

CT Performed Procedure Protocol IOD

B.5.1.21

XA Performed Procedure Protocol Storage

1.2.840.10008.5.1.4.1.1.200.8

XA Performed Procedure Protocol IOD

B.5.1.21

RT Image Storage

1.2.840.10008.5.1.4.1.1.481.1

RT Image IOD

RT Dose Storage

1.2.840.10008.5.1.4.1.1.481.2

RT Dose IOD

RT Structure Set Storage

1.2.840.10008.5.1.4.1.1.481.3

RT Structure Set IOD

RT Beams Treatment Record Storage

1.2.840.10008.5.1.4.1.1.481.4

RT Beams Treatment Record IOD

RT Plan Storage

1.2.840.10008.5.1.4.1.1.481.5

RT Plan IOD

RT Brachy Treatment Record Storage

1.2.840.10008.5.1.4.1.1.481.6

RT Brachy Treatment Record IOD

RT Treatment Summary Record Storage

1.2.840.10008.5.1.4.1.1.481.7

RT Treatment Summary Record IOD

RT Ion Plan Storage

1.2.840.10008.5.1.4.1.1.481.8

RT Ion Plan IOD

RT Ion Beams Treatment Record Storage

1.2.840.10008.5.1.4.1.1.481.9

RT Ion Beams Treatment Record IOD

RT Physician Intent Storage

1.2.840.10008.5.1.4.1.1.481.10

RT Physician Intent IOD

RT Segment Annotation Storage

1.2.840.10008.5.1.4.1.1.481.11

RT Segment Annotation IOD

RT Radiation Set Storage

1.2.840.10008.5.1.4.1.1.481.12

RT Radiation Set IOD

C-Arm Photon-Electron Radiation Storage

1.2.840.10008.5.1.4.1.1.481.13

C-Arm Photon-Electron Radiation IOD

Tomotherapeutic Radiation Storage

1.2.840.10008.5.1.4.1.1.481.14

Tomotherapeutic Radiation IOD

Robotic-Arm Radiation Storage

1.2.840.10008.5.1.4.1.1.481.15

Robotic-Arm Radiation IOD

RT Radiation Record Set Storage

1.2.840.10008.5.1.4.1.1.481.16

RT Radiation Record Set IOD

RT Radiation Salvage Record Storage

1.2.840.10008.5.1.4.1.1.481.17

RT Radiation Salvage Record IOD

Tomotherapeutic Radiation Record Storage

1.2.840.10008.5.1.4.1.1.481.18

Tomotherapeutic Radiation Record IOD

C-Arm Photon-Electron Radiation Record Storage

1.2.840.10008.5.1.4.1.1.481.19

C-Arm Photon-Electron Radiation Record IOD

Robotic Radiation Record Storage

1.2.840.10008.5.1.4.1.1.481.20

Robotic-Arm Radiation Record IOD

RT Radiation Set Delivery Instruction Storage

1.2.840.10008.5.1.4.1.1.481.21

RT Radiation Set Delivery Instruction IOD

RT Treatment Preparation Storage

1.2.840.10008.5.1.4.1.1.481.22

RT Treatment Preparation IOD

Enhanced RT Image Storage

1.2.840.10008.5.1.4.1.1.481.23

Enhanced RT Image IOD

Enhanced Continuous RT Image Storage

1.2.840.10008.5.1.4.1.1.481.24

Enhanced Continuous RT Image IOD

RT Patient Position Acquisition Instruction Storage

1.2.840.10008.5.1.4.1.1.481.25

RT Patient Position Acquisition Instruction IOD

RT Beams Delivery Instruction Storage

1.2.840.10008.5.1.4.34.7

RT Beams Delivery Instruction IOD

RT Brachy Application Setup Delivery Instruction Storage

1.2.840.10008.5.1.4.34.10

RT Brachy Application Setup Delivery Instruction IOD


Примечание

SOP классы Generic Implant Template Storage, Implant Assembly Template Storage и Implant Template Group Storage ранее были указаны в данной таблице, что было некорректно, поскольку они не используют информационную модель Patient / Study / Series / Instance. Они были объединены в класс сервиса Non-Patient Object Storage Service Class (см. Приложение GG).

B.5.1 Специализация для стандартных SOP классов

B.5.1.1 SOP классы Digital X-Ray Image Storage

SOP класс Digital X-Ray Image Storage - For Presentation должен использовать DX IOD с перечисляемым значением FOR PRESENTATION для атрибута Presentation Intent Type (0008,0068).

SOP класс Digital X-Ray Image Storage - For Processing должен использовать DX IOD с перечисляемым значением FOR PROCESSING для атрибута Presentation Intent Type (0008,0068).

SCU или SCP класса Digital X-Ray Image Storage - For Processing также должен поддерживать SOP класс Digital X-Ray Image Storage - For Presentation в той же роли.

Примечание

  1. Цель данного требования — обеспечить полезный уровень совместимости, избегая ситуации, когда SCU может поддерживать только SOP класс Digital X-Ray Image Storage - For Processing, а SCP — только SOP класс Digital X-Ray Image Storage - For Presentation, или наоборот. Таким образом, бременем является поддержка SOP класса Digital X-Ray Image Storage - For Presentation в качестве "базового".

  2. Термин "поддержка" используется в данном разделе в том смысле, что SCU или SCP должен быть способен отправлять или принимать SOP класс For Presentation. Нет намерения подразумевать, что SCU должен всегда отправлять экземпляр SOP класса For Presentation при отправке экземпляра SOP класса For Processing.

    Также нет намерения подразумевать, что во время установления ассоциации инициатор должен предлагать контекст презентации для SOP класса For Presentation. Однако акцептор ассоциации может отклонить контекст презентации для SOP класса For Presentation, если он принимает контекст презентации для SOP класса For Processing и предпочитает данный SOP класс; в этом случае он может больше не иметь возможности "передать" объект в дальнейшем как SCU, если только он не способен сгенерировать объект For Presentation.

    SCP не может определить по предложенным контекстам презентации, "поддерживает" ли SCU (способен ли отправлять) экземпляры обоих SOP классов For Processing и For Presentation. Такое определение требует априорного знания информации, содержащейся в заявлении о соответствии SCU, а также того, как SCU сконфигурирован и эксплуатируется. SCU, поддерживающий оба SOP класса, может вполне выбрать для предложения только один из них во время установления ассоциации, в зависимости от того, какие экземпляры он фактически намерен отправить через данную конкретную ассоциацию (хотя SCU должен быть способен отправлять экземпляры SOP класса For Presentation, если SCP не принимает For Processing).

    Цель требования состоит в том, что если SCU способен отправлять только SOP класс For Presentation, любой SCP гарантированно сможет его принять. И наоборот, если SCP способен принимать только SOP класс For Presentation, любой SCU гарантированно сможет его отправить.

B.5.1.2 SOP классы Digital Mammography X-Ray Image Storage

SOP класс Digital Mammography X-Ray Image Storage - For Presentation должен использовать Digital Mammography IOD с перечисляемым значением FOR PRESENTATION для атрибута Presentation Intent Type (0008,0068).

SOP класс Digital Mammography X-Ray Image Storage - For Processing должен использовать Digital Mammography IOD с перечисляемым значением FOR PROCESSING для атрибута Presentation Intent Type (0008,0068).

SCU или SCP класса Digital Mammography X-Ray Image Storage - For Processing также должен поддерживать SOP класс Digital Mammography X-Ray Image Storage - For Presentation в той же роли.

B.5.1.3 SOP классы Digital Intra-Oral X-Ray Image Storage

SOP класс Digital Intra-Oral X-Ray Image Storage - For Presentation должен использовать Digital Intra-Oral X-Ray IOD с перечисляемым значением FOR PRESENTATION для атрибута Presentation Intent Type (0008,0068).

SOP класс Digital Intra-Oral X-Ray Image Storage - For Processing должен использовать Digital Intra-Oral X-Ray IOD с перечисляемым значением FOR PROCESSING для атрибута Presentation Intent Type (0008,0068).

SCU или SCP класса Digital Intra-Oral X-Ray Image Storage - For Processing также должен поддерживать SOP класс Digital Intra-Oral X-Ray Image Storage - For Presentation в той же роли.

B.5.1.4 SOP классы Softcopy Presentation State Storage

См. Annex N.

B.5.1.5 SOP классы Structured Reporting Storage

Требования Приложения O применяются к следующим SOP классам:

  • Basic Text SR

  • Extensible SR, Enhanced SR, and SOP Classes for which it is the Related General SOP Class

  • Comprehensive 3D SR, Comprehensive SR, and SOP Classes for which they are the Related General SOP Classes

  • Mammography CAD SR

  • Chest CAD SR

  • Procedure Log

  • X-Ray Radiation Dose SR

  • Radiopharmaceutical Radiation Dose SR

  • Patient Radiation Dose SR

  • Enhanced X-Ray Radiation Dose SR Storage

  • Spectacle Prescription Report

  • Colon CAD SR

  • Macular Grid Thickness and Volume Report

  • Implantation Plan SR Document

  • Acquisition Context SR

  • Simplified Adult Echo SR

  • Waveform Annotation SR

Приложение O требования не применяются к SOP классу Key Object Selection Document.

B.5.1.6 SOP классы Enhanced MR Image Storage и Legacy Converted Enhanced MR Image Storage

SCP класса Enhanced MR Image Storage или Legacy Converted Enhanced MR Image Storage также должен поддерживать SOP класс Grayscale Softcopy Presentation State Storage в качестве SCP.

Примечание

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

B.5.1.7 SOP классы Enhanced CT Image Storage и Legacy Converted Enhanced CT Image Storage

SCP класса Enhanced CT Image Storage или Legacy Converted Enhanced CT Image Storage также должен поддерживать SOP класс Grayscale Softcopy Presentation State Storage в качестве SCP.

Примечание

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

B.5.1.8 SOP класс Enhanced MR Color Image Storage

SCP класса Enhanced MR Color Image Storage также должен поддерживать SOP класс Color Softcopy Presentation State Storage в качестве SCP.

Примечание

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

B.5.1.9 Basic Structured Display

SCU класса Basic Structured Display Storage, который создаёт SOP экземпляры данного SOP класса, должен указать в своём заявлении о соответствии составные SOP классы хранения и SOP классы хранения состояний программной презентации, которые также поддерживаются данным SCU и на которые могут ссылаться создаваемые им SOP экземпляры Basic Structured Display. Он должен указать в своём заявлении о соответствии значения, которые он может использовать в атрибутах Image Box Layout Type (0072,0304) и Type of Synchronization (0072,0434).

SCP класса Basic Structured Display Storage при визуализации SOP экземпляров данного SOP класса должен сохранять соотношение сторон, заданное атрибутами Nominal Screen Definition Sequence (0072,0102): Number of Vertical Pixels (0072,0104) и Number of Horizontal Pixels (0072,0106), без обрезки.

Примечание

  1. SCP не обязан отображать изображение, используя точное количество вертикальных и горизонтальных пикселей. SCP может использовать столько экранного пространства, сколько считает нужным, сохраняя соотношение сторон Structured Display.

  2. Если экран имеет другое соотношение сторон, позиционирование изображения на экране не определено (по центру, выравнивание по левому или правому краю, по верхнему или нижнему краю).

SCP класса Basic Structured Display Storage, способный визуализировать SOP экземпляры данного SOP класса, должен указать в своём заявлении о соответствии составные SOP классы хранения и SOP классы хранения состояний программной презентации, которые также поддерживаются данным SCP и будут отображаться при ссылке на них из SOP экземпляров Basic Structured Display. Он должен указать в своём заявлении о соответствии пользовательские средства управления отображением и взаимодействия для значений Image Box Layout Type (0072,0304) и Type of Synchronization (0072,0434), которые он поддерживает. Он должен указать в своём заявлении о соответствии своё поведение при обнаружении связанного состояния презентации или иного составного SOP экземпляра хранения, отображение которого он не поддерживает, либо неподдерживаемого значения Image Box Layout Type или Type of Synchronization; такое поведение должно как минимум включать отображение пользователю характера несовместимости.

B.5.1.10 SOP классы Implant Template Storage

См. Annex GG.

Примечание

Требования данного раздела были объединены в класс сервиса Non-Patient Object Storage Service Class (см. Раздел GG.6.3).

B.5.1.11 SOP класс Ophthalmic Axial Measurements Storage

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

Для устройства, которое является как SCU, так и SCP класса Ophthalmic Axial Measurements Storage, в дополнение к поведению для класса сервиса хранения, определённому в Разделе B.2.2, указаны следующие дополнительные требования для SOP классов Ophthalmic Axial Measurements Storage:

  • SCP данного SOP класса должен поддерживать уровень хранения 2 (Full), как определено в Разделе B.4.1.

Примечание

Данное требование означает, что все атрибуты Type 1, Type 2 и Type 3, определённые в определении информационного объекта, и приватные атрибуты, связанные с данным SOP классом, будут сохранены и могут быть доступны.

B.5.1.12 IOL Calculation Storage SOP Class

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

Для устройства, которое является как SCU, так и SCP класса IOL Calculation Storage, в дополнение к поведению для класса сервиса хранения, определённому в Разделе B.2.2, указаны следующие дополнительные требования для SOP классов IOL Calculation Storage:

  • SCP данного SOP класса должен поддерживать уровень хранения 2 (Full), как определено в Разделе B.4.1.

Примечание

Данное требование означает, что все атрибуты Type 1, Type 2 и Type 3, определённые в определении информационного объекта, и приватные атрибуты, связанные с данным SOP классом, будут сохранены и могут быть доступны.

B.5.1.13 Intravascular OCT Image Storage SOP Classes

SOP класс Intravascular OCT Image Storage - For Presentation должен использовать IVOCT IOD с перечисляемым значением FOR PRESENTATION для атрибута Presentation Intent Type (0008,0068).

SOP класс Intravascular OCT Image Storage - For Processing должен использовать IVOCT IOD с перечисляемым значением FOR PROCESSING для атрибута Presentation Intent Type (0008,0068).

SCU или SCP класса Intravascular OCT Image Storage - For Processing также должен поддерживать SOP класс Intravascular OCT Image Storage - For Presentation в той же роли.

Примечание

  1. Цель данного требования — обеспечить полезный уровень совместимости, избегая ситуации, когда SCU может поддерживать только SOP класс Intravascular OCT Image Storage - For Processing, а SCP — только SOP класс Intravascular OCT Image Storage - For Presentation, или наоборот. Таким образом, бременем является поддержка SOP класса Intravascular OCT Image Storage - For Presentation в качестве "базового".

  2. Термин "поддержка" используется в данном разделе в том смысле, что SCU или SCP должен быть способен отправлять или принимать SOP класс For Presentation. Нет намерения подразумевать, что SCU должен всегда отправлять экземпляр SOP класса For Presentation при отправке экземпляра SOP класса For Processing.

    Также нет намерения подразумевать, что во время установления ассоциации инициатор должен предлагать контекст презентации для SOP класса For Presentation. Однако акцептор ассоциации может отклонить контекст презентации для SOP класса For Presentation, если он принимает контекст презентации для SOP класса For Processing и предпочитает данный SOP класс; в этом случае он может больше не иметь возможности "передать" объект в дальнейшем как SCU, если только он не способен сгенерировать объект For Presentation.

    SCP не может определить по предложенным контекстам презентации, "поддерживает" ли SCU (способен ли отправлять) экземпляры обоих SOP классов For Processing и For Presentation. Такое определение требует априорного знания информации, содержащейся в заявлении о соответствии SCU, а также того, как SCU сконфигурирован и эксплуатируется. SCU, поддерживающий оба SOP класса, может вполне выбрать для предложения только один из них во время установления ассоциации, в зависимости от того, какие экземпляры он фактически намерен отправить через данную конкретную ассоциацию (хотя SCU должен быть способен отправлять экземпляры SOP класса For Presentation, если SCP не принимает For Processing).

    Цель требования состоит в том, что если SCU способен отправлять только SOP класс For Presentation, любой SCP гарантированно сможет его принять. И наоборот, если SCP способен принимать только SOP класс For Presentation, любой SCU гарантированно сможет его отправить.

B.5.1.14 Ophthalmic Thickness Map Storage SOP Class

SOP класс Ophthalmic Thickness Map кодирует топографическое представление измерений толщины/высоты заднего отдела глаза.

Для устройства, которое является как SCU, так и SCP класса Ophthalmic Thickness Map Storage, в дополнение к поведению для класса сервиса хранения, определённому в Разделе B.2.2, указаны следующие дополнительные требования для SOP классов Ophthalmic Thickness Map Storage:

  • SCP данного SOP класса должен поддерживать уровень хранения 2 (Full), как определено в Разделе B.4.1.

Примечание

Данное требование означает, что все атрибуты Type 1, Type 2 и Type 3, определённые в определении информационного объекта, и приватные атрибуты, связанные с данным SOP классом, будут сохранены и могут быть доступны.

B.5.1.15 Enhanced PET Image Storage and Legacy Converted Enhanced PET Image Storage SOP Class

SCP класса Enhanced PET Image Storage или Legacy Converted Enhanced PET Image Storage также должен поддерживать SOP класс Grayscale Softcopy Presentation State Storage и, по выбору, SOP класс Variable Modality LUT Softcopy Presentation State Storage в качестве SCP.

Примечание

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

B.5.1.16 Enhanced PET Image Storage SOP Classes

SCP класса Enhanced PET Image Storage также должен поддерживать SOP класс Grayscale Softcopy Presentation State Storage и, по выбору, SOP класс Variable Modality LUT Softcopy Presentation State Storage в качестве SCP.

Примечание

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

B.5.1.17 Corneal Topography Map Storage SOP Class

SOP класс Corneal Topography Map кодирует топографическое представление измерений кривизны и/или высоты передней и задней поверхностей роговицы (например, карты, отображающие кривизну роговицы, высоту роговицы и оптическую силу роговицы и т.д.).

SCP класса Corneal Topography Map Storage, визуализирующий SOP экземпляры данного SOP класса, должен применять преобразования изображений (т.е. Palette Color LUT) и Real World Value LUT для отображения аннотированной цветовой шкалы. Аннотированная цветовая шкала должна соответствовать "ISO Standard 19980 - Ophthalmic instruments - Corneal topographers, second edition, section B.4 Standardized Colour Scale." [ISO 19980]

SCP может отображать карту топографии роговицы, наложенную поверх изображения, на которое ссылается Source Image Sequence (0008,2112). При таком отображении пиксели карты топографии роговицы со значением атрибута Pixel Padding Value (0028,0120) должны визуализироваться прозрачно, чтобы соответствующие пиксели нижележащего изображения были видимы. Для отображения аннотированной цветовой шкалы SCP должен использовать только те значения, для которых определено сопоставление в Real World Value Mapping Sequence (0040,9096). Цвета, которые должны использоваться как для карты, так и для шкалы, определены атрибутами Palette Color Lookup Table.

Примечание

  1. Размер карты топографии роговицы обычно совпадает с размером нижележащего изображения, на которое она наложена, т.е. атрибуты Rows (0028,0010) и Columns (0028,0011) имеют те же значения, а ориентация и начало координат те же. В этом случае нет необходимости задавать Spatial Registration.

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

  3. Примеры визуализации наложенных изображений и аннотированной цветовой шкалы можно найти в Разделе NNN.2 «Корнеальные топографические шкалы и цветовые палитры» в PS3.17 и Разделе NNN.3 «Примеры топографии роговицы» в PS3.17.

Для устройства, которое является как SCU, так и SCP класса Corneal Topography Map Storage, в дополнение к поведению для класса сервиса хранения, определённому в Разделе B.2.2, указаны следующие дополнительные требования для SOP классов Corneal Topography Map Storage:

  • SCP данного SOP класса должен поддерживать уровень хранения 2 (Full), как определено в Разделе B.4.1.

Примечание

Данное требование означает, что все атрибуты Type 1, Type 2 и Type 3, определённые в определении информационного объекта, и приватные атрибуты, связанные с данным SOP классом, будут сохранены и могут быть доступны.

B.5.1.18 Breast Projection X-Ray Image Storage SOP Classes

SOP класс Breast Projection X-Ray Image Storage - For Presentation должен использовать Breast Projection X-Ray Image IOD с перечисляемым значением FOR PRESENTATION для атрибута Presentation Intent Type (0008,0068).

SOP класс Breast Projection X-Ray Image Storage - For Processing должен использовать Breast Projection X-Ray Image IOD с перечисляемым значением FOR PROCESSING для атрибута Presentation Intent Type (0008,0068).

SCU или SCP класса Breast Projection X-Ray Image Storage - For Processing также должен поддерживать SOP класс Breast Projection X-Ray Image Storage - For Presentation в той же роли.

B.5.1.19 Planar MPR Volumetric Presentation State Storage SOP Classes

Требования Раздела FF.2.1.1 применяются к следующим SOP классам:

  • Grayscale Planar MPR Volumetric Presentation State Storage

  • Compositing Planar MPR Volumetric Presentation State Storage

SOP класс Grayscale Planar MPR Volumetric Presentation State Storage должен использовать Planar MPR Volumetric Presentation State IOD с перечисляемым значением MONOCHROME для атрибута Pixel Presentation (0008,9205) и должен иметь только один элемент в Volumetric Presentation State Input Sequence (0070,1201).

SOP класс Compositing Planar MPR Volumetric Presentation State Storage должен использовать Planar MPR Volumetric Presentation State IOD с перечисляемым значением TRUE_COLOR для атрибута Pixel Presentation (0008,9205).

B.5.1.20 Content Assessment Results Storage SOP Classes

SCU класса Content Assessment Results Storage, который создаёт SOP экземпляры данного SOP класса, должен указать в своём заявлении о соответствии критерии для установки атрибута Observation Significance (0082,0008).

B.5.1.21 CT and XA Performed Procedure Protocol Storage SOP Classes

SOP классы CT and XA Performed Procedure Protocol Storage кодируют значения параметров протокола получения, реконструкции и хранения, использованные во время конкретной выполненной процедуры, а также связанные подробности.

Для устройства, которое является как SCU, так и SCP класса CT или XA Performed Procedure Protocol Storage, в дополнение к поведению для класса сервиса хранения, определённому в Разделе B.2.2, указаны следующие дополнительные требования для SOP классов CT and XA Performed Procedure Protocol Storage:

  • SCP данного SOP класса должен поддерживать уровень хранения 2 (Full), как определено в Разделе B.4.1.

Примечание

Данное требование означает, что все атрибуты Type 1, Type 2 и Type 3, определённые в определении информационного объекта, и приватные атрибуты, связанные с данным SOP классом, будут сохранены и могут быть доступны.

B.5.1.22 Raw Data Storage SOP Class

Для устройства, которое является как SCU, так и SCP класса Raw Data Storage, в дополнение к поведению для класса сервиса хранения, определённому в Разделе B.2.2, указаны следующие дополнительные требования для SOP класса Raw Data Storage:

  • SCP данного SOP класса должен поддерживать уровень хранения 2 (Full), как определено в Разделе B.4.1.

Примечание

Данное требование означает, что все атрибуты Type 1, Type 2 и Type 3, определённые в определении информационного объекта, и приватные атрибуты, связанные с данным SOP классом, будут сохранены и могут быть доступны.

B.5.1.23 Enhanced Multi-Frame Image SOP Classes

SCP любого из SOP классов Enhanced Multi-Frame Image, который делает SOP экземпляры доступными через расширенное согласование Enhanced Multi-Frame Image Conversion класса сервиса Query/Retrieve (см. Раздел C.3.5), должен поддерживать уровень хранения 2 (Full).

Примечание

Эффективное использование параметра Image Conversion требует хранения атрибутов Type 3.

B.5.1.24 Volume Rendering Volumetric Presentation State Storage SOP Classes

Требования Раздела FF.2.1.2 применяются к следующим SOP классам:

  • Volume Rendering Volumetric Presentation State SOP Class

  • Segmented Volume Rendering Volumetric Presentation State SOP Class

  • Multiple Volume Rendering Volumetric Presentation State SOP Class

SOP класс Volume Rendering Volumetric Presentation State Storage должен использовать Volume Rendering Volumetric Presentation State IOD и включать один элемент в Volumetric Presentation State Input Sequence (0070,1201) и один элемент в Volume Stream Sequence (0070,1A08). Кроме того, значение атрибута Crop (0070,1204) должно быть NO.

SOP класс Segmented Volume Rendering Volumetric Presentation State Storage должен использовать Volume Rendering Volumetric Presentation State IOD и включать один элемент в Volume Stream Sequence (0070,1A08).

SOP класс Multiple Volume Rendering Volumetric Presentation State Storage должен использовать Volume Rendering Volumetric Presentation State IOD и включать два или более элементов в Volume Stream Sequence (0070,1A08).

B.5.1.25 Segmentation Storage SOP Classes

SOP класс Segmentation Storage должен использовать Segmentation IOD с перечисляемым значением BINARY или FRACTIONAL для атрибута Segmentation Type (0062,0001).

SOP класс Label Map Segmentation Storage должен использовать Segmentation IOD с перечисляемым значением LABELMAP для атрибута Segmentation Type (0062,0001).

B.6 Снятые с поддержки стандартные SOP классы

SOP классы из Таблицы B.6-1 были определены в предыдущих версиях стандарта DICOM. Они были сняты с поддержки и заменены новыми стандартными SOP классами, показанными в Таблице B.5-1.

Примечание

Использование снятых с поддержки SOP классов разрешено DICOM. Однако новые реализации настоятельно рекомендуется разрабатывать на основе более новых SOP классов.

Таблица B.6-1. Снятые с поддержки стандартные SOP классы

SOP Class Name

SOP Class UID

Nuclear Medicine Image Storage

1.2.840.10008.5.1.4.1.1.5

Ultrasound Image Storage

1.2.840.10008.5.1.4.1.1.6

Ultrasound Multi-frame Image Storage

1.2.840.10008.5.1.4.1.1.3

X-Ray Angiographic Bi-plane Image Storage

1.2.840.10008.5.1.4.1.1.12.3


C Класс сервиса Query/Retrieve

C.1 Обзор

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

Сервисный класс Query/Retrieve (запрос/получение) определяет класс обслуживания прикладного уровня, обеспечивающий простое управление экземплярами составных объектов (Composite Object Instances) способом, функционально аналогичным ACR-NEMA 300-1988. Допускаемые типы запросов не являются сложными. Данный сервисный класс не предназначен для предоставления полнофункционального механиз запросов к базе данных общего назначения, такого как SQL. Вместо этого, сервисный класс Query/Retrieve ориентирован на базовые информационные запросы к экземплярам составных объектов с использованием небольшого набора общих ключевых атрибутов (Key Attributes).

Кроме того, сервисный класс Query/Retrieve предоставляет возможность извлекать/передавать чётко идентифицированный набор экземпляров составных объектов. Возможность извлечения/передачи позволяет DICOM AE извлекать экземпляры составных объектов из удалённой DICOM AE или запрашивать удалённую DICOM AE инициировать передачу экземпляров составных объектов другой DICOM AE.

Примечание

Функциональное сходство с ACR-NEMA 300-1988 облегчает переход на DICOM.

Опция расширенного согласования преобразования многоформатных изображений Enhanced (Enhanced Multi-Frame Image Conversion Extended Negotiation) позволяет сервисному классу Query/Retrieve получать доступ к классическим одноформатным изображениям (Classic single-frame), преобразованным в многоформатные изображения Enhanced, и наоборот. Это достигается за счёт предоставления альтернативных «представлений» (views) исследований, так что:

  • представление по умолчанию (default view) предоставляет изображения в том виде, в котором они были получены,

  • классическое одноформатное «представление» (Classic single-frame) предоставляет изображения как классические одноформатные (которые были получены в таком виде или были преобразованы из многоформатных Enhanced),

  • многоформатное «представление» Enhanced предоставляет изображения как многоформатные Enhanced (которые были получены в таком виде или были преобразованы из классических одноформатных).

Запрос или извлечение на уровне выше IMAGE не показывает и не возвращает дублирующую информацию (два набора изображений). SCU может запросить представление по умолчанию, многоформатное Enhanced или классическое одноформатное. Для каждого представления ссылочная целостность (referential integrity) должна быть согласована в рамках пациента и данного представления; т.е. ссылки на UID будут преобразованы во всех экземплярах, а не только в преобразованных изображениях.

Примечание

  1. Классическое одноформатное представление не предназначено в качестве альтернативы SOP классам извлечения на уровне кадров (Frame Level Retrieve SOP Classes), определённым в Приложении Y. SOP классы хранения Enhanced-изображений (Enhanced Image Storage SOP Classes) и SOP классы извлечения на уровне кадров (Frame Level Retrieve SOP Classes) следует использовать совместно, поскольку они поддерживают единое представление связей между экземплярами через общий набор UID.

  2. В представлении Enhanced экземпляры, не имеющие Enhanced-эквивалента, будут возвращены в исходной форме, но с изменениями, связанными с обеспечением ссылочной целостности.

C.1.2 Соглашения

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

Таблица C.1.2-1. Соглашения о типах ключей для информационных моделей Query/Retrieve

Символ

Описание

U

Уникальный ключевой атрибут (Unique Key Attribute)

R

Обязательный ключевой атрибут (Required Key Attribute)

O

Необязательный ключевой атрибут (Optional Key Attribute)


C.1.3 Информационная модель Query/Retrieve

Чтобы выступать в роли SCP сервисного класса Query/Retrieve, DICOM AE должна обладать информацией об атрибутах ряда хранимых экземпляров составных объектов. Эта информация организована в виде чётко определённой информационной модели Query/Retrieve (Query/Retrieve Information Model). Информационная модель Query/Retrieve должна быть стандартной информационной моделью Query/Retrieve, как определено в данном Приложении стандарта DICOM.

Запросы и извлечения реализуются на основе чётко определённых информационных моделей. Конкретный SOP класс сервисного класса Query/Retrieve состоит из определения информационной модели (Information Model Definition) и группы сервисов DIMSE-C (DIMSE-C Service Group). В данном сервисном классе информационная модель играет роль, аналогичную информационной объектной дефиниции (Information Object Definition, IOD) большинства других сервисных классов DICOM.

C.1.4 Определение сервиса

Две равноправные DICOM AE реализуют SOP класс сервисного класса Query/Retrieve, при этом одна выступает в роли SCU, а другая — в роли SCP. SOP классы сервисного класса Query/Retrieve реализуются с использованием сервисов DIMSE-C C-FIND, C-MOVE и C-GET, определённых в PS3.7.

Для сервисов DIMSE-C C-FIND, C-MOVE и C-GET определены как базовое, так и расширенное поведение. Базовое поведение (baseline behavior) определяет минимальный уровень соответствия для всех реализаций с целью обеспечения совместимости. Расширенное поведение (extended behavior) дополняет базовое поведение, предоставляя дополнительные возможности, которые могут быть отдельно согласованы при установлении ассоциации (Association).

Следующие описания сервисов DIMSE-C C-FIND, C-MOVE и C-GET представляют краткий обзор семантики SCU/SCP:

  1. Сервис C-FIND передаёт следующую семантику:

    • SCU запрашивает выполнение SCP сопоставления всех ключей, указанных в идентификаторе (Identifier) запроса, с информацией, которой обладает SCP, на уровне (например, Patient, Study, Series или Composite Object Instance), заданном в запросе.

      Примечание

      В данном Приложении термин «идентификатор» (Identifier) относится к служебному параметру Identifier сервиса C-FIND, C-MOVE или C-GET, определённому в PS3.7.

    • SCP генерирует ответ C-FIND для каждого совпадения с идентификатором, содержащим значения всех ключевых полей и всех известных запрошенных атрибутов. Все такие ответы будут содержать статус Pending (ожидание). Статус Pending указывает, что процесс сопоставления не завершён.

    • Когда процесс сопоставления завершён, отправляется ответ C-FIND со статусом Success (успех) и без идентификатора.

    • Ответ Failure (отказ) на запрос C-FIND указывает, что SCP не способен обработать запрос.

    • SCU может отменить сервис C-FIND, отправив запрос C-CANCEL-FIND в любой момент во время обработки сервиса C-FIND. SCP прервёт все операции сопоставления и вернёт статус Cancel (отмена).

      Примечание

      SCU должен быть готов к приёму ответов C-FIND, отправляемых SCP, до тех пор, пока SCP окончательно не обработает запрос C-CANCEL-FIND.

  2. Сервис C-MOVE передаёт следующую семантику:

    • SCU предоставляет значения уникальных ключей (Unique Key) для идентификации сущности на уровне извлечения. SCP сервиса C-MOVE инициирует подоперации C-STORE для соответствующих экземпляров SOP класса хранения, идентифицированных по значениям уникальных ключей. Эти подоперации C-STORE выполняются в другой ассоциации, отличной от ассоциации сервиса C-MOVE. Роль SCP в SOP классе Query/Retrieve и роль SCU в SOP классе хранения могут выполняться различными приложениями, которые могут как находиться, так и не находиться в одной системе. Механизм инициирования подопераций C-STORE находится за пределами области действия стандарта DICOM.

      Примечание

      Это не означает, что они используют один и тот же AE Title. См. Раздел C.6.1.2.2.2 и Раздел C.6.2.2.2.2 для требований к соответствию SCP C-MOVE.

    • SCP может по выбору генерировать ответы на C-MOVE со статусом Pending во время обработки подопераций C-STORE. Эти ответы C-MOVE указывают количество оставшихся (Remaining) подопераций C-STORE и количество подопераций C-STORE, завершившихся со статусом Success, Warning и Failure.

    • Когда количество оставшихся подопераций C-STORE достигает нуля, SCP генерирует окончательный ответ со статусом Success, Warning или Failure. Этот ответ может указывать количество подопераций C-STORE, завершившихся со статусом Success, Warning и Failure. Если подоперация C-STORE завершилась со статусом Failure, будет возвращён список UID (UID List).

    • SCU может отменить сервис C-MOVE, отправив запрос C-CANCEL-MOVE в любой момент во время обработки C-MOVE. SCP прекращает все незавершённые подоперации C-STORE и возвращает статус Cancel.

  3. Сервис C-GET передаёт следующую семантику:

    • SCU предоставляет значения уникальных ключей для идентификации сущности на уровне извлечения. SCP генерирует подоперации C-STORE для соответствующих экземпляров SOP класса хранения, идентифицированных значениями уникальных ключей. Эти подоперации C-STORE выполняются в той же ассоциации, что и сервис C-GET, и роли SCU/SCP будут обращены для C-STORE.

    • SCP может по выбору генерировать ответы на C-GET со статусом Pending во время обработки подопераций C-STORE. Эти ответы C-GET указывают количество оставшихся подопераций C-STORE и количество подопераций C-STORE, завершившихся со статусом Success, Warning и Failure.

    • Когда количество оставшихся подопераций C-STORE достигает нуля, SCP генерирует окончательный ответ со статусом Success, Warning или Failure. Этот ответ может указывать количество подопераций C-STORE, завершившихся со статусом Success, Warning и Failure. Если подоперация C-STORE завершилась со статусом Failure, будет возвращён список UID.

    • SCU может отменить сервис C-GET, отправив запрос C-CANCEL-GET в любой момент во время обработки C-GET. SCP прекращает все незавершённые подоперации C-STORE и возвращает статус Cancel.

C.2 Определение информационной модели Query/Retrieve

Информационная модель Query/Retrieve идентифицируется SOP классом, согласованным при установлении ассоциации. SOP класс состоит как из информационной модели, так и из группы сервисов DIMSE-C.

Примечание

Данный SOP класс идентифицирует класс информационной модели Query/Retrieve (т.е. не SOP класс хранимых экземпляров SOP, информацию о которых имеет SCP).

Определения информационных моделей для стандартных SOP классов сервисного класса Query/Retrieve определены в данном Приложении. Определение информационной модели Query/Retrieve содержит:

  • Определение модели «сущность-связь» (Entity-Relationship Model Definition)

  • Определение ключевых атрибутов (Key Attributes Definition)

C.2.1 Определение модели «сущность-связь»

Для любой информационной модели Query/Retrieve модель «сущность-связь» (Entity-Relationship Model) определяет иерархию сущностей с атрибутами, определёнными для каждого уровня иерархии (например, Patient, Study, Series, Composite Object Instance).

C.2.2 Определение атрибутов

Атрибуты должны быть определены на каждом уровне в модели «сущность-связь». Идентификатор в команде C-FIND, C-MOVE или C-GET должен содержать значения для сопоставления с атрибутами сущностей в информационной модели Query/Retrieve. Для любого запроса набор сущностей, для которых возвращаются атрибуты, должен определяться набором ключевых атрибутов (Key Attributes), указанных в идентификаторе и имеющих соответствующие совпадения у сущностей, управляемых SCP, связанным с запросом.

C.2.2.1 Типы атрибутов

Все атрибуты сущностей в информационной модели Query/Retrieve должны быть либо уникальными ключами (Unique Key), либо обязательными ключами (Required Key), либо необязательными ключами (Optional Key). Термин «ключевые атрибуты» (Key Attributes) относится к уникальным, обязательным и необязательным ключевым атрибутам.

C.2.2.1.1 Уникальные ключи

На каждом уровне в модели «сущность-связь» один атрибут должен быть определён как уникальный ключ. Одно значение в атрибуте уникального ключа должно однозначно идентифицировать одну сущность на заданном уровне. То есть две сущности на одном уровне не могут иметь одинаковое значение уникального ключа.

SCP C-FIND, C-MOVE и C-GET должны поддерживать существование и сопоставление всех уникальных ключей, определённых информационной моделью Query/Retrieve. Все сущности, управляемые SCP C-FIND, C-MOVE и C-GET, должны иметь конкретное ненулевое значение уникального ключа.

Уникальные ключи могут содержаться в идентификаторе запроса C-FIND. Уникальные ключи должны содержаться в идентификаторе запросов C-MOVE и C-GET.

C.2.2.1.2 Обязательные ключи

На каждом уровне в модели «сущность-связь» набор атрибутов должен быть определён как обязательные ключи. Обязательные ключи означают, что SCP сервиса C-FIND должен поддерживать сопоставление на основе значения, содержащегося в обязательном ключе запроса C-FIND. Несколько сущностей могут иметь одинаковое значение обязательных ключей. То есть отдельное значение обязательного ключа не обязательно идентифицирует одну сущность на уровне ключа.

SCP C-FIND должны поддерживать существование и сопоставление всех обязательных ключей, определённых информационной моделью Query/Retrieve. Если SCP C-FIND управляет сущностью с обязательным ключом нулевой длины, значение считается неизвестным, и любое сопоставление с обязательным ключом нулевой длины должно считаться успешным совпадением (т.е. любое значение, предоставленное SCU, включая значение нулевой длины, будет соответствовать значению нулевой длины SCP).

Обязательные ключи могут содержаться в идентификаторе запроса C-FIND. Обязательные ключи не должны содержаться в идентификаторе запросов C-MOVE и C-GET.

C.2.2.1.3 Необязательные ключи

На каждом уровне в модели «сущность-связь» набор атрибутов должен быть определён как необязательные ключи.

Необязательные ключи, содержащиеся в идентификаторе запроса C-FIND, могут иметь три различных типа поведения в зависимости от поддержки существования и/или сопоставления SCP C-FIND. Если SCP C-FIND:

  • не поддерживает существование необязательного ключа, то атрибут не должен возвращаться в ответах C-FIND

  • поддерживает существование необязательного ключа, но не поддерживает сопоставление по необязательному ключу, то необязательный ключ должен обрабатываться так же, как обязательный ключ нулевой длины. То есть значение, указанное для сопоставления по необязательному ключу, игнорируется, но SCP может возвратить значение для этого необязательного ключа.

  • поддерживает существование и сопоставление необязательного ключа, то необязательный ключ должен обрабатываться так же, как обязательный ключ.

Примечание

  1. SCU C-FIND не может предполагать, что необязательный ключ с ненулевой длиной будет обрабатываться так же, как обязательный ключ. Заявление о соответствии (Conformance Statement) SCP C-FIND должно перечислять поддерживаемые необязательные ключи.

  2. Необязательные ключи отличаются от обязательных ключей тем, что для необязательных ключей может поддерживаться или не поддерживаться существование и/или сопоставление SCP C-FIND. Обязательные ключи, напротив, всегда должны поддерживаться SCP C-FIND.

Необязательные ключи могут содержаться в идентификаторе запроса C-FIND. Необязательные ключи не должны содержаться в идентификаторе запросов C-MOVE и C-GET.

C.2.2.2 Сопоставление атрибутов

В сервисном классе Query/Retrieve для ключевых атрибутов могут выполняться следующие типы сопоставления:

  • Сопоставление по одному значению (Single Value Matching)

  • Сопоставление по списку UID (List of UID Matching)

  • Универсальное сопоставление (Universal Matching)

  • Сопоставление по шаблону (Wild Card Matching)

  • Сопоставление по диапазону (Range Matching)

  • Сопоставление последовательностей (Sequence Matching)

  • Сопоставление пустого значения (Empty Value Matching)

  • Многозначное сопоставление (Multiple Value Matching)

Сопоставление требует специальных символов (т.е. «*», «?», «-», «=», «\» и кавычки QUOTATION MARK из стандартного набора символов Default Character Repertoire), которые не обязательно должны быть частью набора символов для VR ключевых атрибутов.

Примечание

  1. Например, символ «-» недопустим для VR DA, DT и TM, но используется для сопоставления по диапазону. Символы шаблона «*» и «?» недопустимы для VR CS, но используются для сопоставления по шаблону.

  2. При использовании наборов символов, отличных от стандартного (Default Character Repertoire), применяются правила из PS3.5, например, в отношении использования 05/12 «\» (BACKSLASH) (в ISO IR 6) или 05/12 «¥» (YEN SIGN) (в ISO IR 14).

Общая длина ключевого атрибута может превышать длину, указанную для VR в PS3.5. Кратность значения (Value Multiplicity, VM) может быть больше, чем VM, указанная в PS3.6 для ключевого атрибута, как определено для конкретного типа сопоставления.

Атрибут Specific Character Set (0008,0005) может присутствовать в идентификаторе, но никогда не сопоставляется. Rather, он определяет, как другие атрибуты кодируются в идентификаторах запроса и ответа.

Это может влиять на то, как выполняется сопоставление других атрибутов. Если Specific Character Set (0008,0005) отсутствует, должен использоваться стандартный набор символов (Default Character Repertoire). Specific Character Set (0008,0005) не должен иметь значение нулевой длины.

Specific Character Set (0008,0005) может иметь несколько значений, если escape-последовательности используются для переключения между наборами символов внутри значений.

Если SCP не поддерживает значение(я) Specific Character Set (0008,0005) в идентификаторе запроса, то способ выполнения сопоставления не определён и должен быть указан в заявлении о соответствии (Conformance Statement).

Примечание

  1. Если SCU отправляет идентификатор запроса с однобайтовым набором символов, не поддерживаемым SCP, то вероятно (но не обязательно), что SCP будет трактовать нераспознанные символы как шаблоны и сопоставлять только символы из стандартного набора, возвращая ответ в стандартном наборе символов.

  2. Некоторые значения Specific Character Set используются с многокомпонентными именами персон (например, однобайтовыми, идеографическими и фонетическими группами компонентов, разделёнными символом «=» (3DH)), что может также влиять на поведение сопоставления строк буквально.

Атрибут Timezone Offset From UTC (0008,0201) может присутствовать в идентификаторе, но не сопоставляется, если согласована корректировка часового пояса запроса (Timezone query adjustment). Если корректировка часового пояса запроса согласована, он определяет, как значения атрибутов VR DT и TM (включая связанные значения атрибутов VR DA, если они присутствуют) интерпретируются в идентификаторах запроса и ответа, если эти значения не содержат явного указания смещения часового пояса.

C.2.2.2.1 Сопоставление по одному значению

Если значение, указанное для ключевого атрибута в запросе, имеет ненулевую длину и не имеет VR SQ и:

  1. имеет VR AE, CS, LO, LT, PN, SH, ST, UC, UR или UT и содержит одно значение без символов шаблона, и если расширенное согласование сопоставления пустого значения (Empty Value Matching) прошло успешно и значение не состоит ровно из двух символов QUOTATION MARK, или

  2. имеет VR DA, TM или DT и содержит одно значение без «-» и без символов QUOTATION MARK, или

  3. имеет любой другой VR

то выполняется сопоставление по одному значению. За исключением атрибутов с VR PN, совпадают только сущности, значения которых точно соответствуют значению, указанному в запросе. Это сопоставление чувствительно к регистру, т.е. чувствительно к точному кодированию значения ключевого атрибута в наборах символов, где буква может иметь несколько кодировок (например, в зависимости от регистра, позиции в слове или наличия диакритических знаков).

Следующие подразделы определяют особенности для определённых VR.

C.2.2.2.1.1 Атрибуты VR PN

Для атрибутов с VR PN (например, Patient Name (0010,0010)) приложение может выполнять буквальное сопоставление, чувствительное к регистру, или нечувствительное к некоторым или ко всем аспектам регистра, позиции, акцента или другим вариантам кодирования символов.

Примечание

Для многокомпонентных имён разделитель групп компонентов «=» (3DH) может присутствовать в значении ключевого атрибута, но может давать неожиданные результаты, если SCP не поддерживает сопоставление по отдельным компонентам, а интерпретирует всё значение буквально как одну строку. Например, «Wang^XiaoDong=王^小東» может как соответствовать, так и не соответствовать «Wang^XiaoDong» или «王^小東»; может потребоваться сопоставление по шаблону без разделителя групп компонентов, такое как «*Wang^XiaoDong*» или «*王^小東*».

Если расширенное согласование нечёткого семантического сопоставления (fuzzy semantic matching) атрибутов VR PN прошло успешно вместо буквального сопоставления, сопоставление может быть нечувствительным не только к регистру, позиции, акценту и кодированию символов (включая комбинируемые символы), но и применять дополнительные методы, такие как фонетическое сопоставление.

Примечание

  1. Сопоставление атрибутов PN может быть нечувствительным к диакритическим знакам, как указано в заявлении о соответствии. Нечувствительное к диакритическим знакам сопоставление успешно сопоставит, например, символ запроса «SMALL LETTER a» (06/01 в стандартном ISO-IR 6) с

    • "SMALL LETTER a WITH GRAVE ACCENT" (14/00 in ISO-IR 100),

    • "SMALL LETTER a WITH TILDE" (14/03 in ISO-IR 100),

    • "SMALL LETTER a WITH BREVE" (14/03 in ISO-IR 101), and

    • "CAPITAL LETTER a WITH ACUTE ACCENT" (12/01 in ISO-IR 100) (if matching is also case-insensitive),

    но не будет соответствовать 14/00 в ISO-IR 101, который является «SMALL LETTER r WITH ACUTE ACCENT». Сопоставление с конкретными битовыми комбинациями зависит от каждого поддерживаемого набора символов (обратите внимание на разницу в значении 14/00) и должно быть описано в заявлении о соответствии.

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

Однако если было согласовано нечёткое семантическое сопоставление атрибутов PN, сопоставление SCP может привести к ответам, которые не имеют очевидной связи с запросом, поэтому следует проявлять осторожность при выполнении SCU любой дополнительной фильтрации ответов. Например, при фонетическом сопоставлении запрос «Swain» может вернуть «Swayne», а при сопоставлении, нечувствительном к порядку компонентов имени, запрос «Smith^Mary» может вернуть «Mary^Smith» или «Mary Smith» или «Smith, Mary». Нечёткое семантическое сопоставление может также учитывать отдельные группы компонентов имени — однобайтовые, идеографические и фонетические.

C.2.2.2.1.2 Атрибуты VR AE, CS, LO, LT, PN, SH, ST, UC, UR и UT

VR AE, LO, LT, PN, SH, ST, UC, UR и UT допускают наличие символов шаблона «*» и «?». Сопоставление по шаблону также определено для значений CS. Сопоставление по одному значению для таких символов не поддерживается. См. Раздел C.2.2.2.4.

C.2.2.2.1.3 Атрибуты VR DA, DT или TM

Если атрибут Timezone Offset From UTC (0008,0201) присутствует в идентификаторе и корректировка часового пояса запроса была согласована, он должен использоваться для корректировки значений атрибутов VR TM (и связанных атрибутов VR DA, если они присутствуют) из местного часового пояса в UTC. Он также должен корректировать значения атрибутов VR DT, не указывающие смещение часового пояса. Кодирование и семантика атрибута Timezone Offset From UTC (0008,0201) должны соответствовать определению в модуле SOP Common в PS3.3.

Способ выполнения сопоставления зависит от реализации и должен быть указан в заявлении о соответствии.

Примечание

  1. Это определение подразумевает, что значения VR TM, DA и DT сопоставляются по их смыслу, а не как буквальные строки. Например:

    • the DT "19980128103000.0000" matches "19980128103000"

    • the DT "19980128103000" with no timezone offset matches "19980128073000" with timezone offset "-0300"

    • the TM "2230" matches "223000"

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

  3. Исключение символа «-» для сопоставления по одному значению означает, что ключевой атрибут с VR DT не может содержать отрицательное смещение от всемирного координированного времени (UTC), если предполагается сопоставление по одному значению. Использование символа «-» в значениях VR TM, DA и DT указывает на сопоставление по диапазону.

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

C.2.2.2.1.4 Атрибуты VR DS или IS

VR DS и IS кодируют числа как символьные строки. Одно и то же число может быть закодировано по-разному при использовании символьных строк. Поэтому способ выполнения сопоставления зависит от реализации и должен быть указан в заявлении о соответствии.

Примечание

Например, в зависимости от реализации SCP значения IS «+7» и «007» могут как соответствовать, так и не соответствовать значению «7».

C.2.2.2.2 Сопоставление по списку UID

Список UID кодируется с использованием оператора кратности значения — обратной косой черты («\») в качестве разделителя между UID. Каждый элемент списка должен содержать одно значение UID. Каждый UID в списке, содержащемся в идентификаторе запроса, может породить совпадение.

Примечание

Список отдельных значений кодируется точно так же, как VR UI с VM Multiple (см. PS3.5).

C.2.2.2.3 Универсальное сопоставление

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

C.2.2.2.4 Сопоставление по шаблону

Если атрибут имеет VR AE, CS, LO, LT, PN, SH, ST, UC, UR, UT и значение, указанное в запросе, содержит любое вхождение «*» или «?», то «*» должно соответствовать любой последовательности символов (включая значение нулевой длины), а «?» должен соответствовать любому одиночному символу. Это сопоставление чувствительно к регистру, за исключением атрибутов с VR PN (например, Patient Name (0010,0010)).

Для атрибутов с VR PN, включая случай расширенного согласования нечёткого семантического сопоставления, сопоставление по шаблону зависит от реализации и должно быть указано в заявлении о соответствии.

Примечание

  1. Сопоставление по шаблону для значения «*» эквивалентно универсальному сопоставлению.

  2. Метод сопоставления по шаблону, определённый в DICOM, может не поддерживаться некоторыми не-DICOM текстовыми процессорами многобайтовых символов.

  3. Для многокомпонентных имён разделитель групп компонентов «=» (3DH) может присутствовать в значении ключевого атрибута, но может давать неожиданные результаты, если SCP не поддерживает сопоставление по отдельным компонентам, а интерпретирует всё значение буквально. Например, «*=*» или «*=*=*» может как возвращать, так и не возвращать все строки, и поэтому не эквивалентно «*», ни универсальному сопоставлению.

  4. Атрибуты с VR AE, LO, PN, SH и UC могут содержать символы шаблона «*» и «?». Попытки сопоставить строку, явно содержащую «*» или «?», будут рассматриваться как сопоставление по шаблону и, таким образом, могут вернуть несколько результатов, а не один. Не существует механизма сопоставления по одному значению для значений, содержащих символы «*» и «?» для данных VR — такие запросы всегда будут рассматриваться как запросы с сопоставлением по шаблону.

  5. Атрибуты с VR ST, LT и UT предназначены для передачи текста описаний и могут содержать символы шаблона «*» и «?». Попытки сопоставить строку, явно содержащую «*» или «?», будут рассматриваться как сопоставление по шаблону и, таким образом, могут вернуть несколько результатов, а не один. Не существует механизма сопоставления по одному значению для значений, содержащих символы «*» и «?» для данных VR — такие запросы всегда будут рассматриваться как запросы с сопоставлением по шаблону.

  6. Атрибуты с VR UR могут содержать символы шаблона «*» и «?» в качестве разделителей. Эти символы зарезервированы в соответствии с [RFC3986] Раздел 2. Попытки сопоставить строку, явно содержащую «*» или «?», будут рассматриваться как сопоставление по шаблону и, таким образом, могут вернуть несколько результатов, а не один. Не существует механизма сопоставления по одному значению для значений, содержащих символы «*» и «?» для данных VR — такие запросы всегда будут рассматриваться как запросы с сопоставлением по шаблону.

C.2.2.2.5 Сопоставление по диапазону
C.2.2.2.5.1 Сопоставление по диапазону атрибутов VR DA

При отсутствии расширенного согласования:

  1. Строка вида «<дата1> - <дата2>», где <дата1> меньше или равна <дата2>, должна соответствовать всем вхождениям дат, попадающим в диапазон от <дата1> до <дата2> включительно

  2. Строка вида «- <дата1>» должна соответствовать всем вхождениям дат до <дата1> включительно

  3. Строка вида «<дата1> -» должна соответствовать всем вхождениям <дата1> и последующим датам

C.2.2.2.5.2 Сопоставление по диапазону атрибутов VR TM

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

Смещение от всемирного координированного времени не допускается в значениях VR TM. Если Timezone Offset From UTC (0008,0201) присутствует в идентификаторе запроса, указанные значения времени и определение полуночи соответствуют указанному часовому поясу.

При отсутствии расширенного согласования:

  1. Строка вида «<время1> - <время2>», где <время1> меньше или равно <время2>, должна соответствовать всем вхождениям моментов времени, попадающим в диапазон от <время1> до <время2> включительно

  2. Строка вида «- <время1>» должна соответствовать всем вхождениям моментов времени до <время1> включительно

  3. Строка вида «<время1> -» должна соответствовать всем вхождениям <время1> и последующим моментам времени

C.2.2.2.5.3 Сопоставление по диапазону атрибутов VR DT
  1. Строка вида «<дата-время1> - <дата-время2>», где <дата-время1> меньше или равно <дата-время2>, должна соответствовать всем моментам времени, попадающим в диапазон от <дата-время1> до <дата-время2> включительно

  2. Строка вида «- <дата-время1>» должна соответствовать всем моментам времени до <дата-время1> включительно

  3. Строка вида «<дата-время1> -» должна соответствовать всем моментам времени после <дата-время1> включительно

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

C.2.2.2.5.4 Общие правила сопоставления по диапазону

Если расширенное согласование комбинированного сопоставления даты-времени (combined datetime matching) прошло успешно, то пара атрибутов VR DA и TM, обе из которых указывают одну и ту же форму сопоставления по диапазону, должна иметь конкатенированные строковые значения каждого компонента сопоставления по диапазону, сопоставляемые так, как если бы они были одним атрибутом VR DT.

Примечание

Например, Study Date «20060705-20060707» и Study Time «1000-1800» будут соответствовать периоду времени с 5 июля, 10:00, до 7 июля, 18:00, а не трём периодам времени с 10:00 до 18:00 5, 6 и 7 июля, как было бы без расширенного согласования.

Независимо от другого расширенного согласования, приложение может использовать значение Timezone Offset From UTC (0008,0201) для корректировки значений атрибутов VR TM и DT из местного часового пояса в UTC для сопоставления. См. Раздел C.2.2.2.1.

Примечание

Если расширенное согласование комбинированного сопоставления даты-времени прошло успешно, смещение часового пояса может вызвать изменение даты, если местное время и UTC находятся по разные стороны от полуночи.

Сопоставление по диапазону не определено для типов атрибутов, отличных от дат и времени.

C.2.2.2.6 Сопоставление последовательностей

Если ключевой атрибут в идентификаторе запроса C-FIND должен быть сопоставлен с атрибутом, структурированным как последовательность элементов (Sequence of Items, VR SQ), ключевой атрибут должен быть структурирован как последовательность элементов с одним элементом (Item). Этот элемент может содержать ноль или более ключевых атрибутов элемента (Item Key Attributes). Сопоставление каждого ключевого атрибута элемента должно выполняться на поэлементной основе. Должны использоваться типы сопоставления, определённые в Разделе C.2.2.2: сопоставление по одному значению, сопоставление по списку UID, универсальное сопоставление, сопоставление по шаблону, сопоставление по диапазону и сопоставление последовательностей (рекурсивное сопоставление последовательностей).

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

Если ключевой атрибут в идентификаторе запроса C-FIND не содержит ни одного ключевого атрибута элемента (тег Item нулевой длины), то все сущности должны соответствовать этому атрибуту. Это обеспечивает механизм, подобный универсальному сопоставлению, для запроса значения выбранного ключевого атрибута (всей последовательности элементов) в соответствующих ответах C-FIND.

C.2.2.2.7 Сопоставление пустого значения

Если расширенное согласование сопоставления пустого значения (Empty Value Matching) прошло успешно, и для атрибутов с VR AE, CS, DA, DT, LO, LT, PN, SH, ST, TM, UC, UR или UT, значение ключевого атрибута, состоящее ровно из двух символов QUOTATION MARK (22H в стандартном наборе символов Default Character Repertoire), указанное в запросе, должно означать сопоставление с пустым значением. Такое сопоставление считается успешным для сущностей с значением нулевой длины для соответствующего атрибута или для которых атрибут отсутствует.

Примечание

  1. Другие символы кавычек, определённые в расширенном или заменяющем наборе символов, такие как двойные угловые кавычки, левые и правые изогнутые кавычки и т.д., недопустимы для указания сопоставления пустого значения.

  2. VR AE, LO, LT, PN, SH, ST, UC и UT допускают символ QUOTATION MARK. Сопоставление строки из двух символов QUOTATION MARK в этих атрибутах может быть выполнено с помощью сопоставления по шаблону с использованием символа ASTERISK (например, ""*).

C.2.2.2.8 Многозначное сопоставление

Многозначное сопоставление (Multiple Value Matching) относится к предоставлению нескольких значений в ключевом атрибуте. В этом разделе описывается, как выполнять сопоставление с такими ключевыми атрибутами. Раздел C.2.2.3 описывает, что возвращать, когда сопоставляемый атрибут сущности содержит несколько значений.

Если расширенное согласование многозначного сопоставления (Multiple Value Matching) прошло успешно, для атрибутов с VR AE, AS, AT, CS, LO, PN, SH или UC и определённой VM больше 1, ключевой атрибут с несколькими значениями, указанный в запросе, должен означать сопоставление с многозначным атрибутом сущности. Такое сопоставление считается успешным только если каждое значение в ключевом атрибуте соответствует значению в соответствующем атрибуте сущности.

Значения ключевого атрибута не должны содержать шаблоны.

Порядок значений атрибутов в запросе не обязан соответствовать порядку в соответствующем атрибуте сущности.

Примечание

  1. Это логическая функция «И» для всех значений в ключевом атрибуте. Например, значение CT\PT для Modalities in Study (0008,0061) в идентификаторе запроса будет соответствовать только исследованиям, которые включают как серию CT, так и серию PT.

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

  3. Multiple Value Matching does not apply to Specific Character Set (0008,0005), which is not a Key Attribute for matching, but rather specifies the encoding of characters in the Identifier.

  4. При отсутствии успешного расширенного согласования многозначного сопоставления семантика нескольких значений в ключевом атрибуте не определена.

C.2.2.3 Сопоставление многозначных атрибутов сущностей

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

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

C.3 Стандартные информационные модели Query/Retrieve

Стандартные информационные модели Query/Retrieve определены в данном Приложении. Каждая информационная модель Query/Retrieve связана с рядом SOP классов. Определены следующие иерархические информационные модели Query/Retrieve:

  • Корень пациента (Patient Root)

  • Корень исследования (Study Root)

C.3.1 Информационная модель Query/Retrieve с корнем Patient

Информационная модель Query/Retrieve с корнем Patient (Patient Root Query/Retrieve Information Model) основана на четырёхуровневой иерархии:

  • Patient

  • Study

  • Series

  • Composite Object Instance

Уровень пациента является верхним уровнем и содержит атрибуты, связанные с информационной сущностью пациента (Patient Information Entity, IE) составных IOD, как определено в PS3.3. IE пациентов не зависят от модальности.

Уровень исследования находится ниже уровня пациента и содержит атрибуты, связанные с IE исследования (Study IE) составных IOD, как определено в PS3.3. Исследование принадлежит одному пациенту. Один пациент может иметь несколько исследований. IE исследований не зависят от модальности.

Уровень серии находится ниже уровня исследования и содержит атрибуты, связанные с IE серии (Series IE), IE системы координат (Frame of Reference IE) и IE оборудования (Equipment IE) составных IOD, как определено в PS3.3. Серия принадлежит одному исследованию. Одно исследование может иметь несколько серий. IE серий зависят от модальности. Для учёта этой зависимости от модальности набор необязательных ключей на уровне серии включает все атрибуты, определённые на уровне серии для любого составного IOD, определённого в PS3.3.

Нижний уровень — это уровень экземпляра составного объекта (Composite Object Instance), который содержит атрибуты, связанные с IE составного объекта (Composite object IE) составных IOD, как определено в PS3.3. Экземпляр составного объекта принадлежит одной серии. Одна серия может содержать несколько экземпляров составных объектов. Большинство IE составных объектов зависят от модальности. Для учёта этой возможной зависимости от модальности набор необязательных ключей на уровне экземпляра составного объекта включает все атрибуты, определённые на уровне экземпляра составного объекта для любого составного IOD, определённого в PS3.3.

C.3.2 Информационная модель Query/Retrieve с корнем Study

Информационная модель Query/Retrieve с корнем Study (Study Root Query/Retrieve Information Model) идентична модели с корнем Patient, за исключением того, что верхним уровнем является уровень исследования. Атрибуты пациентов считаются атрибутами исследований.

C.3.3 Информационная модель Query/Retrieve Patient/Study Only (Retired)

Анулировано (Retired). См. PS3.4-2004.

C.3.4 Дополнительные атрибуты Query/Retrieve

Некоторые необязательные атрибуты, которые могут использоваться в информационных моделях Query/Retrieve и не являются атрибутами информационной объектной дефиниции (IOD), и, следовательно, не определены в PS3.3. Эти атрибуты определены в Таблице C.3-1.

Таблица C.3-1. Дополнительные атрибуты Query/Retrieve

Имя атрибута

Тег

Описание атрибута

Number of Patient Related Studies

(0020,1200)

Количество исследований, соответствующих критериям поиска Query/Retrieve на уровне Patient

Number of Patient Related Series

(0020,1202)

Количество серий, соответствующих критериям поиска Query/Retrieve на уровне Patient

Number of Patient Related Instances

(0020,1204)

Количество экземпляров составных объектов, соответствующих критериям поиска Query/Retrieve на уровне Patient

Number of Study Related Series

(0020,1206)

Количество серий, соответствующих критериям поиска Query/Retrieve на уровне Study

Number of Series Related Instances

(0020,1209)

Количество экземпляров составных объектов в серии, соответствующих критериям поиска Query/Retrieve на уровне Series

Number of Study Related Instances

(0020,1208)

Количество экземпляров составных объектов, соответствующих критериям поиска Query/Retrieve на уровне Study

Modalities in Study

(0008,0061)

Все уникальные значения, использованные для Modality (0008,0060) в сериях исследования.

SOP Classes in Study

(0008,0062)

SOP классы, содержащиеся в исследовании.

Anatomic Regions in Study Code Sequence

(0008,0063)

Анатомические области интереса в данном исследовании (т.е. внешняя анатомия, анатомия поверхности или общая область тела).

В этой последовательности допускается один или несколько элементов (Items).

Примечание

Если экземпляры в исследовании содержат Anatomic Region Sequence (0008,2218), то элементы этой последовательности могут быть объединением кодов в экземплярах. Альтернативно, несколько (обычно смежных) анатомических областей могут быть объединены в один код. Например, (51185008, SCT, "Chest"), (113345001, SCT, "Abdomen") и (12921003, SCT, "Pelvis") могут быть объединены в (416775004, SCT, "Chest, Abdomen and Pelvis").

Если экземпляры в исследовании не содержат Anatomic Region Sequence (0008,2218), но содержат Body Part Examined (0018,0015), то могут использоваться коды, эквивалентные распознанным значениям Body Part Examined (0018,0015). См. Приложение L «Соответствие кодов анатомических областей и Defined Terms для Body Part Examined» в PS3.16 для стандартных эквивалентных значений. Например, если экземпляр содержит Body Part Examined (0018,0015) со значением «CHEST», то эта последовательность может содержать (51185008, SCT, "Chest").

Alternate Representation Sequence

(0008,3001)

Последовательность элементов, каждый из которых идентифицирует альтернативное кодирование изображения, соответствующее критериям поиска Query/Retrieve на уровне Instance (см. Раздел C.6.1.1.5.1)

Available Transfer Syntax UID

(0008,3002)

Описывает один или несколько синтаксисов передачи (Transfer Syntaxes), которые SCP гарантирует поддерживать для извлечения SOP Instance (см. Раздел C.6.1.1.5.2).

Study Update DateTime

(0008,041F)

Дата/время последнего обновления метаданных исследования (например, атрибутов Patient, Study или Procedure, Imaging Service Request или Series) или набора SOP Instance в исследовании.

Примечание

Может также отражать дату/время обновления места хранения SOP Instance для исследования, если SCP поддерживает атрибуты для доступа к хранимым SOP Instance через протокол, отличный от DICOM (см. Раздел C.6.4.1.3),


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

C.3.5 Создание нового экземпляра для преобразования многоформатных изображений Enhanced

Если Query/Retrieve View (0008,0053) присутствует со значением «CLASSIC» или «ENHANCED» в идентификаторе запроса C-FIND, C-MOVE или C-GET, то информационная модель, по которой выполняется запрос или извлечение, и любые извлекаемые SOP Instance должны быть возвращены, сконструированы или преобразованы в соответствии с требованиями данного раздела.

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

Примечание

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

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

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

Примечание

  1. Не допускается исключать подмножество экземпляров из этой области действия, например, состояния отображения (presentation states) или документы выбора ключевых объектов (key object selection documents), из представления «ENHANCED» с целью избежать затрат на создание новых экземпляров с обновлёнными ссылками, необходимыми для поддержания ссылочной целостности. Иными словами, суммарное «информационное содержание» любого представления будет не меньше, чем у представления по умолчанию.

  2. Это не означает, что все экземпляры должны быть преобразованы, поскольку если они не содержат таких ссылок, они могут быть оставлены без изменений и включены в представление. Например, классическое однослойное КТ-изображение-локализатор без ссылок может оставаться неизменным в представлении как SOP класс CT Image Storage с его существующим SOP Instance UID и SOP классом в его существующей серии и ссылаться из преобразованных экземпляров, таких как аксиальные срезы, назначенные на его основе. SCU не может делать никаких предположений о том, что будет или не будет преобразовано, или в каком порядке.

  3. Следует понимать, что требования данного раздела применимы к отдельному SCP; невозможно требовать, чтобы все SCP, выполняющие преобразование, делали это одинаково или создавали одни и те же UID и т.д.

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

  • Многоформатные изображения Enhanced (истинные или преобразованные из устаревших), созданные из классических одноформатных изображений

  • Классические одноформатные изображения, созданные из многоформатных изображений Enhanced (истинных или преобразованных из устаревших)

  • Экземпляры, содержащие ссылки на SOP Instance UID или Series Instance UID, соответствующие либо преобразованным одноформатным изображениям, либо другим экземплярам с такими ссылками

Общие требования заключаются в следующем:

  • Новый составной экземпляр (Composite Instance) должен иметь новый SOP Instance UID.

  • Новый составной экземпляр должен быть действительным SOP Instance (т.е. должен соответствовать требованиям IOD, модуля и атрибутов для SOP класса хранения).

  • Новый составной экземпляр должен содержать Contributing Equipment Sequence (0018,A001). Если исходные составные экземпляры уже содержат Contributing Equipment Sequence с согласованным набором значений элементов (исключая Contribution DateTime (0018,A002)), то новый элемент должен быть добавлен к копии последовательности в новом составном экземпляре; если исходный составной экземпляр не содержит Contributing Equipment Sequence или значения элементов (исключая Contribution DateTime (0018,A002)) различаются между исходными экземплярами, то Contributing Equipment Sequence должна быть создана, содержащая один новый элемент. В любом случае новый элемент должен описывать оборудование, создающее новый составной экземпляр, а Purpose of Reference Code Sequence (0040,A170) внутри элемента должен быть (109106, DCM, "Enhanced Multi-frame Conversion Equipment"), а Contribution Description (0018,A003) должен быть «Legacy Enhanced Image created from Classic Images», «Classic Image created from Enhanced Image» или «Updated UID references during Legacy Enhanced Classic conversion» в зависимости от ситуации.

  • Новый составной экземпляр должен иметь ту же информацию на уровне Patient и Study, что и исходный экземпляр, включая тот же Study Instance UID.

  • Новый составной экземпляр должен иметь ту же пространственную и временную информацию системы координат (Frame of Reference), что и исходный экземпляр, если она присутствует (например, Frame of Reference UID должен быть тем же).

  • Новый составной экземпляр должен быть помещён в новую серию (вместе с другими новыми составными экземплярами, имеющими ту же новую информацию на уровне Series), с новым Series Instance UID. Series Date (0008,0021) и Series Time (0008,0031) всех экземпляров в новой серии должны быть самыми ранними из значений в исходных составных экземплярах, если они присутствуют.

    Примечание

    1. Новые Series Date и Time НЕ должны соответствовать моменту выполнения преобразования, а должны отражать значения в исходных изображениях.

    2. Не существует стандартного требования или механизма для изменения или сохранения других атрибутов уровня серии, таких как Series Number или Series Description. Это оставлено на усмотрение разработчика, особенно в случаях, когда экземпляры из разных серий объединяются.

  • Новый составной экземпляр должен иметь те же элементы и значения Request Attributes Sequence (0040,0275), что и исходные составные экземпляры, если Request Attributes Sequence (0040,0275) присутствует в любом из исходных составных экземпляров.

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

    Примечание

    1. Например, если исходный экземпляр ссылается на экземпляр в серии, и ссылаемый экземпляр также преобразован и, следовательно, помещён в новую серию, то как SOP Instance UID, так и Series Reference UID в иерархической ссылке на экземпляр должны быть обновлены, как и SOP Class UID ссылаемого экземпляра, если он изменился (что, вероятно, произойдёт).

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

    3. UID, указанные в Conversion Source Attributes Sequence (0020,9172), не преобразуются, поскольку по определению они ссылаются на экземпляры в «другом» представлении; они не должны существовать в источнике, но будут вставлены (или заменены, если ранее были преобразованы) во время преобразования.

Специальные требования для преобразования одноформатных изображений в многоформатные изображения Enhanced:

  • SOP класс нового составного экземпляра должен быть соответствующим специфичным для модальности SOP классом хранения Enhanced-изображений (Enhanced Image Storage SOP Class), предназначенным для создания с нуля устройством сканирования или постобработки, если только исходные изображения не содержат достаточно информации для заполнения обязательных атрибутов стандартными перечисляемыми значениями (Enumerated Values) и Defined Terms или значениями элементов кодированных последовательностей (Coded Sequence Item), в этом случае должен использоваться соответствующий специфичный для модальности SOP класс хранения устаревших преобразованных Enhanced-изображений (Legacy Converted Enhanced Image Storage SOP Class). Соответствующие SOP классы определены в Таблице C.3.5-1.

    Примечание

    1. Например, если исходные изображения для преобразования принадлежат к SOP классу CT Image Storage, то предпочтительным новым SOP классом является Enhanced CT Image Storage SOP Class, но если это невозможно, используется Legacy Converted Enhanced CT Image Storage SOP Class.

    2. Не предполагается, что изображения из разных модальностей будут объединены в одном новом составном экземпляре. Например, не ожидается, что КТ и ПЭТ изображения будут объединены в одном экземпляре, поскольку технические атрибуты и характеристики пиксельных данных совершенно различны.

    3. Ожидается, что столько одноформатных изображений, сколько разумно, будет объединено в одно многоформатное изображение с учётом ограничений на то, какие атрибуты должны быть идентичны, как определено в данном разделе, и в зависимости от типа изображений и размера результирующего объекта. Различные реализации могут делать различный выбор в этом отношении. Например, приложение может объединять только изображения в одной серии, или с одинаковым расстоянием между срезами, или с одинаковыми значениями Image Type, или с одинаковым Image Orientation (Patient).

  • Новый составной экземпляр (Composite Instance) не должен входить в конкатенацию (Concatenation). Это означает, что он не должен содержать атрибут Concatenation UID (0020,9161) или другие атрибуты конкатенации. Если существующий составной экземпляр содержит такие атрибуты, они не должны включаться в новый составной экземпляр.

  • Новый составной экземпляр содержит только один набор атрибутов для модуля Image Pixel, поэтому содержимое модуля Image Pixel должно быть либо одинаковым во всех исходных изображениях, либо Pixel Data для каждого кадра должна быть преобразована по мере необходимости для соответствия модулю Image Pixel нового составного экземпляра.

    Примечание

    1. В частности, это означает, что значения Rows, Columns, Bits Stored, Bits Allocated, High Bit, Pixel Representation, Samples per Pixel, Photometric Interpretation и Planar Configuration, применимые ко всем кадрам, должны быть одинаковыми. В особых случаях, например, когда Bits Stored меньше Bits Allocated, но варьируется от кадра к кадру, может быть безопасно использовать наибольшее значение для всех кадров и убедиться, что любые неиспользуемые старшие биты соответствующим образом замаскированы перед кодированием. Не ожидается, что исходные изображения с разным количеством Rows и Columns будут объединены (путём добавления полей вокруг изображений, меньших, чем самое большое); помимо того, что это не является предполагаемым вариантом использования, это может привести к значительному увеличению размера экземпляра, а также может потребовать корректировки значений Image Position (Patient). Если значение Photometric Interpretation в исходных одноформатных изображениях не разрешено для IOD многоформатного изображения Enhanced, требуется lossless-преобразование PixelData и обновление связанных атрибутов, например, с MONOCHROME1 на MONOCHROME2.

    2. Особое внимание следует уделить Pixel Padding Value и связанным атрибутам, в случае если они варьируются от кадра к кадру в исходных изображениях; в этом случае Pixel Data для некоторых кадров может потребоваться изменить для согласованности со всеми остальными кадрами.

    3. При преобразовании можно изменить атрибуты модуля Image Pixel Module, связанные со сжатыми синтаксисами передачи (включая сжатие с потерями или необратимое сжатие).

  • All mandatory Attributes of all mandatory Modules and Functional Group Macros of the SOP Class of the new Composite Instance shall be populated as required by the IOD. In this context, "mandatory" means either required or conditional where the condition is satisfied.

    Примечание

    For example, if the source images to be converted are of the CT Image Storage SOP Class, and the new Composite Instance is of the Legacy Converted Enhanced CT Image Storage SOP Class, then it is required that the Pixel Measures Functional Group be populated from Pixel Spacing, that the Plane Position (Patient) Functional Group be populated from Image Position (Patient), etc. In addition, if Body Part Examined is present in the source images with a standard value, then the condition for the inclusion of the Frame Anatomy Functional Group is satisfied, and the value therein needs to be converted to the appropriate Anatomic Region Sequence code.

  • Все необязательные атрибуты, модули и макросы функциональных групп (Functional Group Macros), для которых в исходных изображениях присутствует соответствующая информация в стандартных атрибутах (Standard Attributes), также должны быть заполнены.

  • Все атрибуты модуля Overlay должны быть удалены и преобразованы в Grayscale или Color Softcopy Presentation State (в зависимости от значения Photometric Interpretation); если наложение (Overlay) использует старшие биты в Pixel Data (7FE0,0010), они должны быть извлечены и закодированы в Overlay Data (60xx,3000) в Presentation State, а в атрибуте Pixel Data (7FE0,0010) преобразованного изображения они должны быть установлены в ноль.

    Примечание

    Извлечение оверлеев (Overlays) из нескольких кадров может привести к proliferation экземпляров GSPS (по одному на каждый преобразованный кадр), если только преобразователь не распознаёт общность в двоичных значениях битовых плоскостей оверлеев и не выносит её в меньшее количество объектов GSPS, каждый из которых применяется к нескольким кадрам.

  • All Attributes of the Curve Module (retired, but formerly defined in DICOM) shall be removed; they may be converted into a Grayscale or Color Softcopy Presentation State (depending on the value of Photometric Interpretation) or a Waveform as appropriate, but this is not required.

  • All Attributes of the Graphic Annotation Sequence (0070,0001) (not defined in Classic image IODs, but sometimes used in a Standard Extended SOP Class) shall be removed; they may be converted into a Grayscale or Color Softcopy Presentation State (depending on the value of Photometric Interpretation), but this is not required.

  • Все оставшиеся атрибуты исходных изображений (т.е. те, которые не были использованы для заполнения обязательных или необязательных атрибутов в модулях и функциональных группах), включая частные атрибуты (Private Attributes), должны быть скопированы в набор данных верхнего уровня (Data Set) или в последовательность Unassigned Shared Converted Attributes Sequence (0020,9170), если они присутствуют во всех исходных изображениях для нового составного экземпляра, имеют одинаковое количество значений и одинаковые значения; в противном случае они должны быть скопированы в последовательность Unassigned Per-Frame Converted Attributes Sequence (0020,9171).

    Примечание

    Семантика частных атрибутов (Private Attributes) или стандартных атрибутов, используемых в Standard Extended SOP Class, может не сохраняться, будучи неизвестной преобразующему приложению; например, ссылочная целостность UID в частных атрибутах может не обновляться.

  • The new Composite Instance shall contain references to the source Instances from which it was converted, encoded in the Conversion Source Attributes Sequence (0020,9172) of the Image Frame Conversion Source Functional Group Macro.

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

  • The SOP Class of the new Composite Instance shall be the appropriate modality-specific (Classic) Image Storage SOP Class that is intended for de novo creation by an acquisition or post-processing device.

    Примечание

    For example, if the source images to be converted are of the Enhanced CT Image Storage SOP Class or the Legacy Converted Enhanced CT Image Storage SOP Class, then the new SOP Class is the CT Image Storage SOP Class.

  • All mandatory Attributes of the IOD of the SOP Class of the new Composite Instance shall be populated. In this context, "mandatory" means either required or conditional where the condition is satisfied.

    Примечание

    For example, if the source images to be converted are of the Legacy Converted Enhanced CT Image Storage SOP Class, and the new Composite Instance is of the CT Image Storage SOP Class, then it is required that Pixel Spacing be populated from the Pixel Measures Functional Group, that Image Position (Patient) be populated from the Plane Position (Patient) Functional Group, etc.

  • Все необязательные атрибуты в модулях IOD, для которых в исходных изображениях присутствует соответствующая информация, также должны быть заполнены.

  • All remaining Attributes in the source images (i.e., those that have not been used to populate mandatory or optional Attributes in Modules), including Private Attributes, shall be copied from the top-level Data Set and the Shared Functional Group Macro and the corresponding Item of the Per-Frame Functional Group Macro into the top-level Data Set of the new Composite Instance, including those in the Unassigned Shared Converted Attributes Sequence (0020,9170) and the corresponding Item of the Unassigned Per-Frame Converted Attributes Sequence (0020,9171) (which will result in a Standard Extended SOP Class).

    Примечание

    1. Identifying Attributes, such as Series Number or Series Description, will be present in the Unassigned functional groups, and UIDs will be present in the Conversion Source Attributes Sequence, allowing, for example, the original Series organization to be recovered, whether or not a single Series was previously converted into a single Legacy Converted instance or it was split or merged with other Series.

    2. Целостность набора частных атрибутов, восстановленных таким образом, не может быть гарантирована для корректного функционирования любых приложений, которые зависят от них, но ожидается, что это будет не лучше и не хуже, чем влияние хранения экземпляров с частными атрибутами на любом Storage SCP, который может как реорганизовывать и/или выборочно сохранять частные атрибуты, так и не делать этого.

  • The new Composite Instance shall contain references to the source Instances from which it was converted, encoded in the Conversion Source Attributes Sequence (0020,9172) in the SOP Common Module.

Специальные требования для преобразования других экземпляров:

  • The new Composite Instance shall be an instance of the same SOP Class as the source Composite Instance.

  • The new Composite Instance shall contain references to the source Instances from which it was converted, encoded in the Conversion Source Attributes Sequence (0020,9172) in the SOP Common Module.

Таблица C.3.5-1. Специфичные для модальности преобразования SOP классов

Classic

True Enhanced

Legacy Converted Enhanced

CT Image Storage

Enhanced CT Image Storage

Legacy Converted Enhanced CT Image Storage

MR Image Storage

Enhanced MR Image Storage

Legacy Converted Enhanced MR Image Storage

PET Image Storage

Enhanced PET Image Storage

Legacy Converted Enhanced PET Image Storage


C.4 Группы сервисов DIMSE-C

Три сервиса DIMSE-C используются при конструировании SOP классов сервисного класса Query/Retrieve. Используются следующие операции DIMSE-C:

  • C-FIND

  • C-MOVE

  • C-GET

C.4.1 Операция C-FIND

SCP некоторых SOP классов сервисного класса Query/Retrieve могут обладать способностью обрабатывать запросы с использованием операции C-FIND, как описано в PS3.7. Операция C-FIND — это механизм, с помощью которого выполняются запросы. Совпадения с ключами, присутствующими в идентификаторе, возвращаются в ответах C-FIND.

C.4.1.1 Параметры сервиса C-FIND

C.4.1.1.1 SOP Class UID

SOP Class UID идентифицирует информационную модель Query/Retrieve, по которой выполняется C-FIND. Поддержка SOP Class UID подразумевается Abstract Syntax UID контекста представления (Presentation Context), используемого данной операцией C-FIND.

C.4.1.1.2 Приоритет

Атрибут Priority определяет запрошенный приоритет операции C-FIND по отношению к другим операциям DIMSE, выполняемым тем же SCP.

Обработка запросов приоритета не требуется от SCP. Поддерживает ли SCP обработку приоритета и значение различных уровней приоритета, должно быть указано в заявлении о соответствии SCP.

C.4.1.1.3 Идентификатор

Как запрос, так и ответ C-FIND содержат идентификатор (Identifier), закодированный как набор данных (Data Set) (см. PS3.5).

Примечание

Определение набора данных (Data Set) в PS3.5 конкретно исключает диапазон групп ниже группы 0008, и это включает, в частности, элементы заголовка метаинформации (Meta Information Header), такие как Transfer Syntax UID (0002,0010). Запрос C-FIND и идентификатор не поддерживают механизм для выяснения того, как SCP мог закодировать хранимое изображение, будь то путём запроса Transfer Syntax UID (0002,0010) или любым другим механизмом.

C.4.1.1.3.1 Структура идентификатора запроса

Идентификатор в запросе C-FIND должен содержать:

  • Значения ключевых атрибутов для сопоставления со значениями хранимых SOP Instance, управляемых SCP.

  • Query/Retrieve Level (0008,0052), который определяет уровень запроса.

  • Условно — атрибут Query/Retrieve View (0008,0053). Этот атрибут может быть включён, если преобразование многоформатных изображений Enhanced (Enhanced Multi-Frame Image Conversion) было принято при расширенном согласовании ассоциации. В противном случае он не должен быть включён.

  • Условно — атрибут Specific Character Set (0008,0005). Этот атрибут должен быть включён, если расширенные или заменяющие наборы символов могут использоваться в любом из атрибутов в идентификаторе запроса. В противном случае он не должен быть включён.

  • Условно — атрибут Timezone Offset From UTC (0008,0201). Этот атрибут должен быть включён, если ключевые атрибуты времени должны интерпретироваться явно в указанном местном часовом поясе. В противном случае он не должен присутствовать, т.е. не должен отправляться со значением нулевой длины.

Ключевые атрибуты и допустимые значения для уровня запроса должны быть определены в определении SOP класса для информационной модели Query/Retrieve.

C.4.1.1.3.2 Структура идентификатора ответа

Ответ C-FIND не должен содержать атрибуты, которых не было в запросе или не указано в данном разделе.

Идентификатор в ответе C-FIND должен содержать:

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

    Примечание

    1. All Required Keys in the request Identifier, as well as all Optional Keys specified in the Information Model for the SOP Class (e.g., in Section C.6.1.1, Section C.6.2.1) in the request Identifier that are supported by the SCP, will therefore be present in the Response Identifier.

    2. Required Keys and supported Optional Keys in the Response Identifier will have zero length if the SCP has no value to send; i.e., there is no requirement that the SCP have a value for these, or create a dummy value.

    3. Требование о том, что неподдерживаемые необязательные ключи, присутствующие в идентификаторе запроса, не должны включаться в идентификатор ответа, указано в Разделе C.2.2.1.3.

    4. Private Attributes present in the request Identifier may be ignored by the SCP if unrecognized (as defined for a Standard Extended SOP Class in PS3.2 ), hence may or may not be present in the Response Identifier.

  • Query/Retrieve Level (0008,0052), which defines the level of the query. The Query/Retrieve level shall be equal to the level specified in the request.

  • Conditionally, the Attribute Specific Character Set (0008,0005). This Attribute shall be included if expanded or replacement character sets may be used in any of the Attributes in the Response Identifier. It shall not be included otherwise. The C-FIND SCP is not required to return responses in the Specific Character Set requested by the SCU if that character set is not supported by the SCP. The SCP may return responses with a different Specific Character Set.

  • Conditionally, the Attribute Timezone Offset From UTC (0008,0201). This Attribute shall be included if any Attributes of time in the Response Identifier are to be interpreted explicitly in the designated local time zone. It shall not be present otherwise, i.e., it shall not be sent with a zero-length value.

The C-FIND SCP is required to support either or both the Retrieve AE Title Data Element or the Storage Media File-Set ID/Storage Media File Set UID Data Elements. An Identifier in a C-FIND response shall contain:

  • Storage Media File-Set ID (0088,0130), which defines a user or implementation specific human readable Identifier that identifies the Storage Media on which the Composite Object Instance(s) reside. This element pertains to the set of Composite Object Instances available at the Query/Retrieve Level specified in the Identifier of the C-FIND request (e.g., Patient, Study, Series, Composite Object Instance). This Attribute shall be present if the Retrieve AE Title Data Element is not present. A null value (Data Element length of 0) is valid for all levels except the lowest level in the Information Model as defined by the SOP Class.

  • Storage Media File-Set UID (0088,0140), which uniquely identifies the Storage Media on which the Composite Object Instance(s) reside. This element pertains to the set of Composite Object Instances available at the Query/Retrieve Level specified in the Identifier of the C-FIND request (e.g., Patient, Study, Series, Composite Object Instance). This Attribute shall be present if the Retrieve AE Title Data Element is not present. A null value (Data Element length of 0) is valid for all levels except the lowest level in the Information Model as defined by the SOP Class.

    Примечание

    Концепции File-Set используются в PS3.10.

  • Retrieve AE Title (0008,0054), which defines a list of DICOM Application Entity Title(s) that identify the location from which the Composite Object Instance(s) may be retrieved on the network. This element pertains to the set of Composite Object Instances available at the Query/Retrieve Level specified in the Identifier of the C-FIND request (e.g., Patient, Study, Series, Composite Object Instance). This Attribute shall be present if the Storage Media File-Set ID and Storage Media File-Set UID elements are not present. The Application Entity named in this field shall support either the C-GET or C-MOVE SOP Class of the Query/Retrieve Service Class. A null value (Data Element length of 0) is valid for all levels except the lowest level in the Information Model as defined by the SOP Class.

    Примечание

    1. For example, a DICOM AE with the AE Title of "A" performs a C-FIND request to a DICOM AE with the AE Title of "B" with the Query/Retrieve level set to "STUDY". DICOM AE "B" determines that the Composite Object Instances for each matching study may be retrieved by itself and sets the Data Element Retrieve AE Title to "B".

    2. File-Sets may not be defined at every Query/Retrieve Level. If the SCP supports the File-Set ID/File-Set UID option but does not define these Attributes at the Query/Retrieve Level specified in the C-FIND request it may return these Data Elements with a length of 0 to signify that the value is unknown. An SCU should reissue a C-FIND at a Query/Retrieve Level lower in the hierarchy.

    3. Тот факт, что значение ключевого атрибута неизвестно SCP сервисного класса Query/Retrieve, не означает, что оно отсутствует в базовом информационном объекте. Таким образом, последующее извлечение может привести к сохранению SOP Instance, который содержит значение атрибута.

The C-FIND SCP may also, but is not required to, support the Instance Availability (0008,0056) Data Element. This Data Element shall not be included in a C-FIND request. An Identifier in a C-FIND response may contain:

  • Instance Availability (0008,0056), which defines how rapidly Composite Object Instance(s) become available for transmission after a C-MOVE or C-GET retrieval request. This element pertains to the set of Composite Object Instances available at the Query/Retrieve Level specified in the Identifier of the C-FIND request (e.g., Patient, Study, Series, Composite Object Instance). When some composite instances are less rapidly available than others, the availability of the least rapidly available shall be returned. If this Data Element is not returned, the availability is unknown or unspecified. A null value (Data Element length of 0) is not permitted. The Enumerated Values for this Data Element are:

    • "ONLINE", which means the instances are immediately available,

    • "NEARLINE", which means the instances need to be retrieved from relatively slow media such as optical disk or tape, or require conversion that takes time,

    • "OFFLINE", which means the instances need to be retrieved by manual intervention,

    • "UNAVAILABLE", which means the instances cannot be retrieved. Note that SOP Instances that are unavailable may have an alternate representation that is available (see Section C.6.1.1.5.1).

C.4.1.1.4 Статус

Table C.4-1 defines the specific Status Code values that might be returned in a C-FIND response. General Status Code values and fields related to Status Code values are defined for C-FIND DIMSE Service in PS3.7.

Таблица C.4-1. Значения статуса ответа C-FIND

Статус сервиса

Дополнительное значение

Коды статуса

Связанные поля

Отказ

Отклонено: нехватка ресурсов

A700

(0000,0902)

Ошибка: набор данных не соответствует SOP классу

A900

(0000,0901)

(0000,0902)

Сбой: не удалось обработать

Cxxx

(0000,0901)

(0000,0902)

Отмена

Сопоставление прекращено из-за запроса Cancel

FE00

Нет

Успех

Сопоставление завершено — окончательный идентификатор не предоставляется.

0000

Нет

Ожидание

Сопоставления продолжаются — текущее совпадение предоставляется, и все необязательные ключи поддерживались так же, как обязательные ключи.

FF00

Идентификатор

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

FF01

Идентификатор


Некоторые коды статуса Failure зависят от реализации.

An SCP implementation shall assign specific Failure Status Codes by replacing each 'x' symbol with a hexadecimal digit in the range from 0 to F. An SCP implementation wishing to differentiate between causes of “Failed: Unable to process” Failure Meaning shall assign those causes specific Status Code Values within valid range specified in Table C.4-1.

An SCU implementation shall recognize any Failure Status Code within the value range specified in Table C.4-1 as an indicator of the Failure Meaning stated in the table. There is no requirement for an SCU implementation to differentiate between specific Status Codes within the valid range.

C.4.1.2 Поведение SCU C-FIND

В данном разделе рассматриваются как базовое, так и расширенное поведение SCU C-FIND.

C.4.1.2.1 Базовое поведение SCU

All C-FIND SCUs shall be capable of generating query requests that meet the requirements of the Hierarchical Search.

The Identifier contained in a C-FIND request shall contain a single value in the Unique Key Attribute for each level above the Query/Retrieve level. No Required or Optional Keys shall be specified that are associated with levels above the Query/Retrieve level.

The Unique Key Attribute associated with the Query/Retrieve level shall be contained in the C-FIND request and may specify Single Value Matching, Universal Value Matching, or List of UID Matching. In addition, Required and Optional Keys associated with the Query/Retrieve level may be contained in the Identifier.

An SCU conveys the following semantics using the C-FIND request:

  • The SCU requests that the SCP perform a match of all keys specified in the Identifier of the request against the information it possesses down to the Query/Retrieve level specified in the request.

    Примечание

    1. The SCU may not assume the SCP supports any Optional Keys. Hence, Optional Keys serve only to reduce network related overhead when they are supported by the SCP.

    2. The SCU must be prepared to filter C-FIND responses when the SCP fails to support an Optional Key specified in the C-FIND request.

  • The SCU shall interpret Pending responses to convey the Attributes of a match of an Entity at the level of the query.

  • The SCU shall interpret a response with a status equal to Success or Failure to convey the end of Pending responses.

  • The SCU shall interpret a Failure response to a C-FIND request as an indication that the SCP is unable to process the request.

  • The SCU may cancel the C-FIND service by issuing a C-CANCEL-FIND request at any time during the processing of the C-FIND. The SCU shall recognize a status of Cancel to indicate that the C-CANCEL-FIND was successful.

    Примечание

    The SCU needs to be prepared to receive C-FIND responses sent by the SCP until the SCP finally processed the C-CANCEL-FIND request.

C.4.1.2.2 Расширенное поведение SCU

Extended SCU behavior shall be negotiated at Association establishment time. If an option within the extended behavior is not agreed upon in the negotiation, then only baseline SCU behavior shall be performed with respect to that option. Extended SCU behavior includes all baseline behavior with the following option:

  • Relational-queries

  • Enhanced Multi-Frame Image Conversion

Может быть согласовано более одной опции.

C.4.1.2.2.1 Реляционные запросы

The C-FIND Service with relational-queries allows any combination of keys at any level in the hierarchy. The Unique Key Attribute associated with the Query/Retrieve level shall be contained in the C-FIND request and may specify Single Value Matching, Universal Value Matching, or List of UID Matching. Support for relational-queries removes the baseline restriction that a Unique Key shall be specified for all levels above the Query/Retrieve level in the C-FIND request.

C.4.1.2.2.2 Преобразование многоформатных изображений Enhanced

The C-FIND Service with Enhanced Multi-Frame Image Conversion allows for selection of the default or an alternative view of the instances represented by the Information Model.

Support for Enhanced Multi-Frame Image Conversion allows the SCU to specify the Query/Retrieve View (0008,0053) in the request Identifier with a value of either "CLASSIC" or "ENHANCED".

If Query/Retrieve View (0008,0053) is not present in the request Identifier, then the SCU requests that the SCP perform a match of all keys specified in the Identifier of the request against the information about the instances that it possesses, as received.

If Query/Retrieve View (0008,0053) is present with a value of "CLASSIC", then the SCU requests that the SCP perform a match of all keys specified in the Identifier of the request against the information about Classic single frame Instances (converted from Enhanced multi-frame Instances if required), as well as any instances that were converted to preserve referential integrity, and any that did not need to be converted.

If Query/Retrieve View (0008,0053) is present with a value of "ENHANCED", then the SCU requests that the SCP perform a match of all keys specified in the Identifier of the request against the information about Enhanced multi-frame Instances (converted from Classic single frame Instances if required), as well as any instances that were converted to preserve referential integrity, and any that did not need to be converted.

Примечание

  1. The SCU may assume that no duplicate information will be returned. For example, if an entire series of single frame instances can be converted to a separate series of converted instances, a STUDY level C-FIND will not return both series.

  2. The Query Information Model is unchanged, and the same unique, required and optional keys are equally applicable to both views, except that the values for the SERIES and IMAGE level queries will be different and will depend on the converted instance content.

  3. Непреобразованные экземпляры, например, для других модальностей, таких как Ultrasound, будут выглядеть одинаково независимо от представления.

  4. Реализации могут применять оптимизацию производительности, такую как предварительное вычисление или кэширование потенциальной информации, по которой могут выполняться запросы CLASSIC и ENHANCED, чтобы минимизировать значительные задержки между запросом и ответом, вызванные преобразованием «по требованию», но SCU может потребоваться учитывать возможность задержки ответа при настройке тайм-аутов и т.д.

C.4.1.3 Поведение SCP C-FIND

В данном разделе рассматриваются как базовое, так и расширенное поведение SCP C-FIND.

C.4.1.3.1 Базовое поведение SCP

All C-FIND SCPs shall be capable of processing queries that meet the requirements of the Hierarchical Search.

An SCP conveys the following semantics with a C-FIND response:

  • SCP выполняет сопоставление всех ключей, указанных в идентификаторе (Identifier) запроса, с информацией, которой он обладает, на уровне, заданном в запросе. Сопоставление атрибутов выполняется с использованием значений ключей, указанных в идентификаторе запроса C-FIND, как определено в Разделе C.2.

  • The SCP generates a C-FIND response for each match using the Hierarchical Search method. All such responses shall contain an Identifier whose Attributes contain values from a single match. All such responses shall contain a status of Pending.

  • Когда все совпадения отправлены, SCP генерирует ответ C-FIND, содержащий статус Success. Статус Success должен означать, что ответ отправлен для каждого совпадения, известного SCP.

    Примечание

    Когда совпадений нет, ответы со статусом Pending не отправляются — только один ответ со статусом Success.

  • The SCP shall generate a response with a status of Failure if it is unable to process the request. A Failure response shall contain no Identifier.

  • If the SCP receives C-CANCEL-FIND indication before it has completed the processing of the matches it shall interrupt the matching process and return a status of Cancel.

  • Если SCP управляет изображениями в нескольких альтернативных кодированиях (см. Раздел C.6.1.1.5.1), только одно из альтернативных кодирований изображения должно быть включено в набор совпадений для запроса C-FIND на уровне экземпляра (Instance).

    Примечание

    При запросе изображений с альтернативными кодированиями SCP может выбрать экземпляр с соответствующим кодированием для ответа на запрос на основе идентичности SCU или других факторов.

C.4.1.3.1.1 Метод иерархического поиска

Начиная с верхнего уровня в информационной модели Query/Retrieve и продолжая до достижения уровня, указанного в запросе C-FIND, следующие процедуры используются для генерации совпадений:

  1. Если текущий уровень является уровнем, указанным в запросе C-FIND, то строки сопоставления ключей, содержащиеся в идентификаторе запроса C-FIND, сопоставляются со значениями ключевых атрибутов для каждой сущности на текущем уровне. Для каждой сущности, атрибуты которой соответствуют всем указанным строкам сопоставления, конструируется идентификатор. Этот идентификатор должен содержать все уникальные ключи на более высоких уровнях и все значения атрибутов для этой сущности, соответствующие указанным в запросе C-FIND. Возвращается ответ для каждого такого идентификатора. Если нет совпадающих ключей, то совпадений нет — возвращается ответ со статусом Success и без идентификатора.

  2. Otherwise, if the current level is not the level specified in the C-FIND request and there is an entity matching the Unique Key Attribute Value for this level specified in the C-FIND request, perform this procedure at the next level down in the hierarchy.

  3. В противном случае совпадений нет; возвращается ответ со статусом Success.

    Примечание

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

C.4.1.3.2 Расширенное поведение SCP

Extended SCP behavior shall be negotiated at Association establishment time. If an option within the extended behavior is not agreed upon in the negotiation, then only baseline SCP behavior shall be performed with respect to that option. Extended SCP behavior includes all baseline behavior with the following option:

  • Relational-queries

  • Enhanced Multi-Frame Image Conversion

Может быть согласовано более одной опции.

C.4.1.3.2.1 Реляционные запросы

The C-FIND Service with relational-queries allows any combination of keys at any level in the hierarchy. At the lowest level, a query using the relational-queries shall contain the Unique Key for that level with either Single Value Matching, Wild Card Matching, or Universal Matching. Support for relational-queries removes the baseline restriction that a Unique Key shall be specified for all levels above the Query/Retrieve level in the C-FIND request.

The C-FIND SCP shall perform matching based on all keys specified in the C-FIND request regardless of the Query/Retrieve level.

C.4.1.3.2.2 Метод реляционного поиска

A query using the relational method may contain any combination of keys at any level in the hierarchy. Starting at the top level in the Query/Retrieve Information Model, continuing until the Query/Retrieve level specified in the C-FIND request is reached, the following procedures are used to generate matches:

  1. Строки сопоставления ключей, содержащиеся в идентификаторе запроса C-FIND, сопоставляются со значениями ключевых атрибутов для каждой сущности на текущем уровне.

  2. If no Key Attribute is specified at the current level and the current level is not the level specified in the C-FIND request, the match shall be performed as if a wild card were specified for the Unique Key Attribute for the current level (i.e., all entities at the current level shall match).

  3. Если текущий уровень является уровнем, указанным в запросе C-FIND, то для каждой совпадающей сущности (совпадающая сущность — это та, атрибуты которой соответствуют всем указанным строкам сопоставления в ключевых атрибутах) конструируется идентификатор. Этот идентификатор должен содержать все атрибуты, сгенерированные данной процедурой на более высоких уровнях на этом пути рекурсии, и все значения ключевых атрибутов для этой сущности, соответствующие указанным в запросе C-FIND.

  4. Otherwise, if the current level is not the level specified in the C-FIND request, then for each matching entity construct a list of Attributes containing all of the matching Key Attributes and all Attributes that were prepared at the previous level for this entity. Then perform this procedure at the next level down in the hierarchy for each matching entity.

  5. Otherwise, if there are no matches, return a response with status equal to Success and no Identifier.

Примечание

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

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

C.4.1.3.2.3 Преобразование многоформатных изображений Enhanced

If Query/Retrieve View (0008,0053) is not present in the request Identifier, then the SCP shall perform a match of all keys specified in the Identifier of the request against the information about the instances that it possesses, as received.

If Query/Retrieve View (0008,0053) is present with a value of "CLASSIC", then the SCP shall perform a match of all keys specified in the Identifier of the request against the information about Classic single frame Instances (converted from Enhanced multi-frame Instances if required), as well as any instances that were converted to preserve referential integrity, and any that did not need to be converted.

If Query/Retrieve View (0008,0053) is present with a value of "ENHANCED", then the SCP shall perform a match of all keys specified in the Identifier of the request against the information about Enhanced multi-frame Instances (converted from Classic single frame Instances if required), as well as any instances that were converted to preserve referential integrity, and any that did not need to be converted.

Примечание

  1. The SCP will not return information that is duplicated. For example, if an entire series of single frame instances can be converted to a separate series of converted instances, a STUDY level C-FIND will not return both series.

  2. The Query Information Model is unchanged, and the same unique, required and optional keys are equally applicable to both views, except that the values for the SERIES and IMAGE level queries will be different and will depend on the converted instance content.

  3. Непреобразованные экземпляры, например, для других модальностей, таких как Ultrasound, будут выглядеть одинаково независимо от представления.

C.4.2 Операция C-MOVE

SCUs of some SOP Classes of the Query/Retrieve Service Class may generate retrievals using the C-MOVE operation as described in PS3.7. The C-MOVE operation allows an application entity to instruct another application entity to transfer stored SOP Instances to another application entity using the C-STORE operation. Support for the C-MOVE service shall be agreed upon at Association establishment time by both the SCU and SCP of the C-MOVE in order for a C-MOVE operation to occur over the Association. The C-STORE sub-operations shall always be accomplished over an Association different from the Association that accomplishes the C-MOVE operation. Hence, the SCP of the Query/Retrieve Service Class serves as the SCU of the Storage Service Class.

Примечание

Прикладная сущность, получающая хранимые SOP Instance, может как быть, так и не быть инициатором операции C-MOVE.

Запрос C-MOVE может быть выполнен на любом уровне информационной модели Query/Retrieve. Однако передача хранимых экземпляров SOP может не выполняться на этом уровне. Уровень, на котором выполняется передача, зависит от SOP класса (см. Раздел C.6).

C.4.2.1 Параметры сервиса C-MOVE

C.4.2.1.1 SOP Class UID

The SOP Class UID identifies the Query/Retrieve Information Model against which the C-MOVE is to be performed. Support for the SOP Class UID is implied by the Abstract Syntax UID of the Presentation Context used by this C-MOVE operation.

C.4.2.1.2 Приоритет

The Priority Attribute defines the requested priority of the C-MOVE operation and corresponding C-STORE sub-operations with respect to other DIMSE operations being performed by the same SCP.

Обработка запросов приоритета не требуется от SCP. Поддерживает ли SCP обработку приоритета и значение различных уровней приоритета должно быть указано в заявлении о соответствии SCP. Один и тот же приоритет должен использоваться для всех подопераций C-STORE.

C.4.2.1.3 Получатель перемещения

Получатель перемещения (Move Destination) определяет заголовок прикладной сущности (Application Entity Title) получателя подопераций C-STORE.

C.4.2.1.4 Идентификатор

Запрос C-MOVE должен содержать идентификатор (Identifier). Ответ C-MOVE должен условно содержать идентификатор, как требуется в Разделе C.4.2.1.4.2.

Примечание

Идентификатор указан как U в определении примитива C-MOVE в PS3.7, но специализирован для использования с данным сервисом.

C.4.2.1.4.1 Структура идентификатора запроса

Идентификатор в запросе C-MOVE должен содержать:

  • Query/Retrieve Level (0008,0052), определяющий уровень извлечения

  • Атрибуты уникальных ключей (Unique Key Attributes), которые могут включать Patient ID (0010,0020), Study Instance UIDs (0020,000D), Series Instance UIDs (0020,000E) и SOP Instance UIDs (0008,0018)

  • Условно — атрибут Query/Retrieve View (0008,0053). Этот атрибут может быть включён, если преобразование многоформатных изображений Enhanced (Enhanced Multi-Frame Image Conversion) было принято во время расширенного согласования ассоциации (Association Extended Negotiation). В противном случае он не должен включаться.

Specific Character Set (0008,0005) должен присутствовать, если Patient ID (0010,0020) использует набор символов, отличный от Default Character Repertoire.

Уникальные ключи на каждом уровне иерархии и допустимые значения для уровня извлечения должны быть определены в определении SOP класса для информационной модели Query/Retrieve.

Примечание

  1. При нереляционном поведении может быть извлечено более одной сущности, если уровень Query/Retrieve равен IMAGE, SERIES или STUDY с использованием сопоставления по списку UID, но для Patient ID (0010,0020) может быть указано только одно значение при сопоставлении по одному значению.

  2. Эмитент Patient ID (0010,0020) подразумевается; не существует возможности передать Issuer of Patient ID (0010,0021). При возможности неоднозначности значения Patient ID (0010,0020) следует использовать извлечение на уровне STUDY вместо извлечения на уровне PATIENT.

C.4.2.1.4.2 Структура идентификатора ответа

Failed SOP Instance UID List (0008,0058) задаёт список UID экземпляров SOP подопераций C-STORE, для которых данная операция C-MOVE завершилась неудачей. Идентификатор в ответе C-MOVE должен условно содержать Failed SOP Instance UID List (0008,0058) в зависимости от значения статуса ответа C-MOVE. Если ни одна подоперация C-STORE не завершилась неудачей, атрибут Failed SOP Instance UID List (0008,0058) отсутствует, и поэтому в ответе C-MOVE не должен передаваться набор данных (Data Set).

Specific Character Set (0008,0005) не должен присутствовать.

Идентификатор в ответе C-MOVE со статусом:

  • Cancel, Failure или Warning должен содержать атрибут Failed SOP Instance UID List

  • Pending не должен содержать атрибут Failed SOP Instance UID List (без набора данных)

C.4.2.1.5 Статус

Таблица C.4-2 определяет конкретные значения кодов состояния, которые могут быть возвращены в ответе C-MOVE. Общие значения кодов состояния и поля, связанные со значениями кодов состояния, для службы C-MOVE DIMSE определены в PS3.7.

Таблица C.4-2. Значения состояния ответа C-MOVE

Состояние службы

Дополнительное значение

Коды состояния

Связанные поля

Сбой

Отказано: нехватка ресурсов — невозможно вычислить количество совпадений

A701

(0000,0902)

Отказано: нехватка ресурсов — невозможно выполнить подоперации

A702

(0000,1021)

(0000,1022)

(0000,1023)

Отказано: получатель перемещения неизвестен

A801

(0000,0902)

Ошибка: набор данных не соответствует SOP Class

A900

(0000,0901)

(0000,0902)

Ошибка: невозможно обработать

Cxxx

(0000,0901)

(0000,0902)

Отмена

Подоперации прекращены вследствие индикации отмены

FE00

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)

Предупреждение

Подоперации завершены — один или несколько сбоев

B000

(0000,1021)

(0000,1022)

(0000,1023)

Успех

Подоперации завершены — без сбоев

0000

(0000,1021)

(0000,1022)

(0000,1023)

Ожидание

Подоперации продолжаются

FF00

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)


Некоторые коды состояния сбоя зависят от реализации.

Реализация SCP должна назначать конкретные коды состояния сбоя путём замены каждого символа 'x' шестнадцатеричной цифрой в диапазоне от 0 до F. Реализация SCP, желающая различать причины значения сбоя «Ошибка: невозможно обработать», должна назначить этим причинам конкретные значения кодов состояния в допустимом диапазоне, указанном в Таблице C.4-2.

Реализация SCU должна распознавать любой код состояния сбоя в диапазоне значений, указанном в Таблице C.4-2, как индикатор значения сбоя, указанного в таблице. От реализации SCU не требуется различать конкретные коды состояния в пределах допустимого диапазона.

C.4.2.1.6 Количество оставшихся подопераций

Включение количества оставшихся подопераций является условным и зависит от состояния в ответе C-MOVE. Количество оставшихся подопераций указывает число оставшихся подопераций C-STORE, необходимых для завершения операции C-MOVE.

Ответ C-MOVE со статусом:

  • Ожидание должен содержать атрибут «Количество оставшихся подопераций»

  • Отмена может содержать атрибут «Количество оставшихся подопераций»

  • Предупреждение, Сбой или Успех не должны содержать атрибут «Количество оставшихся подопераций»

C.4.2.1.7 Количество завершённых подопераций

Включение количества завершённых подопераций является условным и зависит от состояния в ответе C-MOVE. Количество завершённых подопераций указывает число подопераций C-STORE, созданных запрошенной передачей, которые были успешно завершены.

Ответ C-MOVE со статусом:

  • Ожидание должен содержать атрибут «Количество завершённых подопераций»

  • Отмена, Предупреждение, Сбой или Успех может содержать атрибут «Количество завершённых подопераций»

C.4.2.1.8 Количество неудачных подопераций

Включение количества неудачных подопераций является условным и зависит от состояния в ответе C-MOVE. Количество неудачных подопераций указывает число подопераций C-STORE, созданных запрошенной передачей, которые завершились неудачно.

Ответ C-MOVE со статусом:

  • Ожидание должен содержать атрибут «Количество неудачных подопераций»

  • Отмена, Предупреждение, Сбой или Успех может содержать атрибут «Количество неудачных подопераций»

C.4.2.1.9 Количество подопераций с предупреждением

Включение количества подопераций с предупреждением является условным и зависит от состояния в ответе C-MOVE. Количество подопераций с предупреждением указывает число подопераций C-STORE, созданных запрошенной передачей, которые имели статус предупреждения.

Ответ C-MOVE со статусом:

  • Ожидание должен содержать атрибут «Количество подопераций с предупреждением»

  • Отмена, Предупреждение, Сбой или Успех может содержать атрибут «Количество подопераций с предупреждением»

C.4.2.2 Поведение SCU для C-MOVE

В этом разделе рассматривается как базовое, так и расширенное поведение SCU для C-MOVE.

C.4.2.2.1 Базовое поведение SCU

SCU передаёт следующие семантические значения с запросом C-MOVE:

  • SCU должен указывать одно значение в атрибуте уникального ключа для каждого уровня выше уровня запроса/получения. Для уровня получения SCU должен указывать одно значение одного уникального ключа, если уровень получения выше уровня STUDY, и должен указывать один UID или список UID, если требуется получение нескольких элементов и уровень получения — STUDY, SERIES или IMAGE. SCU также должен указывать получателя перемещения. Получатель перемещения должен быть заголовком прикладной сущности DICOM (DICOM Application Entity Title) прикладной сущности DICOM, способной выступать в роли SCP сервисного класса хранения (Storage Service Class).

  • SCU должен интерпретировать ответы на C-MOVE со статусом «Ожидание» во время обработки подопераций C-STORE. Эти ответы должны указывать количество оставшихся, завершённых, неудачных подопераций C-STORE и подопераций C-STORE с предупреждением.

  • SCU должен интерпретировать ответы со статусом «Успех», «Предупреждение» или «Сбой» как окончательные ответы. Окончательный ответ должен указывать количество успешных подопераций C-STORE и количество неудачных подопераций C-STORE, являющихся результатом операции C-MOVE. SCU должен интерпретировать статус:

    • «Успех» — означает, что все подоперации были успешно завершены

    • «Предупреждение» — означает, что одна или несколько подопераций были успешно завершены и одна или несколько подопераций были неудачными или имели статус предупреждения, либо все подоперации имели статус предупреждения

    • «Сбой» — означает, что все подоперации были неудачными

  • SCU может отменить службу C-MOVE путём отправки запроса C-CANCEL-MOVE в любое время во время обработки C-MOVE. SCU должен интерпретировать ответ C-MOVE со статусом «Отмена» как указание того, что передача была отменена. Ответ C-MOVE со статусом «Отмена» должен содержать количество завершённых, неудачных подопераций C-STORE и подопераций C-STORE с предупреждением. Если присутствует, счётчик оставшихся подопераций должен содержать количество подопераций C-STORE, которые не были начаты вследствие запроса C-CANCEL-MOVE.

C.4.2.2.2 Расширенное поведение SCU

Расширенное поведение SCU должно быть согласовано во время установления ассоциации. Если параметр в рамках расширенного поведения не согласован в ходе переговоров, то в отношении этого параметра должно выполняться только базовое поведение SCU. Расширенное поведение SCU включает всё базовое поведение со следующими дополнительными параметрами:

  • Реляционное получение (Relational-retrieve)

  • Преобразование расширенных много кадров их изображений (Enhanced Multi-Frame Image Conversion)

Может быть согласовано более одного параметра.

C.4.2.2.2.1 Реляционное получение

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

  • все экземпляры составных объектов (Composite Object Instances), относящиеся к исследованию, путём указания только Study Instance UID (0020,000D)

  • все экземпляры составных объектов, относящиеся к серии, путём указания только Series Instance UID (0020,000E)

  • отдельные экземпляры составных объектов путём указания только списка SOP Instance UID (0008,0018)

C.4.2.2.2.2 Преобразование расширенных много кадров их изображений

Служба C-MOVE с преобразованием расширенных много кадров их изображений (Enhanced Multi-Frame Image Conversion) позволяет выбрать представление по умолчанию или альтернативное представление экземпляров, описываемых информационной моделью, и, следовательно, получение либо исходных, либо преобразованных изображений вместе со всеми непреобразованными экземплярами, все из которых должны быть обработаны для сохранения ссылочной целостности в рамках области пациента.

Поддержка преобразования расширенных много кадров их изображений позволяет SCU указать атрибут Query/Retrieve View (0008,0053) в идентификаторе запроса со значением «CLASSIC» или «ENHANCED».

Если Query/Retrieve View (0008,0053) отсутствует в идентификаторе запроса, то SCU запрашивает, чтобы SCP предоставил все запрошенные экземпляры, которыми он располагает, в исходном виде.

Если Query/Retrieve View (0008,0053) присутствует со значением «CLASSIC», то SCU запрашивает, чтобы SCP предоставил все классические однокадровые экземпляры (преобразованные из расширенных мультикадровых экземпляров, если требуется), а также любые экземпляры, преобразованные для сохранения ссылочной целостности, и те, которые не требуют преобразования.

Если Query/Retrieve View (0008,0053) присутствует со значением «ENHANCED», то SCU запрашивает, чтобы SCP предоставил все расширенные мультикадровые экземпляры (преобразованные из классических однокадровых экземпляров, если требуется), а также любые экземпляры, преобразованные для сохранения ссылочной целостности, и те, которые не требуют преобразования.

Примечание

  1. SCU может предполагать, что дублирующая информация не будет предоставлена. Например, если целая серия однокадровых экземпляров может быть преобразована в отдельную серию преобразованных экземпляров, C-MOVE на уровне STUDY не предоставит обе серии.

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

  3. Query/Retrieve View по-прежнему требуется в идентификаторе запроса на уровне IMAGE или SERIES, даже если запрошенные уникальные ключи однозначны, и представление в определённом смысле «избыточно», поскольку преобразование, создавшее запрошенные экземпляры, могло ещё не быть выполнено. Не допускается указывать представление, несовместимое с запрошенными уникальными ключами.

C.4.2.3 Поведение SCP для C-MOVE

В этом разделе рассматривается как базовое, так и расширенное поведение SCP для C-MOVE.

C.4.2.3.1 Базовое поведение SCP

SCP передаёт следующие семантические значения с ответом C-MOVE:

  • SCP должен идентифицировать набор сущностей на уровне передачи на основе значений уникальных ключей в идентификаторе запроса C-MOVE. SCP должен инициировать подоперации C-STORE для соответствующих экземпляров SOP хранения. Эти подоперации C-STORE должны выполняться по другой ассоциации (которая может уже существовать), отличной от операции C-MOVE. SCP сервисного класса запроса/получения должен выступать в роли SCU сервисного класса хранения.

  • SCP должен либо повторно использовать установленную и совместимую ассоциацию, либо установить новую ассоциацию для подопераций C-STORE. SCP должен инициировать подоперации C-STORE по этой ассоциации для всех хранимых экземпляров SOP, связанных с Patient ID, списком Study Instance UID, списком Series Instance UID или списком SOP Instance UID, в зависимости от уровня запроса/получения, указанного в запросе C-MOVE. Подоперация считается неудачной, если SCP не может согласовать соответствующий контекст представления для данного хранимого экземпляра SOP.

  • SCP может генерировать ответы на C-MOVE со статусом «Ожидание» во время обработки подопераций C-STORE. Эти ответы должны указывать количество оставшихся, завершённых, неудачных подопераций C-STORE и подопераций C-STORE с предупреждением.

  • Когда количество оставшихся подопераций достигает нуля, SCP должен генерировать окончательный ответ со статусом «Успех», «Предупреждение» или «Сбой». Этот ответ должен указывать количество завершённых подопераций, количество неудачных подопераций и количество подопераций со статусом предупреждения. Статус, содержащийся в ответе C-MOVE, должен включать:

    • «Успех», если все подоперации были успешно завершены

    • «Предупреждение», если одна или несколько подопераций были успешно завершены и одна или несколько подопераций были неудачными или имели статус предупреждения

    • «Предупреждение», если все подоперации имели статус предупреждения

    • «Сбой», если все подоперации были неудачными

  • SCP может получить запрос C-CANCEL-MOVE в любое время во время обработки C-MOVE. SCP должен прервать всю обработку подопераций C-STORE и вернуть статус «Отмена» в ответе C-MOVE. Ответ C-MOVE со статусом «Отмена» должен содержать количество завершённых, неудачных подопераций C-STORE и подопераций C-STORE с предупреждением. Если присутствует, счётчик оставшихся подопераций должен содержать количество подопераций C-STORE, которые не были начаты вследствие запроса C-CANCEL-MOVE.

  • Если SCP управляет изображениями в нескольких альтернативных кодировках (см. Раздел C.6.1.1.5.1), только одно из альтернативных кодировок изображения должно быть включено в набор экземпляров объектов, извлекаемых запросом C-MOVE на уровне Patient, Study или Series.

    Примечание

    Для получения изображений с альтернативными кодировками с использованием запроса C-MOVE на уровне Patient, Study или Series, SCP может выбрать соответствующим образом кодированный экземпляр для получения на основе идентичности SCU, синтаксисов передачи, принятых в согласовании ассоциации C-STORE, или других факторов.

Примечание

Если ассоциация, по которой была инициирована операция C-MOVE, аварийно завершена, то будет невозможно выдать дальнейшие ожидающие ответы, ни окончательный ответ, ни будут получены запросы C-CANCEL-MOVE. Поведение SCP C-MOVE, действующего в качестве SCU C-STORE, в этом состоянии не определено. В частности, не определено, будут ли продолжаться незавершённые подоперации C-STORE.

C.4.2.3.2 Расширенное поведение SCP

Расширенное поведение SCP должно быть согласовано во время установления ассоциации. Если параметр в рамках расширенного поведения не согласован в ходе переговоров, то в отношении этого параметра должно выполняться только базовое поведение SCP. Расширенное поведение SCP включает всё базовое поведение со следующими дополнительными параметрами:

  • Реляционное получение (Relational-retrieve)

  • Преобразование расширенных мультикадровых изображений (Enhanced Multi-Frame Image Conversion)

Может быть согласовано более одного параметра.

C.4.2.3.2.1 Реляционное получение

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

  • всех экземпляров составных объектов, относящихся к исследованию, путём указания только Study Instance UID (0020,000D)

  • всех экземпляров составных объектов, относящихся к серии, путём указания только Series Instance UID (0020,000E)

  • отдельных экземпляров составных объектов путём указания только списка SOP Instance UID (0008,0018)

C.4.2.3.2.2 Преобразование расширенных мультикадровых изображений

Если Query/Retrieve View (0008,0053) отсутствует в идентификаторе запроса, то SCP должен идентифицировать набор сущностей на уровне передачи на основе значений уникальных ключей в идентификаторе запроса C-MOVE, соответствующих экземплярам, которыми он располагает, в исходном виде, и должен инициировать подоперации C-STORE для всех соответствующих экземпляров SOP хранения.

Если Query/Retrieve View (0008,0053) присутствует со значением «CLASSIC», то SCP должен идентифицировать набор сущностей на уровне передачи на основе значений уникальных ключей в идентификаторе запроса C-MOVE, соответствующих классическим однокадровым экземплярам (преобразованным из расширенных мультикадровых экземпляров, если требуется), а также любым экземплярам, преобразованным для сохранения ссылочной целостности, и тем, которые не требуют преобразования, и должен инициировать подоперации C-STORE для всех соответствующих экземпляров SOP хранения.

Если Query/Retrieve View (0008,0053) присутствует со значением «ENHANCED», то SCP должен идентифицировать набор сущностей на уровне передачи на основе значений уникальных ключей в идентификаторе запроса C-MOVE, соответствующих расширенным мультикадровым экземплярам (преобразованным из классических однокадровых экземпляров, если требуется), а также любым экземплярам, преобразованным для сохранения ссылочной целостности, и тем, которые не требуют преобразования, и должен инициировать подоперации C-STORE для всех соответствующих экземпляров SOP хранения.

Примечание

  1. SCP не будет отправлять дублирующую информацию SCP C-STORE. Например, если целая серия однокадровых экземпляров может быть преобразована в отдельную серию преобразованных экземпляров, C-MOVE на уровне STUDY не отправит обе серии.

  2. SCP C-STORE должен поддерживать необходимые SOP Class для преобразованных экземпляров, в противном случае подоперации C-STORE завершатся неудачно обычным образом, и это будет отражено в ответах C-MOVE.

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

  4. Query/Retrieve View по-прежнему требуется в идентификаторе запроса на уровне IMAGE или SERIES, даже если запрошенные уникальные ключи однозначны.

C.4.3 Операция C-GET

SCU некоторых SOP Class сервисного класса запроса/получения могут выполнять извлечение с использованием операции C-GET, как описано в PS3.7. Операция C-GET позволяет прикладной сущности поручить другой прикладной сущности передать хранимые экземпляры SOP инициирующей прикладной сущности с использованием операции C-STORE. Поддержка службы C-GET должна быть согласована во время установления ассоциации как SCU, так и SCP C-GET, чтобы операция C-GET могла быть выполнена через ассоциацию. Подоперации C-STORE должны выполняться по той же ассоциации, что и операция C-GET. Следовательно, SCP сервисного класса запроса/получения выступает в роли SCU сервисного класса хранения.

Примечание

Прикладная сущность, принимающая хранимые экземпляры SOP, всегда является инициатором операции C-GET.

Запрос C-GET может быть выполнен на любом уровне информационной модели запроса/получения. Однако передача хранимых экземпляров SOP может не выполняться на этом уровне. Уровень, на котором выполняется передача, зависит от SOP Class.

C.4.3.1 Параметры службы C-GET

C.4.3.1.1 SOP Class UID

SOP Class UID идентифицирует информационную модель запроса/получения, по которой выполняется C-GET. Поддержка SOP Class UID подразумевается Abstract Syntax UID контекста представления, используемого этой операцией C-GET.

C.4.3.1.2 Приоритет

Атрибут приоритета (Priority) определяет запрошенный приоритет операции C-GET и соответствующих подопераций C-STORE по отношению к другим операциям DIMSE, выполняемым тем же SCP.

Обработка запросов с приоритетом не требуется от SCP. Поддерживает ли SCP обработку с приоритетом и значение различных уровней приоритета должны быть указаны в заявлении о соответствии SCP. Один и тот же приоритет должен использоваться для всех подопераций C-STORE.

C.4.3.1.3 Идентификатор

Запрос C-GET должен содержать идентификатор. Ответ C-GET должен условно содержать идентификатор, как требуется в Разделе C.4.3.1.3.2.

Примечание

Идентификатор указан как U в определении примитива C-GET в PS3.7, но специализирован для использования с данной службой.

C.4.3.1.3.1 Структура идентификатора запроса

Идентификатор в запросе C-GET должен содержать:

  • Query/Retrieve Level (0008,0052), определяющий уровень получения

  • Атрибуты уникального ключа, которые могут включать Patient ID (0010,0020), Study Instance UID (0020,000D), Series Instance UID (0020,000E) и SOP Instance UID (0008,0018)

  • Условно — атрибут Query/Retrieve View (0008,0053). Этот атрибут может быть включён, если преобразование расширенных мультикадровых изображений было принято во время расширенного согласования ассоциации. В остальных случаях он не должен включаться.

Specific Character Set (0008,0005) должен присутствовать, если Patient ID (0010,0020) использует набор символов, отличный от набора символов по умолчанию (Default Character Repertoire).

Уникальные ключи на каждом уровне иерархии и допустимые значения для уровня получения должны быть определены в определении SOP Class для информационной модели запроса/получения.

Примечание

  1. При нереляционном поведении может быть извлечено более одной сущности, если Query/Retrieve Level — IMAGE, SERIES или STUDY, с использованием сопоставления списка UID (List of UID matching), но для Patient ID (0010,0020) может быть указано только одно значение при сопоставлении по одному значению (Single Value Matching).

  2. Эмитент Patient ID (0010,0020) подразумевается; не предусмотрена возможность отправки Issuer of Patient ID (0010,0021). При возможности неоднозначного толкования значения Patient ID (0010,0020) следует использовать получение на уровне STUDY вместо получения на уровне PATIENT.

C.4.3.1.3.2 Структура идентификатора ответа

Список UID неудачных экземпляров SOP (Failed SOP Instance UID List, 0008,0058) указывает список UID экземпляров SOP подопераций C-STORE, для которых данная операция C-GET завершилась неудачно. Идентификатор в ответе C-GET должен условно содержать Failed SOP Instance UID List (0008,0058) в зависимости от ответа C-GET. Если ни одна подоперация C-STORE не завершилась неудачно, Failed SOP Instance UID List (0008,0058) отсутствует, и, следовательно, набор данных не должен передаваться в ответе C-GET.

Specific Character Set (0008,0005) не должен присутствовать.

Идентификатор в ответе C-GET со статусом:

  • Отмена, Сбой или Предупреждение должен содержать атрибут Failed SOP Instance UID List

  • Ожидание не должен содержать атрибут Failed SOP Instance UID List (без набора данных)

C.4.3.1.4 Статус

Таблица C.4-3 определяет конкретные значения кодов состояния, которые могут быть возвращены в ответе C-GET. Общие значения кодов состояния и поля, связанные со значениями кодов состояния, для службы C-GET DIMSE определены в PS3.7.

Таблица C.4-3. Значения состояния ответа C-GET

Состояние службы

Дополнительное значение

Коды состояния

Связанные поля

Сбой

Отказано: нехватка ресурсов — невозможно вычислить количество совпадений

A701

(0000,0902)

Отказано: нехватка ресурсов — невозможно выполнить подоперации

A702

(0000,1021)

(0000,1022)

(0000,1023)

Ошибка: набор данных не соответствует SOP Class

A900

(0000,0901)

(0000,0902)

Ошибка: невозможно обработать

Cxxx

(0000,0901)

(0000,0902)

Отмена

Подоперации прекращены вследствие индикации отмены

FE00

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)

Предупреждение

Подоперации завершены — один или несколько сбоев или предупреждений

B000

(0000,1021)

(0000,1022)

(0000,1023)

Успех

Подоперации завершены — без сбоев или предупреждений

0000

(0000,1021)

(0000,1022)

(0000,1023)

Ожидание

Подоперации продолжаются

FF00

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)


Некоторые коды состояния сбоя зависят от реализации.

Реализация SCP должна назначать конкретные коды состояния сбоя путём замены каждого символа 'x' шестнадцатеричной цифрой в диапазоне от 0 до F. Реализация SCP, желающая различать причины значения сбоя «Ошибка: невозможно обработать», должна назначить этим причинам конкретные значения кодов состояния в допустимом диапазоне, указанном в Таблице C.4-3.

Реализация SCU должна распознавать любой код состояния сбоя в диапазоне значений, указанном в Таблице C.4-3, как индикатор значения сбоя, указанного в таблице. От реализации SCU не требуется различать конкретные коды состояния в пределах допустимого диапазона.

C.4.3.1.5 Количество оставшихся подопераций

Включение количества оставшихся подопераций является условным и зависит от состояния в ответе C-GET. Количество оставшихся подопераций указывает число оставшихся подопераций C-STORE, необходимых для завершения операции C-GET.

Ответ C-GET со статусом:

  • Ожидание должен содержать атрибут «Количество оставшихся подопераций»

  • Отмена может содержать атрибут «Количество оставшихся подопераций»

  • Предупреждение, Сбой или Успех не должны содержать атрибут «Количество оставшихся подопераций».

C.4.3.1.6 Количество завершённых подопераций

Включение количества завершённых подопераций является условным и зависит от состояния в ответе C-GET. Количество завершённых подопераций указывает число подопераций C-STORE, созданных запрошенной передачей, которые были успешно завершены.

Ответ C-GET со статусом:

  • Ожидание должен содержать атрибут «Количество завершённых подопераций»

  • Отмена, Предупреждение, Сбой или Успех может содержать атрибут «Количество завершённых подопераций»

C.4.3.1.7 Количество неудачных подопераций

Включение количества неудачных подопераций является условным и зависит от состояния в ответе C-GET. Количество неудачных подопераций указывает число подопераций C-STORE, созданных запрошенной передачей, которые завершились неудачно.

Ответ C-GET со статусом:

  • Ожидание должен содержать атрибут «Количество неудачных подопераций»

  • Отмена, Предупреждение, Сбой или Успех может содержать атрибут «Количество неудачных подопераций»

C.4.3.1.8 Количество подопераций с предупреждением

Включение количества подопераций с предупреждением является условным и зависит от состояния в ответе C-GET. Количество подопераций с предупреждением указывает число подопераций C-STORE, созданных запрошенной передачей, которые имели статус предупреждения.

Ответ C-GET со статусом:

  • Ожидание должен содержать атрибут «Количество подопераций с предупреждением»

  • Отмена, Предупреждение, Сбой или Успех может содержать атрибут «Количество подопераций с предупреждением»

C.4.3.2 Поведение SCU для C-GET

В этом разделе рассматривается как базовое, так и расширенное поведение SCU для C-GET.

C.4.3.2.1 Базовое поведение SCU

SCU передаёт следующие семантические значения с запросом C-GET:

  • SCU должен предложить достаточные контексты представления во время установления ассоциации для обеспечения ожидаемых подопераций C-STORE, которые должны выполняться по той же ассоциации. SCU сервисного класса запроса/получения должен выступать в роли SCP сервисного класса хранения.

  • SCU должен указывать одно значение в атрибуте уникального ключа для каждого уровня выше уровня запроса/получения. Для уровня получения SCU должен указывать одно значение одного уникального ключа, если уровень получения выше уровня STUDY, и должен указывать один UID или список UID, если требуется получение нескольких элементов и уровень получения — STUDY, SERIES или IMAGE.

  • SCU должен интерпретировать ответы C-GET со статусом «Ожидание» во время обработки подопераций C-STORE. Эти ответы должны указывать количество оставшихся, завершённых, неудачных подопераций C-STORE и подопераций C-STORE с предупреждением.

  • SCU должен интерпретировать ответ C-GET со статусом «Успех», «Предупреждение» или «Сбой» как окончательный ответ. Окончательный ответ должен указывать количество завершённых подопераций и количество неудачных подопераций C-STORE, являющихся результатом операции C-GET. SCU должен интерпретировать статус:

    • «Успех» — означает, что все подоперации были успешно завершены

    • «Предупреждение» — означает, что одна или несколько подопераций были успешно завершены и одна или несколько неудачных, либо все подоперации имели статус предупреждения

    • «Сбой» — означает, что все подоперации были неудачными

  • SCU может отменить операцию C-GET путём отправки запроса C-CANCEL-GET в любое время во время обработки запроса C-GET. Ответ C-GET со статусом «Отмена» должен указывать SCU, что получение было отменено. По желанию ответ C-GET со статусом «Отмена» должен указывать количество завершённых, неудачных подопераций C-STORE и подопераций C-STORE с предупреждением. Если присутствует, счётчик оставшихся подопераций должен содержать количество подопераций C-STORE, которые не были начаты вследствие запроса C-CANCEL-GET.

C.4.3.2.2 Расширенное поведение SCU

Расширенное поведение SCU должно быть согласовано во время установления ассоциации. Если параметр в рамках расширенного поведения не согласован в ходе переговоров, то в отношении этого параметра должно поддерживаться только базовое поведение SCU. Расширенное поведение SCU включает всё базовое поведение со следующими дополнительными параметрами:

  • Реляционное получение (Relational-retrieve)

  • Преобразование расширенных мультикадровых изображений (Enhanced Multi-Frame Image Conversion)

Может быть согласовано более одного параметра.

C.4.3.2.2.1 Реляционное получение

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

  • все экземпляры составных объектов, относящиеся к исследованию, путём указания Study Instance UID (0020,000D)

  • все экземпляры составных объектов, относящиеся к серии, путём указания Series Instance UID (0020,000E)

  • отдельные экземпляры составных объектов путём указания списка SOP Instance UID (0008,0018)

C.4.3.2.2.2 Преобразование расширенных мультикадровых изображений

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

Поддержка преобразования расширенных мультикадровых изображений позволяет SCU указать атрибут Query/Retrieve View (0008,0053) в идентификаторе запроса со значением «CLASSIC» или «ENHANCED».

Если Query/Retrieve View (0008,0053) отсутствует в идентификаторе запроса, то SCU запрашивает, чтобы SCP получил все запрошенные экземпляры, которыми он располагает, в исходном виде.

Если Query/Retrieve View (0008,0053) присутствует со значением «CLASSIC», то SCU запрашивает, чтобы SCP получил все классические однокадровые экземпляры (преобразованные из расширенных мультикадровых экземпляров, если требуется), а также любые экземпляры, преобразованные для сохранения ссылочной целостности, и те, которые не требуют преобразования.

Если Query/Retrieve View (0008,0053) присутствует со значением «ENHANCED», то SCU запрашивает, чтобы SCP получил все расширенные мультикадровые экземпляры (преобразованные из классических однокадровых экземпляров, если требуется), а также любые экземпляры, преобразованные для сохранения ссылочной целостности, и те, которые не требуют преобразования.

Примечание

  1. SCU C-GET, выступающий в роли SCP C-STORE, может предполагать, что дублирующая информация не будет предоставлена. Например, если целая серия однокадровых экземпляров может быть преобразована в отдельную серию преобразованных экземпляров, C-GET на уровне STUDY не вернёт обе серии.

  2. SCU C-GET, выступающий в роли SCP C-STORE, должен поддерживать необходимые SOP Class для преобразованных экземпляров, в противном случае подоперации C-STORE завершатся неудачно обычным образом, и это будет отражено в ответах C-GET.

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

  4. Query/Retrieve View по-прежнему требуется в идентификаторе запроса на уровне IMAGE или SERIES, даже если запрошенные уникальные ключи однозначны, и представление в определённом смысле «избыточно», поскольку преобразование, создавшее запрошенные экземпляры, могло ещё не быть выполнено. Не допускается указывать представление, несовместимое с запрошенными уникальными ключами.

C.4.3.3 Поведение SCP для C-GET

В этом разделе рассматривается как базовое, так и расширенное поведение SCP для C-GET.

C.4.3.3.1 Базовое поведение SCP

SCP передаёт следующие семантические значения с ответом C-GET:

  • SCP должен идентифицировать набор сущностей на уровне получения на основе значений уникальных ключей в идентификаторе запроса C-GET. SCP должен инициировать подоперации C-STORE для соответствующих экземпляров SOP хранения. SCP сервисного класса запроса/получения должен выступать в роли SCU сервисного класса хранения.

  • SCP должен инициировать подоперации C-STORE по той же ассоциации для всех хранимых экземпляров SOP, связанных с Patient ID, списком Study Instance UID, списком Series Instance UID или списком SOP Instance UID, в зависимости от уровня запроса/получения, указанного в запросе C-GET

  • Подоперация считается неудачной, если SCP не может инициировать подоперацию C-STORE, поскольку SCU запроса/получения не предложил соответствующий контекст представления для данного хранимого экземпляра SOP.

  • SCP может генерировать ответы на C-GET со статусом «Ожидание» во время обработки подопераций C-STORE. Эти ответы должны указывать количество оставшихся, завершённых, неудачных подопераций C-STORE и подопераций C-STORE с предупреждением.

  • Когда количество оставшихся подопераций достигает нуля, SCP должен генерировать окончательный ответ со статусом «Успех», «Предупреждение» или «Сбой». Статус, содержащийся в ответе C-GET, должен включать:

    • «Успех», если все подоперации были успешно завершены

    • «Предупреждение», если одна или несколько подопераций были успешно завершены и одна или несколько подопераций были неудачными или имели статус предупреждения

    • «Предупреждение», если все подоперации имели статус предупреждения

    • «Сбой», если все подоперации были неудачными

  • SCP может получить запрос C-CANCEL-GET в любое время во время обработки запроса C-GET. SCP должен прервать всю обработку подопераций C-STORE и вернуть статус «Отмена» в ответе C-GET. Ответ C-GET со статусом «Отмена» должен содержать количество завершённых, неудачных подопераций C-STORE и подопераций C-STORE с предупреждением. Если присутствует, счётчик оставшихся подопераций должен содержать количество подопераций C-STORE, которые не были начаты вследствие запроса C-CANCEL-GET.

  • Если SCP управляет изображениями в нескольких альтернативных кодировках (см. Раздел C.6.1.1.5.1), только одно из альтернативных кодировок изображения должно быть включено в набор экземпляров объектов, извлекаемых запросом C-GET на уровне Patient, Study или Series.

    Примечание

    Для получения изображений с альтернативными кодировками с использованием запроса C-GET на уровне Patient, Study или Series, SCP может выбрать соответствующим образом кодированный экземпляр для получения на основе идентичности SCU, синтаксисов передачи, принятых в согласовании ассоциации C-STORE, или других факторов.

C.4.3.3.2 Расширенное поведение SCP

Расширенное поведение SCP должно быть согласовано во время установления ассоциации. Если параметр в рамках расширенного поведения не согласован в ходе переговоров, то в отношении этого параметра должно выполняться только базовое поведение SCP. Расширенное поведение SCP включает всё базовое поведение со следующими дополнительными параметрами:

  • Реляционное получение (Relational-retrieve)

  • Преобразование расширенных мультикадровых изображений (Enhanced Multi-Frame Image Conversion)

Может быть согласовано более одного параметра.

C.4.3.3.2.1 Реляционное получение

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

  • все экземпляры составных объектов, относящиеся к исследованию, путём указания Study Instance UID

  • все экземпляры составных объектов, относящиеся к серии, путём указания Series Instance UID

  • отдельные экземпляры составных объектов путём указания списка SOP Instance UID

C.4.3.3.2.2 Преобразование расширенных мультикадровых изображений

Если Query/Retrieve View (0008,0053) отсутствует в идентификаторе запроса, то SCP должен идентифицировать набор сущностей на уровне передачи на основе значений уникальных ключей в идентификаторе запроса C-GET, соответствующих экземплярам, которыми он располагает, в исходном виде, и должен инициировать подоперации C-STORE для всех соответствующих экземпляров SOP хранения.

Если Query/Retrieve View (0008,0053) присутствует со значением «CLASSIC», то SCP должен идентифицировать набор сущностей на уровне передачи на основе значений уникальных ключей в идентификаторе запроса C-GET, соответствующих классическим однокадровым экземплярам (преобразованным из расширенных мультикадровых экземпляров, если требуется), а также любым экземплярам, преобразованным для сохранения ссылочной целостности, и тем, которые не требуют преобразования, и должен инициировать подоперации C-STORE для всех соответствующих экземпляров SOP хранения.

Если Query/Retrieve View (0008,0053) присутствует со значением «ENHANCED», то SCP должен идентифицировать набор сущностей на уровне передачи на основе значений уникальных ключей в идентификаторе запроса C-GET, соответствующих расширенным мультикадровым экземплярам (преобразованным из классических однокадровых экземпляров, если требуется), а также любым экземплярам, преобразованным для сохранения ссылочной целостности, и тем, которые не требуют преобразования, и должен инициировать подоперации C-STORE для всех соответствующих экземпляров SOP хранения.

Примечание

  1. SCP C-GET, выступающий в роли SCU C-STORE, не будет отправлять дублирующую информацию SCU C-GET, выступающему в роли SCP C-STORE. Например, если целая серия однокадровых экземпляров может быть преобразована в отдельную серию преобразованных экземпляров, C-GET на уровне STUDY не отправит обе серии.

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

  3. Query/Retrieve View по-прежнему требуется в идентификаторе запроса на уровне IMAGE или SERIES, даже если запрошенные уникальные ключи однозначны.

C.5 Согласование ассоциации

Установление ассоциации — первая фаза любого сеанса связи между равноправными прикладными сущностями DICOM AE. Прикладные сущности, поддерживающие SOP Class запроса/получения DICOM, используют согласование при установлении ассоциации путём определения использования информации о прикладной ассоциации. См. PS3.7 для обзора согласования ассоциации.

SOP Class сервисного класса запроса/получения, включающие службы запросов на основе операции C-FIND, могут использовать субэлемент расширенного согласования SOP Class (SOP Class Extended Negotiation Sub-Item) для согласования таких параметров, как реляционные запросы и преобразование расширенных мультикадровых изображений.

SOP Class сервисного класса запроса/получения, включающие службы получения на основе операций C-MOVE и C-GET, могут использовать субэлемент расширенного согласования SOP Class для согласования реляционного получения и преобразования расширенных мультикадровых изображений.

SOP Class сервисного класса запроса/получения, включающие службы получения на основе операции C-GET, используют субэлемент выбора роли SCP/SCU (SCP/SCU Role Selection Sub-Item) для идентификации SOP Class, которые могут использоваться для получения.

C.5.1 Согласование ассоциации для C-FIND SOP Class

Следующие правила согласования применяются к DICOM SOP Class и специализированным DICOM SOP Class сервисного класса запроса/получения, включающим операцию C-FIND.

Инициатор ассоциации (роль SCU запроса) должен передать в запросе A-ASSOCIATE:

  • один Abstract Syntax в контексте представления для каждого поддерживаемого SOP Class на основе запроса

  • по желанию — один субэлемент расширенного согласования SOP Class для каждого SOP Class на основе запроса

Акцептор ассоциации (роль SCP запроса) запроса A-ASSOCIATE должен принять:

  • один Abstract Syntax в контексте представления для каждого поддерживаемого SOP Class на основе запроса

  • по желанию — один субэлемент расширенного согласования SOP Class для каждого SOP Class на основе запроса

C.5.1.1 Расширенное согласование SOP Class

Расширенное согласование SOP Class позволяет при установлении ассоциации равноправным DICOM AE обмениваться информацией о прикладной ассоциации, определённой конкретными SOP Class. Это достигается путём определения поля Service-class-application-information. Поле Service-class-application-information используется для определения поддержки реляционных запросов, комбинированного сопоставления даты и времени, нечёткого семантического сопоставления имён лиц, корректировки запросов по часовому поясу, преобразования расширенных мультикадровых изображений, сопоставления пустых значений (Empty Value Matching) и сопоставления множественных значений (Multiple Value Matching).

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

  • отсутствие поддержки реляционных запросов

  • раздельное (независимое) сопоставление диапазона атрибутов даты и времени

  • буквальное сопоставление имён лиц с неопределённой чувствительностью к регистру

  • корректировка запросов по часовому поясу не определена

  • отсутствие поддержки преобразования расширенных мультикадровых изображений

  • отсутствие сопоставления пустых значений (Empty Value Matching)

  • отсутствие сопоставления множественных значений (Multiple Value Matching)

Инициатор ассоциации для каждого SOP Class может использовать один субэлемент расширенного согласования SOP Class. SOP Class идентифицируется соответствующим именем Abstract Syntax (как определено в PS3.7), за которым следует поле Service-class-application-information. Это поле определяет один или несколько подполей:

  • поддержка реляционных запросов инициатором ассоциации

  • комбинированное сопоставление диапазона даты и времени инициатором ассоциации

  • буквальное или нечёткое семантическое сопоставление имён лиц инициатором ассоциации

  • корректировка запросов по часовому поясу инициатором ассоциации

  • поддержка преобразования расширенных мультикадровых изображений инициатором ассоциации

  • поддержка сопоставления пустых значений инициатором ассоциации

  • поддержка сопоставления множественных значений инициатором ассоциации

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

Примечание

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

Акцептор ассоциации для каждого предложенного подполя субэлемента расширенного согласования SOP Class либо принимает предложение инициатора ассоциации, возвращая то же значение (1), либо отклоняет предложение, возвращая значение (0).

Если субэлемент расширенного согласования SOP Class не возвращён акцептором ассоциации, то реляционные запросы не поддерживаются через ассоциацию (условие по умолчанию).

Если субэлементы расширенного согласования SOP Class отсутствуют в индикации A-ASSOCIATE, они должны быть опущены в ответе A-ASSOCIATE.

C.5.1.1.1 Структура субэлемента расширенного согласования SOP Class (A-ASSOCIATE-RQ)

Субэлемент расширенного согласования SOP Class состоит из последовательности обязательных полей, как определено в PS3.7. Таблица C.5-1 определяет поле Service-class-application-information для DICOM Query/Retrieve SOP Class и специализированных DICOM Query/Retrieve SOP Class, включающих операцию C-FIND. Это поле может состоять из одного или более байтов (т.е. байты элемента со 2-го по 7-й являются необязательными).

Таблица C.5-1. Субэлемент расширенного согласования SOP Class (поле Service-Class-Application-Information) — A-ASSOCIATE-RQ

Байты элемента

Имя поля

Описание поля

1

Реляционные запросы

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

0 — реляционные запросы не поддерживаются

1 — реляционные запросы поддерживаются

2

Комбинированное сопоставление даты и времени

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

0 — комбинированное сопоставление не запрашивается

1 — комбинированное сопоставление запрашивается

3

Нечёткое семантическое сопоставление имён лиц

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

0 — нечёткое семантическое сопоставление не запрашивается

1 — нечёткое семантическое сопоставление запрашивается

4

Корректировка запросов по часовому поясу

Это байтовое поле определяет, должен ли атрибут Timezone Offset From UTC (0008,0201) использоваться для корректировки значения запроса для полей времени и datetime в запросах. Оно должно быть закодировано как беззнаковое двоичное целое и должно использовать одно из следующих значений

0 — корректировка запросов по часовому поясу не запрашивается

1 — корректировка запросов по часовому поясу запрашивается

5

Преобразование расширенных мультикадровых изображений

Это байтовое поле определяет, должен ли атрибут Query/Retrieve View (0008,0053) использоваться для корректировки представления, возвращаемого в запросах, для учёта преобразования в или из расширенных мультикадровых изображений. Оно должно быть закодировано как беззнаковое двоичное целое и должно использовать одно из следующих значений

0 — Query/Retrieve View не поддерживается

1 — Query/Retrieve View поддерживается

6

Сопоставление пустых значений (Empty Value Matching)

Это байтовое поле определяет, запрашивается ли инициатором ассоциации поддержка сопоставления пустых значений (Empty Value Matching). Оно должно быть закодировано как беззнаковое двоичное целое и должно использовать одно из следующих значений

0 — сопоставление пустых значений не запрашивается

1 — сопоставление пустых значений запрашивается

7

Сопоставление множественных значений (Multiple Value Matching)

Это байтовое поле определяет, запрашивается ли инициатором ассоциации поддержка сопоставления множественных значений (Multiple Value Matching). Оно должно быть закодировано как беззнаковое двоичное целое и должно использовать одно из следующих значений

0 — сопоставление множественных значений не запрашивается

1 — сопоставление множественных значений запрашивается


C.5.1.1.2 Структура субэлемента расширенного согласования SOP Class (A-ASSOCIATE-AC)

Субэлемент расширенного согласования SOP Class состоит из последовательности обязательных полей, как определено в PS3.7. Таблица C.5-2 определяет поле Service-class-application-information для DICOM Query/Retrieve SOP Class и специализированных DICOM Query/Retrieve SOP Class, включающих операцию C-FIND. Это поле может состоять из одного или более байтов (т.е. байты элемента со 2-го по 7-й являются необязательными).

Таблица C.5-2. Субэлемент расширенного согласования SOP Class (поле Service-Class-Application-Information) — A-ASSOCIATE-AC

Байты элемента

Имя поля

Описание поля

1

Реляционные запросы

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

0 — реляционные запросы не поддерживаются

1 — реляционные запросы поддерживаются

2

Комбинированное сопоставление даты и времени

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

0 — комбинированное сопоставление не выполняется

1 — комбинированное сопоставление выполняется

3

Нечёткое семантическое сопоставление имён лиц

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

0 — нечёткое семантическое сопоставление не выполняется

1 — нечёткое семантическое сопоставление выполняется

4

Корректировка запросов по часовому поясу

Это байтовое поле определяет, должен ли атрибут Timezone Offset From UTC (0008,0201) использоваться для корректировки значения запроса для полей времени и datetime в запросах. Оно должно быть закодировано как беззнаковое двоичное целое и должно использовать одно из следующих значений

0 — корректировка запросов по часовому поясу не выполняется

1 — корректировка запросов по часовому поясу выполняется

5

Преобразование расширенных мультикадровых изображений

Это байтовое поле определяет, должен ли атрибут Query/Retrieve View (0008,0053) использоваться для корректировки представления, возвращаемого в запросах, для учёта преобразования в или из расширенных мультикадровых изображений. Оно должно быть закодировано как беззнаковое двоичное целое и должно использовать одно из следующих значений

0 — Query/Retrieve View не поддерживается

1 — Query/Retrieve View поддерживается

6

Сопоставление пустых значений (Empty Value Matching)

Это байтовое поле определяет поддержку сопоставления пустых значений (Empty Value Matching) акцептором ассоциации. Оно должно быть закодировано как беззнаковое двоичное целое и должно использовать одно из следующих значений

0 — сопоставление пустых значений не поддерживается

1 — сопоставление пустых значений поддерживается

7

Сопоставление множественных значений (Multiple Value Matching)

Это байтовое поле определяет поддержку сопоставления множественных значений (Multiple Value Matching) акцептором ассоциации. Оно должно быть закодировано как беззнаковое двоичное целое и должно использовать одно из следующих значений

0 — сопоставление множественных значений не поддерживается

1 — сопоставление множественных значений поддерживается


C.5.2 Согласование ассоциации для C-MOVE SOP Class

Следующие правила согласования применяются к DICOM SOP Class и специализированным DICOM SOP Class сервисного класса запроса/получения, включающим операцию C-MOVE.

Инициатор ассоциации (роль SCU получения) должен передать в запросе A-ASSOCIATE:

  • один Abstract Syntax в контексте представления для каждого поддерживаемого SOP Class на основе получения

  • по желанию — один субэлемент расширенного согласования SOP Class для каждого SOP Class на основе получения

Акцептор ассоциации (роль SCP получения) запроса A-ASSOCIATE должен принять:

  • один Abstract Syntax в контексте представления для каждого поддерживаемого SOP Class на основе получения

  • по желанию — один субэлемент расширенного согласования SOP Class для каждого SOP Class на основе получения

C.5.2.1 Расширенное согласование SOP Class

Расширенное согласование SOP Class позволяет при установлении ассоциации равноправным DICOM AE обмениваться информацией о прикладной ассоциации, определённой конкретными SOP Class. Это достигается путём определения поля Service-class-application-information. Поле Service-class-application-information используется для определения поддержки реляционного получения.

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

  • отсутствие поддержки реляционного получения

  • отсутствие поддержки преобразования расширенных мультикадровых изображений

Инициатор ассоциации для каждого SOP Class может использовать один субэлемент расширенного согласования SOP Class. SOP Class идентифицируется соответствующим именем Abstract Syntax (как определено в PS3.7), за которым следует поле Service-class-application-information. Это поле определяет:

  • поддержка реляционного получения инициатором ассоциации

  • поддержка преобразования расширенных мультикадровых изображений инициатором ассоциации

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

Примечание

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

Акцептор ассоциации для каждого предложенного субэлемента расширенного согласования SOP Class либо принимает предложение инициатора ассоциации, возвращая то же значение (1), либо отклоняет предложение, возвращая значение (0).

Если субэлемент расширенного согласования SOP Class не возвращён акцептором ассоциации, то реляционное получение и преобразование расширенных мультикадровых изображений не поддерживаются (условие по умолчанию).

Если субэлементы расширенного согласования SOP Class отсутствуют в индикации A-ASSOCIATE, они должны быть опущены в ответе A-ASSOCIATE.

C.5.2.1.1 Структура субэлемента расширенного согласования SOP Class (A-ASSOCIATE-RQ)

Субэлемент расширенного согласования SOP Class состоит из последовательности обязательных полей, как определено в PS3.7. Таблица C.5-3 определяет поле Service-class-application-information для DICOM Query/Retrieve SOP Class и специализированных DICOM Query/Retrieve SOP Class, включающих операции C-MOVE и C-GET.

Таблица C.5-3. Субэлемент расширенного согласования SOP Class (поле Service-Class-Application-Information) — A-ASSOCIATE-RQ

Байты элемента

Имя поля

Описание поля

1

Relational-retrieval

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

0 — реляционное получение не поддерживается

1 — реляционное получение поддерживается

2

Enhanced Multi-Frame Image Conversion

Это байтовое поле определяет, должен ли атрибут Query/Retrieve View (0008,0053) использоваться для корректировки представления, возвращаемого в запросах, для учёта преобразования в или из расширенных мультикадровых изображений. Оно должно быть закодировано как беззнаковое двоичное целое и должно использовать одно из следующих значений

0 - Query/Retrieve View not supported

1 - Query/Retrieve View supported


C.5.2.1.2 Структура субэлемента расширенного согласования SOP Class (A-ASSOCIATE-AC)

Субэлемент расширенного согласования SOP Class состоит из последовательности обязательных полей, как определено в PS3.7. Таблица C.5-4 определяет поле Service-class-application-information для DICOM Query/Retrieve SOP Class и специализированных DICOM Query/Retrieve SOP Class, включающих операции C-MOVE и C-GET.

Таблица C.5-4. Субэлемент расширенного согласования SOP Class (поле Service-Class-Application-Information) — A-ASSOCIATE-AC

Байты элемента

Имя поля

Описание поля

1

Relational-retrieval

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

0 — реляционное получение не поддерживается

1 — реляционное получение поддерживается

2

Enhanced Multi-Frame Image Conversion

Это байтовое поле определяет, должен ли атрибут Query/Retrieve View (0008,0053) использоваться для корректировки представления, возвращаемого в запросах, для учёта преобразования в или из расширенных мультикадровых изображений. Оно должно быть закодировано как беззнаковое двоичное целое и должно использовать одно из следующих значений

0 - Query/Retrieve View not supported

1 - Query/Retrieve View supported


C.5.3 Согласование ассоциации для C-GET SOP Class

Когда SCP выполняет операцию C-GET, она порождает операцию C-STORE для передачи составных экземпляров SOP для хранения. Эта индуцированная операция C-STORE (называемая подоперацией) требует переключения с контекста представления C-GET на контекст представления, поддерживающий конкретную подоперацию C-STORE.

Следующие правила согласования применяются к DICOM Query/Retrieve SOP Class на основе получения и специализированным DICOM Query/Retrieve SOP Class, включающим операцию C-GET.

Инициатор ассоциации (роль SCU получения) в запросе A-ASSOCIATE должен передать:

  1. Поддержка операции C-GET:

    • один Abstract Syntax в контексте представления для каждого поддерживаемого SOP Class

    • и, по желанию, один субэлемент расширенного согласования SOP Class для каждого SOP Class на основе получения

  2. Поддержка индуцированной подоперации хранения, где SOP Class (в роли SCU получения) выступает как Storage SOP Class в роли SCP. См. Рисунок C.5-1. Для каждого поддерживаемого Storage SOP Class запрос A-ASSOCIATE содержит:

    • один Abstract Syntax в контексте представления

    • один субэлемент согласования выбора роли SCP/SCU с полем SCP-role, установленным для указания поддержки роли SCP. Согласование выбора роли SCP/SCU должно использоваться, как определено в PS3.7.

An Example of the Sub-Operation SCU/SCP Roles

Рисунок C.5-1. Пример ролей SCU/SCP для подоперации


Примечание

Это согласование не предъявляет никаких требований к флагу SCU в субэлементе согласования выбора роли SCP/SCU. Он может быть установлен, если инициатор ассоциации поддерживает Storage Service Class в роли SCU.

Акцептор ассоциации (роль SCP получения) в ответе A-ASSOCIATE должен передать:

  1. Поддержку операции C-GET:

    • один Abstract Syntax в контексте представления для каждого поддерживаемого SOP Class

  2. Поддержку индуцированной подоперации хранения, где SOP Class (используя роль SCP получения) выступает как Storage SOP Class в роли SCU. См. Рисунок C.5-1. Для каждого поддерживаемого Storage SOP Class ответ A-ASSOCIATE содержит:

    • один Abstract Syntax в контексте представления

    • один субэлемент согласования выбора роли SCP/SCU с полем SCP-role, установленным для указания принятия акцептором ассоциации поддержки инициатором роли SCP. Согласование выбора роли SCP/SCU должно использоваться, как определено в PS3.7.

Примечание

Согласование не предъявляет никаких требований к флагу SCU в субэлементе согласования выбора роли SCP/SCU. Он может быть установлен, если акцептор ассоциации принимает роль Storage SCP. Рисунок C.5-2 иллюстрирует пример согласования получения (C-GET).

Рисунок C.5-2 иллюстрирует пример согласования получения (C-GET).

C.5.3.1 Расширенное согласование SOP Class

Расширенное согласование SOP Class позволяет при установлении ассоциации связанным DICOM AE обмениваться прикладной информацией ассоциации, определённой конкретными SOP Class.

Это достигается путём определения поля Service-class-application-information. Поле Service-class-application-information используется для определения поддержки реляционного получения и альтернативных представлений для преобразования расширенных мультикадровых изображений.

An Example of the Retrieve (C-GET) Negotiation

Рисунок C.5-2. Пример согласования получения (C-GET)


Расширенное согласование для SOP Class на основе служб получения, включающих операции C-GET, идентично согласованию, определённому для C-MOVE, которое определено в Разделе C.5.2.1 данного приложения.

Расширенное согласование для SOP Class Storage Service Class (для подоперации C-STORE) определено в Приложении B.

C.6 SOP Class Definitions

C.6.1 Patient Root SOP Class Group

In the Patient Root Query/Retrieve Information Model, the information is arranged into four levels that correspond to one of the four values in element (0008,0052) shown in Table C.6.1-1.

Table C.6.1-1. Query/Retrieve Level Values for Patient Root

Query/Retrieve Level

Value in (0008,0052)

Patient Information

PATIENT

Study Information

STUDY

Series Information

SERIES

Composite Object Instance Information

IMAGE


Примечание

Использование слова «Images» (изображения) вместо «Composite Object Instances» (составные экземпляры объекта) является историческим для обеспечения обратной совместимости с предыдущими редакциями стандарта. Не следует считать, что составные экземпляры объекта, не являющиеся изображениями, не включены на уровень, обозначаемый значением IMAGE.

C.6.1.1 Информационная модель Query/Retrieve с корнем Patient

C.6.1.1.1 E/R-модель

Информационная модель Query/Retrieve с корнем Patient может быть представлена диаграммой «сущность-связь», показанной на Рисунке C.6-1.

Patient Root Query/Retrieve Information Model E-R Diagram

Рисунок C.6-1. Диаграмма E-R информационной модели Query/Retrieve с корнем Patient


C.6.1.1.2 Уровень Patient

Таблица C.6-1 определяет атрибуты на уровне запроса/получения Patient информационной модели Query/Retrieve с корнем Patient.

Примечание

  1. Описание атрибутов этой информационной модели содержится в Разделе C.3 данной части.

  2. Хотя Patient ID может не быть глобально уникальным, Study Instance UID является глобально уникальным, что гарантирует отсутствие ошибочной идентификации двух исследований. Область уникальности Patient ID может быть указана с помощью атрибута Issuer of Patient ID (0010,0021).

  3. Ранее атрибут Other Patient IDs (0010,1000) входил в эту таблицу. Этот атрибут был удалён. См. PS3.4 2017a.

Таблица C.6-1. Атрибуты уровня Patient информационной модели Query/Retrieve с корнем Patient

Имя атрибута

Тег

Тип

Patient's Name

(0010,0010)

R

Patient ID

(0010,0020)

U

Issuer of Patient ID

(0010,0021)

O

Referenced Patient Sequence

(0008,1120)

O

>Referenced SOP Class UID

(0008,1150)

O

>Referenced SOP Instance UID

(0008,1155)

O

Patient's Birth Date

(0010,0030)

O

Patient's Birth Time

(0010,0032)

O

Patient's Sex

(0010,0040)

O

Other Patient IDs Sequence

(0010,1002)

O

Other Patient Names

(0010,1001)

O

Ethnic Group

(0010,2160)

O

Patient Comments

(0010,4000)

O

Number of Patient Related Studies

(0020,1200)

O

Number of Patient Related Series

(0020,1202)

O

Number of Patient Related Instances

(0020,1204)

O

Все остальные атрибуты уровня Patient

O


C.6.1.1.3 Уровень Study

Таблица C.6-2 определяет ключи на информационном уровне Study информационной модели Query/Retrieve с корнем Patient.

Примечание

  1. Описание атрибутов этой информационной модели содержится в Разделе C.3 данной части.

  2. Хотя Patient ID может не быть глобально уникальным, Study Instance UID является глобально уникальным, что гарантирует отсутствие ошибочной идентификации двух исследований. Область уникальности Patient ID может быть указана с помощью атрибута Issuer of Patient ID (0010,0021).

Таблица C.6-2a. Макрос расширенных ключей Code Value с дополнительными ключами


Таблица C.6-2b. Макрос базовых ключей Code Value с дополнительными ключами

Имя атрибута

Тег

Использование

Code Value

(0008,0100)

OC — может присутствовать только если длина значения кода составляет 16 символов или менее и значение кода не является URN или URL.

Coding Scheme Designator

(0008,0102)

O

Coding Scheme Version

(0008,0103)

O

Code Meaning

(0008,0104)

O

Long Code Value

(0008,0119)

OC — может присутствовать только если Code Value (0008,0100) отсутствует и значение кода не является URN или URL.

URN Code Value

(0008,0120)

OC — может присутствовать только если Code Value (0008,0100) отсутствует и значение кода является URN или URL.

Context Identifier

(0008,010F)

O

Context UID

(0008,0117)

O

Mapping Resource

(0008,0105)

O

Mapping Resource UID

(0008,0118)

O

Context Group Version

(0008,0106)

O

Context Group Extension Flag

(0008,010B)

O

Context Group Local Version

(0008,0107)

O

Context Group Extension Creator UID

(0008,010D)

O


Таблица C.6-2. Ключи уровня исследования для информационной модели запроса/получения корня пациента

Имя атрибута

Tag

Type

Study Date

(0008,0020)

R

Study Time

(0008,0030)

R

Accession Number

(0008,0050)

R

Study ID

(0020,0010)

R

Study Instance UID

(0020,000D)

U

Modalities in Study

(0008,0061)

O

SOP Classes in Study

(0008,0062)

O

Anatomic Regions in Study Code Sequence

(0008,0063)

O

>Include Table C.6-2a “Enhanced Code Value Keys Macro with Optional Keys”

Referring Physician's Name

(0008,0090)

O

Study Description

(0008,1030)

O

Procedure Code Sequence

(0008,1032)

O

>Include Table C.6-2a “Enhanced Code Value Keys Macro with Optional Keys”

Name of Physician(s) Reading Study

(0008,1060)

O

Admitting Diagnoses Description

(0008,1080)

O

Referenced Study Sequence

(0008,1110)

O

>Referenced SOP Class UID

(0008,1150)

O

>Referenced SOP Instance UID

(0008,1155)

O

Patient's Age

(0010,1010)

O

Patient's Size

(0010,1020)

O

Patient's Weight

(0010,1030)

O

Occupation

(0010,2180)

O

Additional Patient History

(0010,21B0)

O

Other Study Numbers

(0020,1070)

O

Number of Study Related Series

(0020,1206)

O

Number of Study Related Instances

(0020,1208)

O

Study Update DateTime

(0008,041F)

O

Gender Identity Sequence

(0010,0041)

O

>Gender Identity Code Sequence

(0010,0044)

O

>>Include Table C.6-2a “Enhanced Code Value Keys Macro with Optional Keys”

>Effective Start DateTime

(0040,A034)

O

>Effective Stop DateTime

(0040,A035)

O

>Gender Identity Comment

(0010,0045)

O

Sex Parameters for Clinical Use Category Sequence

(0010,0043)

O

>Sex Parameters for Clinical Use Category Code Sequence

(0010,0046)

O

>>Include Table C.6-2a “Enhanced Code Value Keys Macro with Optional Keys”

>Effective Start DateTime

(0040,A034)

O

>Effective Stop DateTime

(0040,A035)

O

>Sex Parameters for Clinical Use Category Comment

(0010,0042)

O

>Sex Parameters for Clinical Use Category Reference

(0010,0047)

O

Person Names to Use Sequence

(0010,0011)

O

>Name to Use

(0010,0012)

O

>Effective Start DateTime

(0040,A034)

O

>Effective Stop DateTime

(0040,A035)

O

>Name to Use Comment

(0010,0013)

O

Third Person Pronouns Sequence

(0010,0014)

O

>Pronoun Code Sequence

(0010,0015)

O

>>Include Table C.6-2a “Enhanced Code Value Keys Macro with Optional Keys”

>Effective Start DateTime

(0040,A034)

O

>Effective Stop DateTime

(0040,A035)

O

>Pronoun Comment

(0010,0016)

O

Все остальные атрибуты на уровне исследования

O


C.6.1.1.4 Уровень серии

Таблица C.6-3 определяет ключи на уровне информации о серии информационной модели запроса/получения корня пациента.

Таблица C.6-3. Атрибуты уровня серии для информационной модели запроса/получения корня пациента

Имя атрибута

Tag

Type

Modality

(0008,0060)

R

Series Number

(0020,0011)

R

Series Instance UID

(0020,000E)

U

Number of Series Related Instances

(0020,1209)

O

Все остальные атрибуты на уровне серии

O


Примечание

Атрибут Number of Series Related Instances является необязательным ключом. Тем не менее, он признан широко востребованным ключом и возвращаемым атрибутом, который SCP настоятельно рекомендуется поддерживать.

C.6.1.1.5 Уровень составного объектного экземпляра

Таблица C.6-4 определяет ключи на уровне информации о составном объектном экземпляре информационной модели запроса/получения корня пациента.

Таблица C.6-4. Ключи уровня составного объектного экземпляра для информационной модели запроса/получения корня пациента

Имя атрибута

Tag

Type

Instance Number

(0020,0013)

R

SOP Instance UID

(0008,0018)

U

SOP Class UID

(0008,0016)

O

Available Transfer Syntax UID

(0008,3002)

O

Alternate Representation Sequence

(0008,3001)

O

>Series Instance UID

(0020,000E)

O

>SOP Class UID

(0008,1150)

O

>SOP Instance UID

(0008,1155)

O

>Purpose of Reference Code Sequence

(0040,A170)

O

>>Include Table C.6-2a “Enhanced Code Value Keys Macro with Optional Keys”

Related General SOP Class UID

(0008,001A)

O

Concept Name Code Sequence

(0040,A043)

O

>Include Table C.6-2a “Enhanced Code Value Keys Macro with Optional Keys”

Content Template Sequence

(0040,A504)

O

>Template Identifier

(0040,DB00)

O

>Mapping Resource

(0008,0105)

O

Container Identifier

(0040,0512)

O

Specimen Description Sequence

(0040,0560)

O

>Specimen Identifier

(0040,0551)

O

>Specimen UID

(0040,0554)

O

Все остальные атрибуты на уровне составного объектного экземпляра

O


Примечание

  1. SOP Class UID (0008,0016) является необязательным ключом, однако настоятельно рекомендуется, чтобы он всегда возвращался всеми SCP, если запрашивается сопоставление.

  2. Concept Name Code Sequence (0040,A043) и Content Template Sequence (0040,A504) — необязательные ключи, полезные для идентификации экземпляров различных SOP-классов хранения структурированных отчётов. Настоятельно рекомендуется, чтобы SCP поддерживал эти ключи для запросов к таким экземплярам.

C.6.1.1.5.1 Alternate Representation Sequence

Alternate Representation Sequence (0008,3001) кодирует ссылку на альтернативное кодирование составного изображения, указанного в элементе ответа на запрос. Это альтернативное кодирование может использовать другой SOP-класс или иметь другие характеристики качества изображения, но оно должно быть тем же изображением.

Примечание

Alternate Representation Sequence (0008,3001) позволяет ответу на запрос об исходном изображении ссылаться на версию со сжатием с потерями, и наоборот.

Изображение может быть сжато с потерями, например, для целей долгосрочного архивирования, и его SOP Instance UID изменён. Приложение, обрабатывающее SOP Instance, который ссылается на UID исходного изображения (например, структурированный отчёт), может выполнить запрос к C-FIND SCP для получения изображения. SCP возвращает ссылку на доступную версию изображения, даже если исходный SOP Instance больше не доступен.

Alternate Representation Sequence (0008,3001), если присутствует в идентификаторе запроса, должен иметь нулевую длину или содержать единственный элемент нулевой длины. Таким образом, для данного атрибута определено только универсальное сопоставление (Universal Matching).

Alternate Representation Sequence (0008,3001), если присутствует в идентификаторе ответа на запрос, может содержать ноль или более элементов. Каждый элемент Alternate Representation Sequence в идентификаторе ответа на запрос должен включать

  • Series Instance UID (0020,000E), если альтернативно кодированное изображение находится в другой серии.

  • SOP Class UID (0008,0016) и SOP Instance UID (0008,0018) альтернативно кодированного изображения.

  • Purpose of Reference Code Sequence (0040,A170), которая должна описывать характер альтернативного кодирования изображения. Purpose of Reference Code Sequence (0040,A170) должна включать только один элемент. Базовая группа контекста для данной последовательности кодов — CID 7205.

C.6.1.1.5.2 Available SOP Transfer Syntax UID

Available Transfer Syntax UID (0008,3002) описывает один или несколько синтаксисов передачи (Transfer Syntaxes), которые SCP может гарантировать как поддерживаемые для получения SOP Instance. Это может, но не обязано, включать синтаксис передачи, в котором SCP сохранил экземпляр. Для всех перечисленных синтаксисов передачи перекодирование из сохранённой формы не должно сопровождаться потерями.

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

Не существует требования включать каждый синтаксис передачи, в котором экземпляр может быть получен без потерь. Например, синтаксис передачи по умолчанию, как указано в Разделе 10.1 в PS3.5 , если он применим, может быть опущен, если он не является синтаксисом передачи, в котором экземпляр фактически сохранён.

Примечание

Значение этого атрибута может быть полезно, например, для определения того, сохранён ли экземпляр в синтаксисе передачи с потерями, который не поддерживается SCU, и для которого распаковка или преобразование в другую форму сжатия повлекло бы потери и было бы нецелесообразным, что потребовало бы использования альтернативного представления (Alternate Representation).

C.6.1.1.6 Область действия команд C-GET и C-MOVE и подопераций

Запрос C-MOVE или C-GET может быть выполнен на любой уровень модели запроса/получения. Однако передача сохранённых SOP Instance всегда должна происходить на уровне составного объектного экземпляра. C-MOVE или C-GET, где уровень запроса/получения — это:

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

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

  • уровень SERIES указывает, что все составные объектные экземпляры, относящиеся к серии, должны быть переданы.

  • уровень IMAGE указывает, что выбранные отдельные составные объектные экземпляры должны быть переданы.

Примечание

В базовом поведении более одной сущности может быть получено, если уровень запроса/получения — IMAGE, SERIES или STUDY, с использованием сопоставления по списку UID (List of UID matching), но для Patient ID (0010,0020) может быть указано только значение однозначного сопоставления (Single Value Matching).

C.6.1.2 Требования соответствия

Реализация может соответствовать одному из SOP-классов группы SOP-классов корня пациента (Patient Root SOP Class Group) в качестве SCU, SCP или обоих. Заявление о соответствии должно быть в формате, определённом в PS3.2.

C.6.1.2.1 Соответствие SCU
C.6.1.2.1.1 Соответствие C-FIND SCU

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента, должна поддерживать запросы к информационной модели запроса/получения, описанной в Разделе C.6.1.1, с использованием базового поведения C-FIND SCU, описанного в Разделе C.4.1.2.

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCU, должна указать в своём заявлении о соответствии, поддерживает ли она необязательные ключи (Optional Keys). Если она поддерживает необязательные ключи, она должна перечислить поддерживаемые необязательные ключи.

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCU, должна указать в своём заявлении о соответствии, может ли она генерировать реляционные запросы (Relational-queries). Если она поддерживает реляционные запросы, она также должна поддерживать расширенное согласование (Extended Negotiation) реляционных запросов в качестве SCU.

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCU, должна указать в своём заявлении о соответствии, поддерживает ли она расширенное согласование комбинированного сопоставления даты-времени (combined date-time matching), нечёткого семантического сопоставления имён лиц (fuzzy semantic matching of person names), сопоставления пустых значений (Empty Value Matching) и/или многозначного сопоставления (Multiple Value Matching).

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCU, должна указать в своём заявлении о соответствии, как она использует Specific Character Set (0008,0005) и Timezone Offset From UTC (0008,0201) при кодировании запросов и интерпретации ответов.

C.6.1.2.1.2 Соответствие C-MOVE SCU

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCU, должна поддерживать передачи в рамках информационной модели запроса/получения, описанной в Разделе C.6.1.1, с использованием поведения C-MOVE SCU, описанного в Разделе C.4.2.2.

C.6.1.2.1.3 Соответствие C-GET SCU

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCU, должна поддерживать получение данных в рамках информационной модели запроса/получения, описанной в Разделе C.6.1.1, с использованием поведения C-GET SCU, описанного в Разделе C.4.3.2.

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCU и генерирующая получение данных с помощью операции C-GET, должна указать в своём заявлении о соответствии SOP-классы сервисного класса хранения (Storage Service Class), для которых она будет поддерживать подоперации C-STORE, генерируемые C-GET.

C.6.1.2.2 Соответствие SCP
C.6.1.2.2.1 Соответствие C-FIND SCP

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента, должна поддерживать запросы к информационной модели запроса/получения, описанной в Разделе C.6.1.1, с использованием поведения C-FIND SCP, описанного в Разделе C.4.1.3.

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCP, должна указать в своём заявлении о соответствии, поддерживает ли она необязательные ключи. Если она поддерживает необязательные ключи, она должна перечислить поддерживаемые необязательные ключи.

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCP, должна указать в своём заявлении о соответствии, поддерживает ли она реляционные запросы. Если она поддерживает реляционные запросы, она также должна поддерживать расширенное согласование реляционных запросов в качестве SCP.

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCP, должна указать в своём заявлении о соответствии, поддерживает ли она расширенное согласование комбинированного сопоставления даты-времени, нечёткого семантического сопоставления имён лиц, сопоставления пустых значений и/или многозначного сопоставления. Если поддерживается нечёткое семантическое сопоставление имён лиц, должен быть specified механизм нечёткого семантического сопоставления.

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCP, должна указать в своём заявлении о соответствии, поддерживает ли она сопоставление без учёта регистра для атрибутов VR PN, и перечислить атрибуты, к которым это применяется.

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCP, должна указать в своём заявлении о соответствии, как она использует Specific Character Set (0008,0005) и Timezone Offset From UTC (0008,0201) при интерпретации запросов, выполнении сопоставления и кодировании ответов.

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCP, должна указать в своём заявлении о соответствии способ выполнения однозначного сопоставления (Single Value Matching) для атрибутов VR DS и IS (если поддерживается) и перечислить атрибуты, к которым это применяется.

C.6.1.2.2.2 Соответствие C-MOVE SCP

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCP, должна поддерживать передачи в рамках информационной модели запроса/получения, описанной в Разделе C.6.1.1, с использованием поведения C-MOVE SCP, описанного в Разделе C.4.2.3.

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCP и генерирующая передачи с помощью операции C-MOVE, должна указать в своём заявлении о соответствии SOP-классы сервисного класса хранения, для которых она будет поддерживать подоперации C-STORE, генерируемые C-MOVE.

C.6.1.2.2.3 Соответствие C-GET SCP

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCP, должна поддерживать получение данных в рамках информационной модели запроса/получения, описанной в Разделе C.6.1.1, с использованием поведения C-GET SCP, описанного в Разделе C.4.3.3.

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCP и генерирующая получение данных с помощью операции C-GET, должна указать в своём заявлении о соответствии SOP-классы сервисного класса хранения, для которых она будет поддерживать подоперации C-STORE, генерируемые C-GET.

C.6.1.3 SOP-классы

SOP-классы в группе SOP-классов запроса корня пациента (Patient Root Query SOP Class Group) сервисного класса запроса/получения идентифицируют информационную модель запроса/получения корня пациента и поддерживаемые операции DIMSE-C. Стандартные SOP-классы перечислены в Таблице C.6.1.3-1.

Таблица C.6.1.3-1. SOP-классы для запроса/получения корня пациента

SOP Class Name

SOP Class UID

Patient Root Query/Retrieve Information Model - FIND

1.2.840.10008.5.1.4.1.2.1.1

Patient Root Query/Retrieve Information Model - MOVE

1.2.840.10008.5.1.4.1.2.1.2

Patient Root Query/Retrieve Information Model - GET

1.2.840.10008.5.1.4.1.2.1.3


C.6.2 Группа SOP-классов корня исследования

В информационной модели запроса/получения корня исследования информация организована на трёх уровнях, соответствующих одному из трёх значений в элементе (0008,0052), показанных в Таблице C.6.2-1.

Таблица C.6.2-1. Значения уровня запроса/получения для корня исследования

Уровень запроса/получения

Значение в (0008,0052)

Информация об исследовании

STUDY

Информация о серии

SERIES

Информация о составном объектном экземпляре

IMAGE


Примечание

Использование слова "Images" вместо "Composite Object Instances" является историческим для обеспечения обратной совместимости с предыдущими редакциями стандарта. Это не следует понимать как означающее, что составные объектные экземпляры, не являющиеся изображениями, не включены на уровень, указываемый значением IMAGE.

C.6.2.1 Информационная модель запроса/получения корня исследования

C.6.2.1.1 E/R-модель

Информационная модель запроса/получения корня исследования может быть представлена диаграммой «сущность-связь», показанной на Рисунке C.6-2.

Study Root Query/Retrieve Information Model E-R Diagram

Рисунок C.6-2. Диаграмма E-R информационной модели запроса/получения корня исследования


C.6.2.1.2 Уровень исследования

Таблица C.6-5 определяет ключи на уровне информации об исследовании информационной модели запроса/получения корня исследования.

Примечание

  1. Описание атрибутов данной информационной модели содержится в Разделе C.3.

  2. Хотя Patient ID может не быть глобально уникальным, Study Instance UID является глобально уникальным, что гарантирует отсутствие ошибочной идентификации двух исследований. Область уникальности Patient ID может быть указана с помощью Issuer of Patient ID (0010,0021).

  3. Ранее в эту таблицу был включён Other Patient IDs (0010,1000). Этот атрибут был отозван (retired). См. PS3.4 2017a.

Таблица C.6-5. Ключи уровня исследования для информационной модели запроса/получения корня исследования

Имя атрибута

Tag

Type

Study Date

(0008,0020)

R

Study Time

(0008,0030)

R

Accession Number

(0008,0050)

R

Patient's Name

(0010,0010)

R

Patient ID

(0010,0020)

R

Study ID

(0020,0010)

R

Study Instance UID

(0020,000D)

U

Modalities in Study

(0008,0061)

O

SOP Classes in Study

(0008,0062)

O

Anatomic Regions in Study Code Sequence

(0008,0063)

O

>Include Table C.6-2a “Enhanced Code Value Keys Macro with Optional Keys”

Referring Physician's Name

(0008,0090)

O

Study Description

(0008,1030)

O

Procedure Code Sequence

(0008,1032)

O

>Include Table C.6-2a “Enhanced Code Value Keys Macro with Optional Keys”

Name of Physician(s) Reading Study

(0008,1060)

O

Admitting Diagnoses Description

(0008,1080)

O

Referenced Study Sequence

(0008,1110)

O

>Referenced SOP Class UID

(0008,1150)

O

>Referenced SOP Instance UID

(0008,1155)

O

Referenced Patient Sequence

(0008,1120)

O

>Referenced SOP Class UID

(0008,1150)

O

>Referenced SOP Instance UID

(0008,1155)

O

Issuer of Patient ID

(0010,0021)

O

Patient's Birth Date

(0010,0030)

O

Patient's Birth Time

(0010,0032)

O

Patient's Sex

(0010,0040)

O

Gender Identity Sequence

(0010,0041)

O

>Gender Identity Code Sequence

(0010,0044)

O

>>Include Table C.6-2a “Enhanced Code Value Keys Macro with Optional Keys”

>Effective Start DateTime

(0040,A034)

O

>Effective Stop DateTime

(0040,A035)

O

>Gender Identity Comment

(0010,0045)

O

Sex Parameters for Clinical Use Category Sequence

(0010,0043)

O

>Sex Parameters for Clinical Use Category Code Sequence

(0010,0046)

O

>>Include Table C.6-2a “Enhanced Code Value Keys Macro with Optional Keys”

>Effective Start DateTime

(0040,A034)

O

>Effective Stop DateTime

(0040,A035)

O

>Sex Parameters for Clinical Use Category Comment

(0010,0042)

O

>Sex Parameters for Clinical Use Category Reference

(0010,0047)

O

Person Names to Use Sequence

(0010,0011)

O

>Name to Use

(0010,0012)

O

>Effective Start DateTime

(0040,A034)

O

>Effective Stop DateTime

(0040,A035)

O

>Name to Use Comment

(0010,0013)

O

Third Person Pronouns Sequence

(0010,0014)

O

>Pronoun Code Sequence

(0010,0015)

O

>>Include Table C.6-2a “Enhanced Code Value Keys Macro with Optional Keys”

>Effective Start DateTime

(0040,A034)

O

>Effective Stop DateTime

(0040,A035)

O

>Pronoun Comment

(0010,0016)

O

Other Patient IDs Sequence

(0010,1002)

O

Other Patient Names

(0010,1001)

O

Patient's Age

(0010,1010)

O

Patient's Size

(0010,1020)

O

Patient's Weight

(0010,1030)

O

Ethnic Group

(0010,2160)

O

Occupation

(0010,2180)

O

Additional Patient History

(0010,21B0)

O

Patient Comments

(0010,4000)

O

Other Study Numbers

(0020,1070)

O

Number of Study Related Series

(0020,1206)

O

Number of Study Related Instances

(0020,1208)

O

Study Update DateTime

(0008,041F)

O

Все остальные атрибуты на уровне исследования

O


Примечание

Использование слова "Images" вместо "Composite Object Instances" является историческим и не должно пониматься как означающее, что составные объектные экземпляры, не являющиеся изображениями, не включены в это число.

C.6.2.1.3 Уровень серии

Атрибуты уровня серии информационной модели запроса/получения корня исследования совпадают с атрибутами уровня серии информационной модели запроса/получения корня пациента, описанными в Разделе C.6.1.1.4.

C.6.2.1.4 Уровень составного объектного экземпляра

Атрибуты уровня составного объектного экземпляра информационной модели запроса/получения корня исследования совпадают с атрибутами уровня составного объектного экземпляра информационной модели запроса/получения корня пациента, описанными в Разделе C.6.1.1.5.

C.6.2.1.5 Область действия команд Get и Move и подопераций

Запрос C-MOVE или C-GET может быть выполнен на любой уровень модели запроса/получения. Однако передача сохранённых SOP Instance всегда должна происходить на уровне составного объектного экземпляра. C-MOVE или C-GET, где уровень запроса/получения — это:

  • уровень STUDY указывает, что все составные объектные экземпляры, относящиеся к исследованию, должны быть переданы

  • уровень SERIES указывает, что все составные объектные экземпляры, относящиеся к серии, должны быть переданы

  • уровень IMAGE указывает, что выбранные отдельные составные объектные экземпляры должны быть переданы

Примечание

В базовом поведении более одной сущности может быть получено, если уровень запроса/получения — IMAGE, SERIES или STUDY, с использованием сопоставления по списку UID,

C.6.2.2 Требования соответствия

Реализация может соответствовать одному из SOP-классов группы SOP-классов корня исследования (Study Root SOP Class Group) в качестве SCU, SCP или обоих. Заявление о соответствии должно быть в формате, определённом в PS3.2.

C.6.2.2.1 Соответствие SCU
C.6.2.2.1.1 Соответствие C-FIND SCU

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования, должна поддерживать запросы к информационной модели запроса/получения, описанной в Разделе C.6.2.1, с использованием базового поведения C-FIND SCU, описанного в Разделе C.4.1.2.

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования в качестве SCU, должна указать в своём заявлении о соответствии, поддерживает ли она необязательные ключи. Если она поддерживает необязательные ключи, она должна перечислить поддерживаемые необязательные ключи.

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования в качестве SCU, должна быть способна генерировать запросы с использованием иерархического поиска (Hierarchical Search). Она не должна генерировать реляционные запросы, если опция реляционных запросов не была успешно согласована.

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

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

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования в качестве SCU, должна указать в своём заявлении о соответствии, как она использует Specific Character Set (0008,0005) и Timezone Offset From UTC (0008,0201) при кодировании запросов и интерпретации ответов.

C.6.2.2.1.2 Соответствие C-MOVE SCU

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования в качестве SCU, должна поддерживать передачи в рамках информационной модели запроса/получения, описанной в Разделе C.6.2.1, с использованием поведения C-MOVE SCU, описанного в Разделе C.4.2.2.

C.6.2.2.1.3 Соответствие C-GET SCU

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования в качестве SCU, должна поддерживать получение данных в рамках информационной модели запроса/получения, описанной в Разделе C.6.2.1, с использованием поведения C-GET SCU, описанного в Разделе C.4.3.2.

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования в качестве SCU и генерирующая получение данных с помощью операции C-GET, должна указать в своём заявлении о соответствии SOP-классы сервисного класса хранения, для которых она будет поддерживать подоперации C-STORE, генерируемые C-GET.

C.6.2.2.2 Соответствие SCP
C.6.2.2.2.1 Соответствие C-FIND SCP

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования, должна поддерживать запросы к информационной модели запроса/получения, описанной в Разделе C.6.2.1, с использованием поведения C-FIND SCP, описанного в Разделе C.4.1.3.

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования в качестве SCP, должна указать в своём заявлении о соответствии, поддерживает ли она необязательные ключи. Если она поддерживает необязательные ключи, она должна перечислить поддерживаемые необязательные ключи.

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

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

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования в качестве SCP, должна указать в своём заявлении о соответствии, поддерживает ли она сопоставление без учёта регистра для атрибутов VR PN, и перечислить атрибуты, к которым это применяется.

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования в качестве SCP, должна указать в своём заявлении о соответствии, как она использует Specific Character Set (0008,0005) и Timezone Offset From UTC (0008,0201) при интерпретации запросов, выполнении сопоставления и кодировании ответов.

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования в качестве SCP, должна указать в своём заявлении о соответствии способ выполнения однозначного сопоставления для атрибутов VR DS и IS (если поддерживается) и перечислить атрибуты, к которым это применяется.

C.6.2.2.2.2 Соответствие C-MOVE SCP

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования в качестве SCP, должна поддерживать передачи в рамках информационной модели запроса/получения, описанной в Разделе C.6.2.1, с использованием поведения C-MOVE SCP, описанного в Разделе C.4.2.3.

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования в качестве SCP и генерирующая передачи с помощью операции C-MOVE, должна указать в своём заявлении о соответствии SOP-классы сервисного класса хранения, для которых она будет поддерживать подоперации C-STORE, генерируемые C-MOVE.

C.6.2.2.2.3 Соответствие C-GET SCP

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования в качестве SCP, должна поддерживать получение данных в рамках информационной модели запроса/получения, описанной в Разделе C.6.2.1, с использованием поведения C-GET SCP, описанного в Разделе C.4.3.3.

Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования в качестве SCP и генерирующая получение данных с помощью операции C-GET, должна указать в своём заявлении о соответствии SOP-классы сервисного класса хранения, для которых она будет поддерживать подоперации C-STORE, генерируемые C-GET.

C.6.2.3 SOP-классы

SOP-классы в группе SOP-классов корня исследования сервисного класса запроса/получения идентифицируют информационную модель запроса/получения корня исследования и поддерживаемые операции DIMSE-C. Стандартные SOP-классы перечислены в Таблице C.6.2.3-1.

Таблица C.6.2.3-1. SOP-классы для запроса/получения корня исследования

SOP Class Name

SOP Class UID

Study Root Query/Retrieve Information Model - FIND

1.2.840.10008.5.1.4.1.2.2.1

Study Root Query/Retrieve Information Model - MOVE

1.2.840.10008.5.1.4.1.2.2.2

Study Root Query/Retrieve Information Model - GET

1.2.840.10008.5.1.4.1.2.2.3


C.6.3 Группа SOP-классов только Patient/Study (отозвано)

Отозвано (Retired). См. PS3.4-2004.

C.6.4 SOP-класс запроса к репозиторию

SOP-класс запроса к репозиторию (Repository Query SOP Class) использует службу C-FIND и информационную модель запроса/получения корня исследования. SOP-класс определяет дополнительную семантику и поведение для SCU и SCP, помимо тех, что определены для SOP-класса Study Root Query/Retrieve Information Model - FIND.

В частности, SOP-класс запроса к репозиторию поддерживает инкрементальный запрос/ответ для большого числа сущностей с использованием следующих возможностей:

  • Как SCU, так и SCP могут устанавливать ограничения на количество записей сущностей (ответов со статусом Pending), возвращаемых в транзакции C-FIND.

  • Если число ответов превысит ограничение SCU или SCP, обработка запроса C-FIND завершается с определённым ответом со статусом Warning, указывающим на неполный набор ответов.

  • По запросу SCU каждый ответ возвращает уникальное значение Record Key (0008,041B), по которому SCP упорядочивает ответы C-FIND.

  • SCU может включить значение Record Key (0008,041B), полученное в одной транзакции C-FIND, в качестве Prior Record Key (0008,041C) в запросе C-FIND для последующей транзакции. SCP обрабатывает этот последующий C-FIND, начиная с записи, следующей за указанным Prior Record Key (0008,041C).

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

Примечание

См. дополнительную поясняющую информацию в Приложении YYYY “Inventories (Informative)” в PS3.17, включая обсуждение использования SOP-класса запроса к репозиторию для создания Inventory SOP Instance.

C.6.4.1 Дополнительные атрибуты информационной модели запроса

SOP-класс запроса к репозиторию использует информационную модель запроса/получения корня исследования, указанную в Разделе C.6.2.1, но определяет дополнительные ключевые атрибуты. Эти ключевые атрибуты, как и те, что определены в Разделе C.3.4, не указаны в составных IOD PS3.3, но представляют информацию, которая может использоваться системой репозитория для управления сохранёнными SOP Instance. Таблица C.6.4.1-1 определяет дополнительные ключевые атрибуты.

Таблица C.6.4.1-1. Дополнительные ключи для запроса к репозиторию

Имя атрибута

Tag

Type

Описание атрибута

Record Key

(0008,041B)

R

Специфичный для реализации уникальный идентификатор записи сущности. Этот атрибут поддерживается только с универсальным сопоставлением (Universal Matching). См. Раздел C.6.4.1.1.

Removed from Operational Use

(0008,0405)

O

Признак того, что сущность на уровне запроса/получения, указанном в идентификаторе C-FIND, и её набор составных объектных экземпляров удалены из оперативного использования, связанного с обслуживанием пациентов. См. Раздел C.6.4.1.2.

Reason for Removal Code Sequence

(0008,0406)

O

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

В эту последовательность может быть включено ноль или один элемент.

>Include Table C.6-2b “Basic Code Value Keys Macro with Optional Keys”

DCID 7031 “Reason for Removal from Operational Use”.

File Set Access Sequence

(0008,0419)

O

Описание доступа к наборам сохранённых SOP Instance по протоколу, не относящемуся к DICOM. Этот атрибут определён только на уровнях исследования и серии. Этот атрибут поддерживается только с универсальным сопоставлением, т.е. если присутствует в идентификаторе запроса, он имеет нулевую длину или содержит только элемент нулевой длины. См. Раздел C.6.4.1.3.

См. Раздел C.6.4.5.5 для дополнительных требований к SCP.

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

>Stored Instance Base URI

(0008,0407)

-

Базовый URI для доступа к SOP Instance через протокол, не относящийся к DICOM.

>Folder Access URI

(0008,0408)

-

URI доступа к папке, содержащей все SOP Instance для данного исследования или серии.

>File Access URI

(0008,0409)

-

URI доступа к файлу-контейнеру, содержащему все SOP Instance для данного исследования или серии.

>Container File Type

(0008,040A)

-

Тип файла-контейнера.

Определённые термины:

ZIP

TAR

GZIP

TARGZIP

BLOB

См. Раздел P.1.2 «Форматы файлов-контейнеров» в PS3.3 для определений терминов.

Обязательно в идентификаторе ответа, если присутствует File Access URI (0008,0409).

File Access Sequence

(0008,041A)

O

Описание доступа по протоколу, не относящемуся к DICOM, к сохранённой SOP Instance. Этот атрибут определён только на уровне составного экземпляра (Composite Instance). Этот атрибут поддерживается только с универсальным сопоставлением (Universal Matching), т.е. если присутствует в идентификаторе запроса, он имеет нулевую длину или содержит только элемент нулевой длины. См. Раздел C.6.4.1.3.

См. Раздел C.6.4.5.5 для дополнительных требований к SCP.

В эту последовательность в идентификаторе ответа может быть включено ноль или более элементов.

>File Access URI

(0008,0409)

-

URI доступа для файла, содержащего SOP Instance.

Обязательно в идентификаторе ответа, если File Access Sequence (0008,041A) содержит элемент.

>Container File Type

(0008,040A)

-

Тип файла-контейнера.

Определённые термины:

ZIP

TAR

GZIP

TARGZIP

DICM

Отдельная SOP Instance в формате DICOM File Format

См. Раздел P.1.2 «Форматы файлов-контейнеров» в PS3.3 для определений терминов, не описанных здесь.

Обязательно в идентификаторе ответа, если присутствует File Access URI (0008,0409).

>Filename in Container

(0008,040B)

-

Имя файла внутри файла-контейнера, содержащего файл с SOP Instance.

Обязательно в идентификаторе ответа, если Container File Type (0008,040A) имеет значение ZIP, TAR или TARGZIP.

>File Offset in Container

(0008,040C)

-

Байтовое смещение (с отсчётом от нуля) внутри файла-контейнера для начала файла SOP Instance.

Обязательно в идентификаторе ответа, если Container File Type (0008,040A) имеет значение BLOB, может присутствовать в остальных случаях.

>File Length in Container

(0008,040D)

-

Длина файла SOP Instance внутри файла-контейнера.

Обязательно в идентификаторе ответа, если Container File Type (0008,040A) имеет значение BLOB, может присутствовать в остальных случаях.

>Stored Instance Transfer Syntax UID

(0008,040E)

-

Transfer Syntax SOP Instance, закодированной в формате DICOM File Format. Равна Transfer Syntax UID (0002,0010) в заголовке File Meta Information.

Обязательно в идентификаторе ответа, если File Access Sequence (0008,041A) содержит элемент.

>Lossy Image Compression Ratio

(0028,2112)

-

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

>MAC Algorithm

(0400,0015)

-

Алгоритм, используемый для генерации кода аутентификации сообщения (Message Authentication Code). См. Раздел C.12.1.1.3.1.2 «Подпись» в PS3.3 для определённых терминов.

Обязательно в идентификаторе ответа, если присутствует MAC (0400,0404).

>MAC

(0400,0404)

-

Код аутентификации сообщения (Message Authentication Code), вычисленный по файлу сохранённого экземпляра для проверки целостности файла.

Metadata Sequence

(0008,041D)

O

Все неблочные (non-bulk) атрибуты данных на уровне запроса/получения, управляемые SCP. См. Раздел C.6.4.1.4.

См. Раздел C.6.4.5.5 для дополнительных требований к SCP.

Этот атрибут поддерживается только с универсальным сопоставлением (Universal Matching), т.е. если присутствует в идентификаторе запроса, он имеет нулевую длину или содержит только элемент нулевой длины.

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

>Any non-bulk data Attributes

-

В идентификаторе ответа может присутствовать несколько атрибутов.

Updated Metadata Sequence

(0008,041E)

O

Неблочные (non-bulk) атрибуты данных на уровне запроса/получения, управляемые SCP, значения которых отличаются от значений, содержащихся в сохранённых файлах SOP Instance. См. Раздел C.6.4.1.4.

См. Раздел C.6.4.5.5 для дополнительных требований к SCP.

Этот атрибут поддерживается только с универсальным сопоставлением (Universal Matching), т.е. если присутствует в идентификаторе запроса, он имеет нулевую длину или содержит только элемент нулевой длины.

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

>Any non-bulk data Attributes

-

В идентификаторе ответа может присутствовать несколько атрибутов.


Примечание

Символ "-" в столбце Type используется для обозначения атрибутов, находящихся внутри последовательности (Sequence), которая определена только с универсальным сопоставлением (Universal Matching). Следовательно, эти атрибуты не будут присутствовать в идентификаторе запроса; поэтому они не являются ключевыми атрибутами (Key Attributes) для сопоставления, и столбец Type к ним не применяется. Если SCP поддерживает атрибут последовательности, и он запрошен SCU, SCP возвращает эти атрибуты "-" в соответствии с их описанием атрибута.

C.6.4.1.1 Record Key (ключ записи)

Record Key (0008,041B) определён на уровнях запроса исследования (Study), серии (Series) и экземпляра (Instance). Это специфичный для реализацию уникальный идентификатор в пределах уровня записи сущности в SCP. SCP класса SOP Repository Query должен возвращать значения Record Key (0008,041B) ненулевой длины. Содержимое Record Key (0008,041B) непрозрачно (opaque) для приложений, отличных от SCP.

SCP должен конструировать значение Record Key (0008,041B) таким образом, чтобы для каждого значения SCP мог определить его порядок относительно всех остальных таких значений. Идентификаторы ответов C-FIND должны возвращаться в порядке значений Record Key (0008,041B). SCP должен иметь возможность определить по заданному значению следующую запись сущности, подлежащую возврату, соответствующую заданному идентификатору запроса, без повторения каких-либо записей.

Значения Record Key (0008,041B) используются как значение Prior Record Key (0008,041C) в последующем запросе (см. Раздел C.6.4.5.3). SCP может устанавливать специфичные для реализации условия, после которых значение Record Key (0008,041B) становится недействительным, т.е. больше не позволяет продолжать последовательность операций запроса. SCP должен иметь возможность определить по заданному значению Prior Record Key (0008,041C), действительно ли это значение всё ещё пригодно для определения следующей возвращаемой записи.

Примечание

  1. Структура, содержимое и метод упорядочивания значений Record Key (0008,041B) являются специфичными для реализации SCP и непрозрачны (opaque) для SCU, т.е. SCU не должен пытаться анализировать эти значения на компоненты или семантику. Значения могут быть постоянными или могут конструироваться динамически во время обработки запроса. Только SCP может определить по значению одного Record Key (0008,041B), какая запись должна быть возвращена следующей. Например, SCP может использовать зашифрованные представления внутреннего первичного ключа базы данных в качестве Record Key (0008,041B), и для SCU они могут выглядеть как случайные неупорядоченные значения.

  2. Цель требований к упорядочиванию и использованию Record Key (0008,041B) — позволить SCU получить полный перечень, соответствующий ключевым атрибутам (Key Attributes), в последовательности запросов. См. Раздел YYYY.2.2 «Record Key and Continuation» в PS3.17.

C.6.4.1.2 Удаление из оперативного использования (Removed From Operational Use)

Атрибут Removed from Operational Use (0008,0405) определён на уровнях запроса исследования (Study), серии (Series) и экземпляра (Instance).

Перечислимые значения:

Y

Экземпляры не подлежат использовать в оперативных целях.

N

Экземпляры могут использоваться в оперативных целях.

Значение Y указывает, что исследование (Study), серия (Series) или экземпляр (Instance) были удалены из оперативного использования, связанного с обслуживанием пациентов, хотя они могут сохраняться в системе репозитория по другим причинам (например, для аудита лучевой нагрузки пациента). На уровне исследования и серии этот атрибут указывает, было ли всё исследование или вся серия удалена из оперативного использования. Значение Y на уровне исследования имеет приоритет над любым значением, указанным для подчинённых серий и экземпляров, а значение Y на уровне серии имеет приоритет над любым значением, указанным для подчинённых экземпляров.

Хотя атрибут определён на уровнях исследования, серии и экземпляра, SCP может не поддерживать этот атрибут на некоторых или на всех этих уровнях. Например, SCP может управлять этим атрибутом только на уровне экземпляра и не обязан выводить значение для уровня серии или исследования.

Примечание

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

  2. Исследования, серии или экземпляры могут быть помечены как удалённые из оперативного использования действиями, связанными с обработкой определённых SOP Instance документа выбора ключевого объекта (Key Object Selection Document), например, в соответствии с [IHE RAD TF-1]. Image Object Change Management Integration Profile (IOCM). Сами эти SOP Instance документа выбора ключевого объекта и их серии могут быть помечены как удалённые из оперативного использования. Контекстная группа для Reason for Removal Code Sequence (0008,0406) включает коды концептов Key Object Selection Concept Codes, указанные в IOCM.

  3. Семантика атрибута Removed from Operational Use (0008,0405) позволяет SCP включать такие сущности в ответ на запрос к репозиторию без ограничений. SCP может исключать сущности, помеченные как удалённые из оперативного использования, из ответов C-FIND других классов SOP Query/Retrieve (например, см. [IHE RAD TF-2] Раздел 4.66.4.1.3.1 «Доступ к отклонённым экземплярам»).

  4. Атрибут Removed from Operational Use (0008,0405) не зависит от Instance Availability (0008,0056). Составной экземпляр может быть удалён из оперативного использования, но всё ещё быть доступным с оперативностью, указанной Instance Availability (0008,0056). И наоборот, экземпляр может не быть удалённым из оперативного использования, но быть «UNAVAILABLE» (недоступным) для получения.

  5. Если SCP сохраняет записи об удалённых исследованиях, сериях или экземплярах, даже если сами экземпляры физически удалены, он может включать эти сущности в ответ C-FIND с соответствующим значением Reason for Removal Code Sequence (0008,0406). Такие экземпляры могут иметь значение Instance Availability (0008,0056) «UNAVAILABLE» (см. Раздел C.4.1.1.3.2).

C.6.4.1.3 File Set Access Sequence и File Access Sequence

SCP может поддерживать необязательные атрибуты, предоставляющие URI-ссылку на SOP Instance, сохранённые в формате DICOM File Format (см. Раздел 7 «DICOM File Format» в PS3.10) и доступные через протокол доступа к файлам, не относящийся к DICOM (см. Приложение P «Stored File Access Through Non-DICOM Protocols (Normative)» в PS3.3).

Примечание

  1. См. Раздел YYYY.3.4 «Access Mechanisms For Repository Data» в PS3.17

  2. Понятие «File Set», используемое здесь, может не совпадать с концепцией File-set, определённой в PS3.10 и используемой в Storage Media File-set ID (0088,0130).

Для запроса на уровне исследования или серии Stored Instance Base URI (0008,0407) внутри File Set Access Sequence (0008,0419) устанавливает базовый URI [RFC3986], который объединяется с URI относительных ссылок пути для доступа к SOP Instance исследования или серии по протоколу, не относящемуся к DICOM. Если все сохранённые файлы SOP Instance этого исследования или серии каталогизированы в одной папке, Folder Access URI (0008,0408) предоставляет URI для операций протокола над этой папкой. Если все сохранённые файлы SOP Instance находятся в одном файле-контейнере, File Access URI (0008,0409) предоставляет URI для доступа к этому файлу. Folder Access URI (0008,0408) и/или File Access URI (0008,0409) могут быть URI относительной ссылки пути, начинающимися с одноточечного сегмента «./», и URI объединяется со Stored Instance Base URI (0008,0407) в соответствии с Разделом P.2.1 «URI Format» в PS3.3.

Примечание

Stored Instance Base URI (0008,0407) является необязательным. Если он отсутствует, значения Folder Access URI (0008,0408) и File Access URI (0008,0409) будут полными URI. Если Stored Instance Base URI (0008,0407) присутствует, эти другие атрибуты всё же могут содержать полные URI, а не относительные пути для объединения с базовым URI. Полный путь, указанный в Folder Access URI (0008,0408) или File Access URI (0008,0409), может иметь схему и полномочия (authority), отличные от указанных в Stored Instance Base URI (0008,0407).

Для запроса на уровне экземпляра каждый элемент File Access Sequence (0008,041A) в идентификаторе ответа предоставляет URI [RFC3986] для доступа к сохранённой SOP Instance. File Access URI (0008,0409) может быть URI относительной ссылки пути, начинающимся с одноточечного сегмента «./», и URI объединяется со Stored Instance Base URI (0008,0407), указанным внутри File Set Access Sequence (0008,0419) на уровне серии, если он присутствует, или иначе со Stored Instance Base URI (0008,0407), указанным внутри File Set Access Sequence (0008,0419) на уровне исследования.

Примечание

  1. SCP может хранить SOP Instance на нескольких устройствах хранения (например, на быстрых носителях краткосрочного хранения и более медленных носителях долгосрочного хранения) или в разных Transfer Syntax. Поэтому SOP Instance может быть доступна через протокол, не относящийся к DICOM, по нескольким URI.

  2. Если File Access URI (0008,0409) для SOP Instance является URI относительной ссылки пути, SCU должен получить Stored Instance Base URI (0008,0407) из запросов на иерархически вышестоящих уровнях STUDY и SERIES. Т.е. запросы на уровне исследования и серии должны были включать запрос File Set Access Sequence (0008,0419).

  3. См. Раздел YYYY.7.2 «Using Non-DICOM Protocols» в PS3.17.

C.6.4.1.4 Metadata Sequence и Updated Metadata Sequence

SCP может управлять набором атрибутов метаданных для SOP Instance в репозитории для ответа на запросы. Metadata Sequence (0008,041D) в идентификаторе ответа должен содержать все атрибуты SOP Instance на уровне запроса, управляемые SCP, исключая элементы блочных данных (bulk data, такие как данные пикселей, сигналов и поверхностных сетей) и атрибуты, не относящиеся к SOP Instance, указанные в Разделе C.3.4 или в Таблице C.6.4.1-1.

Примечание

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

SCP может управлять набором атрибутов метаданных, «обновлённые» значения которых отличаются от значений в сохранённой SOP Instance, доступной через протокол, не относящийся к DICOM, указанный в File Access URI (0008,0409) или Folder Access URI (0008,0408). Хотя сохранённая SOP Instance должна соответствовать своему IOD (согласно требованиям DICOM File Format), некоторые атрибуты в файле могут не иметь текущих значений (например, Patient's Name (0010,0010) мог быть исправлён или изменён после сохранения SOP Instance). Updated Metadata Sequence (0008,041E) в идентификаторе ответа должен содержать все атрибуты на уровне запроса, значения которых отличаются от значений, содержащихся в сохранённом файле SOP Instance.

SCP, поддерживающий URI-ссылки протокола, не относящегося к DICOM, на сохранённые SOP Instance, должен поддерживать либо Metadata Sequence (0008,041D), либо Updated Metadata Sequence (0008,041E), либо оба, для предоставления текущих значений метаданных для SOP Instance, доступ к которым осуществляется через протокол, не относящийся к DICOM.

Примечание

  1. Ожидается, что SOP Instance, доступ к которым осуществляется через протоколы DICOM, имеют текущие значения во всех атрибутах.

  2. SCP может не отслеживать, изменились ли значения атрибутов или какие именно атрибуты изменили значения, и, следовательно, может не поддерживать Updated Metadata Sequence (0008,041E). В этом случае SCU может запросить Metadata Sequence (0008,041D), который содержит все текущие значения атрибутов, управляемые SCP, независимо от того, были ли они обновлены. Определение различий, если таковые имеются, между возвращёнными значениями атрибутов и значениями в сохранённой SOP Instance является ответственностью SCU.

На любом уровне запроса Metadata Sequence (0008,041D) или Updated Metadata Sequence (0008,041E) может включать Original Attributes Sequence (0400,0561), описывающую происхождение изменений атрибутов на этом уровне или на более высоких уровнях запроса.

Если Metadata Sequence (0008,041D) и/или Updated Metadata Sequence (0008,041E) присутствуют в идентификаторе запроса, их отсутствие в идентификаторе ответа означает, что они не поддерживаются SCP (см. Раздел C.2.2.1.3).

Значение нулевой длины или один пустой элемент в Updated Metadata Sequence (0008,041E) в идентификаторе ответа указывает на поддержку со стороны SCP, но отсутствие различающихся значений атрибутов метаданных.

C.6.4.2 Атрибуты идентификатора запроса Repository Query

Помимо атрибутов, указанных в Разделе C.4.1.1.3.1, идентификатор запроса к репозиторию может содержать атрибуты, показанные в Таблице C.6.4.2-1, чтобы SCU мог запросить определённое содержимое ответа C-FIND.

Таблица C.6.4.2-1. Дополнительные атрибуты идентификатора запроса Repository Query

Имя атрибута

Tag

Описание атрибута

Prior Record Key

(0008,041C)

Идентификатор сущности, который был возвращён как значение Record Key (0008,041B) в предыдущем запросе. Сущности, возвращённые для текущего запроса, будут начинаться с первой соответствующей записи с ключом записи, следующим после данного ключа записи. См. Раздел C.6.4.5.3 для требований к обработке на стороне SCP.

Maximum Number of Records

(0008,0429)

Максимальное количество сопоставленных сущностей, возвращаемых для данного запроса. См. Раздел C.6.4.5.2 для требований к обработке на стороне SCP.


C.6.4.3 Коды состояния

Класс SOP Repository Query указывает значения кодов состояния из Таблицы C.6.4.3-1 в дополнение к статусам и связанным полям, указанным в Разделе C.4.1.1.4 для C-FIND класса обслуживания Query/Retrieve и в Разделе 9.1.2.1.6 «Status» в PS3.7 для службы C-FIND DIMSE.

Таблица C.6.4.3-1. Дополнительные значения состояния Repository Query

Статус службы

Дополнительное значение

Коды состояния

Связанные поля

Отказ

Недействительный Prior Record Key

A710

Нет

Предупреждение

Сопоставление достигло предела ответа; последующий запрос может вернуть дополнительные совпадения

B001

Нет


C.6.4.4 Поведение C-FIND SCU

Помимо поведений, указанных в Разделе C.4.1.2, SCU должен интерпретировать ответ со статусом B001 «Warning» (Предупреждение) как указывающий на окончание отложенных (Pending) ответов и как признак того, что доступны дополнительные ответы, но SCP больше не обрабатывает данный запрос в этой операции C-FIND.

C.6.4.5 Поведение C-FIND SCP

Класс SOP Repository Query добавляет следующие поведения как к базовому, так и к расширенному поведению SCP, описанному в Разделе C.4.1.3.

C.6.4.5.1 Record Key (ключ записи)

SCP должен возвращать ответы C-FIND в соответствии с упорядочиванием значений Record Key (0008,041B), если этот атрибут включён в идентификатор запроса.

Примечание

  1. Если Record Key (0008,041B) не запрошен, требования к упорядочиванию отсутствуют, и SCU не сможет issued последующий запрос с Prior Record Key (0008,041C).

  2. Структура, содержимое и метод упорядочивания значений Record Key (0008,041B) являются специфичными для реализации SCP и непрозрачны для SCU (см. Раздел C.6.4.1.1).

C.6.4.5.2 Maximum Number of Records и неполный ответ

SCP должен отправить не более указанного SCU в атрибуте Maximum Number of Records (0008,0429) в идентификаторе запроса к репозиторию количества отложенных ответов (т.е. возвращённых сопоставленных записей). Кроме того, SCP может ограничить количество ответов в транзакции запроса до собственного определяемого реализацией предела ресурсов. Если достигнут любой из этих пределов и имеются дополнительные записи, удовлетворяющие сопоставлению ключевых атрибутов, SCP должен отправить итоговое значение статуса B001 «Warning» (Предупреждение).

Примечание

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

C.6.4.5.3 Prior Record Key и последующий ответ

Если Prior Record Key (0008,041C) присутствует в идентификаторе запроса к репозиторию, SCP должен вернуть записи сущностей, начиная со следующего ключа записи, которые удовлетворяют сопоставлению ключевых атрибутов. SCP должен вернуть код состояния отказа A710, если значение Prior Record Key (0008,041C) недействительно для идентификации сущности, определяющей точку продолжения. См. Раздел C.6.4.1.1.

Для последовательного набора транзакций запроса с одними и теми же значениями ключевых атрибутов, в котором каждый запрос C-FIND после первого включает значение Prior Record Key (0008,041C), равное последнему Record Key (0008,041B) в ответах C-FIND предыдущей транзакции запроса, SCP должен вернуть тот же набор ответов C-FIND, как если бы весь запрос был бы завершён в одной транзакции. Будут ли новые сущности и обновления, полученные SCP после времени начальной транзакции запроса, включены в ответы C-FIND, зависит от реализации.

Примечание

  1. Например, сущность, добавленная после времени начального запроса, может получить Record Key (0008,041B), предшествующий Record Key (0008,041B), уже отправленному в ответе C-FIND; эта сущность не будет возвращена в наборе транзакций запроса. Однако добавленная сущность, чей Record Key (0008,041B) находится после последнего отправленного Record Key (0008,041B), может как быть включена, так и не быть включена в набор транзакций запроса; поскольку она была добавлена после начальной транзакции запроса, реализация определяет, включать ли такое изменение в ответы.

  2. SCP не должен предполагать, что последний отправленный им Record Key (0008,041B) будет использован как Prior Record Key (0008,041C) в последующей транзакции. Условия ошибки могут потребовать от SCU возобновить работу с более раннего значения.

  3. Не требуется, чтобы ключевые атрибуты в идентификаторе запроса были идентичны атрибутам в предыдущей транзакции запроса к репозиторию, даже несмотря на то, что наличие Prior Record Key (0008,041C) подразумевает продолжение предыдущей транзакции. Каждая транзакция запроса к репозиторию является независимой. SCP не должен сохранять информацию о состоянии между транзакциями запроса к репозиторию, хотя он может включать информацию о состоянии в Record Key (0008,041B).

C.6.4.5.4 Сущности, удалённые из оперативного использования

Если SCP поддерживает Removed from Operational Use (0008,0405) (см. Раздел C.6.4.1.2) как ключевой атрибут, ответы на запрос должны включать все сущности независимо от значения этого атрибута, если только SCU явно не включил сопоставление по этому атрибуту в запрос C-FIND и SCP поддерживает сопоставление по этому атрибуту.

Примечание

Поскольку класс SOP Study Root Query/Retrieve Information Model - FIND обычно используется в оперативных целях, реализация SCP этого класса SOP по политике может не возвращать сущности со значением Removed from Operational Use (0008,0405) «Y».

C.6.4.5.5 File Set Access Sequence и File Access Sequence

SCP, поддерживающий File Set Access Sequence (0008,0419) на уровне запроса исследования или серии, должен поддерживать либо Metadata Sequence (0008,041D), либо Updated Metadata Sequence (0008,041E), либо оба, на тех же уровнях.

SCP, поддерживающий File Access Sequence (0008,041A) на уровне запроса экземпляра, должен поддерживать либо Metadata Sequence (0008,041D), либо Updated Metadata Sequence (0008,041E), либо оба, на этом уровне.

SCP может поддерживать Metadata Sequence (0008,041D) или Updated Metadata Sequence (0008,041E) без поддержки File Set Access Sequence (0008,0419) или File Access Sequence (0008,041A).

См. Раздел C.6.4.1.4 для дальнейших разъяснений.

C.6.4.6 Требования соответствия

Реализация может соответствовать классу SOP Repository Query как SCU, SCP или оба. Заявление о соответствии (Conformance Statement) должно быть в формате, определённом в PS3.2.

C.6.4.6.1 Соответствие C-FIND SCU

Реализация, соответствующая классу SOP Repository Query как SCU, должна поддерживать запросы к модели информации Study Root Query/Retrieve, описанной в Разделе C.6.2.1 и Разделе C.6.4.1, с использованием поведения C-FIND SCU, описанного в Разделе C.4.1.2 и Разделе C.6.4.4.

Реализация, соответствующая классу SOP Repository Query как SCU, должна поддерживать формирование запросов с использованием иерархического поиска (Hierarchical Search). Она не должна формировать запросы с использованием реляционных запросов (Relational-queries), если только опция Relational-queries не была успешно согласована. Реализация, соответствующая классу SOP Repository Query как SCU, должна указать в своём заявлении о соответствии (Conformance Statement), может ли она формировать реляционные запросы (Relational-queries).

Реализация, соответствующая классу SOP Repository Query как SCU, должна указать в своём заявлении о соответствии:

  • Поддерживает ли она расширенное согласование (Extended Negotiation) комбинированного сопоставления даты и времени, нечёткого семантического сопоставления имён лиц, сопоставления пустых значений и/или сопоставления множественных значений.

  • Как она использует Specific Character Set (0008,0005) и Timezone Offset From UTC (0008,0201) при кодировании запросов и интерпретации ответов.

  • Любые ограничения, накладываемые ею на количество ответов C-FIND через атрибут Maximum Number of Records (0008,0429).

C.6.4.6.2 Соответствие C-FIND SCP

Реализация, соответствующая классу SOP Repository Query как SCP, должна поддерживать запросы к модели информации Study Root Query/Retrieve, описанной в Разделе C.6.2.1 и Разделе C.6.4.1, с использованием поведения C-FIND SCP, описанного в Разделе C.4.1.3 и Разделе C.6.4.5.

Реализация, соответствующая классу SOP Repository Query как SCP, должна указать в своём заявлении о соответствии:

  • Какие необязательные ключи (Optional Keys) она поддерживает для существования (т.е. для возврата в ответах) и какие — для сопоставления.

  • Какие атрибуты она поддерживает в элементах тех ключевых атрибутов, которые являются последовательностями (Sequences).

  • Поддерживает ли она реляционный поиск (Relational Search). Если она поддерживает реляционный поиск, то она должна также поддерживать расширенное согласование (Extended Negotiation) реляционных запросов (Relational-queries) как SCP.

  • Поддерживает ли она расширенное согласование (Extended Negotiation) комбинированного сопоставления даты и времени, нечёткого семантического сопоставления имён лиц, сопоставления пустых значений и/или сопоставления множественных значений. Если поддерживается нечёткое семантическое сопоставление имён лиц, то механизм нечёткого семантического сопоставления должен быть указан.

  • Поддерживает ли она сопоставление без учёта регистра для атрибутов VR PN, и перечислить атрибуты, к которым это применяется.

  • Как она использует Specific Character Set (0008,0005) и Timezone Offset From UTC (0008,0201) при интерпретации запросов, выполнении сопоставления и кодировании ответов.

  • Любые ограничения, накладываемые ею на количество ответов C-FIND.

  • Условия, после которых значение Record Key (0008,041B) становится недействительным для возобновления операции C-FIND.

  • Любые механизмы, не относящиеся к DICOM, используемые для доступа к SOP Instance, которые могут быть указаны File Access URI (0008,0409), включая протоколы (такие как NFS, SMB или HTTP), а также использование папок и/или файлов-контейнеров (ZIP, TAR, GZIP, TARGZIP, BLOB) для SOP Instance. Если такие механизмы используются, должно быть описано использование Metadata Sequence (0008,041D) или Updated Metadata Sequence (0008,041E).

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

C.6.4.7 Классы SOP

UID для класса SOP Repository Query приведён в Таблице C.6.4.7-1.

Таблица C.6.4.7-1. Классы SOP для Repository Query

SOP Class Name

SOP Class UID

Repository Query

1.2.840.10008.5.1.4.1.1.201.6


D Класс службы уведомления о содержании исследования (Study Content Notification Service Class) (выведен из употребления)

Выведен из употребления. См. PS3.4-2004.

E Класс службы управления пациентами (Patient Management Service Class) (выведен из употребления)

Выведен из употребления. См. PS3.4-2004.

F Классы SOP этапа процедуры (Procedure Step)

F.1 Обзор

Это приложение определяет классы SOP этапа процедуры (Procedure Step).

Примечание

Ранее в этом приложении определялся класс службы управления исследованием (Study Management Service Class), который был выведен из употребления. См. PS3.4-2004.

F.1.1 Область применения (выведено из употребления)

Выведено из употребления. См. PS3.4-2004.

F.1.2 Функциональная модель управления исследованием (выведено из употребления)

Выведено из употребления. См. PS3.4-2004.

F.1.3 Модель информации управления исследованием (выведено из употребления)

Выведено из употребления. См. PS3.4-2004.

F.1.4 Состояния управления исследованием (выведено из употребления)

Выведено из употребления. См. PS3.4-2004.

F.1.5 Состояния управления выполненным этапом процедуры модальности

Информация о состоянии, относящаяся к Modality Performed Procedure Step, задаётся IOD Modality Performed Procedure Step в атрибуте Performed Procedure Step Status (0040,0252).

Объект Performed Procedure Step представляет только «выполненный» (performed) сегмент реального этапа процедуры, а не «запланированный» (scheduled) сегмент. Поэтому количество событий ограничено; все события инициируются модальностью. Состояние «DISCONTINUED» означает отмену или неудачное завершение, что может произойти, когда выполнение этапа процедуры было начато, но не может быть завершено модальностью. Модальность должна сообщить об этом изменении состояния информационной системе (SCP), чтобы позволить информационной системе перепланировать или отменить связанный этап процедуры. Состояние «COMPLETED» означает, что получение составных SOP Instance (Composite SOP Instances) успешно завершено и SCU предоставил все требуемые значения атрибутов для Performed Procedure Step.

Таблица F.1-3 описывает допустимые состояния Modality Performed Procedure Step.

Таблица F.1-3. Состояния Modality Performed Procedure Step

Состояние

Описание

In Progress

Modality Performed Procedure Step создан, выполнение в процессе

Discontinued

Выполнение Modality Performed Procedure Step отменено модальностью

Completed

Modality Performed Procedure Step завершён


Таблица F.1-4 определяет допустимые переходы состояний для Performed Procedure Steps. Для каждого из определённых выше состояний указывается допустимое состояние, возникающее в результате наступления событий. Эти переходы состояний управляются классом SOP Modality Performed Procedure Step.

Таблица F.1-4. Диаграмма переходов состояний Modality Performed Procedure Step

Состояния

События

In Progress

Discontinued

Completed

Performed Procedure Step Discontinued

Discontinued

Performed Procedure Step Completed

Completed


F.1.6 Состояния управления общим назначением запланированного этапа процедуры (выведено из употребления)

Выведено из употребления. См. PS3.4-2011.

F.1.7 Состояния управления общим назначением выполненного этапа процедуры (выведено из употребления)

Выведено из употребления. См. PS3.4-2011.

F.2 Обзор соответствия

Службы прикладного уровня, рассматриваемые в данном определении класса службы (Service Class Definition), задаются через следующие отдельные классы SOP:

  1. Modality Performed Procedure Step SOP Class

  2. Modality Performed Procedure Step Notification SOP Class

  3. Modality Performed Procedure Step Retrieve SOP Class

Каждый класс SOP работает с подмножеством IOD Modality Performed Procedure Step и определяет атрибуты, операции, уведомления и поведение, применимые к классу SOP. Соответствие прикладных сущностей (Application Entities) определяется путём выбора одного или нескольких классов SOP. Для каждого класса SOP требования соответствия определяются с точки зрения поставщика класса службы (Service Class Provider, SCP) и пользователя класса службы (Service Class User, SCU).

F.2.1 Согласование ассоциации

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

Поддержка согласования выбора роли SCP/SCU (SCP/SCU Role Selection Negotiation) является обязательной. Расширенное согласование класса SOP (SOP Class Extended Negotiation) не должно поддерживаться.

Примечание

Уведомление о событиях — это процесс, который логически охватывает несколько ассоциаций. Реализации SCP должны поддерживать локальную таблицу SCU, которым должны отправляться уведомления о событиях.

F.3 Класс SOP отдельного управления исследованием (Detached Study Management SOP Class) (выведен из употребления)

Выведен из употребления. См. PS3.4-2004.

F.4 Класс SOP управления компонентом исследования (Study Component Management SOP Class) (выведен из употребления)

Выведен из употребления. См. PS3.4-2004.

F.5 Мета-класс SOP управления исследованием (Study Management Meta SOP Class) (выведен из употребления)

Выведен из употребления. См. PS3.4-2004.

F.6 Соответствие специализированного класса SOP (выведено из употребления)

Выведено из употребления. См. PS3.4-2004.

F.7 Класс SOP Modality Performed Procedure Step

F.7.1 Группа служб DIMSE

Службы DIMSE, показанные в Таблице F.7.1-1, применимы к IOD Modality Performed Procedure Step в рамках класса SOP Modality Performed Procedure Step.

Таблица F.7.1-1. Группа служб DIMSE, применимая к Modality Performed Procedure Step

Элемент службы сообщений DICOM (Элемент службы сообщений DICOM)

Использование (SCU/SCP)

N-CREATE

M/M

N-SET

M/M


Службы и протоколы DIMSE специфицированы в PS3.7

F.7.2 Операции

Прикладная сущность, заявляющая о соответствии этому классу SOP как SCU, должна иметь право вызывать следующие операции, а прикладная сущность, заявляющая о соответствии как SCP, должна быть способна предоставлять следующие операции.

F.7.2.1 Создание SOP Instance выполненного этапа процедуры модальности

Эта операция позволяет SCU создать экземпляр класса SOP Modality Performed Procedure Step и предоставить информацию о конкретном реальном выполненном этапе процедуры (Performed Procedure Step), находящемся под управлением SCU. Эта операция должна вызываться через службу DIMSE N-CREATE.

Примечание

Модальность должна уведомить информационную систему как можно скорее о том, что выполнение этапа процедуры было начато, отправив запрос службы N-CREATE. Это позволяет SCP класса SOP Modality Worklist (если поддерживается) обновить Modality Worklist. Некоторые значения атрибутов уже известны в начале этапа процедуры; они должны быть отправлены в команде N-CREATE. Другие обязательные атрибуты известны только в конце Performed Procedure Step; им присваивается значение в команде N-SET.

Один и тот же UID SOP Instance используется всеми тремя классами SOP Modality Performed Procedure Step. Это означает, что SOP Instance, созданная и установленная с использованием служб класса SOP Modality Performed Procedure Step, может быть получена с использованием её UID SOP Instance в рамках службы класса SOP Modality Performed Procedure Step Retrieve. Об изменениях её состояния можно уведомить, используя её UID SOP Instance в рамках службы класса SOP Modality Performed Procedure Step Notification. UID класса SOP, указанный в примитивах запроса DIMSE N-CREATE и N-SET, должен быть UID класса SOP Modality Performed Procedure Step.

F.7.2.1.1 Спецификация подмножества выполненного этапа процедуры модальности

Прикладная сущность, заявляющая о соответствии этому классу SOP как SCU, должна предоставить все обязательные атрибуты, указанные в Таблице F.7.2-1. Необязательные атрибуты, поддерживаемые SCP, также могут быть предоставлены. Прикладная сущность, заявляющая о соответствии как SCP этому классу SOP, должна поддерживать подмножество атрибутов Modality Performed Procedure Step, указанное в Таблице F.7.2-1.

Таблица F.7.2-1a. Макрос Enhanced Code Value для Modality Performed Procedure Step без N-SET

Имя атрибута

Tag

Использование N-CREATE (SCU/SCP)

Использование N-SET (SCU/SCP)

Использование Final State (см. Примечание 1)

Include Table F.7.2-1b “Modality Performed Procedure Step Simple Code Value Macro with no N-SET”

Equivalent Code Sequence

(0008,0121)

3/3

Не допускается

>Include Table F.7.2-1b “Modality Performed Procedure Step Simple Code Value Macro with no N-SET”


Таблица F.7.2-1b. Макрос Simple Code Value для Modality Performed Procedure Step без N-SET

Имя атрибута

Tag

Использование N-CREATE (SCU/SCP)

Использование N-SET (SCU/SCP)

Использование Final State (см. Примечание 1)

Code Value

(0008,0100)

1C/1C

Должно присутствовать, если длина значения кода составляет 16 символов или менее, и значение кода не является URN или URL.

Не допускается

Coding Scheme Designator

(0008,0102)

1C/1C

Должно присутствовать, если присутствует Code Value (0008,0100) или Long Code Value (0008,0119). Может присутствовать в остальных случаях.

Не допускается

Coding Scheme Version

(0008,0103)

1C/1C

Должно присутствовать, если значение Coding Scheme Designator (0008,0102) присутствует и недостаточно для однозначной идентификации Code Value (0008,0100), Long Code Value (0008,0119) или URN Code Value (0008,0120). Не должно присутствовать, если Coding Scheme Designator (0008,0102) отсутствует. Может присутствовать в остальных случаях.

Не допускается

Code Meaning

(0008,0104)

1/1

Не допускается

Long Code Value

(0008,0119)

1C/1C

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода не является URN или URL.

Не допускается

URN Code Value

(0008,0120)

1C/1C

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода является URN или URL.

Не допускается

Mapping Resource

(0008,0105)

3/3

Не допускается

Mapping Resource UID

(0008,0118)

3/3

Не допускается

Context Group Version

(0008,0106)

3/3

Не допускается

Context Group Extension Flag

(0008,010B)

3/3

Не допускается

Context Group Local Version

(0008,0107)

3/3

Не допускается

Context Group Extension Creator UID

(0008,010D)

3/3

Не допускается


Таблица F.7.2-1c. Макрос Enhanced Code Value для Modality Performed Procedure Step с N-SET, обязательное значение (Mandatory Meaning)

Имя атрибута

Tag

Использование N-CREATE (SCU/SCP)

Использование N-SET (SCU/SCP)

Использование Final State (см. Примечание 1)

>Include Table F.7.2-1d “Modality Performed Procedure Step Simple Code Value Macro with N-SET, Mandatory Meaning”

Equivalent Code Sequence

(0008,0121)

3/3

3/3

>Include Table F.7.2-1d “Modality Performed Procedure Step Simple Code Value Macro with N-SET, Mandatory Meaning”


Таблица F.7.2-1d. Макрос Simple Code Value для Modality Performed Procedure Step с N-SET, обязательное значение (Mandatory Meaning)

Имя атрибута

Tag

Использование N-CREATE (SCU/SCP)

Использование N-SET (SCU/SCP)

Использование Final State (см. Примечание 1)

Code Value

(0008,0100)

1C/1C

Должно присутствовать, если длина значения кода составляет 16 символов или менее, и значение кода не является URN или URL.

3/1C

Должно присутствовать, если длина значения кода составляет 16 символов или менее, и значение кода не является URN или URL.

Coding Scheme Designator

(0008,0102)

1C/1C

Должно присутствовать, если присутствует Code Value (0008,0100) или Long Code Value (0008,0119). Может присутствовать в остальных случаях.

1C/1C

Должно присутствовать, если присутствует Code Value (0008,0100) или Long Code Value (0008,0119). Может присутствовать в остальных случаях.

Coding Scheme Version

(0008,0103)

1C/1C

Должно присутствовать, если значение Coding Scheme Designator (0008,0102) присутствует и недостаточно для однозначной идентификации Code Value (0008,0100), Long Code Value (0008,0119) или URN Code Value (0008,0120). Не должно присутствовать, если Coding Scheme Designator (0008,0102) отсутствует. Может присутствовать в остальных случаях.

1C/1C

Должно присутствовать, если значение Coding Scheme Designator (0008,0102) присутствует и недостаточно для однозначной идентификации Code Value (0008,0100), Long Code Value (0008,0119) или URN Code Value (0008,0120). Не должно присутствовать, если Coding Scheme Designator (0008,0102) отсутствует. Может присутствовать в остальных случаях.

Code Meaning

(0008,0104)

1/1

1/1

Long Code Value

(0008,0119)

1C/1C

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода не является URN или URL.

3/1C

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода не является URN или URL.

URN Code Value

(0008,0120)

1C/1C

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода является URN или URL.

3/1C

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода является URN или URL.

Mapping Resource

(0008,0105)

3/3

3/3

Mapping Resource UID

(0008,0118)

3/3

3/3

Context Group Version

(0008,0106)

3/3

3/3

Context Group Extension Flag

(0008,010B)

3/3

3/3

Context Group Local Version

(0008,0107)

3/3

3/3

Context Group Extension Creator UID

(0008,010D)

3/3

3/3


Таблица F.7.2-1e. Макрос Enhanced Code Value для Modality Performed Procedure Step с N-SET, необязательное значение (Optional Meaning)

Имя атрибута

Tag

Использование N-CREATE (SCU/SCP)

Использование N-SET (SCU/SCP)

Использование Final State (см. Примечание 1)

>Include Table F.7.2-1f “Modality Performed Procedure Step Simple Code Value Macro with N-SET, Optional Meaning”

Equivalent Code Sequence

(0008,0121)

3/3

3/3

>Include Table F.7.2-1f “Modality Performed Procedure Step Simple Code Value Macro with N-SET, Optional Meaning”


Таблица F.7.2-1f. Макрос Simple Code Value для Modality Performed Procedure Step с N-SET, необязательное значение (Optional Meaning)

Имя атрибута

Tag

Использование N-CREATE (SCU/SCP)

Использование N-SET (SCU/SCP)

Использование Final State (см. Примечание 1)

Code Value

(0008,0100)

1C/1C

Должно присутствовать, если длина значения кода составляет 16 символов или менее, и значение кода не является URN или URL.

3/1C

Должно присутствовать, если длина значения кода составляет 16 символов или менее, и значение кода не является URN или URL.

Coding Scheme Designator

(0008,0102)

1C/1C

Должно присутствовать, если присутствует Code Value (0008,0100) или Long Code Value (0008,0119). Может присутствовать в остальных случаях.

1C/1C

Должно присутствовать, если присутствует Code Value (0008,0100) или Long Code Value (0008,0119). Может присутствовать в остальных случаях.

Coding Scheme Version

(0008,0103)

1C/1C

Должно присутствовать, если значение Coding Scheme Designator (0008,0102) присутствует и недостаточно для однозначной идентификации Code Value (0008,0100), Long Code Value (0008,0119) или URN Code Value (0008,0120). Не должно присутствовать, если Coding Scheme Designator (0008,0102) отсутствует. Может присутствовать в остальных случаях.

1C/1C

Должно присутствовать, если значение Coding Scheme Designator (0008,0102) присутствует и недостаточно для однозначной идентификации Code Value (0008,0100), Long Code Value (0008,0119) или URN Code Value (0008,0120). Не должно присутствовать, если Coding Scheme Designator (0008,0102) отсутствует. Может присутствовать в остальных случаях.

Code Meaning

(0008,0104)

3/3

3/3

Long Code Value

(0008,0119)

1C/1C

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода не является URN или URL.

3/1C

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода не является URN или URL.

URN Code Value

(0008,0120)

1C/1C

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода является URN или URL.

3/1C

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода является URN или URL.

Mapping Resource

(0008,0105)

3/3

3/3

Mapping Resource UID

(0008,0118)

3/3

3/3

Context Group Version

(0008,0106)

3/3

3/3

Context Group Extension Flag

(0008,010B)

3/3

3/3

Context Group Local Version

(0008,0107)

3/3

3/3

Context Group Extension Creator UID

(0008,010D)

3/3

3/3


Таблица F.7.2-1. Атрибуты N-CREATE, N-SET и Final State класса SOP Modality Performed Procedure Step

Имя атрибута

Tag

Использование N-CREATE (SCU/SCP)

Использование N-SET (SCU/SCP)

Использование Final State (см. Примечание 1)

Specific Character Set

(0008,0005)

1C/1C

(Обязательно, если используется расширенный или заменяющий набор символов)

1C/1C

(Обязательно, если расширенный или заменяющий набор символов используется в атрибуте, который устанавливается)

Связь выполненного этапа процедуры (Performed Procedure Step Relationship)

Scheduled Step Attributes Sequence

(0040,0270)

1/1

Не допускается

>Study Instance UID

(0020,000D)

1/1

Не допускается

>Referenced Study Sequence

(0008,1110)

2/2

Не допускается

>>Referenced SOP Class UID

(0008,1150)

1/1

Не допускается

>>Referenced SOP Instance UID

(0008,1155)

1/1

Не допускается

>Accession Number

(0008,0050)

2/2

Не допускается

>Issuer of Accession Number Sequence

(0008,0051)

3/3

Не допускается

>>Local Namespace Entity ID

(0040,0031)

1C/1C

Обязательно, если Universal Entity ID (0040,0032) отсутствует; может присутствовать в остальных случаях

Не допускается

>>Universal Entity ID

(0040,0032)

1C/1C

Обязательно, если Local Namespace Entity ID (0040,0031) отсутствует; может присутствовать в остальных случаях.

Не допускается

>>Universal Entity ID Type

(0040,0033)

1C/1C

Обязательно, если присутствует Universal Entity ID (0040,0032).

Не допускается

>Placer Order Number/Imaging Service Request

(0040,2016)

3/3

Не допускается

>Order Placer Identifier Sequence

(0040,0026)

3/3

Не допускается

>>Local Namespace Entity ID

(0040,0031)

1C/1C

Обязательно, если Universal Entity ID (0040,0032) отсутствует; может присутствовать в остальных случаях

Не допускается

>>Universal Entity ID

(0040,0032)

1C/1C

Обязательно, если Local Namespace Entity ID (0040,0031) отсутствует; может присутствовать в остальных случаях.

Не допускается

>>Universal Entity ID Type

(0040,0033)

1C/1C

Обязательно, если присутствует Universal Entity ID (0040,0032).

Не допускается

>Filler Order Number/Imaging Service Request

(0040,2017)

3/3

Не допускается

>Order Filler Identifier Sequence

(0040,0027)

3/3

Не допускается

>>Local Namespace Entity ID

(0040,0031)

1C/1C

Обязательно, если Universal Entity ID (0040,0032) отсутствует; может присутствовать в остальных случаях

Не допускается

>>Universal Entity ID

(0040,0032)

1C/1C

Обязательно, если Local Namespace Entity ID (0040,0031) отсутствует; может присутствовать в остальных случаях.

Не допускается

>>Universal Entity ID Type

(0040,0033)

1C/1C

Обязательно, если присутствует Universal Entity ID (0040,0032).

Не допускается

>Requested Procedure ID

(0040,1001)

2/2

Не допускается

>Requested Procedure Code Sequence

(0032,1064)

3/3

Не допускается

>>Include Table F.7.2-1a “Modality Performed Procedure Step Enhanced Code Value Macro with no N-SET”

>Requested Procedure Description

(0032,1060)

2/2

Не допускается

>Scheduled Procedure Step ID

(0040,0009)

2/2

Не допускается

>Scheduled Procedure Step Description

(0040,0007)

2/2

Не допускается

>Scheduled Protocol Code Sequence

(0040,0008)

2/2

Не допускается

>>Include Table F.7.2-1a “Modality Performed Procedure Step Enhanced Code Value Macro with no N-SET”

>>All other Attributes of the Scheduled Protocol Code Sequence

3/3

Не допускается

Patient's Name

(0010,0010)

2/2

Не допускается

Patient ID

(0010,0020)

2/2

Не допускается

Issuer of Patient ID

(0010,0021)

3/3

Не допускается

Issuer of Patient ID Qualifiers Sequence

(0010,0024)

3/3

Не допускается

>Universal Entity ID

(0040,0032)

3/3

Не допускается

>Universal Entity ID Type

(0040,0033)

1C/1C

Обязательно, если присутствует Universal Entity ID (0040,0032).

Не допускается

>All other Attributes of the Issuer of Patient ID Qualifiers Sequence

3/3

Не допускается

Other Patient IDs Sequence

(0010,1002)

3/3

Не допускается

>Patient ID

(0010,0020)

3/3

Не допускается

>Issuer of Patient ID

(0010,0021)

3/3

Не допускается

>Issuer of Patient ID Qualifiers Sequence

(0010,0024)

3/3

Не допускается

>>All other Attributes of the Issuer of Patient ID Qualifiers Sequence

3/3

Не допускается

>Type of Patient ID

(0010,0022)

3/3

Не допускается

Patient's Birth Date

(0010,0030)

2/2

Не допускается

Patient's Sex

(0010,0040)

2/2

Не допускается

Gender Identity Sequence

(0010,0041)

3/3

-/-

>Gender Identity Code Sequence

(0010,0044)

1/1

-/-

>>Include Table F.7.2-1a “Modality Performed Procedure Step Enhanced Code Value Macro with no N-SET”

>Effective Start DateTime

(0040,A034)

3/3

-/-

>Effective Stop DateTime

(0040,A035)

3/3

-/-

>Gender Identity Comment

(0010,0045)

3/3

-/-

Sex Parameters for Clinical Use Category Sequence

(0010,0043)

3/3

-/-

>Sex Parameters for Clinical Use Category Code Sequence

(0010,0046)

1/1

-/-

>>Include Table F.7.2-1a “Modality Performed Procedure Step Enhanced Code Value Macro with no N-SET”

>Effective Start DateTime

(0040,A034)

3/3

-/-

>Effective Stop DateTime

(0040,A035)

3/3

-/-

>Sex Parameters for Clinical Use Category Comment

(0010,0042)

2C/2C

-/-

Required if Sex Parameters for Clinical Use Category Code Sequence (0010,0046) is (131232, DCM, "Specified"). May be present otherwise.

>Sex Parameters for Clinical Use Category Reference

(0010,0047)

2C/2C

-/-

Required if Sex Parameters for Clinical Use Category Code Sequence (0010,0046) is (131232, DCM, "Specified"). May be present otherwise.

Person Names to Use Sequence

(0010,0011)

3/3

-/-

>Name to Use

(0010,0012)

1/1

-/-

>Effective Start DateTime

(0040,A034)

3/3

-/-

>Effective Stop DateTime

(0040,A035)

3/3

-/-

>Name to Use Comment

(0010,0013)

3/3

-/-

Third Person Pronouns Sequence

(0010,0014)

3/3

-/-

>Pronoun Code Sequence

(0010,0015)

1/1

-/-

>>Include Table F.7.2-1a “Modality Performed Procedure Step Enhanced Code Value Macro with no N-SET”

>Effective Start DateTime

(0040,A034)

3/3

-/-

>Effective Stop DateTime

(0040,A035)

3/3

-/-

>Pronoun Comment

(0010,0016)

3/3

-/-

Referenced Patient Sequence

(0008,1120)

2/2

Не допускается

>Referenced SOP Class UID

(0008,1150)

1/1

Не допускается

>Referenced Instance UID

(0008,1155)

1/1

Не допускается

Admission ID

(0038,0010)

3/3

-/-

Issuer of Admission ID Sequence

(0038,0014)

3/3

Не допускается

>Local Namespace Entity ID

(0040,0031)

1C/1C

Обязательно, если Universal Entity ID (0040,0032) отсутствует; может присутствовать в остальных случаях

Не допускается

>Universal Entity ID

(0040,0032)

1C/1C

Обязательно, если Local Namespace Entity ID (0040,0031) отсутствует; может присутствовать в остальных случаях.

Не допускается

>Universal Entity ID Type

(0040,0033)

1C/1C

Обязательно, если присутствует Universal Entity ID (0040,0032).

Не допускается

Service Episode ID

(0038,0060)

3/3

Не допускается

Issuer of Service Episode ID Sequence

(0038,0064)

3/3

Не допускается

>Local Namespace Entity ID

(0040,0031)

1C/1C

Обязательно, если Universal Entity ID (0040,0032) отсутствует; может присутствовать в остальных случаях

Не допускается

>Universal Entity ID

(0040,0032)

1C/1C

Обязательно, если Local Namespace Entity ID (0040,0031) отсутствует; может присутствовать в остальных случаях.

Не допускается

>Universal Entity ID Type

(0040,0033)

1C/1C

Обязательно, если присутствует Universal Entity ID (0040,0032).

Не допускается

Service Episode Description

(0038,0062)

3/3

Не допускается

Информация о выполненном этапе процедуры (Performed Procedure Step Information)

Performed Procedure Step ID

(0040,0253)

1/1

Не допускается

Performed Station AE Title

(0040,0241)

1/1

Не допускается

Performed Station Name

(0040,0242)

2/2

Не допускается

Performed Location

(0040,0243)

2/2

Не допускается

Performed Procedure Step Start Date

(0040,0244)

1/1

Не допускается

Performed Procedure Step Start Time

(0040,0245)

1/1

Не допускается

Performed Procedure Step Status

(0040,0252)

1/1

3/1

Performed Procedure Step Description

(0040,0254)

2/2

3/2

Performed Procedure Type Description

(0040,0255)

2/2

3/2

Procedure Code Sequence

(0008,1032)

2/2

3/2

>Include Table F.7.2-1e “Modality Performed Procedure Step Enhanced Code Value Macro with N-SET, Optional Meaning”

Reason For Performed Procedure Code Sequence

(0040,1012)

3/3

3/3

>Include Table F.7.2-1c “Modality Performed Procedure Step Enhanced Code Value Macro with N-SET, Mandatory Meaning”

Performed Procedure Step End Date

(0040,0250)

2/2

3/1

1

Performed Procedure Step End Time

(0040,0251)

2/2

3/1

1

Comments on the Performed Procedure Step

(0040,0280)

3/3

3/3

Performed Procedure Step Discontinuation Reason Code Sequence

(0040,0281)

3/3

3/3

>Include Table F.7.2-1c “Modality Performed Procedure Step Enhanced Code Value Macro with N-SET, Mandatory Meaning”

Image Acquisition Results

Modality

(0008,0060)

1/1

Не допускается

Study ID

(0020,0010)

2/2

Не допускается

Performed Protocol Code Sequence

(0040,0260)

2/2

3/2

>Include Table F.7.2-1e “Modality Performed Procedure Step Enhanced Code Value Macro with N-SET, Optional Meaning”

>All other Attributes of the Performed Protocol Code Sequence

3/3

Не допускается

Performed Series Sequence

(0040,0340)

2/2

3/1

1

(see Note 2)

>Performing Physician's Name

(0008,1050)

2/2

2/2

>Protocol Name

(0018,1030)

1/1

1/1

>Operators' Name

(0008,1070)

2/2

2/2

>Series Instance UID

(0020,000E)

1/1

1/1

>Series Description

(0008,103E)

2/2

2/2

>Retrieve AE Title

(0008,0054)

2/2

2/2

>Archive Requested

(0040,A494)

3/3

3/3

>Referenced Image Sequence

(0008,1140)

2/2

2/2

См. Section F.7.2.2.2

>>Referenced SOP Class UID

(0008,1150)

1/1

1/1

>>Referenced SOP Instance UID

(0008,1155)

1/1

1/1

>>Container Identifier

(0040,0512)

3/3

3/3

>>Specimen Description Sequence

(0040,0560)

3/3

3/3

>>>Specimen Identifier

(0040,0551)

1/1

1/1

>>>Specimen UID

(0040,0554)

1/1

1/1

>Referenced Non-Image Composite SOP Instance Sequence

(0040,0220)

2/2

2/2

См. Section F.7.2.2.2

>>Referenced SOP Class UID

(0008,1150)

1/1

1/1

>>Referenced SOP Instance UID

(0008,1155)

1/1

1/1

>All other Attributes of the Performed Series Sequence

3/3

3/3

Код учёта и управления материалами (Billing and Material Management Code)

All Attributes of the Billing and Material Management Code Module

3/3

3/3


Примечание

  1. Требование для конечного состояния — это то, которое применяется в момент, когда Performed Procedure Step Status (0040,0252) устанавливается (N-SET) в значение COMPLETED или DISCONTINUED, как описано в Разделе F.7.2.2.2. Оно описывается только в том случае, если оно отличается от требования SCP для N-CREATE.

  2. Performed Series Sequence (0040,0340) не может быть пустым (нулевой длины) в момент, когда Performed Procedure Step Status (0040,0252) устанавливается (N-SET) в значение COMPLETED или DISCONTINUED. Иными словами, для каждого выполненного этапа процедуры (Performed Procedure Step) должна существовать Series, хотя она может не содержать изображений (Images) или объектов Non-Image Composite, если ни one не были созданы, как описано в Разделе F.7.2.2.2.

  3. Атрибуты (0040,1006) Placer Order Number/Procedure и (0040,1007) Filler Order Number/Procedure были ранее определены в DICOM. Они были выведены из употребления (см. PS3.3-1998).

  4. Атрибуты (0040,2006) и (0040,2007) были ранее определены в DICOM. Они были выведены из употребления (см. PS3.3-1998).

  5. Только те атрибуты, которые указаны в SOP Instance при N-CREATE, могут впоследствии быть обновлены посредством N-SET. Если SCU желает использовать PPS Discontinuation Reason Code Sequence (0040,0281), он должен создать этот атрибут (нулевой длины) во время N-CREATE.

  6. Модуль Radiation Dose был ранее определён в DICOM. Он был выведен из употребления (см. PS3.3-2017c).

F.7.2.1.2 Пользователь класса сервиса

SCU должен указать в примитиве запроса N-CREATE SOP Class UID и SOP Instance UID экземпляра Modality Performed Procedure Step SOP Instance, который создаётся и для которого предоставляются значения атрибутов.

Примечание

Это требование облегчает включение релевантных атрибутов в Composite SOP Instances, формируемые во время выполненного этапа процедуры (Performed Procedure Step).

SCU должен предоставить значения атрибутов для атрибутов класса Modality Performed Procedure Step SOP Class, как указано в Таблице F.7.2-1. Кроме того, могут быть предоставлены значения для дополнительных атрибутов Modality Performed Procedure Step IOD, поддерживаемых SCP. Правила кодирования атрибутов Modality Performed Procedure Step указаны в спецификации примитива запроса N-CREATE в PS3.7.

SCU должен быть способен предоставить SCP все обязательные значения атрибутов в примитиве запроса N-CREATE. SCU может предоставлять значения атрибутов для дополнительных атрибутов, которые не поддерживаются SCP. В этом случае SCU должен функционировать должным образом независимо от того, принимает SCP значения этих атрибутов или нет.

Все атрибуты должны быть созданы, прежде чем они смогут быть установлены. Атрибуtы-последовательности (Sequence Attributes) должны быть созданы до того, как они смогут быть заполнены. Атрибуты элементов последовательности (Sequence Item Attributes) не должны создаваться нулевой длины.

Примечание

Не все атрибуты, которые могут быть созданы, могут быть впоследствии установлены (см. Таблицу F.7.2-1).

SCU должен отправлять примитив запроса N-CREATE только со значением атрибута «Performed Procedure Step Status» (0040,0252), равным «IN PROGRESS».

Примечание

  1. Предполагается (но не требуется), что SCU (модальность) получил Study Instance UID в рамках Basic Worklist Management SOP Class.

  2. Если SCU объединил несколько Requested Procedures в один выполненный этап процедуры (performed step), атрибут Study Instance UID (0020,000D) в Scheduled Step Attributes Sequence (0040,0270) может быть Study Instance UID (0020,000D) для исследования, которое содержит все изображения и non-image composite instances, созданные во время выполнения текущего этапа. Это значение может быть сгенерировано SCU и может быть одинаковым для всех элементов последовательности. Кроме того, Referenced Study Sequence (0008,1110) может содержать Study Instance UID из объединяемых Requested Procedures. Если Referenced Study Sequence (0008,1110) присутствует с элементом (Item), в Referenced SOP Class UID (0008,1150) может использоваться SOP Class UID класса Detached Study Management SOP Class (Retired).

  3. Если у SCU нет доступных данных Scheduled Procedure Step, применимых к текущему этапу, SCU может сгенерировать значение для атрибута Study Instance UID (0020,000D) в Scheduled Step Attributes Sequence (0040,0270). Это значение Study Instance UID (0020,000D) может быть сохранено во всех изображениях и non-image composite SOP instances, созданных во время выполнения данного этапа. Все остальные атрибуты в Scheduled Step Attributes Sequence (0040,0270) могут быть установлены в нулевую длину для типов требований 2/2 или отсутствовать для типов требований 3/3 (см. Таблицу F.7.2-1).

F.7.2.1.3 Поставщик класса сервиса

Операция N-CREATE позволяет SCU предоставить SCP выбранные значения атрибутов для конкретного экземпляра Modality Performed Procedure Step SOP Instance. Эта операция должна вызываться с использованием DIMSE-сервиса N-CREATE в сочетании с соответствующим экземпляром Modality Performed Procedure Step SOP Instance.

SCP должен вернуть через примитив ответа N-CREATE код статуса ответа N-CREATE (N-CREATE Response Status Code), применимый к соответствующему запросу.

SCP должен принимать примитивы запроса N-CREATE только если значение Performed Procedure Step Status (0040,0252) равно «IN PROGRESS». Если Performed Procedure Step Status (0040,0252) имеет другое значение, SCP должен установить код статуса сбоя (Failure Status Code) 0106H «Invalid Attribute Value» со списком атрибутов (Attribute List).

Примечание

SCP может обновлять информацию о расписании, на которой основан Modality Worklist, включая значения Study Date (0008,0020) и Study Time (0008,0030), используя самые ранние соответствующие значения Performed Procedure Step Date (0040,0244) и Performed Procedure Step Time (0040,0245), для достижения согласованности атрибутов уровня исследования (Study level Attributes), когда несколько этапов процедуры выполняются на разных устройствах.

F.7.2.1.4 Коды статусов

Специфические коды статусов отсутствуют. См. PS3.7 для кодов статусов ответа.

F.7.2.2 Установка информации о выполненном этапе процедуры модальности

Эта операция позволяет SCU устанавливать значения атрибутов экземпляра класса Modality Performed Procedure Step SOP Class и предоставлять информацию о конкретном реальном этапе процедуры модальности (Modality Performed Procedure Step), находящемся под управлением SCU. Эта операция должна вызываться через DIMSE-сервис N-SET.

F.7.2.2.1 Спецификация подмножества IOD выполненного этапа процедуры модальности

Прикладной элемент (Application Entity), заявляющий о соответствии данному SOP Class как SCU, может выбрать для изменения подмножество атрибутов, поддерживаемых SCP. Прикладной элемент, заявляющий о соответствии данному SOP Class как SCP, должен поддерживать подмножество атрибутов Modality Performed Procedure Step, указанное в Таблице F.7.2-1.

Набор символов, используемый для значений атрибутов, обновляемых с помощью N-SET, должен совпадать с набором, указанным в примитиве запроса N-CREATE.

F.7.2.2.2 Пользователь класса сервиса

SCU должен указать в примитиве запроса N-SET UID экземпляра Modality Performed Procedure Step SOP Instance, для которого он хочет установить значения атрибутов.

SCU разрешается устанавливать значения атрибутов для любого атрибута класса Modality Performed Procedure Step SOP Class, указанного в Таблице F.7.2-1. SCU должен указать список атрибутов класса Modality Performed Procedure Step SOP Class, для которых он хочет установить значения. SCU должен предоставить одним или несколькими примитивами запроса N-SET значения атрибутов, указанные в Таблице F.7.2-1. Правила кодирования атрибутов Modality Performed Procedure Step указаны в спецификации примитива запроса N-SET в PS3.7. SCU должен устанавливать значения только тех атрибутов, которые уже были созданы запросом N-CREATE.

SCU не должен отправлять примитивы запроса N-SET для экземпляра Modality Performed Procedure Step SOP Instance после того, как был отправлен примитив запроса N-SET со значением атрибута «Performed Procedure Step Status» (0040,0252), равным «COMPLETED» или «DISCONTINUED».

Если последовательности (Sequences) включены в команду N-SET, все элементы (Items) последовательности должны быть включены в команду, а не только те элементы, которые должны быть обновлены.

После того как Modality Performed Procedure Step Status (0040,0252) был установлен в «COMPLETED» или «DISCONTINUED», SCU больше не должен изменять экземпляр Modality Performed Procedure Step SOP Instance и не должен создавать новые Composite SOP Instances в рамках того же экземпляра Modality Performed Procedure Step SOP Instance.

Примечание

Модальность, желающая продолжить или возобновить создание Composite SOP Instances, может создать новый Modality Performed Procedure Step.

До или в момент установки Modality Performed Procedure Step Status (0040,0252) в «COMPLETED» или «DISCONTINUED» SCU должен создать или установить все атрибуты в соответствии с требованиями в столбце Final State (конечное состояние) Таблицы F.7.2-1.

До или в момент установки Modality Performed Procedure Step Status (0040,0252) в «COMPLETED» или «DISCONTINUED» SCU должен отправить SCP список всех Image SOP Instances и всех Non-Image Composite SOP Instances, созданных во время этапа процедуры (Procedure Step), в Referenced Image Sequence (0008,1140) и Referenced Non-Image Composite SOP Instance Sequence (0040,0220) соответственно.

Примечание

  1. Предполагается, что завершённый или прекращённый объект Modality Performed Procedure Step будет содержать полный список всех Image и Non-Image Composite SOP Instances, которые были созданы.

  2. Различие между списками изображений (images) и не-изображений (non-images) присутствует только по историческим причинам и не имеет семантического значения.

Modality Performed Procedure Step Status (0040,0252) не должен устанавливаться в «COMPLETED» или «DISCONTINUED», если список не содержит ни ссылок на Image, ни ссылок на Non-Image Composite SOP Instance, за исключением случая, когда ни одного такого экземпляра (Instance) создано не было.

F.7.2.2.3 Поставщик класса сервиса

Операция N-SET позволяет SCU запросить SCP обновить выбранные значения атрибутов для конкретного экземпляра Modality Performed Procedure Step SOP Instance. Эта операция должна вызываться с использованием DIMSE-сервиса N-SET в сочетании с соответствующим экземпляром Modality Performed Procedure Step SOP Instance. Значение N-SET для Specific Character Set (0008,0005) не заменяет предыдущее значение. SCP должен соответствующим образом изменять своё внутреннее представление так, чтобы последующие операции отражали комбинацию наборов символов, используемых атрибутами в данном N-SET, и тех, что используются атрибутами, которые не были изменены.

Примечание

SCP может потребоваться преобразовать текст, например, в набор символов Unicode. Если SCP не способен выполнить необходимое преобразование, он может вернуть код статуса сбоя (Failure Status Code) 0106H Invalid Attribute Value.

SCP должен вернуть через примитив ответа N-SET код статуса ответа N-SET (N-SET Response Status Code), применимый к соответствующему запросу. В зависимости от статуса ответа N-SET, SCP должен обновить Referenced Performed Procedure Step Attributes.

SCP должен принимать примитивы запроса N-SET только если значение уже существующего Performed Procedure Step Status (0040,0252) равно «IN PROGRESS». Если уже существующее значение Performed Procedure Step Status (0040,0252) имеет другое значение, SCP должен установить код статуса сбоя (Failure Status Code) 0110H «Processing failure» со специфическим Error Comment (см. Раздел F.7.2.2.4).

SCP может самостоятельно изменять любые атрибуты экземпляра Modality Performed Procedure Step SOP Instance только после того, как Performed Procedure Step Status (0040,0252) был установлен в значение «COMPLETED» или «DISCONTINUED».

Примечание

  1. Такое принудительное изменение атрибутов со стороны SCP может потребоваться для исправления, например, идентификационной информации пациента (patient identification) или неверно выбранной информации о расписании (scheduling information). Такая операция не разрешена для SCU согласно требованиям, описанным в Таблице F.7.2-1; вместо этого SCU может создать новый экземпляр Modality Performed Procedure Step SOP Instance для достижения той же цели.

  2. В исключительных обстоятельствах SCP может потребоваться самостоятельно установить Performed Procedure Step Status (0040,0252) в значение COMPLETED или DISCONTINUED — например, при отказе модальности. Когда модальность восстановит работу, последующие запросы N-SET могут завершиться неудачей.

F.7.2.2.4 Коды статусов

Специфические коды статусов отсутствуют. Специфические Error Comment и Error ID, которые могут быть возвращены с кодом статуса Processing Failure в N-SET-RSP, определены в Таблице F.7.2-2. См. PS3.7 для дополнительных кодов статусов ответа.

Table F.7.2-2. N-SET Response Status Values

Статус сервиса

Дополнительное значение

Код статуса

Error Comment (0000,0902)

Error ID (0000,0903)

Сбой

Сбой обработки

0110

Объект Performed Procedure Step больше не может быть обновлён

A710


F.7.3 Modality Performed Procedure Step SOP Class UID

Класс Modality Performed Procedure Step SOP Class должен быть однозначно идентифицирован UID класса Modality Performed Procedure Step SOP Class UID, который должен иметь значение «1.2.840.10008.3.1.2.3.3».

F.7.4 Требования соответствия

Реализации, заявляющие о соответствии классу Modality Performed Procedure Step SOP Class, должны соответствовать требованиям, описанным в следующих разделах, и должны включать в своё Заявление о соответствии (Conformance Statement) информацию, как описано ниже.

Реализация может соответствовать данному SOP Class как SCU или как SCP. Заявление о соответствии (Conformance Statement) должно быть оформлено в соответствии с форматом, определённым в PS3.2.

F.7.4.1 Соответствие SCU

Реализация, соответствующая данному SOP Class как SCU, должна удовлетворять требованиям соответствия для операций, которые она вызывает.

F.7.4.1.1 Операции

Любые атрибуты, для которых SCU может предоставлять значения (с использованием сервиса N-CREATE), должны быть перечислены в Заявлении о соответствии (Conformance Statement).

Любые атрибуты, для которых SCU может предоставлять значения (с использованием сервиса N-SET), должны быть перечислены в Заявлении о соответствии (Conformance Statement).

Реализация, соответствующая данному SOP Class как SCU, должна указать, при каких условиях во время выполнения реального этапа процедуры (Performed Procedure Step) она создаёт экземпляр SOP Class Instance и при каких условиях она устанавливает значение статуса в COMPLETED или DISCONTINUED.

Реализация, соответствующая данному SOP Class как SCU, должна указать, какую стратегию она применяет для группировки экземпляров Storage SOP Class Instances, на которые ссылается выполненный этап процедуры (Performed Procedure Step).

Примечание

Например, отправляются ли экземпляры Radiation Dose SR в рамках того же выполненного этапа процедуры (Performed Procedure Step), что и изображения, к которым они относятся, или в рамках другого выполненного этапа процедуры. См. обсуждение Modality Performed Procedure Step в модели DICOM Real-World Model в PS3.3.

F.7.4.2 Соответствие SCP

Реализация, соответствующая данному SOP Class как SCP, должна удовлетворять требованиям соответствия для операций, которые она выполняет.

F.7.4.2.1 Операции

Любые атрибуты, для которых SCU может предоставлять значения (с использованием сервиса N-CREATE), должны быть перечислены в Заявлении о соответствии (Conformance Statement).

Любые атрибуты, значения которых могут быть обновлены SCU (с использованием сервиса N-SET), должны быть перечислены в Заявлении о соответствии (Conformance Statement).

Заявление о соответствии (Conformance Statement) должно также содержать информацию о поведении SCP при следующих событиях:

  • Создание нового экземпляра класса Modality Performed Procedure Step SOP Class со статусом «IN PROGRESS». Результат этого процесса для информации о расписании (scheduling information) и для значений атрибутов класса Modality Worklist SOP Class должен быть указан.

  • Обновление атрибута «Performed Procedure Step Status», т.е. переход из состояния «IN PROGRESS» в «DISCONTINUED» или «COMPLETED».

  • Какие атрибуты SCP может принудительно изменять (coerce) после того, как состояние было установлено в «IN PROGRESS», «DISCONTINUED» или «COMPLETED».

  • Как долго экземпляр Modality Performed Procedure Step SOP Instance будет сохраняться на SCP.

F.8 Modality Performed Procedure Step Retrieve SOP Class

F.8.1 Группа сервисов DIMSE

DIMSE-сервисы, показанные в Таблице F.8.1-1, применимы к Modality Performed Procedure Step IOD в рамках класса Modality Performed Procedure Step Retrieve SOP Class.

Table F.8.1-1. DIMSE Service Group Applicable to Modality Performed Procedure Step Retrieve

Элемент сервиса DICOM-сообщений (DIMSE)

Использование (SCU/SCP)

N-GET

M/M


DIMSE-сервисы и протоколы специфицированы в PS3.7. Если объект Modality Performed Procedure Step Object больше недоступен, примитив запроса (Request Primitive) будет отвечать кодом статуса сбоя (Failure Status Code) 0112H «No such SOP Instance».

F.8.2 Операции

Прикладной элемент (Application Entity), заявляющий о соответствии данному SOP Class как SCU, должен иметь право вызывать следующие операции, а прикладной элемент, заявляющий о соответствии как SCP, должен быть способен предоставлять следующие операции.

F.8.2.1 Получение информации о выполненном этапе процедуры

Эта операция позволяет SCU получить информацию о конкретном реальном этапе процедуры (Performed Procedure Step), который представлен как экземпляр Modality Performed Procedure Step Retrieve SOP Instance, предоставляемый SCP класса Modality Performed Procedure Step Retrieve. Операция выполняется над Modality Performed Procedure Step IOD. Эта операция должна вызываться с использованием DIMSE-сервиса N-GET в сочетании с соответствующим экземпляром Modality Performed Procedure Step Retrieve SOP Instance.

Один и тот же SOP Instance UID является общим для всех трёх классов Modality Performed Procedure Step SOP Class. Это означает, что SOP Instance, созданный и установленный с использованием сервисов класса Modality Performed Procedure Step SOP Class, может быть получен (retrieved) с использованием его SOP Instance UID в рамках сервиса класса Modality Performed Procedure Step Retrieve SOP Class. Изменения его состояния могут быть доведены до сведения с использованием его SOP Instance UID в рамках сервиса класса Modality Performed Procedure Step Notification SOP Class. SOP Class UID, указываемый в примитиве запроса DIMSE N-GET, должен быть UID класса Modality Performed Procedure Step Retrieve SOP Class.

Примечание

Прикладной элемент (Application Entity) может поддерживать роль SCU класса Modality Performed Procedure Step Retrieve SOP Class для получения информации о выполненных этапах процедуры (Performed Procedure Steps), созданных другими прикладными элементами.

F.8.2.1.1 Спецификации подмножества IOD для извлечения выполненного этапа процедуры модальности

Прикладной элемент (Application Entity), заявляющий о соответствии данному SOP Class как SCU, может интерпретировать значения атрибутов, поддерживаемых SCP, которые SCU получает посредством операции данного SOP Class. Прикладной элемент, заявляющий о соответствии данному классу Modality Performed Procedure Step Retrieve SOP Class как SCP, должен поддерживать подмножество атрибутов Modality Performed Procedure Step Retrieve, указанное в Таблице F.8.2-1.

Table F.8.2-1. Modality Performed Procedure Step Retrieve SOP Class N-GET Attributes

Имя атрибута

Tag

Использование (SCU/SCP)

Specific Character Set

(0008,0005)

3/1C

(Обязательно, если используется расширенный или заменяющий набор символов)

Связь выполненного этапа процедуры (Performed Procedure Step Relationship)

Scheduled Step Attributes Sequence

(0040,0270)

3/1

>Study Instance UID

(0020,000D)

-/1

>Referenced Study Sequence

(0008,1110)

-/2

>>Referenced SOP Class UID

(0008,1150)

-/1

>>Referenced SOP Instance UID

(0008,1155)

-/1

>Accession Number

(0008,0050)

-/2

>Issuer of Accession Number Sequence

(0008,0051)

-/3

>>Local Namespace Entity ID

(0040,0031)

-/3

>>Universal Entity ID

(0040,0032)

-/3

>>Universal Entity ID Type

(0040,0033)

-/3

>Placer Order Number/Imaging Service Request

(0040,2016)

-/3

>Order Placer Identifier Sequence

(0040,0026)

-/3

>>Local Namespace Entity ID

(0040,0031)

-/3

>>Universal Entity ID

(0040,0032)

-/3

>>Universal Entity ID Type

(0040,0033)

-/3

>Filler Order Number/Imaging Service Request

(0040,2017)

-/3

>Order Filler Identifier Sequence

(0040,0027)

-/3

>>Local Namespace Entity ID

(0040,0031)

-/3

>>Universal Entity ID

(0040,0032)

-/3

>>Universal Entity ID Type

(0040,0033)

-/3

>Requested Procedure Code Sequence

(0032,1064)

-/3

>>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support”

>Requested Procedure Description

(0032,1060)

-/2

>Requested Procedure ID

(0040,1001)

-/2

>Scheduled Procedure Step ID

(0040,0009)

-/2

>Scheduled Procedure Step Description

(0040,0007)

-/2

>Scheduled Protocol Code Sequence

(0040,0008)

-/2

>>Include Table 8-5a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and Optional Meaning for SCP”

>>All other Attributes of the Scheduled Protocol Code Sequence

-/3

Patient's Name

(0010,0010)

3/2

Patient ID

(0010,0020)

3/2

Issuer of Patient ID

(0010,0021)

3/3

Issuer of Patient ID Qualifiers Sequence

(0010,0024)

3/3

>Universal Entity ID

(0040,0032)

3/3

>Universal Entity ID Type

(0040,0033)

1C/1C

Обязательно, если присутствует Universal Entity ID (0040,0032).

>All other Attributes of the Issuer of Patient ID Qualifiers Sequence

3/3

Patient's Birth Date

(0010,0030)

3/2

Patient's Sex

(0010,0040)

3/2

Gender Identity Sequence

(0010,0041)

3/3

>Gender Identity Code Sequence

(0010,0044)

-/1

>>Include Table 8-2a “Enhanced Coded Entry Macro with Optional Matching Key Support and Optional Meaning”

>Effective Start DateTime

(0040,A034)

-/3

>Effective Stop DateTime

(0040,A035)

-/3

>Gender Identity Comment

(0010,0045)

-/3

Sex Parameters for Clinical Use Category Sequence

(0010,0043)

3/3

>Sex Parameters for Clinical Use Category Code Sequence

(0010,0046)

-/1

>>Include Table 8-2a “Enhanced Coded Entry Macro with Optional Matching Key Support and Optional Meaning”

>Effective Start DateTime

(0040,A034)

-/3

>Effective Stop DateTime

(0040,A035)

-/3

>Sex Parameters for Clinical Use Category Comment

(0010,0042)

-/3

>Sex Parameters for Clinical Use Category Reference

(0010,0047)

-/3

Person Names to Use Sequence

(0010,0011)

3/3

>Name to Use

(0010,0012)

-/1

>Effective Start DateTime

(0040,A034)

-/3

>Effective Stop DateTime

(0040,A035)

-/3

>Name to Use

(0010,0012)

-/3

Third Person Pronouns Sequence

(0010,0014)

3/3

>Pronoun Code Sequence

(0010,0015)

-/1

>>Include Table 8-2a “Enhanced Coded Entry Macro with Optional Matching Key Support and Optional Meaning”

>Effective Start DateTime

(0040,A034)

-/3

>Effective Stop DateTime

(0040,A035)

-/3

>Pronoun Comment

(0010,0016)

-/3

Referenced Patient Sequence

(0008,1120)

3/2

>Referenced SOP Class UID

(0008,1150)

-/1

>Referenced Instance UID

(0008,1155)

-/1

Admission ID

(0038,0010)

3/3

Issuer of Admission ID Sequence

(0038,0014)

3/3

>Local Namespace Entity ID

(0040,0031)

-/3

>Universal Entity ID

(0040,0032)

-/3

>Universal Entity ID Type

(0040,0033)

-/3

Service Episode ID

(0038,0060)

3/3

Issuer of Service Episode ID Sequence

(0038,0064)

3/3

>Local Namespace Entity ID

(0040,0031)

-/3

>Universal Entity ID

(0040,0032)

-/3

>Universal Entity ID Type

(0040,0033)

-/3

Service Episode Description

(0038,0062)

3/3

Performed Procedure Step Information

Performed Station AE Title

(0040,0241)

3/1

Performed Station Name

(0040,0242)

3/2

Performed Location

(0040,0243)

3/2

Performed Procedure Step Start Date

(0040,0244)

3/1

Performed Procedure Step Start Time

(0040,0245)

3/1

Performed Procedure Step ID

(0040,0253)

3/1

Performed Procedure Step Status

(0040,0252)

3/1

Performed Procedure Step End Date

(0040,0250)

3/2

Performed Procedure Step End Time

(0040,0251)

3/2

Performed Procedure Step Description

(0040,0254)

3/2

Performed Procedure Type Description

(0040,0255)

3/2

Procedure Code Sequence

(0008,1032)

3/2

>Include Table 8-5a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and Optional Meaning for SCP”

Comments on the Performed Procedure Step

(0040,0280)

3/3

Performed Procedure Step Discontinuation Reason Code Sequence

(0040,0281)

3/2

>Include Table 8-5a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and Optional Meaning for SCP”

Image Acquisition Results

Performed Series Sequence

(0040,0340)

3/2

>Performing Physician's Name

(0008,1050)

-/2

>Protocol Name

(0018,1030)

-/1

>Operators' Name

(0008,1070)

-/2

>Series Instance UID

(0020,000E)

-/1

>Series Description

(0008,103E)

-/2

>Retrieve AE Title

(0008,0054)

-/2

>Referenced Image Sequence

(0008,1140)

-/2

>>Referenced SOP Class UID

(0008,1150)

-/1

>>Referenced SOP Instance UID

(0008,1155)

-/1

>Referenced Non-Image Composite SOP Instance Sequence

(0040,0220)

-/2

>>Referenced SOP Class UID

(0008,1150)

-/1

>>Referenced SOP Instance UID

(0008,1155)

-/1

>All other Attributes of the Performed Series Sequence

-/3

Modality

(0008,0060)

3/1

Study ID

(0020,0010)

3/2

Performed Protocol Code Sequence

(0040,0260)

3/2

>Include Table 8-5a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and Optional Meaning for SCP”

>All other Attributes of the Performed Protocol Code Sequence

-/3

Код биллинга и управления материалами

All Attributes of the Billing and Material Management Code Module

3/3


Примечание

  1. Атрибуты (0040,1006) Placer Order Number/Procedure и (0040,1007) Filler Order Number/Procedure были ранее определены в DICOM. Они были выведены из употребления (см. PS3.3-1998).

  2. Атрибуты (0040,2006) и (0040,2007) были ранее определены в DICOM. Они были выведены из употребления (см. PS3.3-1998).

  3. Модуль Radiation Dose был ранее определён в DICOM. Он был выведен из употребления (см. PS3.3-2017c).

F.8.2.1.2 Пользователь сервисного класса

SCU использует служебный элемент N-GET для запроса SCP на получение экземпляра SOP модальности «Получение выполненного этапа процедуры» (Modality Performed Procedure Step Retrieve SOP Instance). SCU должен указать в примитиве запроса N-GET UID SOP-экземпляра, подлежащего получению, который является UID SOP-экземпляра выполненного этапа процедуры модальности. SCU имеет право запрашивать возврат значений атрибутов для любого атрибута SOP-класса получения выполненного этапа процедуры модальности, указанного в Таблице F.8.2-1. Кроме того, могут быть запрошены значения дополнительных атрибутов IOD выполненного этапа процедуры модальности.

SCU должен указать список атрибутов SOP-класса получения выполненного этапа процедуры модальности, для которых должны быть возвращены значения. Правила кодирования атрибутов выполненного этапа процедуры модальности указаны в спецификации примитива запроса N-GET в PS3.7.

В операции N-GET значения атрибутов, определённых внутри последовательности элементов (Sequence of Items), не могут быть запрошены SCU.

SCU должен быть способен принимать все запрошенные значения атрибутов, предоставленные SCP в ответ на примитив индикации N-GET. SCU может запрашивать значения атрибутов для дополнительных атрибутов, которые не поддерживаются SCP. В этом случае SCU должен функционировать должным образом независимо от того, возвращает SCP значения для этих атрибутов или нет. Настоящая спецификация сервисного класса не предъявляет требований к тому, что SCU должен сделать в результате получения этой информации.

Примечание

Для точной интерпретации набора символов, используемого для возвращаемых значений атрибутов, рекомендуется запрашивать значение атрибута Specific Character Set (0008,0005) в примитиве запроса N-GET.

F.8.2.1.3 Поставщик сервисного класса

Операция N-GET позволяет SCU запросить у SCP выбранные значения атрибутов для конкретного SOP-экземпляра выполненного этапа процедуры модальности через SOP-экземпляр получения выполненного этапа процедуры модальности. Эта операция должна быть вызвана посредством службы DIMSE N-GET, используемой совместно с соответствующим SOP-экземпляром получения выполненного этапа процедуры модальности, который равен SOP-экземпляру выполненного этапа процедуры модальности. SCP должен получить выбранные значения атрибутов из указанного SOP-экземпляра выполненного этапа процедуры модальности.

SCP должен вернуть через примитив ответа N-GET код состояния ответа N-GET, применимый к соответствующему запросу. Статус «Отказ» (Failure) должен указывать на то, что SCP не получил SOP-экземпляр. В зависимости от статуса ответа N-GET, SCP должен вернуть через примитив ответа N-GET значения атрибутов для всех запрошенных атрибутов, поддерживаемых SCP.

F.8.2.1.4 Коды состояния

Таблица F.8.2-2 определяет конкретные значения кодов состояния, которые могут быть возвращены в ответе N-GET. См. PS3.7 для дополнительных кодов состояния ответа.

Таблица F.8.2-2. Значения состояния ответа N-GET

Статус службы

Дополнительное значение

Status Code

Предупреждение

Запрошенные дополнительные атрибуты не поддерживаются

0001


F.8.3 UID SOP-класса получения выполненного этапа процедуры модальности

SOP-класс получения выполненного этапа процедуры модальности должен быть однозначно идентифицирован UID SOP-класса получения выполненного этапа процедуры модальности, который должен иметь значение "1.2.840.10008.3.1.2.3.4".

F.8.4 Требования соответствия

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

Реализация может соответствовать этому SOP-классу как SCU или как SCP. Заявление о соответствии должно быть составлено в формате, определённом в PS3.2.

F.8.4.1 Соответствие SCU

Реализация, соответствующая этому SOP-классу как SCU, должна удовлетворять требованиям соответствия для операций, которые она инициирует.

F.8.4.1.1 Операции

Любые атрибуты, для значений которых могут быть запрошены SCU (с использованием службы N-GET), должны быть перечислены в заявлении о соответствии. Заявление о соответствии должно быть составлено в формате, определённом в PS3.2.

F.8.4.2 Соответствие SCP

Реализация, соответствующая этому SOP-классу как SCP, должна удовлетворять требованиям соответствия для операций, которые она выполняет.

F.8.4.2.1 Операции

Любые атрибуты, для значений которых могут быть запрошены SCU (с использованием службы N-GET), должны быть перечислены в заявлении о соответствии. Заявление о соответствии должно быть составлено в формате, определённом в PS3.2.

F.9 SOP-класс уведомлений о выполненном этапе процедуры модальности

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

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

Примечание

  1. Например, в одной конфигурации ИС может отвечать за ведение данных, связанных с выполненными этапами процедуры. Рабочая станция просмотра PACS может потребовать отображения изображений для любого просматриваемого исследования. Чтобы PACS мог связать изображения с исследованием, PACS может получать уведомление при каждом выполнении этапа процедуры. В такой конфигурации ИС является SCP, а PACS — SCU. Когда PACS получает это уведомление, он может связать изображения и выполненный этап процедуры с исследованием в своей внутренней базе данных или может не предпринимать никаких действий.

  2. Термины ИС и PACS, использованные в предыдущем примере, приведены исключительно для пояснения. Настоящий документ не определяет и не ограничивает назначение или роль какого-либо ИС, PACS или прикладной сущности получения, соответствующей настоящей спецификации сервисного класса.

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

F.9.1 Группа служб DIMSE

Таблица F.9.1-1 показывает службы DIMSE-N, применимые к IOD выполненного этапа процедуры модальности в рамках SOP-класса уведомлений о выполненном этапе процедуры модальности.

Службы и протоколы DIMSE-N определены в PS3.7.

Таблица F.9.1-1. Группа служб DIMSE, применимая к уведомлению о выполненном этапе процедуры модальности

Элемент службы сообщений DICOM

Использование (SCU/SCP)

N-EVENT-REPORT

M/M


F.9.2 Уведомления

Прикладная сущность, заявляющая о соответствии как SCU этому SOP-классу, должна иметь право получать следующее уведомление. Прикладная сущность, заявляющая о соответствии как SCP этому SOP-классу, должна быть способна предоставлять уведомления, определённые в Таблице F.9.2-1.

Таблица F.9.2-1. Информация о событии уведомления выполненного этапа процедуры

Имя типа события

Идентификатор типа события

Имя атрибута

Tag

Использование (SCP)

Выполненный этап процедуры — в процессе

1

Выполненный этап процедуры — завершён

2

Выполненный этап процедуры — отменён

3

Выполненный этап процедуры — обновлён

4

Событие обновления не должно использоваться для уведомления об изменениях Performed Procedure Step Status (0040,0252).

Выполненный этап процедуры — удалён

5


Примечание

Информация о событии уведомления не содержит атрибутов, помимо определённых в PS3.7. SCU, получающий уведомление и нуждающийся в дополнительной информации, может также быть SCU SOP-класса получения выполненного этапа процедуры модальности и может использовать Affected SOP Instance UID (0000,1000) для выполнения N-GET SOP-экземпляра выполненного этапа процедуры модальности.

F.9.2.1 Получение уведомления о событии выполненного этапа процедуры модальности

Это уведомление позволяет SCU получать от SCP незапрошенное уведомление об изменении SOP-экземпляра выполненного этапа процедуры модальности. Эти уведомления должны инициироваться SCP посредством службы DIMSE N-EVENT-REPORT, используемой совместно с соответствующим SOP-экземпляром выполненного этапа процедуры модальности.

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

Один и тот же UID SOP-экземпляра является общим для всех трёх SOP-классов выполненного этапа процедуры модальности. Это означает, что SOP-экземпляр, созданный и заданный с использованием служб SOP-класса выполненного этапа процедуры модальности, может быть получен с использованием его SOP Instance UID в рамках службы SOP-класса получения выполненного этапа процедуры модальности. Об изменениях его состояния можно уведомлять, используя его SOP Instance UID в примитиве запроса SOP-класса уведомлений о выполненном этапе процедуры модальности.

F.9.2.2 Предоставление уведомления о событии выполненного этапа процедуры модальности

Эти уведомления позволяют SCU получать от SCP незапрошенное уведомление об изменении состояния реального выполненного этапа процедуры. Это уведомление должно инициироваться SCP посредством службы DIMSE N-EVENT-REPORT, используемой совместно с соответствующим SOP-экземпляром выполненного этапа процедуры модальности.

SCP должен указать в примитиве запроса N-EVENT-REPORT UID SOP-экземпляра выполненного этапа процедуры модальности, с которым связано событие, и идентификатор типа события. Affected SOP Class UID, указанный в примитиве запроса DIMSE N-EVENT-REPORT, должен быть UID SOP-класса уведомлений о выполненном этапе процедуры модальности.

Примечание

Кодирование информации о событии уведомления определено в PS3.7.

F.9.2.3 Коды состояния

Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.

F.9.3 UID SOP-класса уведомлений о выполненном этапе процедуры модальности

SOP-класс уведомлений о выполненном этапе процедуры модальности должен быть однозначно идентифицирован UID SOP-класса уведомлений о выполненном этапе процедуры модальности, который должен иметь значение "1.2.840.10008.3.1.2.3.5".

F.9.4 Требования соответствия

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

Реализация может соответствовать этому SOP-классу как SCU, SCP или обоим. Заявление о соответствии должно быть составлено в формате, определённом в PS3.2.

F.9.4.1 Соответствие SCU

Реализация, соответствующая этому SOP-классу как SCU, должна удовлетворять требованиям соответствия для:

  • уведомлений, которые она получает

F.9.4.1.1 Уведомления

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

  • Выполненный этап процедуры — в процессе

  • Выполненный этап процедуры — завершён

  • Выполненный этап процедуры — отменён

  • Выполненный этап процедуры — обновлён

  • Выполненный этап процедуры — удалён

F.9.4.2 Соответствие SCP

Реализация, соответствующая этому SOP-классу как SCP, должна удовлетворять требованиям соответствия для:

  • уведомлений, которые она инициирует

F.9.4.2.1 Уведомления

Любые дополнительные атрибуты, которые могут быть включены в стандартные уведомления для SCU, должны быть перечислены в заявлении о соответствии. Заявление о соответствии должно быть составлено в формате, определённом в PS3.2. За этим заявлением должен следовать список типов событий и дополнительных атрибутов.

F.10 SOP-класс запланированного этапа процедуры общего назначения (выведен из употребления)

Выведен из употребления. См. PS3.4-2011.

F.11 SOP-класс выполненного этапа процедуры общего назначения (выведен из употребления)

Выведен из употребления. См. PS3.4-2011.

G Сервисный класс управления результатами

Выведен из употребления. См. PS3.4-2004.

H Сервисный класс управления печатью

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

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

Примечание

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

H.2 Модель управления печатью

H.2.1 Модель потока данных управления печатью

H.2.1.1 Глобальная модель потока данных

Модель потока данных управления печатью (Рисунок H.2-1) состоит из трёх основных процессов:

  • процесс управления сеансом плёнки

  • процесс печати

Примечание

В стандарте используется слово «плёнка» как общее наименование для различных типов носителей твёрдых копий (например, фотоплёнка, бумага).

Print Management Data Flow Model

Рисунок H.2-1. Модель потока данных управления печатью


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

Каждая плёнка состоит из одного или нескольких изображений и нуля или более аннотаций, связанных с плёнкой. Аннотация состоит из одной или нескольких строк текста.

Каждое изображение состоит из данных пикселей и нуля или более плоскостей наложения (overlay planes). Пользователь управляет видом плёнки, задавая значения параметров печати.

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

Входными данными процесса управления сеансом плёнки являются:

  • набор изображений и связанных с ними данных

  • данные представления, описывающие визуальный вид плёнок

Выходными данными процесса управления сеансом плёнки является задание печати (Print Job), которое содержит всю информацию для печати сеанса плёнки.

Процесс печати печатает набор плёнок на основе информации в задании печати. Процесс печати зависит от реализации, и его управление выходит за рамки стандарта DICOM.

H.2.1.2 Преобразования в градациях серого

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

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

Последовательность преобразований в градациях серого имеет важное значение для достижения стабильного качества изображений из-за неортогонального характера различных преобразований. Рисунок H.2-2 описывает последовательность преобразований в градациях серого.

Примечание

Этот раздел ранее содержал более подробное описание преобразований Modality LUT и VOI LUT. Поскольку Referenced Print SOP Classes были выведены из употребления, эти описания больше не применимы к сервисному классу управления печатью. См. PS3.4-1998.

Print Management Data Flow Model

Рисунок H.2-2. Модель потока данных управления печатью


H.2.1.2.1 Преобразования, зависящие от модальности и пользователя

Примерами таких преобразований являются Modality LUT, вычитание маски (Mask Subtraction) и VOI LUT.

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

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

H.2.1.2.2 Полярность

Полярность (Polarity) определяет, должны ли минимальные входные значения пикселей отображаться как чёрные или белые. Если Polarity (2020,0020) имеет значение NORMAL, пиксели отображаются в соответствии с Photometric Interpretation; если Polarity имеет значение REVERSE, пиксели отображаются с противоположной полярностью, как указано Photometric Interpretation.

Polarity (2020,0020) является атрибутом IOD блока изображения (Image Box).

H.2.1.2.3 Presentation LUT

Presentation LUT преобразует значения пикселей с учётом полярности в значения представления (Presentation Values, P-Values), которые имеют смысл для отображения изображений. P-Values приблизительно соответствуют восприятию человека. Они предназначены для обеспечения согласованного отображения при общем входном сигнале как для устройств отображения твёрдых копий, так и для устройств отображения мягких копий, и не зависят от конкретного класса или характеристик устройства отображения. Он используется для реализации отображения изображений, адаптированного к конкретным модальностям, приложениям и пользовательским предпочтениям

В сервисном классе управления печатью Presentation LUT является частью IOD Presentation LUT.

Устройства твёрдых копий преобразуют P-Values в оптическую плотность для печати. Это преобразование зависит от желаемых значений D-max и D-min изображения. Оно также зависит от ожидаемых условий просмотра, таких как интенсивность светового короба (lightbox) для прозрачных плёнок. Преобразование в плотность отпечатка указывается в SOP-классе Presentation LUT.

Если модальность желает изначально указывать P-Values в качестве своего выхода, она может согласовать поддержку Presentation LUT, но указать LUT, являющуюся тождественной функцией. Тождественная функция сообщает устройству отображения, что дальнейшее преобразование не требуется.

Примечание

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

H.2.2 Структура сервисного класса управления печатью

Структура сервисного класса управления печатью показана на Рисунке H.2-3.

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

Print Management Service Class Structure

Рисунок H.2-3. Структура сервисного класса управления печатью


SCU управления печатью и SCP управления печатью устанавливают ассоциацию, используя службы ассоциации сервиса OSI Upper Layer. Во время установления ассоциации прикладные сущности DICOM для управления печатью согласовывают поддерживаемые SOP-классы. Процедура согласования определена в Разделе H.5.

Рисунок H.2-4 показывает альтернативные конфигурации для печати изображений и связанных с ними данных с одного узла на несколько принтеров.

  • Конфигурация 1: одна прикладная сущность SCU соответствует узлу, и одна прикладная сущность SCP соответствует нескольким принтерам. SCU не имеет контроля над параметрами печати каждого принтера и над назначением печати задания печати.

  • Конфигурация 2: одна прикладная сущность SCU соответствует узлу, и одна прикладная сущность SCP соответствует каждому принтеру. SCU имеет явный контроль над параметрами печати каждого принтера и над назначением печати задания печати. Каждая прикладная сущность SCP имеет одну ассоциацию с прикладной сущностью SCU и идентифицируется по своему титулу прикладной сущности.

Configurations for Printing On Multiple Printers

Рисунок H.2-4. Конфигурации для печати на нескольких принтерах


H.2.3 SOP-классы управления печатью

SCU управления печатью управляет процессом печати путём манипулирования SOP-классами управления печатью посредством служб DIMSE. SOP-классами управления печатью управляет SCP управления печатью.

SOP-классы управления печатью классифицируются следующим образом:

  • Содержательные SOP-классы: эти SOP-классы являются абстракцией содержимого плёнки (например, пиксельные данные, текстовая строка). Содержательные SOP-классы соответствуют SOP-классам, связанным с изображениями, которые описаны в Разделе H.4 настоящей части.

  • Презентационные SOP-классы: эти SOP-классы являются абстракцией представления плёнки (например, информация о макете) и определяются нормализованными IOD и нормализованными службами DIMSE-N. Презентационные SOP-классы определены в Разделе H.4 настоящей части.

  • SOP-классы, связанные с принтером: эти SOP-классы являются абстракцией конфигурации и статуса принтера и определяются нормализованными IOD. SOP-класс Printer определён в Разделе H.4 настоящей части.

H.2.4 Спецификации использования

Базовыми структурными элементами SOP-классов являются модули и службы DIMSE. Модули содержат связанные атрибуты, которые являются обязательными (M, Mandatory) или необязательными (U, Optional). Использование может различаться для SCU и SCP. Использование указывается как пара букв: первая обозначает использование SCU, последняя — использование SCP.

Группа служб DIMSE (DIMSE Service Group) может быть обязательной (M) или необязательной (U), как указано в Разделе 5.4 настоящей части.

Значение и поведение спецификации использования для атрибутов в сервисном классе управления печатью:

M/M

SCU должен предоставить значение для атрибута. Если SCU не предоставляет значение, SCP должен вернуть код состояния ошибки 0120H "Missing Attribute" ("Отсутствует атрибут"). SCP должен поддерживать хотя бы одно значение атрибута. Если SCP не поддерживает значение, указанное SCU, он должен вернуть код состояния ошибки 0106H "Invalid Attribute Value" ("Недопустимое значение атрибута").

-/M

Использование атрибута со стороны SCU не определено. SCP должен поддерживать хотя бы одно значение атрибута.

U/M

SCU может предоставить значение для атрибута. Если SCP не поддерживает значение, указанное SCU, он должен вернуть либо код состояния ошибки 0106H "Invalid Attribute Value" ("Недопустимое значение атрибута"), либо код состояния предупреждения 0116H "Attribute Value out of range" ("Значение атрибута вне диапазона"). В случае состояния предупреждения SCP применит значение по умолчанию, как определено в заявлении о соответствии SCP.

U/U

SCU может предоставить значение для атрибута. Если SCP не поддерживает значение, указанное SCU, но поддерживает атрибут, он должен вернуть либо код состояния ошибки 0106H "Invalid Attribute Value" ("Недопустимое значение атрибута"), либо код состояния предупреждения 0116H "Attribute Value out of range" ("Значение атрибута вне диапазона"). В случае состояния предупреждения SCP применит значение по умолчанию, как определено в заявлении о соответствии SCP.

Если SCP не поддерживает атрибут, указанный SCU, он должен вернуть либо код состояния ошибки 0105H "No such Attribute" ("Нет такого атрибута"), либо код состояния предупреждения 0107H "Attribute List warning" ("Предупреждение о списке атрибутов"). В случае состояния предупреждения поведение SCP определено в заявлении о соответствии SCP.

Если обозначение типа использования модифицируется буквой "C" (например, MC/M), приведённая выше спецификация должна быть изменена, чтобы включить требование о том, что атрибут должен поддерживаться при выполнении указанного условия.

H.2.5 Категории кодов состояния

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

Примечание

Эти категории кодов состояния определены в PS3.7:

  • Успех (Success) — указывает, что SCP выполнил запрошенную операцию, как запрошено.

  • Предупреждение (Warning) — указывает, что SCP получил запрос и обработает его. Однако немедленная обработка запроса или обработка способом, указанным SCU, может быть невозможна. SCP ожидает, что сможет завершить запрос без дальнейших действий SCU через интерфейс DICOM. Точное поведение SCP описано в заявлении о соответствии.

  • Ошибка (Failure) — указывает, что SCP не может выполнить запрос. Запрос не будет обработан, если он не будет повторён SCU в более позднее время. Точное поведение SCP описано в заявлении о соответствии.

H.3 Соответствие управления печатью

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

Соответствие управления печатью определяется в терминах поддерживаемых мета-SOP-классов (Meta SOP Classes), которые соответствуют обязательной функциональности, и поддерживаемых необязательных SOP-классов, которые соответствуют дополнительной функциональности.

Мета-SOP-класс соответствует заранее определённой группе SOP-классов. Определены следующие мета-SOP-классы управления печатью:

  • Basic Grayscale Print Management Meta SOP Class

  • Basic Color Print Management Meta SOP Class

Все SCU и SCP сервисного класса управления печатью должны поддерживать хотя бы один из базовых мета-SOP-классов управления печатью (Basic Print Management Meta SOP Classes).

Кроме того, могут поддерживаться другие мета-SOP-классы или необязательные SOP-классы.

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

Если согласованы несколько мета-SOP-классов и один или более необязательных SOP-классов, SCP должен поддерживать все необязательные SOP-классы совместно со всеми мета-SOP-классами.

При установлении ассоциации процесс согласования между SCU и SCP управления печатью должен происходить для:

  • одного или более мета-SOP-классов и нуля или более необязательных SOP-классов, указанных в Разделе H.3.3.2; либо

  • одного или более SOP-классов Printer, Print Job и Printer Configuration Retrieval.

Примечание

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

H.3.2 Мета-SOP-классы управления печатью

H.3.2.1 Описание

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

  • предформатированные изображения в градациях серого или предформатированные цветные изображения; предформатированные изображения — это изображения, в которых аннотации, графика, наложения (overlays) вшиты в пиксели

  • предопределённые макеты плёнки (форматы отображения изображений)

  • базовые параметры представления на уровнях сеанса плёнки, блока плёнки и блока изображения

  • базовое управление устройством

Необязательные SOP-классы, описанные в Разделе H.3.3, могут использоваться с базовыми мета-SOP-классами управления печатью.

Следующие функции являются необязательными для SCU и SCP:

  • Аннотирование блока плёнки

  • Presentation LUT

H.3.2.2 Определения мета-SOP-классов

H.3.2.2.1 Basic Grayscale Print Management Meta SOP Class

Мета-SOP-класс определяется следующим набором поддерживаемых SOP-классов.

Table H.3.2.2.1-1. SOP-классы мета-SOP-класса Basic Grayscale Print Management

SOP Class Name

Reference

Использование (SCU/SCP)

Basic Film Session SOP Class

H.4.1

M/M

Basic Film Box SOP Class

H.4.2

M/M

Basic Grayscale Image Box SOP Class

H.4.3.1

M/M

Printer SOP Class

H.4.6

M/M


Примечание

Пиксельные данные изображения являются частью SOP-класса Basic Grayscale Image Box

Значение Использования (SCU/SCP) описано в Разделе H.2.4.

UID мета-SOP-класса Basic Grayscale Print Management имеет значение "1.2.840.10008.5.1.1.9".

H.3.2.2.2 Basic Color Print Management Meta SOP Class

Мета-SOP-класс определяется следующим набором поддерживаемых SOP-классов.

Table H.3.2.2.2-1. SOP-классы мета-SOP-класса Basic Color Print Management

SOP Class Name

Reference

Использование (SCU/SCP)

Basic Film Session SOP Class

H.4.1

M/M

Basic Film Box SOP Class

H.4.2

M/M

Basic Color Image Box SOP Class

H.4.3.2

M/M

Printer SOP Class

H.4.6

M/M


Примечание

Пиксельные данные изображения являются частью SOP-класса Basic Color Image Box

Значение Использования (SCU/SCP) описано в Разделе H.2.4.

UID мета-SOP-класса Basic Color Print Management имеет значение "1.2.840.10008.5.1.1.18".

H.3.2.2.3 Referenced Grayscale Print Management Meta SOP Class (Retired)

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

H.3.2.2.4 Referenced Color Print Management Meta SOP Class (Retired)

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

H.3.2.2.5 Pull Stored Print Management Meta SOP Class (Retired)

Этот раздел был ранее определён в DICOM. Он выведен из употребления. См. PS3.4-2004.

H.3.3 Необязательные SOP-классы

H.3.3.1 Описание

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

Следующая функциональность поддерживается необязательными SOP-классами:

  • аннотации (текст, связанный с листом плёнки)

  • отслеживание печати сеанса печати

  • получение информации о конфигурации принтера

  • Presentation LUTs

Использование этих необязательных SOP-классов позволяет SCU предоставлять информацию для печати с изображением или на изображении без вшивания информации в пиксельные данные изображения. Если эти необязательные SOP-классы не поддерживаются как SCU, так и SCP, будет напечатана только информация, вшитая в пиксели изображения до их отправки на SCP. Если необязательные SOP-классы не поддерживаются, SCU отвечает за вшивание всего ожидаемого текста или графики в пиксели изображения.

H.3.3.2 Перечень необязательных SOP-классов

Следующие необязательные SOP-классы могут использоваться совместно с базовыми мета-SOP-классами управления печатью, указанными в Разделе H.3.2.2.

Table H.3.3.2-1. Перечень необязательных SOP-классов для базовых мета-SOP-классов управления печатью

SOP Class Name

Reference

Использование (SCU/SCP)

Basic Annotation Box SOP Class

H.4.4

U/U

Print Job SOP Class

H.4.5

U/U

Presentation LUT SOP Class

H.4.9

U/U

Printer Configuration Retrieval SOP Class

H.4.11

U/U


Примечание

Согласование SOP-класса Presentation LUT не подразумевает какого-либо поведения SCP. Поведение явно определяется при создании SOP-класса Presentation LUT и ссылке на него на уровне сеанса плёнки, блока плёнки или блока изображения.

H.3.4 Заявление о соответствии

Заявление о соответствии реализации этих SOP-классов должно следовать PS3.2.

Заявление о соответствии SCU должно указывать следующие пункты:

  • максимальное количество поддерживаемых одновременно ассоциаций

  • перечень поддерживаемых SOP-классов и мета-SOP-классов

  • для каждого из поддерживаемых SOP- и мета-SOP-классов:

    • перечень поддерживаемых необязательных атрибутов SOP-класса и элементов служб сообщений DICOM

  • для каждого поддерживаемого атрибута (обязательного и необязательного) — допустимый диапазон значений

Заявление о соответствии SCP должно указывать следующие пункты:

  • максимальное количество поддерживаемых одновременно ассоциаций

  • перечень поддерживаемых SOP-классов и мета-SOP-классов

  • минимальное и максимальное количество печатаемых пиксельных матриц для каждого поддерживаемого формата плёнки

  • для каждого из поддерживаемых SOP-классов:

    • перечень поддерживаемых необязательных атрибутов SOP-класса и элементов служб сообщений DICOM

  • для каждого поддерживаемого атрибута (обязательного и необязательного):

    • допустимый диапазон значений

    • значение по умолчанию, если SCU не предоставляет значение

    • код состояния (ошибка или предупреждение), если SCU предоставляет значение вне диапазона

  • для каждой поддерживаемой службы DIMSE — поведение SCP для всех специфических кодов состояния

  • описание каждого поддерживаемого пользовательского формата отображения изображений (Image Display Format) (2010,0010), например, положение и размеры каждого составляющего блока изображения, схема нумерации позиций изображений

  • описание каждого поддерживаемого идентификатора формата отображения аннотаций (Annotation Display Format ID) (2010,0030), например, положение и размеры блока аннотаций, шрифт, количество символов

  • описание каждой поддерживаемой таблицы конфигурации (например, идентификация, содержимое)

  • если SCP поддерживает N-ACTION для SOP-класса сеанса плёнки, то SCP должен указать максимальное количество колированных плёнок

  • в случае полутоновых принтеров, печатающих цветные изображения, — поведение при печати цветных изображений

  • если поддерживается кадрирование изображений, — алгоритм удаления строк и столбцов из изображения

H.4 Определения SOP-классов управления печатью

H.4.1 SOP-класс базового сеанса плёнки

H.4.1.1 Описание IOD

IOD базового сеанса плёнки описывает параметры представления, общие для всех плёнок сеанса плёнки (например, количество плёнок, назначение плёнки)

Экземпляр SOP базового сеанса плёнки ссылается на один или несколько экземпляров SOP базового блока плёнки.

H.4.1.2 Группа служб DIMSE

Службы DIMSE, применимые к данному IOD, показаны в Таблице H.4-1.

Таблица H.4-1. Группа служб DIMSE, применимая к базовому сеансу плёнки

Элемент службы сообщений DICOM

Использование (SCU/SCP)

N-CREATE

M/M

N-SET

U/M

N-DELETE

U/M

N-ACTION

U/U


Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.

В этом разделе описывается поведение служб DIMSE, специфичное для данного IOD. Общее поведение служб DIMSE специфицировано в PS3.7.

H.4.1.2.1 N-CREATE

N-CREATE используется для создания экземпляра SOP-класса базового сеанса плёнки.

H.4.1.2.1.1 Атрибуты

Список атрибутов N-CREATE определён, как показано в Таблице H.4-2.

Таблица H.4-2. Список атрибутов N-CREATE

Имя атрибута

Tag

Использование (SCU/SCP)

Specific Character Set

(0008,0005)

U/U

Number of Copies

(2000,0010)

U/M

Print Priority

(2000,0020)

U/M

Medium Type

(2000,0030)

U/M

Film Destination

(2000,0040)

U/M

Film Session Label

(2000,0050)

U/U

Memory Allocation

(2000,0060)

U/U

Owner ID

(2100,0160)

U/U

Proposed Study Sequence

(2130,00A0)

U/U

>Patient's Name

(0010,0010)

U/U

>Patient ID

(0010,0020)

U/U

>Patient's Birth Date

(0010,0030)

U/U

>Patient's Birth Time

(0010,0032)

U/U

>Patient's Sex

(0010,0040)

U/U

>Patient's Age

(0010,1010)

U/U

>Ethnic Group

(0010,2160)

U/U

>Patient Comments

(0010,4000)

U/U

>Study Instance UID

(0020,000D)

U/U

>Study Date

(0008,0020)

U/U

>Study Time

(0008,0030)

U/U

>Study ID

(0020,0010)

U/U

>Study Description

(0008,1030)

U/U

>Accession Number

(0008,0050)

U/U

>Referring Physician’s Name

(0008,0090)

U/U

>Name of Physician(s) Reading Study

(0008,1060)

U/U

>Admitting Diagnoses Description

(0008,1080)

U/U

>Series Number

(0020,0011)

U/U


Примечание

  1. Атрибут распределения памяти позволяет SCU зарезервировать достаточный объём памяти для хранения иерархии «рабочего» сеанса плёнки, а также иерархии «скопированного» сеанса плёнки в задании печати, чтобы предотвратить ситуации взаимной блокировки.

  2. Owner ID (2100,0160) является пользовательской опцией для базового сеанса плёнки.

Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.

В рамках сеанса плёнки выделенная память расходуется по мере создания экземпляров SOP и освобождается для повторного использования по мере удаления экземпляров SOP. Вся выделенная память должна быть освобождена после завершения ассоциации или удаления экземпляра SOP сеанса плёнки.

H.4.1.2.1.2 Статус

Таблица H.4.1.2.1.2-1 определяет специфические значения кодов состояния, которые могут быть возвращены в ответе N-CREATE или N-SET для данного SOP-класса. См. PS3.7 для получения дополнительных кодов состояния ответа служб DIMSE N-CREATE и N-SET.

Таблица H.4.1.2.1.2-1. Значения статуса для SOP-класса базового сеанса плёнки

Статус службы

Дополнительное значение

Код состояния

Успех

Сеанс плёнки успешно создан

0000

Предупреждение

Распределение памяти не поддерживается

B600


Примечание

Код состояния «0106H» (недопустимое значение атрибута) указывает на то, что запрошенное распределение памяти не может быть предоставлено; код состояния «0213H» (ограничение ресурсов) указывает на то, что запрошенное распределение временно не может быть предоставлено.

H.4.1.2.1.3 Поведение

SCU использует N-CREATE для запроса SCP на создание экземпляра SOP базового сеанса плёнки. SCU должен инициализировать атрибуты SOP-класса, как указано в Разделе H.2.4.

SCP должен создать экземпляр SOP и инициализировать атрибуты SOP-класса, как указано в Разделе H.2.4.

SCP должен вернуть код состояния запрошенного создания экземпляра SOP. Значение кодов состояния успеха, предупреждения и отказа определено в Разделе H.2.5.

Экземпляры SOP базового сеанса плёнки должны быть созданы до создания экземпляров SOP блока плёнки.

В любой момент времени SCU/SCP должен поддерживать только один экземпляр SOP базового сеанса плёнки в рамках ассоциации.

Примечание

Несколько сеансов плёнки могут обрабатываться путём установления нескольких ассоциаций.

Завершение ассоциации фактически выполнит N-DELETE над открытым сеансом плёнки. См. примечание в Разделе H.4.1.2.3.2.

H.4.1.2.2 N-SET

N-SET может использоваться для обновления экземпляра SOP-класса базового сеанса плёнки.

H.4.1.2.2.1 Атрибуты

Все атрибуты и их использование в Таблице H.4-2 применимы к N-SET.

H.4.1.2.2.2 Статус

Значения статуса, специфичные для данного SOP-класса, определены в Разделе H.4.1.2.1.2.

H.4.1.2.2.3 Поведение

SCU использует N-SET для запроса SCP на обновление экземпляра SOP базового сеанса плёнки. SCU должен указать UID экземпляра SOP для обновления и указать список атрибутов, значения которых должны быть установлены.

SCP должен установить новые значения для указанных атрибутов указанного экземпляра SOP.

SCP должен вернуть код состояния запрошенного обновления экземпляра SOP. Значение кодов состояния успеха, предупреждения и отказа определено в Разделе H.2.5

H.4.1.2.3 N-DELETE

N-DELETE используется для удаления полной иерархии экземпляра SOP базового сеанса плёнки. В результате все ссылки на экземпляры SOP изображений в рамках сеанса плёнки удаляются.

Иерархия экземпляра SOP базового сеанса плёнки состоит из одного экземпляра SOP базового сеанса плёнки, одного или нескольких экземпляров SOP базового блока плёнки, одного или нескольких экземпляров SOP блока изображения, нуля или более экземпляров SOP базового блока аннотаций, нуля или более экземпляров SOP LUT представления и нуля или более экземпляров SOP базового блока наложения печатного изображения.

Примечание

Иерархия экземпляра SOP базового сеанса плёнки может быть представлена в виде перевёрнутого дерева, где экземпляр SOP базового сеанса плёнки является корнем, а экземпляры SOP блока изображения — листьями.

H.4.1.2.3.1 Статус

Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.

H.4.1.2.3.2 Поведение

SCU использует N-DELETE для запроса SCP на удаление иерархии экземпляра SOP базового сеанса плёнки. SCU должен указать в примитиве запроса N-DELETE UID экземпляра SOP базового сеанса плёнки (корень).

SCP должен удалить указанную иерархию экземпляра SOP.

SCP не должен удалять экземпляры SOP в иерархии, пока существуют незавершённые ссылки на эти экземпляры SOP

Примечание

Определение того, когда SCP фактически удаляет экземпляры SOP с незавершёнными ссылками, выходит за рамки Стандарта.

SCP должен вернуть код состояния запрошенного удаления экземпляра SOP. Значение кодов состояния успеха, предупреждения и отказа определено в Разделе H.2.5.

H.4.1.2.4 N-ACTION

N-ACTION используется для печати сеанса плёнки; т.е. для печати всех плёнок, принадлежащих сеансу плёнки.

Если было запрошено несколько копий сеанса плёнки, SCP должен колировать копии. Это означает, что если указаны две копии четырёх плёнок, напечатанная последовательность будет 12341234.

H.4.1.2.4.1 Атрибуты

Аргументы N-ACTION определены в Таблице H.4-3.

Аргумент Action Reply кодируется как набор данных DICOM. Набор данных содержит только атрибут Referenced Print Job Sequence (2100,0500), который включает Referenced SOP Class UID (0008,1150) и Referenced SOP Instance UID (0008,1155).

Если SCP поддерживает SOP-класс задания печати, аргумент Action Reply содержится в ответе N-ACTION. В противном случае Action Reply не содержится в ответе N-ACTION.

Таблица H.4-3. Аргументы N-ACTION

Имя типа действия

Идентификатор типа действия

Имя атрибута

Tag

Использование (SCU/SCP)

Print

1

Referenced Print Job Sequence

(2100,0500)

-/MC

Обязательно, если поддерживается SOP задания печати

>Referenced SOP Class UID

(0008,1150)

-/MC

Обязательно, если Referenced Print Job Sequence (2100,0500) присутствует

>Referenced SOP Instance UID

(0008,1155)

-/MC

Обязательно, если Referenced Print Job Sequence (2100,0500) присутствует


H.4.1.2.4.2 Статус

Таблица H.4-4определяет специфические значения кодов состояния, которые могут быть возвращены в ответе N-ACTION. См. PS3.7 для дополнительных кодов состояния ответа.

Таблица H.4-4. Значения статуса SOP-класса

Статус службы

Дополнительное значение

Код состояния

Успех

Плёнки, принадлежащие сеансу плёнки, приняты для печати; если поддерживается, создаётся экземпляр SOP задания печати

0000

Предупреждение

Печать (колирование) сеанса плёнки не поддерживается

B601

Иерархия экземпляра SOP сеанса плёнки не содержит экземпляров SOP блока изображения (пустая страница)

B602

Размер изображения превышает размер блока изображения, изображение было уменьшено.

B604

Размер изображения превышает размер блока изображения. Изображение было обрезано для соответствия.

B609

Размер изображения или размер комбинированного печатного изображения превышает размер блока изображения. Изображение или комбинированное печатное изображение было децимировано для соответствия.

B60A

Отказ

Отказ: иерархия экземпляра SOP сеанса плёнки не содержит экземпляров SOP блока плёнки

C600

Отказ: невозможно создать экземпляр SOP задания печати; очередь печати заполнена

C601

Отказ: размер изображения превышает размер блока изображения

C603

Отказ: размер комбинированного печатного изображения превышает размер блока изображения

C613


Примечание

В предыдущих версиях Стандарта DICOM был определён код состояния C604. Этот код предназначался для случая коллизии позиции изображения. Поскольку коллизия позиции изображения не является возможным состоянием, код был выведен из употребления.

H.4.1.2.4.3 Поведение

SCU использует N-ACTION для запроса SCP на печать всех плёнок, принадлежащих идентифицированному сеансу плёнки.

SCP должен создать копию иерархии «рабочего» экземпляра SOP базового сеанса плёнки, которая содержит всю информацию для управления процессом печати. Таким образом, SCU может далее обновлять «рабочую» иерархию экземпляров SOP, не влияя на результат предыдущих запросов печати. Выполнение процесса печати отслеживается экземпляром SOP задания печати (если поддерживается SCP) и SOP-классом принтера.

Если SCP поддерживает SOP-класс задания печати, то SCP должен создать экземпляр SOP задания печати, содержащий копию иерархии «рабочего» экземпляра SOP базового сеанса плёнки, и вернуть пару SOP-класс/UID-экземпляра задания печати в атрибуте Referenced Print Job Sequence аргумента Action Reply.

Примечание

Если SCP поддерживает SOP-класс задания печати, он создаёт одно задание печати для всех плёнок сеанса плёнки.

SCP должен вернуть код состояния запрошенной операции. Значение кодов состояния успеха, предупреждения и отказа определено в Разделе H.2.5.

N-ACTION должен выдаваться только в том случае, если иерархия экземпляра SOP базового сеанса плёнки содержит хотя бы один экземпляр SOP блока плёнки.

H.4.1.3 Определение SOP-класса и UID

UID SOP-класса базового сеанса плёнки должен иметь значение «1.2.840.10008.5.1.1.1».

H.4.2 SOP-класс базового блока плёнки

H.4.2.1 Описание IOD

IOD базового блока плёнки является абстракцией представления одной плёнки сеанса плёнки. IOD базового блока плёнки описывает параметры представления, общие для всех изображений на данном листе плёнки.

Экземпляр SOP базового блока плёнки ссылается на один или несколько экземпляров SOP блока изображения, нуль или более связанных с плёнкой экземпляров SOP блока аннотаций и нуль или один экземпляр SOP LUT представления.

H.4.2.2 Группа служб DIMSE

Таблица H.4-5 показывает службы DIMSE, применимые к данному IOD.

Таблица H.4-5. Группа служб DIMSE, применимая к базовому блоку плёнки

Элемент службы сообщений DICOM

Использование (SCU/SCP)

N-CREATE

M/M

N-ACTION

M/M

N-DELETE

U/M

N-SET

U/U


Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.

В этом разделе описывается поведение служб DIMSE, специфичное для данного IOD. Общее поведение служб DIMSE специфицировано в PS3.7.

H.4.2.2.1 N-CREATE

N-CREATE используется для создания экземпляра SOP-класса базового блока плёнки.

H.4.2.2.1.1 Атрибуты

Список атрибутов N-CREATE показан в Таблице H.4-6.

Таблица H.4-6. Список атрибутов N-CREATE

Имя атрибута

Tag

Использование (SCU/SCP)

Image Display Format

(2010,0010)

M/M

Referenced Film Session Sequence

(2010,0500)

M/M

>Referenced SOP Class UID

(0008,1150)

M/M

>Referenced SOP Instance UID

(0008,1155)

M/M

Referenced Image Box Sequence

(2010,0510)

-/M

>Referenced SOP Class UID

(0008,1150)

-/M

>Referenced SOP Instance UID

(0008,1155)

-/M

Referenced Basic Annotation Box Sequence

(2010,0520)

-/MC

(Обязательно, если был согласован необязательный SOP аннотаций)

>Referenced SOP Class UID

(0008,1150)

-/MC

(Обязательно, если последовательность присутствует)

>Referenced SOP Instance UID

(0008,1155)

-/MC

(Обязательно, если последовательность присутствует)

Film Orientation

(2010,0040)

U/M

Film Size ID

(2010,0050)

U/M

Magnification Type

(2010,0060)

U/M

Max Density

(2010,0130)

U/M

Configuration Information

(2010,0150)

U/M

Referenced Presentation LUT Sequence

(2050,0500)

U/MC

(Обязательно, если поддерживается LUT представления)

>Referenced SOP Class UID

(0008,1150)

U/MC

(Обязательно, если последовательность присутствует)

>Referenced SOP Instance UID

(0008,1155)

U/MC

(Обязательно, если последовательность присутствует)

Annotation Display Format ID

(2010,0030)

U/U

Smoothing Type

(2010,0080)

U/U

Border Density

(2010,0100)

U/U

Empty Image Density

(2010,0110)

U/U

Min Density

(2010,0120)

U/U

Trim

(2010,0140)

U/U

Illumination

(2010,015E)

U/MC

(Обязательно, если поддерживается LUT представления)

Reflected Ambient Light

(2010,0160)

U/MC

(Обязательно, если поддерживается LUT представления)

Requested Resolution ID

(2020,0050)

U/U

ICC Profile

(0028,2000)

U/U


Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.

Если значения Illumination (2010,015E) и Reflected Ambient Light (2010,0160), обозначаемые соответственно L0 и La, не созданы, для полутоновой печати рекомендуются следующие значения по умолчанию:

  • Для пропускающей плёнки: L0 = 2000 кд/м2. La = 10 кд/м2.

  • Для отражающего носителя: L0 = 150 кд/м2.

Атрибут ICC Profile (0028,2000) должен использоваться только для описания цветового пространства изображений для цветной печати, т.е. в сочетании с SOP-классом базового блока цветного изображения. Он не должен использоваться с SOP-классом базового блока полутонового изображения.

H.4.2.2.1.2 Статус

Таблица H.4.2.2.1.2-1 определяет специфические значения кодов состояния, которые могут быть возвращены в ответе N-CREATE или N-SET для данного SOP-класса. См. PS3.7 для получения дополнительных кодов состояния ответа служб DIMSE N-CREATE и N-SET.

Таблица H.4.2.2.1.2-1. Значения статуса для SOP-класса базового блока плёнки

Статус службы

Дополнительное значение

Код состояния

Успех

Блок плёнки успешно создан

0000

Предупреждение

Запрошенные минимальная или максимальная плотность выходят за рабочий диапазон принтера. Принтер будет использовать соответствующее минимальное или максимальное значение плотности.

B605

Отказ

Отказ: существует непечатанный блок плёнки, и N-ACTION на уровне сеанса плёнки не поддерживается. Новый блок плёнки не будет создан, пока предыдущий блок плёнки не напечатан.

C616


H.4.2.2.1.3 Поведение

SCU использует N-CREATE для запроса SCP на создание экземпляра SOP базового блока плёнки. SCU должен инициализировать атрибуты SOP-класса, как указано в Разделе H.2.4.

SCP должен создать экземпляр SOP и инициализировать атрибуты SOP-класса, как указано в Разделе H.2.4.

Примечание

Если существует непечатанный экземпляр SOP блока плёнки и SCP не поддерживает N-ACTION на уровне сеанса плёнки, то SCP следует отклонить N-CREATE нового экземпляра SOP.

При создании экземпляра SOP базового блока плёнки SCP должен добавить пару SOP-класс/UID-экземпляра созданного экземпляра SOP базового блока плёнки к атрибуту Referenced Film Box Sequence (2000,0500) родительского экземпляра SOP базового сеанса плёнки для связывания экземпляра SOP базового блока плёнки с экземпляром SOP базового сеанса плёнки.

SCP должен создать экземпляры SOP блока изображения соответствующего SOP-класса блока изображения для каждого блока изображения, как определено атрибутом Image Display Format (2010,0010). SOP-класс созданного экземпляра SOP блока изображения зависит от контекста мета-SOP-класса. Например, SOP-класс полутонового блока изображения связан с мета-SOP-классом базового управления полутоновой печатью. Контекст мета-SOP-класса передаётся через идентификатор контекста представления (Presentation Context ID), соответствующий мета-SOP-классу, и определяется при настройке ассоциации.

SCP должен добавить пару SOP-класс/UID-экземпляра созданного экземпляра SOP блока изображения к атрибуту Referenced Image Box Sequence родительского экземпляра SOP базового блока плёнки для связывания каждого экземпляра SOP блока изображения с экземпляром SOP базового блока плёнки. SCP возвращает список пар SOP-класс/UID-экземпляра блока изображения в атрибуте Referenced Image Box Sequence (2010,0510) ответного сообщения N-CREATE.

Если поддерживается, SCP должен создать экземпляры SOP базового блока аннотаций для каждого блока аннотаций, определённого атрибутом Annotation Display Format ID, и добавить пару SOP-класс/UID-экземпляра созданного экземпляра SOP базового блока аннотаций к атрибуту Referenced Annotation Box Sequence родительского экземпляра SOP базового блока плёнки для связывания каждого экземпляра SOP базового блока аннотаций с экземпляром SOP базового блока плёнки. SCP возвращает список пар SOP-класс/UID-экземпляра базового блока аннотаций в атрибуте Referenced Annotation Box Sequence ответного сообщения N-CREATE. Блоки аннотаций должны поддерживать те же наборы символов, что и базовый блок плёнки.

Набор символов, поддерживаемый блоком плёнки, должен совпадать с набором символов базового сеанса плёнки.

SCP должен вернуть код состояния запрошенного создания экземпляра SOP. Значение кодов состояния успеха, предупреждения и отказа определено в Разделе H.2.5.

H.4.2.2.2 N-SET

N-SET может использоваться для обновления последнего созданного экземпляра SOP-класса базового блока плёнки.

H.4.2.2.2.1 Атрибуты

Атрибуты, которые могут быть обновлены, показаны в Таблице H.4-7.

Таблица H.4-7. Атрибуты N-SET

Имя атрибута

Tag

Использование (SCU/SCP)

Magnification Type

(2010,0060)

U/M

Max Density

(2010,0130)

U/M

Configuration Information

(2010,0150)

U/M

Referenced Presentation LUT Sequence

(2050,0500)

U/MC

(Обязательно, если поддерживается LUT представления)

>Referenced SOP Class UID

(0008,1150)

U/MC

(Обязательно, если последовательность присутствует)

>Referenced SOP Instance UID

(0008,1155)

U/MC

(Обязательно, если последовательность присутствует)

Smoothing Type

(2010,0080)

U/U

Border Density

(2010,0100)

U/U

Empty Image Density

(2010,0110)

U/U

Min Density

(2010,0120)

U/U

Trim

(2010,0140)

U/U

Illumination

(2010,015E)

U/MC

(Обязательно, если поддерживается LUT представления)

Reflected Ambient Light

(2010,0160)

U/MC

(Обязательно, если поддерживается LUT представления)

ICC Profile

(0028,2000)

U/U


Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.

H.4.2.2.2.2 Статус

Значения статуса, специфичные для данного SOP-класса, определены в Разделе H.4.2.2.1.2.

H.4.2.2.2.3 Поведение

SCU использует N-SET для запроса SCP на обновление экземпляра SOP базового блока плёнки. SCU должен указать только UID экземпляра SOP последнего созданного базового блока плёнки в примитиве запроса N-SET и указать список атрибутов, значения которых должны быть установлены.

SCP должен установить новые значения для указанных атрибутов указанного экземпляра SOP.

SCP должен вернуть код состояния запрошенного обновления экземпляра SOP. Значение кодов состояния успеха, предупреждения и отказа определено в Разделе H.2.5.

H.4.2.2.3 N-DELETE

N-DELETE используется для удаления иерархии последнего созданного экземпляра SOP базового блока плёнки. В результате удаляется вся информация, описывающая последнюю плёнку.

Иерархия экземпляра SOP базового блока плёнки состоит из одного экземпляра SOP базового блока плёнки, одного или нескольких экземпляров SOP блока изображения, нуля или более экземпляров SOP базового блока аннотаций, нуля или более экземпляров SOP LUT представления и нуля или более экземпляров SOP базового блока наложения печатного изображения.

Примечание

В Стандарте DICOM не предусмотрена возможность удаления ранее созданных экземпляров SOP блока плёнки.

H.4.2.2.3.1 Поведение

SCU использует N-DELETE для запроса SCP на удаление иерархии экземпляра SOP базового блока плёнки. SCU должен указать в примитиве запроса N-DELETE UID экземпляра SOP последнего созданного базового блока плёнки (корень).

SCP должен удалить указанную иерархию экземпляра SOP и удалить UID удалённого экземпляра SOP базового блока плёнки из списка UID экземпляров SOP атрибута Film Box UIDs родительского экземпляра SOP базового сеанса плёнки.

SCP должен вернуть код состояния запрошенного удаления иерархии экземпляра SOP. Значение кодов состояния успеха, предупреждения и отказа определено в Разделе H.2.5.

SCP не должен удалять экземпляры SOP в иерархии, пока существуют незавершённые ссылки на эти экземпляры SOP

Примечание

Определение того, когда SCP фактически удаляет экземпляры SOP изображений с незавершёнными ссылками, выходит за рамки Стандарта.

H.4.2.2.3.2 Статус

Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.

H.4.2.2.4 N-ACTION

N-ACTION используется для печати одной или нескольких копий последнего созданного экземпляра блока плёнки.

H.4.2.2.4.1 Атрибуты

Аргументы N-ACTION определены, как показано в Таблице H.4-8.

Аргумент Action Reply кодируется как набор данных DICOM. Набор данных содержит только атрибут Referenced Print Job Sequence (2100,0500), который включает Referenced SOP Class UID (0008,1150) и Referenced SOP Instance UID (0008,1155).

Если SCP поддерживает SOP-класс задания печати, аргумент Action Reply содержится в ответе N-ACTION. В противном случае Action Reply не содержится в ответе N-ACTION.

Таблица H.4-8. Аргументы N-ACTION

Имя типа действия

Идентификатор типа действия

Имя атрибута

Tag

Использование (SCU/SCP)

Print

1

Referenced Print Job Sequence

(2100,0500)

-/MC

Обязательно, если поддерживается SOP задания печати

>Referenced SOP Class UID

(0008,1150)

-/MC

Обязательно, если Referenced Print Job Sequence (2100,0500) присутствует

>Referenced SOP Instance UID

(0008,1155)

-/MC

Обязательно, если Referenced Print Job Sequence (2100,0500) присутствует


H.4.2.2.4.2 Статус

Таблица H.4-9 определяет специфические значения кодов состояния, которые могут быть возвращены в ответе N-ACTION. См. PS3.7 для дополнительных кодов состояния ответа.

Таблица H.4-9. Значения статуса

Статус службы

Дополнительное значение

Код состояния

Успех

Плёнка принята для печати; если поддерживается, создаётся экземпляр SOP задания печати

0000

Предупреждение

Иерархия экземпляра SOP блока плёнки не содержит экземпляров SOP блока изображения (пустая страница)

B603

Размер изображения превышает размер блока изображения, изображение было уменьшено.

B604

Размер изображения превышает размер блока изображения. Изображение было обрезано для соответствия.

B609

Размер изображения или размер комбинированного печатного изображения превышает размер блока изображения. Изображение или комбинированное печатное изображение было децимировано для соответствия.

B60A

Отказ

Отказ: невозможно создать экземпляр SOP задания печати; очередь печати заполнена

C602

Отказ: размер изображения превышает размер блока изображения

C603

Отказ: размер комбинированного печатного изображения превышает размер блока изображения

C613


Примечание

В предыдущих версиях Стандарта DICOM был определён код состояния C604. Этот код предназначался для случая коллизии позиции изображения. Поскольку коллизия позиции изображения не является возможным состоянием, код был выведен из употребления.

H.4.2.2.4.3 Поведение

SCU использует N-ACTION для запроса SCP на печать одной или нескольких копий отдельной плёнки сеанса плёнки. SCU должен указать только UID экземпляра SOP последнего созданного базового блока плёнки в примитиве запроса N-ACTION.

SCP должен создать копию «рабочего» экземпляра SOP базового сеанса плёнки и «рабочей» иерархии экземпляра SOP базового блока плёнки, которая содержит всю информацию для управления процессом печати. Таким образом, SCU может далее обновлять «рабочие» экземпляры SOP, не влияя на результат предыдущих запросов печати. Выполнение процесса печати отслеживается SOP-классом задания печати (если поддерживается SCP) и SOP-классом принтера.

Если SCP поддерживает SOP-класс задания печати, то SCP должен создать экземпляр SOP задания печати, содержащий копию иерархии «рабочего» экземпляра SOP базового сеанса плёнки, и вернуть пару SOP-класс/UID-экземпляра задания печати в атрибуте Referenced Print Job Sequence аргумента Action Reply.

SCP должен вернуть код состояния запрошенной операции. Значение кодов состояния успеха, предупреждения и отказа определено в Разделе H.2.5.

H.4.2.3 Определение SOP-класса и UID

UID SOP-класса базового блока плёнки должен иметь значение «1.2.840.10008.5.1.1.2».

H.4.3 SOP-классы блока изображения

H.4.3.1 SOP-класс базового полутонового блока изображения

H.4.3.1.1 Описание IOD

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

Экземпляр SOP базового полутонового блока изображения создаётся SCP в момент создания экземпляра SOP базового блока плёнки на основе значения атрибута Image Display Format (2010,0010) базового блока плёнки.

Экземпляр SOP базового полутонового блока изображения ссылается на нуль или один экземпляр SOP блока наложения изображения и нуль или один экземпляр SOP LUT представления.

H.4.3.1.2 Группа служб DIMSE

Службы DIMSE, применимые к данному IOD, показаны ниже.

Таблица H.4.3.1.2-1. Группа служб DIMSE, применимая к базовому полутоновому блоку изображения

Элемент службы сообщений DICOM

Использование (SCU/SCP)

N-SET

M/M


Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.

Примечание

N-CREATE отсутствует, поскольку экземпляры SOP-класса базового полутонового блока изображения создаются SCP в результате выполнения N-CREATE для экземпляра SOP блока плёнки.

В этом разделе описывается поведение служб DIMSE, специфичное для данного IOD. Общее поведение служб DIMSE специфицировано в PS3.7.

H.4.3.1.2.1 N-SET

N-SET может использоваться для обновления экземпляра SOP-класса базового полутонового блока изображения.

H.4.3.1.2.1.1 Атрибуты

Атрибуты, которые могут быть обновлены, показаны в Таблице H.4-10.

Таблица H.4-10. Атрибуты N-SET

Имя атрибута

Tag

Использование (SCU/SCP)

Image Box Position

(2020,0010)

M/M

Basic Grayscale Image Sequence

(2020,0110)

M/M

>Samples Per Pixel

(0028,0002)

M/M

>Photometric Interpretation

(0028,0004)

M/M

>Rows

(0028,0010)

M/M

>Columns

(0028,0011)

M/M

>Pixel Aspect Ratio

(0028,0034)

MC/M

(Обязательно, если соотношение сторон не равно 1\1)

>Bits Allocated

(0028,0100)

M/M

>Bits Stored

(0028,0101)

M/M

>High Bit

(0028,0102)

M/M

>Pixel Representation

(0028,0103)

M/M

>Pixel Data

(7FE0,0010)

M/M

Polarity

(2020,0020)

U/M

Magnification Type

(2010,0060)

U/U

Smoothing Type

(2010,0080)

U/U

Min Density

(2010,0120)

U/U

Max Density

(2010,0130)

U/U

Configuration Information

(2010,0150)

U/U

Requested Image Size

(2020,0030)

U/U

Requested Decimate/Crop Behavior

(2020,0040)

U/U

Referenced Presentation LUT Sequence

(2050,0500)

U/U

>Referenced SOP Class UID

(0008,1150)

U/U

>Referenced SOP Instance UID

(0008,1155)

U/U

Original Image Sequence

(2130,00C0)

U/U

>Study Instance UID

(0020,000D)

M/M

>Series Instance UID

(0020,000E)

M/M

>Patient ID

(0010,0020)

M/M

>Referenced SOP Class UID

(0008,1150)

M/M

>Referenced SOP Instance UID

(0008,1155)

M/M


Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.

Значения Magnification Type (2010,0060) и Smoothing Type (2010,0080) конкретного блока изображения переопределяют значения Magnification Type и Smoothing Type блока плёнки.

Значения Referenced Presentation LUT Sequence переопределяют любую таблицу Presentation LUT, которая могла быть установлена для базового блока плёнки. Значения Min/Max Density переопределяют любые значения плотности, которые могли быть установлены для базового блока плёнки.

H.4.3.1.2.1.2 Статус

Таблица H.4.3.1.2.1.2-1 определяет специфические значения кодов статуса, которые могут быть возвращены в ответе N-SET. См. PS3.7 для дополнительных кодов статуса ответа.

Таблица H.4.3.1.2.1.2-1. Значения статуса для класса SOP базового блока изображения в градациях серого

Статус службы

Дополнительное значение

Код статуса

Успех

Изображение успешно сохранено в блоке изображения

0000

Предупреждение

Размер изображения превышает размер блока изображения. Изображение было уменьшено.

B604

Запрошенная минимальная или максимальная плотность выходит за пределы рабочего диапазона принтера. Принтер будет использовать соответствующее минимальное или максимальное значение плотности.

B605

Размер изображения превышает размер блока изображения. Изображение было обрезано для соответствия.

B609

Размер изображения или комбинированного печатного изображения превышает размер блока изображения. Изображение или комбинированное печатное изображение было децимировано для размещения.

B60A

Отказ

Отказ: размер изображения превышает размер блока изображения

C603

Отказ: недостаточно памяти в принтере для хранения изображения

C605

Отказ: размер комбинированного печатного изображения превышает размер блока изображения

C613


H.4.3.1.2.1.3 Поведение

SCU использует N-SET для запроса SCP на обновление экземпляра SOP базового блока изображения в градациях серого. SCU должен указать только SOP Instance UID базового блока изображения в градациях серого, принадлежащего последнему созданному экземпляру SOP блока плёнки, и должен указать список атрибутов, для которых должны быть установлены значения атрибутов.

Чтобы дать SCP инструкцию стереть изображение в позиции изображения, SCU должен установить нулевую длину и отсутствие значения в атрибуте Basic Grayscale Image Sequence (2020,0110).

SCP должен установить новые значения для указанных атрибутов указанного экземпляра SOP.

Примечание

Изображение в данном N-SET заменяет любое изображение, ранее установленное в блоке изображения.

SCP должен вернуть код статуса запрошенного обновления экземпляра SOP. Значение кодов статуса успеха, предупреждения и отказа определено в Разделе H.2.5.

Если Requested Decimate/Crop Behavior (2020,0040) specifies DECIMATE, Magnification Type (2010,0060) specifies NONE, и изображение слишком велико для размещения в блоке изображения, SCP должен отклонить N-SET.

H.4.3.1.3 Определение и UID класса SOP

UID класса SOP базового блока изображения в градациях серого должен иметь значение "1.2.840.10008.5.1.1.4".

H.4.3.2 SOP-класс базового цветного блока изображения

H.4.3.2.1 Описание IOD

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

Экземпляр SOP базового цветового блока изображения создаётся SCP в момент создания экземпляра SOP базового блока плёнки на основе значения атрибута базового блока плёнки Image Display Format (2010,0010).

Экземпляр SOP базового цветового блока изображения ссылается на ноль или один экземпляр SOP блока наложения изображения (Image Overlay Box SOP Instance).

H.4.3.2.2 Группа служб DIMSE

Следующие службы DIMSE применимы к данному IOD.

Таблица H.4.3.2.2-1. Группа служб DIMSE, применимая к базовому цветовому блоку изображения

DIMSE Service element

Использование (SCU/SCP)

N-SET

M/M


Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.

Примечание

N-CREATE отсутствует, поскольку экземпляры SOP-класса базового цветного блока изображения создаются SCP в результате N-CREATE экземпляра SOP блока плёнки.

В этом разделе описывается поведение служб DIMSE, специфичное для данного IOD. Общее поведение служб DIMSE специфицировано в PS3.7.

H.4.3.2.2.1 N-SET

N-SET может использоваться для обновления экземпляра SOP-класса базового цветного блока изображения.

H.4.3.2.2.1.1 Атрибуты

Атрибуты, которые могут быть обновлены, показаны в Таблице H.4-11.

Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.

Значения атрибутов Magnification Type (2010,0060) и Smoothing Type (2010,0080) конкретного блока изображения переопределяют значения Magnification Type и Smoothing Type блока плёнки.

Таблица H.4-11. Атрибуты N-SET

Имя атрибута

Tag

Использование (SCU/SCP)

Image Box Position

(2020,0010)

M/M

Basic Color Image Sequence

(2020,0111)

M/M

>Samples Per Pixel

(0028,0002)

M/M

>Photometric Interpretation

(0028,0004)

M/M

>Planar Configuration

(0028,0006)

M/M

>Rows

(0028,0010)

M/M

>Columns

(0028,0011)

M/M

>Pixel Aspect Ratio

(0028,0034)

MC/M

(Обязательно, если соотношение сторон не равно 1\1)

>Bits Allocated

(0028,0100)

M/M

>Bits Stored

(0028,0101)

M/M

>High Bit

(0028,0102)

M/M

>Pixel Representation

(0028,0103)

M/M

>Pixel Data

(7FE0,0010)

M/M

Polarity

(2020,0020)

U/M

Magnification Type

(2010,0060)

U/U

Smoothing Type

(2010,0080)

U/U

Requested Image Size

(2020,0030)

U/U

Requested Decimate/Crop Behavior

(2020,0040)

U/U

Original Image Sequence

(2130,00C0)

U/U

>Study Instance UID

(0020,000D)

M/M

>Series Instance UID

(0020,000E)

M/M

>Patient ID

(0010,0020)

M/M

>Referenced SOP Class UID

(0008,1150)

M/M

>Referenced SOP Instance UID

(0008,1155)

M/M


H.4.3.2.2.1.2 Статус

Table H.4.3.1.2.1.2-1 defines the specific Status Code values that may be returned in a N-SET response. See PS3.7 for additional response Status Codes.

Таблица H.4.3.2.2.1.2-1. Значения статуса для SOP-класса базового цветного блока изображения

Статус службы

Дополнительное значение

Код статуса

Предупреждение

Размер изображения превышает размер блока изображения, изображение было уменьшено.

B604

Размер изображения превышает размер блока изображения. Изображение было обрезано для соответствия.

B609

Размер изображения или размер комбинированного печатного изображения превышает размер блока изображения. Изображение или комбинированное печатное изображение было децимировано для вписывания.

B60A

Отказ

Отказ: размер изображения превышает размер блока изображения

C603

Отказ: недостаточно памяти в принтере для хранения изображения

C605

Отказ: размер комбинированного печатного изображения превышает размер блока изображения

C613


H.4.3.2.2.1.3 Поведение

SCU использует N-SET для запроса SCP на обновление экземпляра SOP базового цветного блока изображения. SCU должен указать только SOP Instance UID базового цветного блока изображения, принадлежащего последнему созданному экземпляру SOP блока плёнки, и должен указать список атрибутов, для которых должны быть установлены значения атрибутов.

Чтобы указать SCP стереть изображение в позиции изображения, SCU должен установить нулевую длину и отсутствие значения в атрибуте Basic Color Image Sequence (2020,0111).

SCP должен установить новые значения для указанных атрибутов указанного экземпляра SOP.

Примечание

Изображение в данном N-SET заменяет любое изображение, ранее установленное в блоке изображения.

SCP должен вернуть код статуса запрошенного обновления экземпляра SOP. Значение кодов статуса успеха, предупреждения и отказа определено в Разделе H.2.5.

Если Requested Decimate/Crop Behavior (2020,0040) указывает DECIMATE, Magnification Type (2010,0060) указывает NONE, и изображение слишком велико для вписывания в блок изображения, SCP должен отклонить N-SET.

Цветовые характеристики Pixel Data (7FE0,0010) в базовом цветовом блоке изображения могут быть описаны профилем ICC входного устройства (ICC Input Device Profile), указанным в блоке плёнки, и в этом случае тот же профиль должен применяться ко всем блокам изображений в том же блоке плёнки. См. Раздел H.4.2.2.1 и Раздел H.4.2.2.2.

H.4.3.2.3 Определение SOP-класса и UID

UID SOP-класса базового цветного блока изображения должен иметь значение «1.2.840.10008.5.1.1.4.1».

H.4.3.3 SOP-класс ссылаемого блока изображения (выведен из употребления)

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

H.4.4 SOP-класс базового блока аннотаций

H.4.4.1 Описание IOD

IOD базового блока аннотаций является абстракцией представления аннотации (например, текстовой строки) на плёнке. IOD базового блока аннотаций описывает наиболее используемые параметры представления, связанные с текстом.

Экземпляр SOP базового блока аннотаций создаётся SCP во время создания экземпляра SOP базового блока плёнки на основе значения атрибута Annotation Display Format ID (2010,0030) базового блока плёнки.

H.4.4.2 Группа служб DIMSE

Службы DIMSE, применимые к данному IOD, показаны ниже.

Таблица H.4.4.2-1. Группа служб DIMSE, применимая к базовому блоку аннотаций

Элемент службы сообщений DICOM

Использование (SCU/SCP)

N-SET

U/M


Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.

Примечание

N-CREATE отсутствует, поскольку экземпляры SOP-класса базового блока аннотаций создаются экземпляром SOP блока плёнки.

В этом разделе описывается поведение служб DIMSE, специфичное для данного IOD. Общее поведение служб DIMSE специфицировано в PS3.7.

H.4.4.2.1 N-SET

N-SET используется для обновления экземпляра SOP базового блока аннотаций.

H.4.4.2.1.1 Атрибуты

Атрибуты, которые могут быть обновлены, показаны в Таблице H.4-13.

Таблица H.4-13. Атрибуты N-SET

Имя атрибута

Tag

Использование (SCU/SCP)

Annotation position

(2030,0010)

M/M

Text String

(2030,0020)

U/M


Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.

H.4.4.2.1.2 Статус

Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.

H.4.4.2.1.3 Поведение

SCU использует N-SET для запроса SCP на обновление экземпляра SOP базового блока аннотаций. SCU должен указать только SOP Instance UID базового блока аннотаций, принадлежащего последнему созданному экземпляру SOP блока плёнки, в примитиве запроса N-SET, и должен указать список атрибутов, для которых должны быть установлены значения атрибутов. SCU может стереть текстовую строку, установив нулевое значение длины в атрибуте Text String (2030,0020).

SCP должен установить новые значения для указанных атрибутов указанного экземпляра SOP.

SCP должен вернуть код статуса запрошенного обновления экземпляра SOP. Значение кодов статуса успеха, предупреждения и отказа определено в Разделе H.2.5.

H.4.4.3 Определение SOP-класса и UID

UID SOP-класса базового блока аннотаций должен иметь значение «1.2.840.10008.5.1.1.15».

H.4.5 SOP-класс задания печати

H.4.5.1 Описание IOD

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

SOP-класс задания печати создаётся операцией N-ACTION SOP-класса сеанса плёнки, SOP-класса блока плёнки или SOP-класса запроса pull-печати. Экземпляр SOP задания печати удаляется после печати плёнок или после возникновения условия отказа.

H.4.5.2 Группа служб DIMSE

Службы DIMSE, применимые к данному IOD, показаны ниже.

Таблица H.4.5.2-1. Группа служб DIMSE, применимая к заданию печати

Элемент службы сообщений DICOM

Использование (SCU/SCP)

N-EVENT-REPORT

M/M

N-GET

U/M


Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.

В этом разделе описывается поведение служб DIMSE, специфичное для данного IOD. Общее поведение служб DIMSE специфицировано в PS3.7.

H.4.5.2.1 N-EVENT-REPORT

N-EVENT-REPORT используется для асинхронного сообщения SCU об изменениях состояния выполнения.

H.4.5.2.1.1 Атрибуты

Аргументы N-EVENT-REPORT определены, как показано в Таблице H.4-14.

Примечание

Кодирование информации о событии уведомления определено в PS3.7.

Таблица H.4-14. Информация о событии уведомления

Event Type Name

Event Type ID

Имя атрибута

Tag

Usage (SCP)

Pending

1

Execution Status Info

(2100,0030)

M

Film Session Label

(2000,0050)

U

Printer Name

(2110,0030)

U

Printing

2

Execution Status Info

(2100,0030)

M

Film Session Label

(2000,0050)

U

Printer Name

(2110,0030)

U

Done

3

Execution Status Info

(2100,0030)

M

Film Session Label

(2000,0050)

U

Printer Name

(2110,0030)

U

Отказ

4

Execution Status Info

(2100,0030)

M

Film Session Label

(2000,0050)

U

Printer Name

(2110,0030)

U


H.4.5.2.1.2 Поведение

SCP использует N-EVENT-REPORT для информирования SCU о каждом изменении выполнения. SCP должен использовать N-EVENT-REPORT только в контексте ассоциации, в которой был создан экземпляр SOP задания печати.

Примечание

Если SCU хочет отслеживать полный процесс выполнения задания печати, то SCU следует освобождать ассоциацию только после получения типа события Done или Failure.

SCU должен вернуть подтверждение операции N-EVENT-REPORT.

Если Event Type Name = Failure или Pending, то условие ошибки/ожидания сохраняется в аргументе Execution Status Info. Возможные значения аргумента Execution Status Info определены в Разделе H.4.5.3.

Если Event Type Name = Failure или Done, то SCP должен удалить экземпляр SOP задания печати после получения подтверждения от SCU.

H.4.5.2.1.3 Статус

Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.

H.4.5.2.2 N-GET

N-GET используется для извлечения экземпляра SOP-класса задания печати.

H.4.5.2.2.1 Атрибуты

Атрибуты, которые могут быть извлечены, показаны в Таблице H.4-15.

Таблица H.4-15. Атрибуты N-GET

Имя атрибута

Tag

Использование (SCU/SCP)

Execution Status

(2100,0020)

U/M

Execution Status Info

(2100,0030)

U/M

Print Priority

(2000,0020)

U/M

Creation Date

(2100,0040)

U/U

Creation Time

(2100,0050)

U/U

Printer Name

(2110,0030)

U/U

Originator

(2100,0070)

U/U


Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.

H.4.5.2.2.2 Поведение

SCU использует N-GET для запроса SCP на получение экземпляра SOP задания печати. SCU должен указать в примитиве запроса N-GET UID экземпляра SOP, который должен быть извлечён.

SCP должен вернуть значения для указанных атрибутов указанного экземпляра SOP.

SCP должен вернуть код статуса запрошенного извлечения экземпляра SOP. Значение кодов статуса успеха, предупреждения и отказа определено в Разделе H.2.5.

H.4.5.2.2.3 Статус

Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.

H.4.5.3 Информация о состоянии выполнения

Информация о состоянии определена в PS3.3. Специфические для реализации коды статуса предупреждения и отказа должны быть определены в Заявлении о соответствии (Conformance Statement).

H.4.5.4 Определение SOP-класса и UID

UID SOP-класса задания печати должен иметь значение «1.2.840.10008.5.1.1.14».

H.4.6 SOP-класс принтера

H.4.6.1 Описание IOD

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

Экземпляр SOP принтера создаётся SCP во время запуска принтера твёрдых копий и имеет общеизвестный SOP Instance UID.

H.4.6.2 Группа служб DIMSE

Службы DIMSE, применимые к данному IOD, показаны ниже.

Таблица H.4.6.2-1. Группа служб DIMSE, применимая к принтеру

Элемент службы сообщений DICOM

Использование (SCU/SCP)

N-EVENT-REPORT

M/M

N-GET

U/M


Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.

В этом разделе описывается поведение служб DIMSE, специфичное для данного IOD. Общее поведение служб DIMSE специфицировано в PS3.7.

H.4.6.2.1 N-EVENT-REPORT

N-EVENT-REPORT используется для асинхронного сообщения об изменениях состояния принтера.

H.4.6.2.1.1 Атрибуты

Аргументы N-EVENT-REPORT определены, как показано в Таблице H.4-16.

Примечание

Кодирование информации о событии уведомления определено в PS3.7.

Таблица H.4-16. Информация о событии уведомления

Event Type Name

Event Type ID

Имя атрибута

Tag

Usage (SCP)

Normal

1

Предупреждение

2

Printer Status Info

(2110,0020)

M

Film Destination

(2000,0040)

U

Printer Name

(2110,0030)

U

Отказ

3

Printer Status Info

(2110,0020)

M

Film Destination

(2000,0040)

U

Printer Name

(2110,0030)

U


H.4.6.2.1.2 Поведение

SCP должен использовать N-EVENT-REPORT для информирования SCU о каждом изменении выполнения. SCP должен отправлять события всем SCU, с которыми SCP имеет ассоциацию, использующую принтер, для которого изменяется состояние.

SCU должен вернуть подтверждение операции N-EVENT-REPORT.

Если Event Type Name = Warning или Failure, то условие предупреждения/отказа сохраняется в аргументе Printer Status Info. Возможные значения аргумента Printer Status Info определены в Разделе H.4.6.3.

H.4.6.2.1.3 Статус

Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.

H.4.6.2.2 N-GET

N-GET используется для извлечения экземпляра SOP-класса принтера.

H.4.6.2.2.1 Атрибуты

Атрибуты, которые могут быть извлечены, показаны в Таблице H.4-17.

Таблица H.4-17. Атрибуты N-GET

Имя атрибута

Tag

Использование (SCU/SCP)

Printer Status

(2110,0010)

U/M

Printer Status Info

(2110,0020)

U/M

Printer Name

(2110,0030)

U/U

Manufacturer

(0008,0070)

U/U

Manufacturer Model Name

(0008,1090)

U/U

Device Serial Number

(0018,1000)

U/U

Software Versions

(0018,1020)

U/U

Date Last Calibration

(0018,1200)

U/U

Last Calibration

(0018,1201)

U/U


Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.

H.4.6.2.2.2 Поведение

SCU использует N-GET для запроса SCP на получение экземпляра SOP принтера. SCU должен указать в примитиве запроса N-GET UID экземпляра SOP, который должен быть извлечён.

SCP должен вернуть значения для указанных атрибутов указанного экземпляра SOP.

SCP должен вернуть код статуса запрошенного извлечения экземпляра SOP. Значение кодов статуса успеха, предупреждения и отказа определено в Разделе H.2.5.

H.4.6.2.2.3 Статус

Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.

H.4.6.3 Информация о состоянии принтера

Информация о состоянии определена в PS3.3. Специфические для реализации коды статуса предупреждения и отказа должны быть определены в Заявлении о соответствии (Conformance Statement).

H.4.6.4 Определение SOP-класса и UID

UID SOP-класса принтера должен иметь значение «1.2.840.10008.5.1.1.16».

H.4.6.5 Зарезервированные идентификации

Общеизвестный UID экземпляра SOP принтера должен иметь значение «1.2.840.10008.5.1.1.17».

H.4.7 SOP-класс блока VOI LUT (выведен из употребления)

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

H.4.8 SOP-класс блока наложения изображения (выведен из употребления)

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

H.4.9 SOP-класс LUT представления

H.4.9.1 Описание информационного объекта

Информационный объект LUT представления является абстракцией LUT представления (см. Раздел H.2.1.1). Цель LUT представления состоит в реализации отображения изображений, адаптированного для конкретных модальностей, приложений и пользовательских предпочтений. Он используется для подготовки пиксельных данных изображения для отображения на устройствах, соответствующих стандартной функции отображения в градациях серого, определённой в PS3.14 Grayscale Standard Display Function.

Примечание

Диапазон плотности для печати, от Min Density до Max Density, задаётся либо на уровне блока плёнки, либо на уровне блока изображения. Как следует из определения Min Density и Max Density в PS3.3, если запрошенная минимальная плотность ниже минимальной плотности принтера или запрошенная максимальная плотность выше максимальной плотности принтера, принтер будет использовать свою минимальную или максимальную плотность соответственно при вычислении стандартного отклика.

Выходными данными LUT представления являются значения представления (P-Values). P-значения приблизительно связаны с перцептивным откликом человека. Они предназначены для обеспечения общего входа как для устройств отображения твёрдых копий, так и для устройств отображения мягких копий. P-значения предназначены быть независимыми от конкретного класса или характеристик устройства отображения.

LUT представления не предназначен для изменения внешнего вида пиксельных значений, как специфицировано Photometric Interpretation (0028,0004) и Polarity (2020,0020).

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

Если атрибут Configuration Information (2010,0150) IOD базового блока плёнки содержит информацию, аналогичную LUT представления, то атрибуты LUT представления должны иметь приоритет.

H.4.9.1.1 Отображение P-значений в оптическую плотность

Математическое определение стандартной функции отображения в градациях серого и отображение P-значений в оптическую плотность для рефлексивных и трансмиссивных принтеров содержится в PS3.14 Grayscale Standard Display Function.

H.4.9.2 Группа служб DIMSE

Следующие службы DIMSE применимы к информационному объекту LUT представления, связанному с ассоциацией:

Таблица H.4.9.2-1. Группа служб DIMSE, применимая к LUT представления

Элемент службы сообщений DICOM

Использование (SCU/SCP)

N-CREATE

M/M

N-DELETE

U/M


Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.

В этом разделе описывается поведение служб DIMSE, специфичное для данного информационного объекта. Общее поведение служб DIMSE специфицировано в PS3.7.

H.4.9.2.1 N-CREATE

Элемент службы N-CREATE используется для создания экземпляра SOP-класса LUT представления.

H.4.9.2.1.1 Атрибуты

Список атрибутов элемента службы N-CREATE определён, как показано в Таблице H.4-23.

Таблица H.4-23. Список атрибутов N-CREATE

Имя атрибута

Tag

Использование (SCU/SCP)

Presentation LUT Sequence

(2050,0010)

MC/M

(Required if Presentation LUT Shape (2050,0020) is not present. Not allowed otherwise.)

>LUT Descriptor

(0028,3002)

MC/M

(Обязательно, если последовательность присутствует).

См. Section H.4.9.2.1.1.1.

>LUT Explanation

(0028,3003)

U/U

>LUT Data

(0028,3006)

MC/M

(Обязательно, если последовательность присутствует)

Presentation LUT Shape

(2050,0020)

MC/M

(Required if Presentation LUT Sequence (2050,0010) is not present. Not allowed otherwise.)

SCP должны поддерживать перечислимые значения IDENTITY и LIN OD


H.4.9.2.1.1.1 Дескриптор LUT

Первое значение (количество записей в LUT) должно быть равно:

  • 256 if Bits Stored = 8,

  • 4096 if Bits Stored = 12.

Второе значение должно быть равно 0.

Третье значение (количество бит для каждой записи LUT) должно быть 10–16.

См. определение в PS3.3 для дополнительного пояснения.

H.4.9.2.1.2 Статус

Table H.4.9.2.1.2-1 defines the specific Status Code values that may be returned in a N-CREATE response. See PS3.7 for additional response Status Codes

Таблица H.4.9.2.1.2-1. Значения статуса для SOP-класса LUT представления

Статус службы

Дополнительное значение

Код статуса

Успех

LUT представления успешно создан

0000

Предупреждение

Запрошенные Min Density или Max Density вне рабочего диапазона принтера. Принтер будет использовать соответствующее минимальное или максимальное значение плотности вместо запрошенного.

B605


H.4.9.2.1.3 Поведение

SCU использует элемент службы N-CREATE для запроса SCP на создание экземпляра SOP LUT представления. SCU должен инициализировать атрибуты SOP-класса, как указано в Разделе H.2.4.

SCU должен создать LUT представления до ссылки на него из блока плёнки или блока изображения.

LUT представления сохраняется в SCP до тех пор, пока открыта ассоциация, в которой он был создан, или пока SCU явно не выполнит N-DELETE.

SCP должен вернуть код состояния запрошенного создания экземпляра SOP. Значение кодов состояния успеха, предупреждения и отказа определено в Разделе H.2.5.

SCP должен использовать стандартную функцию отображения в градациях серого, как указано в PS3.14 Grayscale Standard Display Function, для преобразования выхода LUT представления в плотность для печати. Если SCU указывает значения для Illumination (2010,015E) и/или Reflected Ambient Light (2010,0160), эти значения должны использоваться вместо значений SCP по умолчанию или сконфигурированных значений. Если эти значения не предоставлены, SCP должен использовать свои значения по умолчанию или сконфигурированные значения (см. Раздел H.4.2.2.1.1 для предлагаемых значений по умолчанию).

H.4.9.2.2 N-DELETE

Элемент службы N-DELETE используется для удаления экземпляра SOP LUT представления.

H.4.9.2.2.1 Статус

Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.

H.4.9.2.2.2 Поведение

SCU использует элемент службы N-DELETE для запроса SCP на удаление экземпляра SOP LUT представления. SCU должен указать SOP Instance UID LUT представления.

SCP не должен удалять экземпляр SOP LUT представления до тех пор, пока на него имеются незавершённые ссылки. В противном случае SCP должен удалить указанный экземпляр SOP LUT представления. N-DELETE LUT представления предотвратит дальнейшие ссылки SCU на него. SCU не должен ссылаться на ранее удалённый LUT представления. SCP должен вернуть код статуса запрошенного удаления экземпляра SOP LUT представления. Значение кодов статуса успеха, предупреждения и отказа определено в Разделе H.2.5.

H.4.9.2.4 Определение SOP-класса и UID

UID SOP-класса LUT представления — «1.2.840.10008.5.1.1.23».

H.4.10 SOP-класс запроса pull-печати (выведен из употребления)

Этот раздел был ранее определён в DICOM. Он был выведен из употребления. См. PS3.4-2004.

H.4.11 SOP-класс извлечения конфигурации принтера

H.4.11.1 Описание IOD

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

Экземпляр SOP извлечения конфигурации принтера создаётся SCP во время запуска принтера твёрдых копий и имеет общеизвестный SOP Instance UID.

H.4.11.2 Группа служб DIMSE

Службы DIMSE, применимые к данному IOD, показаны в Таблице H.4.11.2-1.

Таблица H.4.11.2-1. Группа служб DIMSE, применимая к извлечению конфигурации принтера

Элемент службы сообщений DICOM

Использование (SCU/SCP)

N-GET

M/M


Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.

В этом разделе описывается поведение служб DIMSE, специфичное для данного IOD. Общее поведение служб DIMSE специфицировано в PS3.7.

H.4.11.2.2 N-GET

N-GET используется для извлечения экземпляра SOP-класса извлечения конфигурации принтера.

H.4.11.2.2.1 Атрибуты

Извлекаемые атрибуты показаны в Таблице H.4-26.

Таблица H.4-26. Атрибуты N-GET

Имя атрибута

Tag

Использование (SCU/SCP)

Printer Configuration Sequence

(2000,001E)

U/M

>SOP Classes Supported

(0008,115A)

-/M

>Maximum Memory Allocation

(2000,0061)

-/M

>Memory Bit Depth

(2000,00A0)

-/M

>Printing Bit Depth

(2000,00A1)

-/M

>Media Installed Sequence

(2000,00A2)

-/M

>>Item Number

(0020,0019)

-/M

>>Medium Type

(2000,0030)

-/M

>>Film Size ID

(2010,0050)

-/M

>>Min Density

(2010,0120)

-/MC

Required if Sequence is Present and Min Density is known

>>Max Density

(2010,0130)

-/M

>Other Media Available Sequence

(2000,00A4)

-/M

>>Medium Type

(2000,0030)

-/M

>>Film Size ID

(2010,0050)

-/M

>>Min Density

(2010,0120)

-/MC

Required if Sequence is Present and Min Density is known

>>Max Density

(2010,0130)

-/M

>Supported Image Display Formats Sequence

(2000,00A8)

-/M

>>Rows

(0028,0010)

-/MC

Required if all Image Boxes in the Display Format have the same number of rows and columns

>>Columns

(0028,0011)

-/MC

Required if all Image Boxes in the Display Format have the same number of rows and columns

>>Image Display Format

(2010,0010)

-/M

>>Film Orientation

(2010,0040)

-/M

>>Film Size ID

(2010,0050)

-/M

>>Printer Resolution ID

(2010,0052)

-/M

>>Printer Pixel Spacing

(2010,0376)

-/M

>>Requested Image Size Flag

(2020,00A0)

-/M

>Default Printer Resolution ID

(2010,0054)

-/M

>Default Magnification Type

(2010,00A6)

-/M

>Other Magnification Types Available

(2010,00A7)

-/M

>Default Smoothing Type

(2010,00A8)

-/M

>Other Smoothing Types Available

(2010,00A9)

-/M

>Configuration Information Description

(2010,0152)

-/M

>Maximum Collated Films

(2010,0154)

-/M

>Decimate/Crop Result

(2020,00A2)

-/M

>Manufacturer

(0008,0070)

-/M

>Manufacturer Model Name

(0008,1090)

-/M

>Printer Name

(2110,0030)

-/M


Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.

H.4.11.2.2.2 Behavior

SCU использует N-GET для запроса SCP на получение экземпляра SOP извлечения конфигурации принтера. SCU должен указать в примитиве запроса N-GET UID экземпляра SOP, подлежащего извлечению.

SCP должен вернуть значения указанных атрибутов указанного экземпляра SOP.

SCP должен вернуть код состояния запрошенного извлечения экземпляра SOP.

Код состояния отказа должен указывать, что SCP не извлёк экземпляр SOP.

H.4.11.2.2.3 Status

Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.

H.4.11.3 Определение и UID класса SOP

UID класса SOP извлечения конфигурации принтера — «1.2.840.10008.5.1.1.16.376».

H.4.11.4 Зарезервированные идентификаторы

Известный UID экземпляра SOP извлечения конфигурации принтера — «1.2.840.10008.5.1.1.17.376».

H.4.12 Класс SOP базового блока оверлея печати (устаревший)

Этот раздел ранее был определён в DICOM. Он устарел. См. PS3.4-2004.

H.5 Согласование ассоциации

Установление ассоциации — первая фаза любого сеанса связи между равноправными DICOM AE. Процедура согласования ассоциации используется для согласования поддерживаемых классов SOP или мета-классов SOP. PS3.7 определяет процедуры ассоциации.

Процедура согласования используется для согласования поддерживаемых мета-классов SOP и поддерживаемых дополнительных классов SOP. SCU и SCP должны поддерживать как минимум один UID мета-класса SOP (например, мета-класс SOP базового управления печатью в оттенках серого) и могут поддерживать дополнительные необязательные классы SOP.

Класс сервиса управления печатью не поддерживает расширенное согласование.

SCU должен указать в запросе A-ASSOCIATE один абстрактный синтаксис в контексте представления для каждого поддерживаемого класса SOP или мета-класса SOP.

Если ассоциация освобождена или прервана, то все экземпляры SOP, за исключением экземпляра SOP задания печати и экземпляра SOP принтера, удаляются.

Примечание

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

H.6 Пример сеанса SCU управления печатью (информативное)

H.6.1 Простой пример

Перемещено в PS3.17.

H.6.2 Расширенный пример (устаревший)

Этот раздел ранее был определён в DICOM. Он устарел. См. PS3.4-1998.

H.7 Пример мета-класса SOP запроса pull-печати (информативное)

Этот раздел ранее был определён в DICOM. Он устарел. См. PS3.4-2004.

H.8 Примеры оверлея (информативное)

Этот раздел ранее был определён в DICOM. Он устарел. См. PS3.4-2004.

I Класс сервиса хранения на носителях

I.1 Обзор

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

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

  1. Обмен изображениями и широким спектром связанной с ними информации.

I.1.2 Определение сервиса

DICOM AE поддерживают класс SOP класса сервиса хранения на носителях, выполняя одну или несколько ролей из трёх: FSC, FSR или FSU. Классы SOP класса сервиса хранения на носителях используют сервисы хранения на носителях (M-WRITE, M-READ, M-DELETE, M-INQUIRE FILE-SET и M-INQUIRE FILE). Эти сервисы определены в PS3.10.

I.2 Поведение

В этом разделе обсуждается поведение FSC, FSR и FSU для классов SOP класса сервиса хранения на носителях.

I.2.1 Поведение FSC

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

FSC должен поддерживать операцию хранения на носителях M-INQUIRE FILE-SET и может дополнительно поддерживать M-INQUIRE FILE.

I.2.2 Поведение FSR

FSR должен быть способен распознавать набор файлов и соответствующий файл DICOMDIR, содержащий класс SOP каталога хранения на носителях. Допустимый набор файлов может содержать только DICOMDIR и никаких других файлов. Если набор файлов содержит другие файлы с сохранёнными экземплярами SOP, FSR должен быть способен вызывать операции M-READ для доступа к содержимому файлов набора файлов. Способ достижения этого выходит за рамки стандарта DICOM.

FSR должен поддерживать операцию хранения на носителях M-INQUIRE FILE и может дополнительно поддерживать M-INQUIRE FILE-SET.

I.2.3 Поведение FSU

FSU должен быть способен распознавать набор файлов и соответствующий файл DICOMDIR, содержащий класс SOP каталога хранения на носителях. Допустимый набор файлов может содержать только DICOMDIR и никаких других файлов. Если набор файлов содержит другие файлы с сохранёнными экземплярами SOP, FSU должен быть способен вызывать операции M-READ для доступа к содержимому файлов набора файлов. Способ достижения этого выходит за рамки стандарта DICOM.

FSU должен поддерживать операцию хранения на носителях M-INQUIRE FILE и M-INQUIRE FILE-SET.

FSU должен быть способен создавать один или несколько новых файлов, принадлежащих набору файлов, вызывая операции M-WRITE с экземплярами SOP, удовлетворяющими требованиям соответствующего IOD. Ответственность FSU — обеспечить, чтобы M-WRITE привёл к созданию корректно сформированного файла DICOM. Способ достижения этого выходит за рамки стандарта DICOM. FSU должен быть способен обновлять содержимое файла DICOMDIR с помощью операций M-DELETE и/или M-WRITE.

I.3 Соответствие

I.3.1 Соответствие в качестве FSC

Реализация, соответствующая одному из классов SOP класса сервиса хранения на носителях:

  1. должна отвечать требованиям, указанным в Разделе I.2.1;

  2. должна отвечать требованиям, указанным в PS3.10;

  3. должна выполнять операции M-WRITE в соответствии со спецификацией класса SOP, определяемой UID класса SOP в метафайле;

  4. должна поддерживать класс SOP каталога хранения на носителях (сохраняемый в файле DICOMDIR).

I.3.2 Соответствие в качестве FSR

Реализация, соответствующая одному из классов SOP класса сервиса хранения на носителях:

  1. должна отвечать требованиям, указанным в Разделе I.2.2;

  2. должна отвечать требованиям, указанным в PS3.10;

  3. должна выполнять операции M-READ в соответствии со спецификацией класса SOP, определяемой UID класса SOP в метафайле. M-READ неподдерживаемых классов SOP должен просто приводить к игнорированию таких сохранённых наборов данных;

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

I.3.3 Соответствие в качестве FSU

Реализация, соответствующая одному из классов SOP класса сервиса хранения на носителях:

  1. должна отвечать требованиям, указанным в Разделе I.2.3;

  2. должна отвечать требованиям, указанным в PS3.10;

  3. должна выполнять операции M-READ в соответствии со спецификацией класса SOP, определяемой UID класса SOP в метафайле. M-READ неподдерживаемых классов SOP должен просто приводить к игнорированию таких сохранённых наборов данных;

  4. должна выполнять операции M-WRITE в соответствии со спецификацией класса SOP, определяемой UID класса SOP в метафайле;

  5. должна поддерживать класс SOP каталога хранения на носителях (сохраняемый в файле DICOMDIR). Каталоги, содержащие модуль информации каталога, должны обновляться FSU. Каталоги, не содержащие модуля информации каталога, не должны обновляться FSU;

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

I.3.4 Требования к заявлению о соответствии

Реализация класса сервиса хранения на носителях может поддерживать одну или несколько ролей, как указано в Таблице I.3-1. Кроме того, реализация может соответствовать одному или нескольким классам SOP класса сервиса хранения на носителях, определённым в Разделе I.4. Заявление о соответствии должно быть оформлено в формате, определённом PS3.2.

Таблица I.3-1. Допустимые комбинации ролей

Роли

FSR

FSC

FSU

С модулем информации каталога

Разрешено

Разрешено

Разрешено. Каталог должен обновляться

Без модуля информации каталога

Разрешено

Разрешено

Разрешено. Каталог не должен обновляться


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

  • поддерживаемое подмножество базовой модели информационного объекта каталога;

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

I.3.5 Стандартное расширенное, специализированное и частное соответствие

В дополнение к стандартным классам SOP хранения на носителях реализации могут поддерживать стандартные расширенные, специализированные и/или частные классы SOP, как определено в PS3.2.

Для всех трёх типов классов SOP реализациям разрешается соответствовать в качестве FSC, FSR, обоих ролей или FSU. Заявление о соответствии должно быть оформлено в формате, определённом в PS3.2.

I.4 Классы SOP хранения на носителях

Классы SOP в классе сервиса хранения на носителях идентифицируют композитные IOD для хранения. IOD следующих классов SOP могут быть сохранены:

  • все IOD классов SOP, указанные для основанного на DIMSE C-STORE класса сервиса хранения, идентифицированного в Таблице B.5-1

  • все IOD классов SOP, указанные для основанного на DIMSE C-STORE класса сервиса хранения объектов, не связанных с пациентом, идентифицированного в Таблице GG.3-1

  • IOD класса SOP каталога носителей, идентифицированный в Таблице I.4-1

Таблица I.4-1. Стандартные классы SOP хранения на носителях

Имя класса SOP

UID класса SOP

Спецификация IOD (определена в PS3.3)

Media Storage Directory Storage

1.2.840.10008.1.3.10

Basic Directory IOD


Примечание

  1. За исключением класса SOP каталога хранения на носителях, всем классам SOP в классе сервиса хранения на носителях присвоено то же значение UID, что и соответствующим классам SOP сетевого обмена. Это было сделано для упрощения назначения UID. Хотя эти классы SOP основаны на разных сервисах, контекст их использования должен однозначно отличать класс SOP, используемый для хранения на носителях, от класса SOP сетевого обмена.

  2. Хранение нормализованных экземпляров SOP печати на носителях ранее было определено в DICOM. Они устарели. См. PS3.4-1998.

  3. Хранение отсоединённых и автономных экземпляров SOP на носителях ранее было определено в DICOM. Они устарели. См. PS3.4-2004

I.4.1 Специализация для стандартных классов SOP (устаревшая)

См. Раздел B.5.1 «Специализация для стандартных классов SOP».

I.5 Устаревшие стандартные классы SOP

См. Section B.6.

J Класс сервиса фиксации хранения

J.1 Обзор

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

Механизм, в настоящее время определённый в DICOM для сетевого хранения экземпляров SOP — класс сервиса хранения — позволяет пользователю класса сервиса (SCU) передавать изображения и другие композитные экземпляры SOP поставщику класса сервиса (SCP). Однако класс сервиса хранения не указывает, что SCP явно принимает ответственность за обеспечение сохранности данных. То есть отсутствует обязательство, что SCP сделает что-либо сверх приёма переданных экземпляров SOP. Для обеспечения управления медицинскими изображениями в дополнение к обмену медицинскими изображениями необходим класс сервиса в рамках DICOM, гарантирующий явно определённое обязательство по сохранению экземпляров SOP.

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

Реализация SCP определяет, как она обеспечивает своё обязательство по хранению. Некоторые SCP могут обязаться постоянно хранить экземпляры SOP (например, архивная система), тогда как другие SCP могут обязаться обеспечить хранение экземпляров SOP в течение ограниченного времени. SCP требуется документировать в своём заявлении о соответствии характер своего обязательства по хранению (например, длительность хранения, возможности и задержка извлечения, ёмкость).

Наличие ссылки для доступа к пиксельным данным не должно быть достаточным для SCP для принятия обязательства по хранению. Требуется копия всех пиксельных данных.

Примечание

Эта ситуация может возникнуть в контексте синтаксиса передачи пиксельных данных по ссылке JPIP.

После того как SCP принял обязательство по хранению экземпляров SOP, SCU может решить, что целесообразно удалить свои копии экземпляров SOP. Такие типы поведения выходят за рамки данного стандарта, однако SCU требуется документировать это поведение в своём заявлении о соответствии.

J.1.2 Обзор моделей

Запрос фиксации хранения может быть выполнен с использованием push-модели.

Push-модель предполагает, что SCU передаёт экземпляры SOP на SCP с использованием соответствующего механизма, выходящего за рамки данного класса сервиса. Фиксация хранения затем инициируется передачей запроса фиксации хранения, содержащего ссылки на набор из одного или нескольких экземпляров SOP. Успех или неудача фиксации хранения впоследствии указывается через уведомление от SCP к SCU.

Примечание

  1. Pull-модель была определена в более ранних версиях, но устарела. См. PS3.4-2001.

  2. Как указано, механизмы, используемые для передачи экземпляров SOP от SCU к SCP, выходят за рамки данного класса сервиса. Однако типичные механизмы можно найти в классе сервиса хранения, классе сервиса запроса/получения или обмене через носители.

J.2 Обзор соответствия

Прикладные сервисы, охватываемые данным классом сервиса, специфицируются через класс SOP push-модели фиксации хранения.:

Реализация SCP класса сервиса фиксации хранения должна поддерживать класс SOP push-модели фиксации хранения.

Класс SOP определяет атрибуты, операции, уведомления и поведение, применимые к классу SOP. Требования соответствия должны быть определены с точки зрения поставщика класса сервиса (SCP) и пользователя класса сервиса (SCU).

Класс сервиса фиксации хранения использует IOD фиксации хранения, как определено в PS3.3, и сервисы DIMSE N-ACTION и N-EVENT-REPORT, специфицированные в PS3.7.

J.2.1 Согласование ассоциации

Установление ассоциации — первая фаза любого сеанса связи между равноправными DICOM AE. Правила согласования ассоциации, указанные в PS3.7, должны использоваться для согласования поддерживаемых классов SOP.

Поддержка согласования выбора ролей SCP/SCU обязательна. Расширенное согласование класса SOP не должно поддерживаться.

Реализация SCP класса сервиса фиксации хранения должна поддерживать класс SOP push-модели фиксации хранения.

J.3 Класс SOP push-модели фиксации хранения

Класс SOP push-модели фиксации хранения предназначен для прикладных сущностей, нуждающихся в фиксации хранения, где SCU определяет момент передачи экземпляров SOP. SCU передаёт экземпляры SOP на SCP с использованием соответствующего механизма. Запрос фиксации хранения передаётся на SCP вместе со списком ссылок на один или несколько экземпляров SOP. Успех или неудача фиксации хранения впоследствии указывается через уведомление от SCP к SCU.

J.3.1 Группа сервисов DIMSE

Сервисы DIMSE-N, применимые к классу SOP push-модели фиксации хранения, показаны в Таблице J.3.1-1.

Таблица J.3.1-1. Группа сервисов DIMSE, применимая к push-модели фиксации хранения

Элемент службы сообщений DICOM

Использование (SCU/SCP)

N-EVENT-REPORT

M/M

N-ACTION

M/M


Сервисы и протокол DIMSE-N специфицированы в PS3.7.

J.3.2 Операции

DICOM AE, заявляющие о соответствии данному классу SOP в роли SCU, должны вызывать операцию N-ACTION. DICOM AE, заявляющие о соответствии данному классу SOP в роли SCP, должны поддерживать операцию N-ACTION.

J.3.2.1 Запрос фиксации хранения

Операция запроса фиксации хранения позволяет SCU запросить SCP принять обязательство по обеспечению сохранности набора экземпляров SOP. Эта операция должна быть вызвана через примитив N-ACTION.

J.3.2.1.1 Информация о действии

DICOM AE, заявляющие о соответствии данному классу SOP в роли SCU и/или SCP, должны поддерживать типы действий и информацию о действии, как указано в Таблице J.3-1.

Таблица J.3-1. Запрос фиксации хранения — Информация о действии

Имя типа действия

Идентификатор типа действия

Имя атрибута

Tag

Использование (SCU/SCP)

Запрос фиксации хранения

1

Transaction UID

(0008,1195)

1/1

Storage Media File-Set ID

(0088,0130)

3/3

См. Section J.3.2.1.1.1.

Storage Media File-Set UID

(0088,0140)

3/3

См. Section J.3.2.1.1.1.

Referenced SOP Sequence

(0008,1199)

1/1

>Referenced SOP Class UID

(0008,1150)

1/1

>Referenced SOP Instance UID

(0008,1155)

1/1

См. Section J.3.2.1.1.3.

>Storage Media File-Set ID

(0088,0130)

3/3

См. Section J.3.2.1.1.1.

>Storage Media File-Set UID

(0088,0140)

3/3

См. Section J.3.2.1.1.1.


J.3.2.1.1.1 Атрибуты идентификатора набора файлов на носителе хранения

Если они присутствуют, Storage Media File-Set ID (0088,0130) и Storage Media File-Set UID (0088,0140) должны находиться либо вне Referenced SOP Sequence (0008,1199), либо внутри одного или нескольких элементов этой последовательности, но не одновременно. Если они находятся вне последовательности, то все экземпляры SOP в последовательности должны быть доступны для извлечения из указанного набора файлов на носителе хранения. Если они находятся внутри элемента этой последовательности, то экземпляр SOP, на который ссылается этот элемент, должен быть доступен для извлечения из указанного набора файлов на носителе хранения.

J.3.2.1.1.2 Атрибут последовательности ссылок на выполненный этап процедуры (устаревший)

Referenced Performed Procedure Step Sequence (0008,1111) был включён в более ранние версии, но его использование здесь устарело. См. PS3.4-2001, где этот атрибут ранее назывался Referenced Study Component Sequence.

Примечание

Этот раздел ранее определял способ ссылки на завершённый компонент исследования (Study Component) и семантику, согласно которой список изображений в запросе фиксации хранения представлял полный набор. Этот раздел устарел, поскольку классы SOP этапа выполненной процедуры модальности (Modality Performed Procedure Step) обеспечивают ту же функциональность в более подходящем сервисе.

J.3.2.1.1.3 Ссылка на экземпляр SOP

На экземпляр SOP можно ссылаться только один раз в пределах Referenced SOP Sequence (0008,1199).

J.3.2.1.2 Поведение пользователя класса сервиса

SCU должен использовать примитив N-ACTION для запроса SCP обеспечить сохранность набора экземпляров SOP. Экземпляры SOP указываются в информации о действии, как определено в Таблице J.3-1. Идентификатор типа действия (Action Type ID) должен быть установлен в 1, указывая запрос фиксации хранения.

SCU должен предоставить атрибут Transaction UID (0008,1195) для однозначной идентификации каждого запроса фиксации хранения. Значение атрибута Transaction UID будет включено SCP в результат фиксации хранения (см. Раздел J.3.3.1). Использование атрибута Transaction UID позволяет SCU сопоставлять запросы и результаты, которые могут происходить в рамках одной или разных ассоциаций.

Примитив N-ACTION должен содержать известный UID экземпляра SOP push-модели фиксации хранения (определённый в Разделе J.3.5) в параметре Requested SOP Instance UID.

Примечание

При описанном здесь использовании не происходит явного создания экземпляра SOP, над которым примитив N-ACTION мог бы выполняться. Вместо этого примитив N-ACTION работает с постоянным известным экземпляром SOP. Этот экземпляр SOP концептуально создаётся при запуске каждого приложения SCP класса сервиса фиксации хранения.

После получения от SCP успешного кода состояния ответа N-ACTION SCU узнаёт, что SCP получил запрос N-ACTION. При получении любого другого кода состояния ответа N-ACTION от SCP SCU узнаёт, что SCP не будет обрабатывать запрос и, следовательно, не примет обязательство по хранению экземпляров SOP, на которые ссылается запрос фиксации хранения. Действия, предпринимаемые SCU при получении состояния, выходят за рамки данного стандарта. При получении кода состояния отказа Transaction UID больше не активен и не должен повторно использоваться для других транзакций.

В любое время после получения ответа N-ACTION SCU может освободить ассоциацию, по которой он отправил запрос N-ACTION.

Примечание

  1. Отказ фиксации хранения будет сигнализироваться через примитив N-EVENT-REPORT.

  2. В ситуациях, когда экземпляры SOP передаются через обмен носителями, запрос фиксации хранения может завершиться неудачей, поскольку носитель, содержащий указанные экземпляры SOP, мог ещё не быть прочитан. Атрибуты (0088,0130) File-Set ID и (0088,0140) File-Set UID могут как присутствовать, так и отсутствовать в случае обмена носителями. Они могут быть предоставлены для облегчения идентификации носителя, содержащего переданные экземпляры SOP, со стороны SCP фиксации хранения.

J.3.2.1.3 Поведение поставщика класса сервиса

После получения запроса N-ACTION SCP должен вернуть через примитив ответа N-ACTION код состояния ответа N-ACTION, применимый к соответствующему запросу. Код успешного состояния означает, что SCP успешно получил запрос. Код состояния отказа означает, что SCP не обрабатывает запрос.

Примечание

  1. Отказ фиксации хранения будет сигнализироваться через примитив N-EVENT-REPORT.

  2. Когда запрос фиксации хранения получен SCP, он может немедленно оценить список ссылок, для которых запрашивается фиксация хранения, и вернуть N-EVENT-REPORT. В ситуациях, когда экземпляры SOP передаются через обмен носителями, N-EVENT-REPORT может завершиться неудачей, поскольку носитель, содержащий указанные экземпляры SOP, мог ещё не быть прочитан. Атрибуты (0088,0130) File-Set ID и (0088,0140) File-Set UID могут как присутствовать, так и отсутствовать в случае обмена носителями. Они могут использоваться для облегчения идентификации носителя, содержащего переданные экземпляры SOP, со стороны SCP фиксации хранения.

J.3.2.1.4 Коды состояния

Для сервиса N-ACTION не определены специфические для класса сервиса значения состояния. См. PS3.7 для общих кодов состояния ответа.

J.3.3 Уведомления

DICOM AE, заявляющие о соответствии данному классу SOP в роли SCP, должны вызывать запрос N-EVENT-REPORT. DICOM AE, заявляющие о соответствии данному классу SOP в роли SCU, должны быть способны принимать запрос N-EVENT-REPORT.

J.3.3.1 Результат фиксации хранения

Уведомление о результате фиксации хранения позволяет SCP сообщить SCU, принял ли он ответственность за фиксацию хранения экземпляров SOP, на которые ссылается запрос фиксации хранения. Это уведомление также используется для передачи информации об ошибках (т.е. фиксация хранения не могла быть достигнута для одного или нескольких указанных экземпляров SOP). Это уведомление должно быть вызвано через примитив N-EVENT-REPORT.

J.3.3.1.1 Информация о событии

DICOM AE, заявляющие о соответствии данному классу SOP в роли SCU и/или SCP, должны поддерживать типы событий и информацию о событии, как указано в Таблице J.3-2.

Таблица J.3-2. Результат фиксации хранения — Информация о событии

Имя типа события

Идентификатор типа события

Имя атрибута

Tag

Использование (SCP)

Запрос фиксации хранения выполнен успешно

1

Transaction UID

(0008,1195)

1

Retrieve AE Title

(0008,0054)

3

См. Section J.3.3.1.1.1.

Storage Media File-Set ID

(0088,0130)

3

См. Section J.3.3.1.1.2.

Storage Media File-Set UID

(0088,0140)

3

См. Section J.3.3.1.1.2.

Referenced SOP Sequence

(0008,1199)

1

>Referenced SOP Class UID

(0008,1150)

1

>Referenced SOP Instance UID

(0008,1155)

1

>Retrieve AE Title

(0008,0054)

3

См. Section J.3.3.1.1.1.

>Storage Media File-Set ID

(0088,0130)

3

См. Section J.3.3.1.1.2.

>Storage Media File-Set UID

(0088,0140)

3

См. Section J.3.3.1.1.2.

Запрос фиксации хранения завершён — имеются отказы

2

Transaction UID

(0008,1195)

1

Retrieve AE Title

(0008,0054)

3

См. Section J.3.3.1.1.1.

Storage Media File-Set ID

(0088,0130)

3

См. Section J.3.3.1.1.2.

Storage Media File-Set UID

(0088,0140)

3

См. Section J.3.3.1.1.2.

Referenced SOP Sequence

(0008,1199)

1C

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

>Referenced SOP Class UID

(0008,1150)

1

>Referenced SOP Instance UID

(0008,1155)

1

>Retrieve AE Title

(0008,0054)

3

См. Section J.3.3.1.1.1.

>Storage Media File-Set ID

(0088,0130)

3

См. Section J.3.3.1.1.2.

>Storage Media File-Set UID

(0088,0140)

3

См. Section J.3.3.1.1.2.

Failed SOP Sequence

(0008,1198)

1

>Referenced SOP Class UID

(0008,1150)

1

>Referenced SOP Instance UID

(0008,1155)

1

>Failure Reason

(0008,1197)

1


J.3.3.1.1.1 Атрибут заголовка AE извлечения

Если он присутствует, Retrieve AE Title (0008,0054) должен находиться либо вне Referenced SOP Sequence (0008,1199), либо внутри одного или нескольких элементов этой последовательности, но не одновременно. Если он находится вне последовательности, то все экземпляры SOP в последовательности должны быть доступны для извлечения с указанного Retrieve AE Title. Если он находится внутри элемента этой последовательности, то экземпляр SOP, на который ссылается этот элемент, должен быть доступен для извлечения с указанного Retrieve AE Title.

J.3.3.1.1.2 Атрибуты идентификатора набора файлов на носителе хранения

Если они присутствуют, Storage Media File-Set ID (0088,0130) и Storage Media File-Set UID (0088,0140) должны находиться либо вне Referenced SOP Sequence (0008,1199), либо внутри одного или нескольких элементов этой последовательности, но не одновременно. Если они находятся вне последовательности, то все экземпляры SOP в последовательности должны быть доступны для извлечения из указанного набора файлов на носителе хранения. Если они находятся внутри элемента этой последовательности, то экземпляр SOP, на который ссылается этот элемент, должен быть доступен для извлечения из указанного набора файлов на носителе хранения.

J.3.3.1.2 Поведение поставщика класса сервиса

Если SCP определяет, что он успешно завершил фиксацию хранения для всех экземпляров SOP, указанных в запросе фиксации хранения, SCP должен выпустить N-EVENT-REPORT с идентификатором типа события, установленным в 1 (Запрос фиксации хранения выполнен успешно). Это событие должно включать ссылки на успешно сохранённые экземпляры SOP. SCP должен сохранить указанные экземпляры SOP в соответствии с уровнем хранения 2 (полный), как определено в классе сервиса хранения (т.е. должен сохранить все атрибуты, включая частные атрибуты). Класс сервиса хранения определён в PS3.4. После отправки N-EVENT-REPORT Transaction UID больше не активен и не должен повторно использоваться для других транзакций.

Если определено, что фиксация хранения не может быть достигнута для одного или нескольких указанных экземпляров SOP, SCP должен выпустить N-EVENT-REPORT с идентификатором типа события, установленным в 2 (Запрос фиксации хранения завершён — имеются отказы), сообщающий, что SCP не принимает обязательство по хранению всех экземпляров SOP. Это событие должно включать ссылки на отклонённые экземпляры SOP вместе со ссылками на те экземпляры SOP, которые были успешно сохранены. Для каждого отклонённого экземпляра SOP причина отказа должна быть описана атрибутом Failure Reason. После отправки N-EVENT-REPORT Transaction UID больше не активен и не должен повторно использоваться для других транзакций.

Полный набор экземпляров SOP, указанных атрибутом Referenced SOP Sequence (0008,1199) в инициирующем N-ACTION, должен присутствовать в обоих типах событий — либо в Referenced SOP Sequence (0008,1199), либо в Failed SOP Sequence (0008,1198).

N-EVENT-REPORT должен включать то же значение атрибута Transaction UID (0008,1195), что и в инициирующем N-ACTION.

SCP должен быть способен выпускать N-EVENT-REPORT по другой ассоциации, отличной от той, на которой выполнялась операция N-ACTION.

Примечание

  1. SCP может попытаться выпустить N-EVENT-REPORT по той же ассоциации, но эта операция может завершиться неудачей, поскольку SCU вправе освободить в любое время ассоциацию, по которой он отправил запрос N-ACTION. Поскольку DICOM по умолчанию назначает инициатору ассоциации роль SCU, SCP (т.е. инициатор ассоциации) согласует роль SCP с помощью согласования выбора ролей SCU/SCP (см. PS3.7).

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

  3. Необязательные атрибуты Retrieve AE Title (0008,0054), Storage Media File-Set ID (0088,0130) и Storage Media File-Set UID (0088,0140) в информации о событии позволяют SCP указать место, где он сохранил экземпляры SOP для обеспечения их сохранности. Например, SCP может передать экземпляры SOP третьей прикладной сущности с использованием данного класса сервиса, и в этом случае он может использовать атрибут Retrieve AE Title для указания реального местоположения данных. Другой пример: если SCP хранит данные на носителях, он может указать это с помощью атрибутов Storage Media File-Set ID и UID.

J.3.3.1.3 Поведение пользователя класса сервиса

SCU должен быть способен принимать N-EVENT-REPORT по другой ассоциации, отличной от той, на которой выполнялась операция N-ACTION.

Примечание

Для получения этого N-EVENT-REPORT SCU принимает ассоциацию, в которой роль SCP предлагается SCP фиксации хранения, выступающим в роли инициатора ассоциации.

SCU должен вернуть через примитив ответа N-EVENT-REPORT код состояния ответа N-EVENT-REPORT, применимый к соответствующему запросу. Действия, предпринимаемые SCU при получении N-EVENT-REPORT, выходят за рамки данного стандарта, но указываются в его заявлении о соответствии.

Примечание

В случае, когда SCP указывает, что он не может обеспечить фиксацию хранения для некоторых экземпляров SOP, SCU может, например, повторно отправить отклонённые экземпляры SOP на SCP (через класс сервиса хранения) и затем повторно передать запрос N-ACTION. Однако это поведение выходит за рамки данного стандарта.

J.3.3.1.4 Коды состояния

Для сервиса N-EVENT-REPORT не определены специфические для класса сервиса значения состояния. См. PS3.7 для общих кодов состояния ответа.

Примечание

Этот раздел относится к кодам состояния, возвращаемым примитивом ответа N-EVENT-REPORT. Атрибут Failure Reason, возвращаемый в информации о событии результата фиксации хранения (см. PS3.3), описан в IOD фиксации хранения.

J.3.4 UID класса SOP push-модели фиксации хранения

Класс SOP push-модели фиксации хранения должен быть однозначно идентифицирован UID класса SOP push-модели фиксации хранения, который должен иметь значение «1.2.840.10008.1.20.1».

J.3.5 Зарезервированный идентификатор push-модели фиксации хранения

Известный UID экземпляра SOP push-модели фиксации хранения должен иметь значение «1.2.840.10008.1.20.1.1».

J.3.6 Требования к соответствию

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

Реализация может заявить о соответствии данному классу SOP в роли SCU, SCP или обоих. Заявление о соответствии должно быть оформлено в формате, определённом в PS3.2.

J.3.6.1 Соответствие SCU

Реализация, соответствующая данному классу SOP в роли SCU, должна отвечать требованиям соответствия для

  • операций и действий, которые она вызывает

  • уведомлений, которые она принимает.

Механизмы, используемые SCU для передачи экземпляров SOP на SCP, должны быть документированы.

J.3.6.1.1 Операции

SCU должен документировать в заявлении о соответствии действия и поведение, вызывающие генерацию SCU примитива N-ACTION (запрос фиксации хранения).

SCU должен указать UID классов SOP, для которых он может запросить фиксацию хранения.

SCU должен указать срок применимости Transaction UID. Это может быть указано как ограничение по времени или как политика, определяющая конец транзакции (например, как долго SCU будет ожидать N-EVENT-REPORT).

SCU должен указать, поддерживает ли он необязательные атрибуты Storage Media File-Set ID и UID в N-ACTION. Если эти атрибуты поддерживаются, SCU должен также указать, какие профили приложений хранения на носителях поддерживаются.

Заявление о соответствии должно быть оформлено в формате, определённом в PS3.2

J.3.6.1.2 Уведомления

SCU должен документировать в заявлении о соответствии поведение и действия, предпринимаемые SCU при получении примитива N-EVENT-REPORT (результат фиксации хранения).

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

SCU должен указать поведение и действия, выполняемые при получении кода состояния отказа (т.е. механизмы восстановления и т.д.).

Заявление о соответствии должно быть оформлено в формате, определённом в PS3.2

J.3.6.2 Соответствие SCP

Реализация, соответствующая данному классу SOP в роли SCP, должна отвечать требованиям соответствия для

  • операций и действий, которые она выполняет

  • уведомлений, которые она генерирует.

J.3.6.2.1 Операции

SCP должен документировать в заявлении о соответствии поведение и действия SCP при получении примитива N-ACTION (запрос фиксации хранения).

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

  • при каких условиях SCP будет удалять экземпляры SOP

  • постоянство хранения

  • ёмкость

  • изменчивость (волатильность)

  • прочую относящуюся к делу информацию

SCP должен указать механизмы и характеристики получения сохранённых экземпляров SOP, такие как:

  • поддерживаемые службы запроса/получения

  • задержка

  • прочую относящуюся к делу информацию

SCP должен указать, поддерживает ли он необязательные атрибуты Storage Media File-Set ID и UID в N-ACTION. Если эти атрибуты поддерживаются, SCP должен также указать, какие профили приложений хранения на носителях поддерживаются.

Заявление о соответствии должно быть оформлено в формате, определённом в PS3.2.

J.3.6.2.2 Уведомления

SCP должен документировать в заявлении о соответствии поведение и действия, вызывающие генерацию SCP примитива N-EVENT-REPORT (результат фиксации хранения).

SCP должен указать, поддерживает ли он необязательные атрибуты Storage Media File-Set ID и UID в N-EVENT-REPORT, и описать политики использования носителя. SCP должен также указать, какие профили приложений хранения на носителях поддерживаются.

SCP должен указать, поддерживает ли он необязательный атрибут Retrieve AE Title (0008,0054) в N-EVENT-REPORT, и описать политики его использования.

Заявление о соответствии должно быть оформлено в формате, определённом в PS3.2.

J.4 Класс SOP модели вытягивания фиксации хранения (Устаревшее)

Модель вытягивания (Pull Model) была определена в более ранних версиях, но признана устаревшей. См. PS3.4-2001.

J.5 Примеры фиксации хранения (Информативное)

Перемещено в PS3.17

K Сервисный класс базового управления рабочим списком

K.1 Обзор

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

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

Рабочий список — это структура для представления информации, связанной с определённым набором задач. Он определяет конкретные детали для каждой задачи. Эта информация поддерживает выбор задачи, которая будет выполнена первой, и поддерживает выполнение этой задачи.

Примечание

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

Настоящее приложение определяет службу для передачи таких рабочих списков. Ниже приведены характеристики данного сервисного класса:

  • Рабочий список должен запрашиваться прикладной сущностью (Application Entity, AE), связанной с приложением, на котором или посредством которого должны выполняться задачи, включённые в рабочий список. В этом запросе может использоваться ряд ключей поиска, определённых для каждого конкретного класса SOP рабочего списка.

  • Рабочий список состоит из элементов рабочего списка, каждый из которых связан с одной задачей. Элемент рабочего списка содержит атрибуты из различных объектов, связанных с задачей.

Примечание

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

  2. Информационные модели базового рабочего списка всегда состоят из одного уровня запроса, который может состоять из одной или нескольких сущностей. В сервисном классе базового управления рабочим списком не проводится различие между иерархическим и реляционным использованием C-FIND.

K.1.2 Соглашения

Ключевые атрибуты служат двум целям: они могут использоваться как атрибуты сопоставления (Matching Key Attributes) и как возвращаемые ключевые атрибуты (Return Key Attributes). Атрибуты сопоставления могут использоваться для сопоставления (критерии, используемые в запросе C-FIND для определения соответствия сущности запросу). Возвращаемые ключевые атрибуты могут использоваться для указания желаемых возвращаемых атрибутов (какие элементы, помимо атрибутов сопоставления, должны быть возвращены в ответе C-FIND).

Примечание

Ключи сопоставления обычно используются в конструкции SQL 'where'. Возвращаемые ключи обычно используются в конструкции SQL 'select' для передачи значений атрибутов.

Атрибуты сопоставления могут иметь тип «обязательный» (required, R) или «необязательный» (optional, O). Возвращаемые ключевые атрибуты могут иметь тип 1, 1C, 2, 2C, 3, как определено в PS3.5.

K.1.3 Информационная модель рабочего списка

Для того чтобы выступать в роли поставщика сервисного класса (Service Class Provider, SCP) сервисного класса базового управления рабочим списком, прикладная сущность DICOM (AE) обладает информацией об атрибутах ряда управляемых записей рабочего списка. Эта информация организована в информационные модели рабочего списка.

Рабочие списки реализуются на основе чётко определённых информационных моделей. Конкретный класс SOP сервисного класса базового управления рабочим списком состоит из информативного обзора, определения информационной модели и группы служб DIMSE-C. В этом сервисном классе информационная модель играет роль, аналогичную информационной объектной дефиниции (IOD) большинства других сервисных классов DICOM.

K.1.4 Определение службы

Два равноправных AE DICOM реализуют класс SOP сервисного класса базового управления рабочим списком, при этом одна выступает в роли SCU, а другая — в роли SCP. Классы SOP сервисного класса базового управления рабочим списком реализуются с использованием службы DIMSE-C C-FIND, как определено в PS3.7.

Для DIMSE-C C-FIND определены как базовое, так и расширенное поведение. Базовое поведение определяет минимальный уровень соответствия для всех реализаций в целях обеспечения интероперабельности. Расширенное поведение дополняет базовое поведение, предоставляя дополнительные возможности, которые могут согласовываться независимо при установлении ассоциации.

Следующее описание службы DIMSE-C C-FIND даёт краткий обзор семантики SCU/SCP.

Служба C-FIND передаёт следующую семантику:

  • SCU запрашивает у SCP выполнение сопоставления по ключам сопоставления и возврата значений по возвращаемым ключам, указанным в идентификаторе запроса, по информации, которой располагает SCP, в отношении объектов, указанных в классе SOP.

    Примечание

    В настоящем приложении термин «идентификатор» относится к параметру службы Identifier службы C-FIND, как определено в PS3.7.

  • SCP генерирует ответ C-FIND для каждого совпадения с идентификатором, содержащим значения всех атрибутов сопоставления и всех известных запрошенных возвращаемых ключевых атрибутов. Каждый ответ содержит один элемент рабочего списка. Все такие ответы будут содержать статус Pending. Статус Pending указывает на то, что процесс сопоставления не завершён.

  • Когда процесс сопоставления завершён, отправляется ответ C-FIND со статусом Success и без идентификатора.

  • Ответ Failure на запрос C-FIND указывает на то, что SCP не может обработать запрос.

  • SCU может отменить службу C-FIND, выдав запрос C-CANCEL-FIND в любой момент во время обработки службы C-FIND. SCP прервёт всё сопоставление и вернёт статус Cancel.

    Примечание

    SCU должен быть готов получать ответы C-FIND, отправляемые SCP, до тех пор, пока SCP окончательно не обработает запрос C-CANCEL-FIND.

K.2 Определение информационной модели рабочего списка

Информационная модель рабочего списка идентифицируется классом SOP, согласованным при установлении ассоциации. Класс SOP состоит как из информационной модели, так и из группы служб DIMSE-C.

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

  • определение модели «сущность-связь»

  • определение ключевых атрибутов;

K.2.1 Определение модели «сущность-связь»

Информационные модели базового рабочего списка состоят из одного уровня, включающего все атрибуты сопоставления и все возвращаемые ключевые атрибуты, которые могут быть отправлены от SCU к SCP в запросе и значения которых ожидается получить от SCP к SCU в каждом из ответов (или элементов рабочего списка). Значения атрибутов сопоставления в запросе определяют, какие элементы рабочего списка должны быть возвращены в ответах. Все ключевые атрибуты (атрибуты сопоставления и возвращаемые ключевые атрибуты) в запросе определяют, какие значения атрибутов возвращаются в ответах для данного рабочего списка.

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

K.2.2 Определение атрибутов

Атрибуты определяются для каждой сущности во внутренней модели «сущность-связь». Идентификатор в запросе C-FIND должен содержать значения, сопоставляемые с атрибутами сущностей информационной модели рабочего списка. Для любого запроса рабочего списка набор сущностей, для которых возвращаются атрибуты, должен определяться набором атрибутов сопоставления и возвращаемых ключевых атрибутов, указанных в идентификаторе.

K.2.2.1 Типы атрибутов

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

K.2.2.1.1 Атрибуты сопоставления

Атрибуты сопоставления — это ключи, отбирающие элементы рабочего списка для включения в запрашиваемый рабочий список.

K.2.2.1.1.1 Обязательные атрибуты сопоставления

SCP одного из классов SOP сервисного класса базового управления рабочим списком должен поддерживать сопоставление на основе значений всех обязательных атрибутов сопоставления запроса C-FIND. Нескольким сущностям может соответствовать заданное значение обязательного ключа.

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

Примечание

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

  2. SCU может по своему усмотрению предоставить любое подмножество обязательных атрибутов сопоставления.

K.2.2.1.1.2 Необязательные атрибуты сопоставления

В информационной модели рабочего списка набор атрибутов может быть определён как необязательные атрибуты сопоставления. Необязательные атрибуты сопоставления, содержащиеся в идентификаторе запроса C-FIND, могут вызывать два различных типа поведения в зависимости от поддержки сопоставления со стороны SCP. Если SCP

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

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

Примечание

  1. Заявление о соответствии SCP перечисляет необязательные атрибуты сопоставления, поддерживаемые для сопоставления.

  2. SCU не может ожидать, что SCP поддерживает сопоставление по необязательному ключу сопоставления.

K.2.2.1.2 Возвращаемые ключевые атрибуты

Значения возвращаемых ключевых атрибутов, которые должны быть получены с рабочим списком, указываются со значением нулевой длины (универсальное сопоставление) в запросе C-FIND. SCP должны поддерживать возвращаемые ключевые атрибуты, определённые информационной моделью рабочего списка, в соответствии с типом элемента данных (1, 1C, 2, 2C, 3), как определено в PS3.5.

Каждый атрибут сопоставления также должен рассматриваться как возвращаемый ключевой атрибут. Поэтому ответ C-FIND должен содержать, помимо значений запрошенных возвращаемых ключевых атрибутов, значения запрошенных атрибутов сопоставления.

Примечание

  1. Заявление о соответствии SCP перечисляет поддерживаемые возвращаемые ключевые атрибуты типа 3.

  2. SCU может по своему усмотрению предоставить любое подмножество возвращаемых ключевых атрибутов.

  3. SCU не может ожидать получения каких-либо возвращаемых ключевых атрибутов типа 3.

  4. Возвращаемые ключевые атрибуты с VR, равным SQ, могут быть указаны либо с нулевой длиной, либо с элементом нулевой длины в последовательности.

K.2.2.2 Сопоставление атрибутов

Следующие типы сопоставления, определённые сервисным классом запроса/получения в Annex C, могут выполняться над атрибутами сопоставления в сервисном классе базового управления рабочим списком. Различные атрибуты сопоставления могут подпадать под разные типы сопоставления. Информационная модель рабочего списка определяет тип сопоставления для каждого обязательного атрибута сопоставления. Заявление о соответствии SCP должно определять тип сопоставления для каждого необязательного атрибута сопоставления. Типы сопоставления:

  • Сопоставление одиночного значения (Single Value Matching)

  • Сопоставление по списку UID (List of UID Matching)

  • Сопоставление по маске (Wild Card Matching)

  • Сопоставление по диапазону (Range Matching)

  • Сопоставление последовательности (Sequence Matching)

Следующий тип сопоставления, определённый сервисным классом запроса/получения в Annex C настоящей части, должен выполняться над возвращаемыми ключевыми атрибутами в сервисном классе базового управления рабочим списком.

  • Универсальное сопоставление (Universal Matching)

См. Section C.2.2.2 and subsections for specific rules governing of Matching Key Attribute encoding for and performing of different types of matching.

Атрибут Specific Character Set (0008,0005) и/или атрибут Timezone Offset From UTC (0008,0201) могут присутствовать в идентификаторе, но никогда не участвуют в сопоставлении, то есть не считаются атрибутами сопоставления. Подробности см. в Section C.2.2.2.

На сопоставление одиночного значения атрибутов с VR, равным PN, может влиять расширенное согласование нечёткого семантического сопоставления имён лиц.

K.2.2.3 Сопоставление нескольких значений

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

K.3 Информационная модель рабочего списка

Каждая информационная модель рабочего списка связана с одним классом SOP. Определена следующая информационная модель рабочего списка:

  • Информационная модель рабочего списка модальности (Modality Worklist Information Model)

K.4 Группа служб DIMSE-C

Одна служба DIMSE-C используется при построении классов SOP сервисного класса базового управления рабочим списком. Используется следующая операция DIMSE-C.

  • C-FIND

K.4.1 Операция C-FIND

SCP некоторых классов SOP сервисного класса базового управления рабочим списком способны обрабатывать запросы с использованием операции C-FIND, как описано в PS3.7. Операция C-FIND является механизмом, посредством которого выполняются запросы. Совпадения по ключам, присутствующим в идентификаторе, возвращаются в ответах C-FIND.

K.4.1.1 Параметры службы C-FIND

K.4.1.1.1 SOP Class UID

SOP Class UID идентифицирует информационную модель рабочего списка, по которой должна выполняться операция C-FIND. Поддержка SOP Class UID подразумевается Abstract Syntax UID контекста представления, используемого данной операцией C-FIND.

K.4.1.1.2 Приоритет (Priority)

Атрибут Priority определяет запрошенный приоритет операции C-FIND по отношению к другим операциям DIMSE, выполняемым тем же SCP.

Обработка запросов приоритета не является обязательной для SCP. Поддерживает ли SCP обработку приоритета и значение различных уровней приоритета должно быть указано в заявлении о соответствии SCP.

K.4.1.1.3 Идентификатор (Identifier)

Как запрос, так и ответ C-FIND содержат идентификатор, закодированный как набор данных (см. PS3.5).

K.4.1.1.3.1 Структура идентификатора запроса

Идентификатор в запросе C-FIND должен содержать

  • значения ключевых атрибутов, сопоставляемые со значениями атрибутов, указанных в данном классе SOP.

  • условно — атрибут Specific Character Set (0008,0005). Этот атрибут должен включаться, если в каких-либо атрибутах идентификатора запроса могут использоваться расширенные или замещающие наборы символов. В противном случае он не должен включаться.

    Примечание

    Это означает, что Specific Character Set (0008,0005) включается, если SCU поддерживает расширенные или замещающие наборы символов в контексте данной службы. Он не будет включён, если SCU не поддерживает расширенные или замещающие наборы символов.

  • условно — атрибут Timezone Offset From UTC (0008,0201). Этот атрибут должен включаться, если ключевые атрибуты времени должны интерпретироваться явно в указанном локальном часовом поясе. В противном случае он не должен присутствовать, то есть не должен отправляться со значением нулевой длины.

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

K.4.1.1.3.2 Структура идентификатора ответа

Ответ C-FIND не должен содержать атрибуты, которых не было в запросе или которые не указаны в настоящем разделе.

Идентификатор в ответе C-FIND должен содержать:

  • ключевые атрибуты со значениями, соответствующими ключевым атрибутам, содержащимся в идентификаторе запроса (ключевые атрибуты, определённые в Section K.2.2.1).

  • условно — атрибут Specific Character Set (0008,0005). Этот атрибут должен включаться, если в каких-либо атрибутах идентификатора ответа могут использоваться расширенные или замещающие наборы символов. В противном случае он не должен включаться. SCP C-FIND не обязан возвращать ответы в наборе символов Specific Character Set, запрошенном SCU, если этот набор символов не поддерживается SCP. SCP может возвращать ответы с другим набором символов Specific Character Set.

    Примечание

    Это означает, что Specific Character Set (0008,0005) включается, если SCP поддерживает расширенные или замещающие наборы символов в контексте данной службы. Он не будет включён, если SCP не поддерживает расширенные или замещающие наборы символов.

  • условно — атрибут Timezone Offset From UTC (0008,0201). Этот атрибут должен включаться, если какие-либо атрибуты времени в идентификаторе ответа должны интерпретироваться явно в указанном локальном часовом поясе. В противном случае он не должен присутствовать, то есть не должен отправляться со значением нулевой длины.

  • условно — атрибут HL7 Structured Document Reference Sequence (0040,A390) и его вложенные элементы последовательности. Этот атрибут должен включаться, если в идентификаторе имеются ссылки на структурированные документы HL7, например, в Pertinent Documents Sequence (0038,0100).

K.4.1.1.4 Статус (Status)

Table K.4-1 определяет значения кодов статуса, которые могут быть возвращены в ответе C-FIND. Общие значения кодов статуса и поля, связанные со значениями кодов статуса, определены для службы DIMSE C-FIND в PS3.7.

Table K.4-1. Значения статуса ответа C-FIND

Статус службы

Дополнительное значение

Коды статуса

Связанные поля

Failure

Отказано: нехватка ресурсов

A700

(0000,0902)

Ошибка: набор данных не соответствует классу SOP

A900

(0000,0901)

(0000,0902)

Ошибка: невозможно обработать

Cxxx

(0000,0901)

(0000,0902)

Cancel

Сопоставление прекращено из-за запроса отмены

FE00

None

Success

Сопоставление завершено — заключительный идентификатор не предоставляется.

0000

Отсутствуют

Pending

Сопоставление продолжается — предоставлено текущее совпадение, и все необязательные ключи обрабатывались так же, как обязательные ключи.

FF00

Identifier

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

FF01

Identifier


Примечание

Коды статуса возвращаются в сообщениях ответа DIMSE (см. PS3.7). Значения кодов, указанные в столбце «Коды статуса», возвращаются в элементе команды Status (0000,0900).

Некоторые коды статуса Failure специфичны для реализации.

Реализация SCP должна присваивать конкретные коды статуса Failure, заменяя каждый символ 'x' шестнадцатеричной цифрой в диапазоне от 0 до F. Реализация SCP, желающая различать причины значения отказа «Failed: Unable to process», должна присваивать этим причинам конкретные значения кода статуса в допустимом диапазоне, указанном в Table K.4-1.

Реализация SCU должна распознавать любой код статуса Failure в диапазоне значений, указанном в Table K.4-1, как индикатор значения отказа, указанного в таблице. Не требуется, чтобы реализация SCU различала конкретные коды статуса в допустимом диапазоне.

K.4.1.2 Поведение SCU C-FIND

Все SCU C-FIND должны быть способны генерировать запросы, отвечающие требованиям метода поиска «Worklist» (см. Section K.4.1.3.1).

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

SCU передаёт следующую семантику посредством запросов и ответов C-FIND:

  • SCU запрашивает у SCP выполнение сопоставления всех ключей, указанных в идентификаторе запроса, с информацией, которой он располагает по рабочему списку, указанному в запросе.

  • SCU должен интерпретировать ответы Pending как передающие атрибуты совпадения сущности.

  • SCU должен интерпретировать ответ со статусом Success, Failure или Cancel как передающий окончание ответов Pending.

  • SCU должен интерпретировать ответ Failure на запрос C-FIND как указание на то, что SCP не может обработать запрос.

  • SCU может отменить службу C-FIND, выдав запрос C-CANCEL-FIND в любой момент во время обработки C-FIND. SCU должен распознавать статус Cancel как индикатор успешного выполнения C-CANCEL-FIND.

    Примечание

    SCU должен быть готов получать ответы C-FIND, отправляемые SCP, до тех пор, пока SCP окончательно не обработает запрос C-CANCEL-FIND.

K.4.1.3 Поведение SCP C-FIND

Все SCP C-FIND должны быть способны обрабатывать запросы, отвечающие требованиям поиска «Worklist» (см. Section K.4.1.3.1).

SCP передаёт следующую семантику посредством запросов и ответов C-FIND:

  • У SCP запрашивается выполнение сопоставления всех ключей, указанных в идентификаторе запроса, с информацией, которой он располагает. Сопоставление атрибутов выполняется с использованием значений ключей, указанных в идентификаторе запроса C-FIND, как определено в Section K.2.

  • SCP генерирует ответ C-FIND для каждого совпадения с использованием метода поиска «Worklist». Все такие ответы должны содержать идентификатор, атрибуты которого содержат значения одного совпадения. Все такие ответы должны содержать статус Pending.

  • Когда все совпадения отправлены, SCP генерирует ответ C-FIND со статусом Success. Статус Success должен указывать на то, что ответ был отправлен для каждого совпадения, известного SCP.

    Примечание

    1. Идентификатор не содержится в ответе со статусом Success. Полное определение см. в PS3.7.

    2. Когда совпадений нет, ответы со статусом Pending не отправляются — отправляется только один ответ со статусом Success.

  • SCP должен генерировать ответ со статусом Failure, если он не может обработать запрос. Ответ Failure не должен содержать идентификатор.

  • Если SCP получает индикацию C-CANCEL-FIND до завершения обработки совпадений, он должен прервать процесс сопоставления и вернуть статус Cancel.

K.4.1.3.1 Метод поиска «Worklist»

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

Ключевые строки сопоставления, содержащиеся в идентификаторе запроса C-FIND, сопоставляются со значениями ключевых атрибутов для каждой сущности рабочего списка. Для каждой сущности, атрибуты которой соответствуют всем указанным строкам сопоставления, строится идентификатор. Этот идентификатор должен содержать все значения атрибутов данной сущности, соответствующие значениям в запросе C-FIND. Для каждого такого идентификатора возвращается ответ. Если ключи сопоставления отсутствуют, значит совпадений нет — возвращается ответ со статусом Success и без идентификатора.

K.5 Согласование ассоциации

Установление ассоциации — первая фаза любого экземпляра обмена данными между равноправными AE DICOM. Процедура согласования ассоциации, определённая в PS3.7, должна использоваться для согласования поддерживаемых классов SOP или мета-классов SOP.

Поддержка согласования выбора роли SCP/SCU необязательна. Расширенное согласование класса SOP необязательно.

K.5.1 Расширенное согласование класса SOP

Расширенное согласование класса SOP позволяет равноправным AE DICOM при установлении ассоциации обмениваться прикладной информацией об ассоциации, определённой конкретными классами SOP. Это достигается путём определения поля Service-class-application-information. Поле Service-class-application-information используется для определения поддержки нескольких опций.

Это согласование необязательно. При его отсутствии условиями по умолчанию являются:

  • буквальное сопоставление имён лиц с неопределённой чувствительностью к регистру

  • корректировка запроса по часовому поясу не определена

Инициатор ассоциации может использовать для каждого класса SOP один подэлемент расширенного согласования класса SOP. Класс SOP идентифицируется соответствующим именем абстрактного синтаксиса (Abstract Syntax Name, как определено в PS3.7), за которым следует поле Service-class-application-information. Это поле определяет три или более подполя:

  • зарезервировано; всегда должно быть равно 1

  • зарезервировано; всегда должно быть равно 1

  • буквальное или нечёткое семантическое сопоставление имён лиц инициатором ассоциации

  • корректировка запроса по часовому поясу инициатором ассоциации

Значение нечёткого семантического сопоставления имён лиц и корректировки запроса по часовому поясу определено в Section K.2.2.2 и Section C.2.2.2.1.

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

Получатель ассоциации для каждого предложенного подполя подэлемента расширенного согласования класса SOP либо принимает предложение инициатора ассоциации, вернув то же значение (1), либо отклоняет предложение, вернув значение (0).

Если подэлемент расширенного согласования класса SOP не возвращается получателем ассоциации, то нечёткое семантическое сопоставление имён лиц не поддерживается, а корректировка запроса по часовому поясу не определена в рамках ассоциации (условие по умолчанию).

Если подэлементы расширенного согласования класса SOP отсутствуют в индикации A-ASSOCIATE, они должны быть опущены в ответе A-ASSOCIATE.

K.5.1.1 Структура подэлемента расширенного согласования класса SOP (A-ASSOCIATE-RQ)

Подэлемент расширенного согласования класса SOP состоит из последовательности обязательных полей, как определено в PS3.7. Длина этого поля должна составлять три или четыре байта.

Table K.5.1-1. Подэлемент расширенного согласования класса SOP (поле Service-Class-Application-Information) — A-ASSOCIATE-RQ

Байты элемента

Имя поля

Описание поля

1

зарезервировано

Это байтовое поле всегда должно быть равно 1

2

зарезервировано

Это байтовое поле всегда должно быть равно 1

3

Нечёткое семантическое сопоставление имён лиц

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

0 — нечёткое семантическое сопоставление не запрошено

1 — нечёткое семантическое сопоставление запрошено

4

Корректировка запроса по часовому поясу

Это байтовое поле определяет, должен ли атрибут Timezone Offset From UTC (0008,0201) использоваться для корректировки значения запроса для полей времени и даты-времени в запросах.

0 — корректировка запроса по часовому поясу не запрошена

1 — корректировка запроса по часовому поясу запрошена


Примечание

Этот подэлемент идентичен подэлементам расширенного согласования, используемым классами SOP запроса/получения. Однако реляционные запросы (байт 1) неприменимы, поскольку информационные модели рабочего списка являются одноуровневыми, а сопоставление даты-времени (байт 2) уже требуется информационными моделями рабочего списка, а поддержка преобразования Enhanced Multi-Frame Image неприменима (байт 5).

K.5.1.2 Структура подэлемента расширенного согласования класса SOP (A-ASSOCIATE-AC)

Подэлемент расширенного согласования класса SOP состоит из последовательности обязательных полей, как определено в PS3.7. Длина этого поля должна составлять три или четыре байта.

Table K.5.1-2. Подэлемент расширенного согласования класса SOP (поле Service-Class-Application-Information) — A-ASSOCIATE-AC

Байты элемента

Имя поля

Описание поля

1

зарезервировано

Это байтовое поле всегда должно быть равно 1

2

зарезервировано

Это байтовое поле всегда должно быть равно 1

3

Нечёткое семантическое сопоставление имён лиц

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

0 — нечёткое семантическое сопоставление не выполняется

1 — нечёткое семантическое сопоставление выполняется

4

Корректировка запроса по часовому поясу

Это байтовое поле определяет, должен ли атрибут Timezone Offset From UTC (0008,0201) использоваться для корректировки значения запроса для полей времени и даты-времени в запросах.

0 — корректировка запросов по часовому поясу не выполняется

1 — корректировка запросов по часовому поясу выполняется


K.6 Определения классов SOP

K.6.1 Класс SOP рабочего списка модальности

K.6.1.1 Обзор класса SOP рабочего списка модальности

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

Этот рабочий список структурирован в соответствии с запланированными этапами процедуры. Этап процедуры — это единица обслуживания в контексте запрошенной процедуры визуализации.

Класс SOP рабочего списка модальности поддерживает следующие требования:

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

  • Выбор запланированного этапа процедуры из IS (например, загрузка информации об этапе процедуры из IS на модальность). Класс SOP рабочего списка модальности поддерживает два альтернативных способа реализации этого требования, поддерживающих различные методы организации работы отделения:

    • Модальность может получать список запланированных этапов процедуры из IS. Отображение списка и выбор из списка выполняются на модальности.

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

  • Подготовка выполнения запланированного этапа процедуры.

  • Однозначная увязка изображений DICOM со связанной информацией из IS (например, демографические данные пациента, описание процедуры, структура данных ID из IS, контекстная информация IS).

  • Получение из IS всех атрибутов, которые обязательно должны быть вставлены в объект изображения DICOM

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

Класс SOP рабочего списка модальности не поддерживает передачу информации от модальности к информационной системе.

K.6.1.2 Информационная модель рабочего списка модальности

K.6.1.2.1 Модель E/R

В ответ на данный запрос C-FIND SCP может потребоваться отправить несколько ответов C-FIND (то есть по одному ответу C-FIND на каждый совпадающий элемент рабочего списка). Каждый элемент рабочего списка сосредоточен на одном запланированном этапе процедуры и связанной с ним информации. Диаграмма E-R, представленная на Figure K.6-1, изображает содержимое одного ответа C-FIND, а именно:

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

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

Информационная модель рабочего списка модальности представлена диаграммой сущность-связь, показанной на рисунке Section K.6 -1.

Примечание

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

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

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

  • Модуль отношений пациента (Patient Relationship Module)

  • Модуль идентификации пациента (Patient Identification Module)

  • Модуль демографических данных пациента (Patient Demographic Module)

  • Модуль медицинской информации пациента (Patient Medical Module)

  • Модуль отношений посещения (Visit Relationship Module)

  • Модуль идентификации посещения (Visit Identification Module)

  • Модуль статуса посещения (Visit Status Module)

  • Модуль поступления при посещении (Visit Admission Module)

  • Модуль запланированного этапа процедуры (Scheduled Procedure Step Module)

  • Модуль запрошенной процедуры (Requested Procedure Module)

  • Модуль запроса на услугу визуализации (Imaging Service Request Module)

Modality Worklist Information Model E-R Diagram

Figure K.6-1. Modality Worklist Information Model E-R Diagram


K.6.1.2.2 Modality Worklist Attributes

Table K.6-1 определяет атрибуты информационной модели рабочего списка модальности:

Table K.6-1. Атрибуты информационной модели рабочего списка модальности

Описание / Модуль

Tag

Тип ключа сопоставления

Тип возвращаемого ключа

Примечание / Тип сопоставления

Scheduled Procedure Step

Scheduled Procedure Step Sequence

(0040,0100)

R

1

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

Scheduled Procedure Step Sequence должна содержать только один элемент.

>Scheduled Station AE Title

(0040,0001)

R

1

Scheduled Station AE Title должно получаться только с помощью сопоставления одиночного значения.

>Scheduled Procedure Step Start Date

(0040,0002)

R

1

Scheduled Procedure Step Start Date (0040,0002) должно получаться с помощью сопоставления одиночного значения или сопоставления по диапазону.

См. примечание к Scheduled Procedure Step Start Time (0040,0003).

>Scheduled Procedure Step Start Time

(0040,0003)

R

1

Scheduled Procedure Step Start Time (0040,0003) должно получаться с помощью сопоставления одиночного значения или сопоставления по диапазону. Scheduled Procedure Step Start Date (0040,0002) и Scheduled Procedure Step Start Time (0040,0003) подлежат сопоставлению по диапазону. Если оба ключа указаны для сопоставления по диапазону, например, диапазон дат с 5 по 7 июля и диапазон времени с 10:00 до 18:00 определяет период времени, начинающийся 5 июля в 10:00 и заканчивающийся 7 июля в 18:00.

Примечание

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

>Modality

(0008,0060)

R

1

Modality должно получаться с помощью сопоставления одиночного значения.

>Scheduled Performing Physician's Name

(0040,0006)

R

2

Scheduled Performing Physician's Name должно получаться с помощью сопоставления одиночного значения или сопоставления по маске.

>Scheduled Procedure Step Description

(0040,0007)

O

1C

SCP должен поддерживать Scheduled Procedure Step Description (0040,0007) и/или Scheduled Protocol Code Sequence (0040,0008).

>Scheduled Station Name

(0040,0010)

O

2

>Scheduled Procedure Step Location

(0040,0011)

O

2

>Referenced Defined Protocol Sequence

(0018,990C)

O

3

>>Referenced SOP Class UID

(0008,1150)

O

1

>>Referenced SOP Instance UID

(0008,1155)

O

1

>Referenced Performed Protocol Sequence

(0018,990D)

O

3

>>Referenced SOP Class UID

(0008,1150)

O

1

>>Referenced SOP Instance UID

(0008,1155)

O

1

>Scheduled Protocol Code Sequence

(0040,0008)

O

1C

SCP должен поддерживать Scheduled Procedure Step Description (0040,0007) и/или Scheduled Protocol Code Sequence (0040,0008).

Scheduled Protocol Code Sequence содержит один или несколько элементов.

>>Include Table 8-2a “Enhanced Coded Entry Macro with Optional Matching Key Support and Optional Meaning”

>>Protocol Context Sequence

(0040,0440)

-

3

Protocol Context Sequence и её элементы не должны использоваться для сопоставления

>>>Value Type

(0040,A040)

-

1

>>>Concept Name Code Sequence

(0040,A043)

-

1

>>>>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support”

>>>DateTime

(0040,A120)

-

1C

Требуется, если Value Type (0040,A040) равен DATETIME.

>>>Person Name

(0040,A123)

-

1C

Требуется, если Value Type (0040,A040) равен PNAME.

>>>Text Value

(0040,A160)

-

1C

Требуется, если Value Type (0040,A040) равен TEXT.

>>>Concept Code Sequence

(0040,A168)

-

1C

Требуется, если Value Type (0040,A040) равен CODE.

>>>>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support”

>>>Numeric Value

(0040,A30A)

-

1C

Требуется, если Value Type (0040,A040) равен NUMERIC.

>>>Measurement Units Code Sequence

(0040,08EA)

-

1C

Требуется, если Value Type (0040,A040) равен NUMERIC.

>>>>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support”

>>>All other Attributes of the Protocol Context Sequence

-

3

>Pre-Medication

(0040,0012)

O

2C

Требуется, если к данному запланированному этапу процедуры должна применяться премедикация.

>Scheduled Procedure Step ID

(0040,0009)

O

1

>Requested Contrast Agent

(0032,1070)

O

2C

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

>Scheduled Procedure Step Status

(0040,0020)

O

3

>All other Attributes of the Scheduled Procedure Step Sequence

O

3

Scheduled Specimen Sequence

(0040,0500)

O

3

В этой последовательности может быть возвращён один или несколько элементов.

>Container Identifier

(0040,0512)

O

1

>Container Type Code Sequence

(0040,0518)

-

2

В этой последовательности должно быть возвращено ноль или один элемент.

>>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support”

>Specimen Description Sequence

(0040,0560)

O

1

В этой последовательности должен быть возвращён один или несколько элементов.

>>Specimen Identifier

(0040,0551)

O

1

>>Specimen UID

(0040,0554)

O

1

>>All other Attributes of the Specimen Description Sequence

O

3

Specimen Preparation Sequence (0040,0610), если присутствует, описывает уже выполненные этапы подготовки, а не запланированные этапы процедуры

>All other Attributes of the Scheduled Specimen Sequence

O

3

Barcode Value

(2200,0005)

O

3

Это значение может совпадать с Container Identifier (0040,0512).

Requested Procedure (Запрошенная процедура)

Requested Procedure ID

(0040,1001)

O

1

Requested Procedure Description

(0032,1060)

O

1C

SCP должен поддерживать Requested Procedure Description (0032,1060) или Requested Procedure Code Sequence (0032,1064), либо оба атрибута.

Requested Procedure Code Sequence

(0032,1064)

O

1C

SCP должен поддерживать Requested Procedure Description (0032,1060) или Requested Procedure Code Sequence (0032,1064), либо оба атрибута.

Requested Procedure Code Sequence должна содержать только один элемент.

>Include Table 8-2a “Enhanced Coded Entry Macro with Optional Matching Key Support and Optional Meaning”

Requested Laterality Code Sequence

(0032,1065)

O

3

В этой последовательности может быть возвращён только один элемент.

>Include Таблица 8-2b «Базовый макрос кодированной записи с необязательной поддержкой ключа сопоставления и необязательным значением»

Study Instance UID

(0020,000D)

O

1

Study Date

(0008,0020)

O

3

См. примечание 5.

Study Time

(0008,0030)

O

3

См. примечание 5.

Referenced Study Sequence

(0008,1110)

O

2

>Referenced SOP Class UID

(0008,1150)

O

1

>Referenced SOP Instance UID

(0008,1155)

O

1

Requested Procedure Priority

(0040,1003)

O

2

Patient Transport Arrangements

(0040,1004)

O

2

All other Attributes of the Requested Procedure Module

O

3

Imaging Service Request (Запрос на услугу визуализации)

Accession Number

(0008,0050)

O

2

Issuer of Accession Number Sequence

(0008,0051)

O

3

Requesting Physician

(0032,1032)

O

2

Referring Physician's Name

(0008,0090)

O

2

All other Attributes of the Imaging Service Request Module

O

3

Visit Identification (Идентификация посещения)

Admission ID

(0038,0010)

O

2

Issuer of Admission ID Sequence

(0038,0014)

O

3

All other Attributes of the Visit Identification Module

O

3

Visit Status (Статус посещения)

Current Patient Location

(0038,0300)

O

2

All other Attributes of the Visit Status Module

O

3

Visit Relationship (Отношения посещения)

Referenced Patient Sequence

(0008,1120)

O

2

>Referenced SOP Class UID

(0008,1150)

O

1

>Referenced SOP Instance UID

(0008,1155)

O

1

All other Attributes of the Visit Relationship Module except those explicitly included in this table (see Note 3)

O

3

Visit Admission (Поступление при посещении)

All Attributes from the Visit Admission Module

O

3

Patient Relationship (Отношения пациента)

All Attributes from the Patient Relationship Module except those explicitly included in this table (see Note 3)

O

3

Patient Identification (Идентификация пациента)

Patient's Name

(0010,0010)

R

1

Patient Name должно получаться с помощью сопоставления одиночного значения или сопоставления по маске.

Patient ID

(0010,0020)

R

1

Patient ID должно получаться с помощью сопоставления одиночного значения.

Issuer of Patient ID

(0010,0021)

O

3

Issuer of Patient ID Qualifiers Sequence

(0010,0024)

O

3

Other Patient IDs Sequence

(0010,1002)

O

3

All other Attributes of the Patient Identification Module

O

3

Patient Demographic (Демографические данные пациента)

Patient's Birth Date

(0010,0030)

O

2

Patient's Sex

(0010,0040)

O

2

Gender Identity Sequence

(0010,0041)

O

3

>Gender Identity Code Sequence

(0010,0044)

O

1

>>Include Table 8-4a “Enhanced Coded Entry Macro with Optional Matching Key Support and Mandatory Meaning”

>Effective Start DateTime

(0040,A034)

O

3

>Effective Stop DateTime

(0040,A035)

O

3

>Gender Identity Comment

(0010,0045)

O

3

Sex Parameters for Clinical Use Category Sequence

(0010,0043)

O

3

>Sex Parameters for Clinical Use Category Code Sequence

(0010,0046)

O

1

>>Include Table 8-4a “Enhanced Coded Entry Macro with Optional Matching Key Support and Mandatory Meaning”

>Effective Start DateTime

(0040,A034)

O

3

>Effective Stop DateTime

(0040,A035)

O

3

>Sex Parameters for Clinical Use Category Comment

(0010,0042)

O

3

>Sex Parameters for Clinical Use Category Reference

(0010,0047)

O

3

Person Names to Use Sequence

(0010,0011)

O

3

>Name to Use

(0010,0012)

O

1

>Effective Start DateTime

(0040,A034)

O

3

>Effective Stop DateTime

(0040,A035)

O

3

>Name to Use Comment

(0010,0013)

O

3

Third Person Pronouns Sequence

(0010,0014)

O

3

>Pronoun Code Sequence

(0010,0015)

O

1

>>Include Table 8-4a “Enhanced Coded Entry Macro with Optional Matching Key Support and Mandatory Meaning”

>Effective Start DateTime

(0040,A034)

O

3

>Effective Stop DateTime

(0040,A035)

O

3

>Pronoun Comment

(0010,0016)

O

3

Patient's Primary Language Code Sequence

(0010,0101)

O

3

Языки, которые можно использовать для общения с пациентом.

Если возвращается, Patient's Primary Language Code Sequence должна содержать один или несколько элементов. Элементы упорядочены по предпочтению (от наиболее предпочитаемого языка к наименее предпочитаемому).

>Include Table 8-4a “Enhanced Coded Entry Macro with Optional Matching Key Support and Mandatory Meaning”

>Patient's Primary Language Modifier Code Sequence

(0010,0102)

O

3

Модификатор для основного языка пациента. Может использоваться для указания национального варианта языка.

Если возвращается, Patient's Primary Language Modifier Code Sequence должна содержать только один элемент.

>>Include Table 8-4a “Enhanced Coded Entry Macro with Optional Matching Key Support and Mandatory Meaning”

Patient's Weight

(0010,1030)

O

2

Patient's Size

(0010,1020)

O

3

Confidentiality Constraint on Patient Data Description

(0040,3001)

O

2

All other Attributes of the Patient Demographic Module

O

3

Patient Medical

Patient State

(0038,0500)

O

2

Pregnancy Status

(0010,21C0)

O

2

Medical Alerts

(0010,2000)

O

2

Allergies

(0010,2110)

O

2

Special Needs

(0038,0050)

O

2

Pertinent Documents Sequence

(0038,0100)

O

3

Pertinent Documents Sequence должна получаться только с помощью универсального сопоставления

>Referenced SOP Class UID

(0008,1150)

-

1

>Referenced SOP Instance UID

(0008,1155)

-

1

>Purpose of Reference Code Sequence

(0040,A170)

-

2

>>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support”

>Document Title

(0042,0010)

-

2

All other Attributes of the Patient Medical Module

O

3


Примечание

  1. Just like Series and Image Entities specified in the Query/Retrieve Service Class either an SCU or an SCP may support optional Matching Key Attributes and/or Type 3 Return Key Attributes that are not included in the Worklist Information Model (i.e., Standard or Private Attributes). This is considered a Standard Extended SOP Class (see PS3.2).

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

  3. Причина такого исключения — обеспечить, чтобы атрибуты, которые могут присутствовать в нескольких модулях, включались только один раз со значением, относящимся только к одному модулю (например, Referenced Study Sequence (0008,1110) должна включаться один раз со значением, определённым в модуле Requested Procedure Module).

  4. The use of Specific Character Set is discussed in Section K.4.1.1.3.1 and Section K.4.1.1.3.2.

  5. Значения Study Date (0008,0020) и Study Time (0008,0030) могут предоставляться для обеспечения согласованности атрибутов уровня исследования в составных экземплярах, создаваемых в нескольких выполненных этапах процедуры на разных устройствах, а значения рабочего списка могут обновляться SCP на основе информации, полученной из Modality Performed Procedure Step, или путём анализа создаваемых составных экземпляров.

The Attributes in Table K.6-1a are not part of the Worklist Information Model; their inclusion in the C-FIND request and response Identifier are governed by rules in sections Section K.4.1.1.3.1 and Section K.4.1.1.3.2, respectively.

Table K.6-1a. Attributes for the Modality Worklist C-FIND Identifier

Имя атрибута

Tag

Идентификатор запроса

Идентификатор ответа

Примечание

Specific Character Set

(0008,0005)

1C

1C

This Attribute is required if expanded or replacement character sets are used. See Section C.2.2.2 and Section K.4.1.1.3

Timezone Offset From UTC

(0008,0201)

1C

1C

This Attribute is required if times are to be interpreted explicitly in the designated local timezone. See Section C.2.2.2 and Section K.4.1.1.3

HL7 Structured Document Reference Sequence

(0040,A390)

-

1C

В эту последовательность может быть включён один или несколько элементов.

Требуется, если в идентификаторе имеются ссылки на структурированные документы HL7. См. Section K.4.1.1.3

>Referenced SOP Class UID

(0008,1150)

-

1

>Referenced SOP Instance UID

(0008,1155)

-

1

>HL7 Instance Identifier

(0040,E001)

-

1

>Retrieve URI

(0040,E010)

-

3


K.6.1.3 Требования соответствия

Реализация может соответствовать классу SOP рабочего списка модальности в роли SCU или SCP. Заявление о соответствии должно быть в формате, определённом в PS3.2.

K.6.1.3.1 Соответствие SCU

Реализация, соответствующая классу SOP рабочего списка модальности в роли SCU, должна поддерживать запросы к информационной модели рабочего списка, описанной в Section K.6.1.2 настоящего приложения, используя базовое поведение SCU C-FIND, описанное в Section K.4.1.2 настоящей части.

Реализация, соответствующая классу SOP рабочего списка модальности в роли SCU, должна указать в своём заявлении о соответствии, запрашивает ли она сопоставление по необязательным атрибутам сопоставления. Если она запрашивает возвращаемые ключевые атрибуты типа 3, она должна перечислить эти необязательные возвращаемые ключевые атрибуты. Она должна указать любые поддерживаемые ею шаблоны для Protocol Context Sequence.

Реализация, соответствующая классу SOP рабочего списка модальности в роли SCU, должна указать в своём заявлении о соответствии, поддерживает ли она расширенное согласование нечёткого семантического сопоставления имён лиц.

Реализация, соответствующая классу SOP рабочего списка модальности в роли SCU, должна указать в своём заявлении о соответствии, как она использует Specific Character Set (0008,0005) и Timezone Offset From UTC (0008,0201) при кодировании запросов и интерпретации ответов.

K.6.1.3.2 Соответствие SCP

Реализация, соответствующая классу SOP рабочего списка модальности в роли SCP, должна поддерживать запросы к информационной модели рабочего списка, описанной в Section K.6.1.2 настоящего приложения, используя поведение SCP C-FIND, описанное в Section K.4.1.3 настоящей части.

Реализация, соответствующая классу SOP рабочего списка модальности в роли SCP, должна указать в своём заявлении о соответствии, поддерживает ли она сопоставление по необязательным атрибутам сопоставления. Если она поддерживает возвращаемые ключевые атрибуты типа 3, она должна перечислить поддерживаемые ею необязательные возвращаемые ключевые атрибуты. Она должна указать любые поддерживаемые ею шаблоны для Protocol Context Sequence (0040,0440).

Реализация, соответствующая классу SOP рабочего списка модальности в роли SCP, должна указать в своём заявлении о соответствии, поддерживает ли она сопоставление без учёта регистра для атрибутов с VR, равным PN, и перечислить атрибуты, для которых это применимо.

Реализация, соответствующая классу SOP рабочего списка модальности в роли SCP, должна указать в своём заявлении о соответствии, поддерживает ли она расширенное согласование нечёткого семантического сопоставления имён лиц. Если нечёткое семантическое сопоставление имён лиц поддерживается, должен быть указан механизм нечёткого семантического сопоставления.

Реализация, соответствующая классу SOP рабочего списка модальности в роли SCP, должна указать в своём заявлении о соответствии, как она использует Specific Character Set (0008,0005) и Timezone Offset From UTC (0008,0201) при интерпретации запросов, выполнении сопоставления и кодировании ответов.

Реализация, соответствующая классу SOP рабочего списка модальности в роли SCP, должна указать в своём заявлении о соответствии способ выполнения сопоставления одиночного значения для атрибутов с VR, равным DS и IS (если поддерживается), и перечислить атрибуты, для которых это применимо.

K.6.1.4 Класс SOP

Класс SOP рабочего списка модальности в сервисном классе базового управления рабочим списком идентифицирует информационную модель рабочего списка модальности и поддерживаемые операции DIMSE-C. Определён следующий стандартный класс SOP:

Table K.6.1.4-1. Класс SOP рабочего списка модальности

Название класса SOP

SOP Class UID

Modality Worklist Information Model - FIND

1.2.840.10008.5.1.4.31


K.6.2 Класс SOP рабочего списка общего назначения (Устаревшее)

Устарело. См. PS3.4-2011.

K.7 Примеры использования рабочего списка модальности (Информативное)

Перемещено в PS3.17

K.8 Пример рабочего списка общего назначения (Информативное) (Устаревшее)

Устарело. См. PS3.17-2011.

L Сервисный класс управления очередью

Устарело. См. PS3.4-2004.

M Обработка идентифицирующих параметров (Информативное)

Устарело. См. PS3.17.

N Классы SOP хранения состояния мягкокопийного представления

N.1 Обзор

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

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

Они включают возможности указания:

  1. выходного пространства серой шкалы в P-значениях

  2. выходного цветового пространства как PCS-значений

  3. преобразований контраста серой шкалы, включая LUT модальности, VOI и представления

  4. вычитания маски для многокадровых изображений в серой шкале

  5. выбора области изображения для отображения и того, следует ли её поворачивать или отражать

  6. аннотаций, относящихся к изображению и дисплею, включая графику, текст и наложения (overlays)

  7. смешивания (blending) двух наборов изображений в единое представление

Классы SOP хранения состояния мягкокопийного представления серой шкалы относятся к преобразованиям изображения серой шкалы, которые должны применяться в явно определённом порядке для преобразования сохранённых значений пиксельных данных изображения в составном экземпляре изображения в значения представления (P-значения) при отображении изображения на мягкокопийном устройстве. P-значения находятся в независимом от устройства перцептивно линейном пространстве, формально определённом в PS3.14 Grayscale Standard Display Function.

Классы SOP хранения состояния мягкокопийного представления цвета и псевдоцвета относятся к преобразованиям цветного изображения, которые должны применяться в явно определённом порядке для преобразования сохранённых значений пиксельных данных изображения в составном экземпляре изображения в значения пространства соединения профилей (Profile Connection Space, PCS-значения) при отображении изображения на мягкокопийном устройстве. PCS-значения находятся в независимом от устройства пространстве, формально определённом в профилях ICC как значения CIEXYZ или CIELab.

Классы SOP хранения состояния представления смешивания мягкой копии и расширенного смешивания определяют два (или более) набора изображений — базовый набор и накладываемые наборы — и способ смешивания их значений пикселей. Базовый набор отображается в серой шкале, а накладываемый набор — в цвете. Смешивание не определяется попарно изображение-за-изображением или кадр-за-кадром — способ объединения двух наборов оставлен на усмотрение реализации. В частности, вопросы пространственной регистрации, любой передискретизации и механизма интерполяции не определены.

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

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

То, каким образом SCU данного класса SOP записывает или создаёт это состояние, выходит за рамки Стандарта.

Примечание

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

То, каким образом SCP данного класса SOP выбирает между несколькими состояниями, которые могут применяться к изображению, выходит за рамки настоящего Стандарта, за исключением утверждения, что заявление о соответствии в роли SCP данного класса SOP подразумевает, что SCP должен сделать состояние представления доступным пользователю устройства, и, если оно выбрано пользователем, должен применить все преобразования, сохранённые в состоянии, тем способом, каким они определены в Стандарте.

Примечание

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

  2. Выбор одного и того же состояния представления для отображения изображения серой шкалы на двух устройствах, заявляющих о соответствии этим классам SOP, через определение пространства P-значений подразумевает, что отображаемое изображение на обоих устройствах будет перцептивно схожим в пределах, определённых в PS3.14 Grayscale Standard Display Function, независимо от фактических возможностей систем отображения.

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

  4. Цветные изображения DICOM без встроенного необязательного профиля ICC не имеют определённого цветового пространства, независимо от их представления. Реализация, создающая состояние мягкокопийного представления цвета с профилем ICC, явно определяет цветовое пространство, в котором следует интерпретировать это изображение, даже если оно не было известно на момент создания изображения. Часто в таких обстоятельствах в состоянии представления используется хорошо известное цветовое пространство, такое как sRGB.

N.2 Последовательность преобразования пикселей

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

Последовательность преобразований от сохранённых значений пикселей в P-значения или PCS-значения явно определена в концептуальной модели. Фактически реализованная последовательность может отличаться, но должна приводить к тому же внешнему виду. Figure N.2-1 описывает эту последовательность преобразований.

Примечание

  1. Хотя класс SOP хранения составных изображений может не включать некоторые модули, входящие в описанные преобразования, классы SOP хранения состояния мягкокопийного представления их включают. Например, класс SOP хранения изображений CT включает Rescale Slope и Intercept в модуле CT Image Module, но не включает модуль Modality LUT Module, и поэтому ограничен описанием линейных преобразований. Сохранённое состояние представления, ссылающееся на экземпляр SOP хранения изображений CT, может включать Modality LUT и, следовательно, может применять нелинейное преобразование.

  2. Для затвора (shutter), аннотации и пространственных преобразований порядок их применения относительно других преобразований не должен приводить к иному внешнему виду. Единственное исключение — когда применяется пространственное преобразование, включающее увеличение, реализованное с помощью интерполяции. В этом случае то, выполняется ли интерполяция до или после преобразований контраста (таких как VOI LUT), может привести к немного другому внешнему виду. Считается, что нет необходимости точнее ограничивать эту последовательность.

Преобразования, определённые в классах SOP хранения состояния мягкокопийного представления, заменяют собой те, которые могут быть определены в экземпляре SOP изображения, на которое есть ссылка (Referenced Image SOP Instance). Если конкретное преобразование отсутствует в классе SOP хранения состояния мягкокопийного представления, оно должно считаться тождественным преобразованием, и любое эквивалентное преобразование, если оно присутствует в экземпляре SOP изображения, на которое есть ссылка, НЕ должно использоваться вместо него.

Значения MONOCHROME1 и MONOCHROME2 для Photometric Interpretation (0028,0004) в экземпляре SOP изображения, на которое есть ссылка, должны игнорироваться, поскольку их эффект определяется применением преобразований состояния представления серой шкалы.

Примечание

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

Экземпляр SOP хранения изображения, на который есть ссылка, может также содержать битовые (bit-mapped) наложения (overlays). Классы SOP хранения состояния мягкокопийного представления определяют механизм их включения или выключения (то есть отображения или неотображения).

Атрибуты, связанные с представлением, классов SOP хранения состояния мягкокопийного представления неизменяемы. Они никогда не должны изменяться или обновляться; только производный экземпляр SOP с новым SOP Instance UID может быть создан для представления другого представления.

Когда Supplemental Palette Color LUT присутствует в экземпляре SOP хранения изображения серой шкалы, на которое есть ссылка:

  • Конвейер серой шкалы в любом применимом экземпляре SOP хранения состояния мягкокопийного представления серой шкалы, состояния представления смешивания мягкой копии или состояния представления с переменным LUT модальности должен применяться только к диапазону сохранённых значений пикселей серой шкалы, и состояние представления не должно влиять на отображение индексированных цветовых значений.

  • Экземпляр SOP хранения состояния мягкокопийного представления цвета не должен применяться.

  • Экземпляр SOP хранения состояния мягкокопийного представления псевдоцвета или состояния представления с переменным LUT модальности может применяться, в этом случае информация Supplemental Palette Color LUT должна игнорироваться.

  • В настоящее время не определён механизм для отдельного указания согласованности цвета цветов в Supplemental Palette Color LUT — только необязательное включение профиля ICC в экземпляр изображения.

Grayscale and Color Image Transformation Models

Рисунок N.2-1. Модели преобразования изображений серой шкалы и цвета


N.2.1 Преобразования серой шкалы

N.2.1.1 Modality LUT (LUT модальности)

Операция Modality LUT применяется только к значениям серой шкалы.

Преобразование Modality LUT преобразует зависящие от производителя значения пикселей в значения пикселей, значимые для модальности и не зависящие от производителя (например, число Хаунсфилда для модальностей CT, оптическая плотность для дигитайзеров плёнки). Они могут представлять физические единицы или быть безразмерными. Modality LUT в состоянии представления зависит от модальности и аналогичен тому же модулю в изображении.

Примечание

  1. В некоторых случаях, например, в классе SOP хранения изображений CT, тот же концептуальный этап, что и Modality LUT, указывается в иной форме, например, как атрибуты Rescale Slope и Rescale Intercept в модуле CT Image Module, хотя модуль Modality LUT Module не входит в IOD CT Image.

  2. Значения пикселей изображения со значением Pixel Padding Value (0028,0120) в изображении, на которое есть ссылка, или в диапазоне, указанном Pixel Padding Value (0028,0120) и Pixel Padding Range Limit (0028,0121) (если присутствуют в изображении, на которое есть ссылка), должны быть учтены до входа на этап Modality LUT. См. определение Pixel Padding Value в PS3.3. Ни Pixel Padding Value (0028,0120), ни Pixel Padding Range Limit (0028,0121) не кодируются в экземпляре состояния представления.

В случае линейного преобразования Modality LUT описывается Rescale Slope (0028,1053) и Rescale Intercept (0028,1052). В случае нелинейного преобразования Modality LUT описывается Modality LUT Sequence. Правила применения Modality LUT определены в Section C.11.1 “Modality LUT Module” in PS3.3 .

Если Modality LUT или эквивалентные атрибуты входят как в изображение, так и в состояние представления, должен использоваться Modality LUT состояния представления вместо Modality LUT изображения или эквивалентных атрибутов в изображении. Если Modality LUT отсутствует в состоянии представления, он должен считаться тождественным преобразованием. Любой Modality LUT или эквивалентные атрибуты в изображении не должны использоваться.

N.2.1.2 Mask (Маска)

Операция Mask применяется только к значениям серой шкалы.

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

Это преобразование использует модуль Mask Module, применяемый в классе SOP хранения изображений рентгеновской ангиографии, хотя оно может применяться к любому экземпляру SOP хранения изображений, содержащему многокадровое изображение.

В случае рентгеновских изображений вычитание определено происходящим в пространстве, логарифмическом относительно интенсивности рентгеновского излучения. Если сохранённые значения пикселей ещё не находятся в таком пространстве, перед вычитанием должно быть выполнено определённое реализацией преобразование в такое пространство. Если присутствует модуль Modality LUT Module наряду с модулем Mask Module, то Modality LUT должен определять преобразование в такое логарифмическое пространство, иначе он не должен присутствовать (даже если Modality LUT может присутствовать в изображении(-ях), на которое есть ссылка, которое должно игнорироваться).

Примечание

  1. В случае изображения XA или XRF, если Pixel Intensity Relationship (0028,1040) в изображении равен LOG, то, хотя Modality LUT присутствовал бы в изображении (для отображения значений пикселей обратно в линейную зависимость от интенсивности рентгеновского излучения), Modality LUT не присутствовал бы в состоянии представления (то есть Modality LUT был бы тождественным преобразованием), поскольку для вычитания требуются логарифмические значения. См. Section C.8.7.1.1.2 “Pixel Intensity Relationship” in PS3.3 .

  2. В случае изображения XA или XRF, если Pixel Intensity Relationship (0028,1040) равен LIN, то Modality LUT не присутствовал бы в изображении, но Modality LUT должен был бы присутствовать в состоянии представления, поскольку для вычитания требуются логарифмические значения.

  3. В случае изображения XA или XRF, если Pixel Intensity Relationship (0028,1040) в изображении равен DISP, то, хотя Modality LUT может присутствовать или не присутствовать в изображении (для отображения значений пикселей обратно в линейную зависимость от интенсивности рентгеновского излучения), в состоянии представления присутствовал бы другой Modality LUT, если бы создатель состояния представления мог создать преобразование значений пикселей DISP в логарифмическое пространство для вычитания, либо Modality LUT в состоянии представления был бы тождественным преобразованием, если бы было известно, что значения пикселей DISP уже являются логарифмическими значениями, требуемыми для вычитания.

Результатом будет знаковое значение с битовой длиной на один бит больше, чем у исходных кадров.

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

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

N.2.1.3 VOI LUT (LUT области интереса)

Операция VOI LUT применяется только к значениям серой шкалы.

Преобразование LUT области интереса (value of interest, VOI) преобразует значения пикселей модальности в значения пикселей, значимые для пользователя или приложения.

Примечание

Photometric Interpretation (0028,0004) игнорируется, поскольку его эффект определяется применением преобразований серой шкалы.

Модуль Softcopy VOI LUT Module в состоянии представления аналогичен модулю VOI LUT Module в изображении.

В случае линейного преобразования VOI LUT описывается Window Center (0028,1050) и Window Width (0028,1051). В случае нелинейного преобразования VOI LUT описывается VOI LUT Sequence. Может присутствовать VOI LUT Function (0028,1056) для определения потенциально нелинейной интерпретации (например, SIGMOID) значений Window Center (0028,1050) и Window Width (0028,1051). Правила применения VOI LUT определены в Section C.11.8 “Softcopy VOI LUT Module” in PS3.3 .

VOI LUT может иметь участки с отрицательным наклоном.

Примечание

В сервисном классе базовой печати VOI LUT не может иметь отрицательный наклон.

Если VOI LUT входит как в изображение, так и в состояние представления, должен использоваться VOI LUT состояния представления вместо VOI LUT изображения. Если VOI LUT (применимый к изображению) отсутствует в состоянии представления, он должен считаться тождественным преобразованием. Любой VOI LUT или эквивалентные значения в изображении не должны использоваться.

N.2.1.4 Presentation LUT (LUT представления)

Операция Presentation LUT применяется только к значениям серой шкалы.

Преобразование Presentation LUT преобразует значения пикселей в P-значения — независимое от устройства перцептивно линейное пространство, определённое в PS3.14 Grayscale Standard Display Function. Оно может быть тождественной функцией, если выход преобразования VOI LUT уже в P-значениях.

Примечание

Если этапы Presentation LUT и VOI LUT являются тождественными преобразованиями, а модуль Mask Module отсутствует, то выход Modality LUT должен по определению быть P-значениями.

Для классов SOP хранения состояния мягкокопийного представления серой шкалы не определено иного выходного пространства, кроме P-значений.

В случае линейного преобразования Presentation LUT описывается Presentation LUT Shape (2050,0020). В случае нелинейного преобразования Presentation LUT описывается Presentation LUT Sequence. Правила применения Presentation LUT определены в Section C.11.6 “Softcopy Presentation LUT Module” in PS3.3 .

Примечание

  1. Поскольку конвейер преобразования серой шкалы полностью определяет все преобразования, применённые к сохранённым значениям пикселей в объекте изображения, на который есть ссылка, значение Photometric Interpretation (0028,0004) в объекте изображения, на который есть ссылка, игнорируется и переопределяется. Это означает, что создатель состояния представления либо выбрал конвейер, отражающий Photometric Interpretation (0028,0004), либо решил игнорировать или переопределить Photometric Interpretation и инвертировать изображение относительно того, что указано в Photometric Interpretation. Если Modality LUT и VOI LUT не имеют отрицательного наклона, можно достичь эффекта инверсии полярности изображения, выбрав Presentation LUT Shape равным IDENTITY или INVERSE, что отображает минимальное значение пикселя как белое, а не чёрное в случае Photometric Interpretation, равного MONOCHROME2, либо чёрное, а не белое в случае Photometric Interpretation, равного MONOCHROME1. Если отправляются данные Presentation LUT Data, можно инвертировать значения записей в таблице LUT для достижения инверсии полярности.

  2. Минимальное P-значение (ноль) всегда предписывает отображение наименьшей интенсивности.

  3. Отдельное преобразование Polarity не определено.

Модуль Softcopy Presentation LUT Module всегда присутствует в состоянии представления. Если Presentation LUT присутствует в изображении, должен использоваться Presentation LUT состояния представления вместо Presentation LUT изображения.

N.2.2 Цветовые преобразования

N.2.2.1 Преобразование пространства соединения профилей (Profile Connection Space)

Операция преобразования Profile Connection Space применяется только к цветным изображениям, включая изображения истинного цвета (например, RGB) и псевдоцвета (например, PALETTE COLOR), изображения серой шкалы, для которых в состоянии представления указан Palette Color LUT, и выходные значения RGB операции смешивания.

Профиль ICC является входным профилем (Input Profile). То есть он описывает цветовые характеристики (возможно, гипотетического) устройства, использованного для создания входных цветовых значений.

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

Примечание

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

    • физические факторы, такие как внешнее освещение среды просмотра (viewing flare) и природа различных источников света

    • психовизуальные факторы у наблюдателя

    • предпочтения наблюдателя

    • цель согласованности — воспроизвести ли цвета, воспринимаемые наблюдателем

      • исходной сцены,

      • воспроизводимого носителя, такого как отпечаток или слайд, при просмотре в указанных условиях.

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

  3. Когда цветное изображение визуализируется на дисплее серой шкалы, поведение не определено. Поскольку значение L* представления CIELab пространства PCS не сильно отличается от модели Бартена, используемой в GSDF, разумным подходом было бы интерпретировать его как P-значение.

Профиль ICC всегда присутствует в состоянии представления цвета, псевдоцвета или смешивания. Если профиль ICC присутствует в изображении, должен использоваться профиль ICC состояния представления вместо профиля ICC изображения.

N.2.2.2 Точка белого (White Point) (Информативное)

D50 означает излучение абсолютно чёрного тела объекта при температуре 5000 градусов К и включает много красного, что выглядит «естественно». D65 более синий, больше похож на «облачные дни», но человеческий глаз более чувствителен к синему. В то время как мониторы, по-видимому, находятся в диапазоне D50–D100, негатоскопы имеют около D110 (11000K).

PCS ICC всегда использует точку белого D50.

Во входном профиле ICC тег chromaticAdaptationTag кодирует преобразование цвета XYZ от фактического источника освещения к источнику освещения PCS (D50) и может быть полезен, если фактический источник освещения не является D50. Фактический источник освещения может также быть определён в mediaWhitePointTag. Однако при перцептивном намерении визуализации ни один из этих тегов не обязан использоваться системой управления цветом, и они не имеют какого-либо заданного поведения визуализации (в отличие от их использования с абсолютным и относительным колориметрическими намерениями визуализации).

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

N.2.3 Общие пространственные преобразования и преобразования аннотаций

Common Spatial and Annotation Transformation Model

Рисунок N.2-2. Модель общих пространственных преобразований и преобразований аннотаций


Общие пространственные преобразования и преобразования аннотаций применяются к любым независимым от устройства значениям — будь то P-значения серой шкалы или PCS-значения цвета — для любого типа состояния представления.

Значения, с которыми визуализируются аннотации, кодируются как независимые от устройства значения — либо как P-значения серой шкалы, либо как PCS-значения цвета. В случае PCS-значений кодируются значения CIELab, определённые со ссылкой на источник света D50.

Состояния представления серой шкалы могут указывать аннотации в цвете для визуализации на цветном выходном устройстве.

Механизм отображения P-значений серой шкалы и PCS-значений цвета на один и тот же дисплей зависит от реализации и не определён Стандартом.

N.2.3.1 Shutter (Затвор)

Преобразование Shutter предоставляет возможность исключить периметр за пределами области изображения. Может быть указан уровень серого для замены области под затвором.

Одна форма этого преобразования использует модуль Display Shutter Module, применяемый в классе SOP хранения изображений рентгеновской ангиографии, хотя она может применяться к любому экземпляру SOP хранения изображений, включая однокадровые изображения.

Другая форма использует битовое наложение (overlay) для указания произвольных областей изображения, которые следует исключить из отображения путём замены указанным уровнем серого, как описано в модуле Bitmap Display Shutter Module.

Примечание

  1. Поскольку аннотации следуют за операцией затвора в конвейере, аннотации в закрытых затвором областях не скрыты и видны.

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

N.2.3.2 Аннотация до пространственного преобразования

Преобразование аннотации до пространственного преобразования включает применение битовых наложений, как определено в модуле Overlay Plane Module, и свободного неформатированного текста или векторной графики, как описано в модуле Graphic Annotation Module, определённых в пространстве пикселей изображения (в отличие от пространства отображаемой области).

N.2.3.3 Пространственное преобразование

Некоторые модальности могут не доставлять изображение в желаемом повороте и требуют указания поворота в желаемое положение для представления. Это преобразование, указанное в модуле Spatial Transformation Module, включает поворот на 90, 180, 270 градусов по часовой стрелке с последующим горизонтальным отражением (L <--> R). Поворот на произвольный угол не поддерживается.

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

Примечание

В частности, число отображаемых пикселей может отличаться от числа пикселей изображения в результате:

  • уменьшения (например, 1 пиксель дисплея на 4 пикселя изображения),

  • увеличения (4 пикселя дисплея на каждый пиксель изображения),

  • интерполяции (пиксели дисплея, полученные из значений, отличных от значений пикселей изображения), и

  • субдискретизации.

N.2.3.4 Аннотация после пространственного преобразования

Преобразование аннотации после пространственного преобразования включает применение свободного неформатированного текста или векторной графики, как описано в модуле Graphic Annotation Module, определённых в пространстве отображаемой области (в отличие от пространства пикселей изображения).

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

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

N.2.4 Преобразования смешивания

Модель преобразования смешивания серой шкалы в цвет применяется только к паре значений серой шкалы, одно из которых сначала отображается в цвет, а затем накладывается на другое. Результирующие значения являются независимыми от устройства цветовыми PCS-значениями. Этот процесс проиллюстрирован на Figure N.2-3.

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

Grayscale to Color Blending Transformation Model

Рисунок N.2-3. Модель преобразования смешивания серой шкалы в цвет


N.2.4.1 Пиксели базового изображения

Преобразования Modality LUT и VOI LUT применяются к сохранённым значениям пикселей базового изображения.

Выходной диапазон преобразования VOI LUT зависит либо от ширины линейного окна, либо от диапазона выходных значений LUT, определённого дескриптором LUT (LUT Descriptor). Концептуально, для целей описания последующей операции смешивания, наименьшее значение пикселя из диапазона отображается в 0.0, наибольшее значение пикселя отображается в 1.0, а все промежуточные значения линейно отображаются в интервал [0.0..1.0].

N.2.4.2 Пиксели накладываемого изображения

Преобразования Modality LUT и VOI LUT применяются к сохранённым значениям пикселей накладываемого изображения.

Полный выходной диапазон предшествующего преобразования VOI LUT неявно масштабируется на весь входной диапазон преобразования Palette Color LUT.

Выходной диапазон значений RGB в преобразовании Palette Color LUT зависит от диапазона выходных значений LUT, определённого дескрипторами LUT. Концептуально, для целей описания последующей операции смешивания, запись LUT со значением 0 отображается в 0.0, а наибольшая возможная запись LUT отображается в 1.0, а все промежуточные значения линейно отображаются в интервал [0.0..1.0].

Примечание

На практике выход Palette Color LUT для накладываемых изображений кодируется в 8 или 16 битах и, следовательно, будет иметь диапазон от 0 до 0xFF или 0xFFFF.

Используемый Palette Color LUT — это тот, что закодирован в состоянии представления смешивания; любые Palette Color LUT или Supplemental Palette Color LUT в экземплярах изображений игнорируются.

N.2.4.3 Операция смешивания

Входными данными операции смешивания являются значения серой шкалы от 0.0 до 1.0 из базового изображения (Yu) и значения RGB от 0.0 до 1.0 из накладываемого изображения (RGBs), а также значение непрозрачности от 0.0 до 1.0 (A).

Выходом является единое изображение, содержащее значения RGB (RGBo), смешанные следующим образом:

Ro = Rs * A + Yu * (1-A)

Go = Gs * A + Yu * (1-A)

Bo = Bs * A + Yu * (1-A)

N.2.4.4 Преобразование в пространство соединения профилей

Выход операции смешивания неявно масштабируется до цветового охвата гипотетического устройства, описанного входным профилем ICC, в результате чего получаются PCS-значения.

N.2.5 Преобразования в оттенках серого для ангиографии

Класс SOP хранения состояния представления в оттенках серого XA/XRF (XA/XRF Grayscale Softcopy Presentation State Storage SOP Class) поддерживает последовательность преобразований, которая полностью определяет преобразование сохранённого изображения в отображаемое изображение.

Последовательность преобразований из сохранённых значений пикселей в P-значения явно определена в концептуальной модели. Фактически реализованная последовательность может отличаться, но должна приводить к тому же самому внешнему виду. Figure N.2.5-1 описывает эту последовательность преобразований.

XA/XRF Grayscale Image Transformation Model

Рисунок N.2.5-1. Модель преобразования изображения в оттенках серого XA/XRF


N.2.5.1 Mask (Маска)

Преобразование Mask состоит из операций вычитания маски, как указано атрибутами модуля XA/XRF Presentation State Mask Module, и атрибутом Mask Visibility Percentage модуля XA/XRF Presentation State Presentation Module.

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

В случае рентгеновских изображений вычитание, как указано, происходит в пространстве, логарифмическом относительно интенсивности рентгеновского излучения. Если сохранённые значения пикселей не находятся в логарифмическом пространстве, то в модуле XA/XRF Presentation Mask Module должен присутствовать Pixel Intensity Relationship LUT, указывающий преобразование в такое логарифмическое пространство, в противном случае он не должен присутствовать. Если Modality LUT или Pixel Intensity Relationship LUT присутствует в изображении(ях), на которое(ые) есть ссылка, он должен игнорироваться. Pixel Intensity Relationship LUT может быть указан покадрово и может отличаться для кадров маски и контрастных кадров.

Примечание

  1. Для изображений класса SOP X-Ray Angiographic Image Storage или X-Ray RF Image Storage состояние представления в оттенках серого XA/XRF позволяет указывать Pixel Intensity Relationship LUT покадрово. Это расширение Modality LUT изображения, который применим только ко всем кадрам изображения в целом.

  2. В случае изображения XA или XRF, если Pixel Intensity Relationship (0028,1040) в изображении равен LOG, то, хотя Modality LUT будет присутствовать в изображении (для преобразования значений пикселей обратно в линейную интенсивность рентгеновского излучения), в состоянии представления не будет присутствовать Pixel Intensity Relationship LUT ни для одного кадра, поскольку для вычитания требуются логарифмические значения. См. Section C.8.7.1.1.2 “Pixel Intensity Relationship” in PS3.3 .

    В случае улучшенного (Enhanced) изображения XA или XRF, если Pixel Intensity Relationship (0028,1040) в кадре равен LOG, то, хотя Pixel Intensity Relationship LUT будет присутствовать в кадре (для преобразования значений пикселей обратно в линейную интенсивность рентгеновского излучения, LUT Function (0028,9474) равен TO_LINEAR), в состоянии представления не будет присутствовать Pixel Intensity Relationship LUT для этого кадра, поскольку для вычитания требуются логарифмические значения. См. Section C.7.6.16.2.13 “Pixel Intensity Relationship LUT Macro” in PS3.3 .

  3. В случае изображения XA или XRF, если Pixel Intensity Relationship (0028,1040) в изображении равен LIN, то в изображении не будет присутствовать Modality LUT, но в состоянии представления для всех кадров необходимо будет присутствие Pixel Intensity Relationship LUT (для преобразования значений пикселей в логарифмические значения, LUT Function (0028,9474) равен TO_LOG), поскольку для вычитания требуются логарифмические значения.

    В случае улучшенного изображения XA или XRF, если Pixel Intensity Relationship (0028,1040) в кадре равен LIN, то в изображении не будет присутствовать Pixel Intensity Relationship LUT с целью преобразования значений пикселей обратно в линейную интенсивность рентгеновского излучения (LUT Function (0028,9474) равен TO_LINEAR), но в состоянии представления для этого кадра необходимо будет присутствие Pixel Intensity Relationship LUT (для преобразования значений пикселей в логарифмические значения), поскольку для вычитания требуются логарифмические значения.

  4. В случае изображения XA или XRF, если Pixel Intensity Relationship (0028,1040) в изображении равен DISP, то, хотя Modality LUT может присутствовать или не присутствовать в изображении (для преобразования значений пикселей обратно в линейную интенсивность рентгеновского излучения), в состоянии представления будет присутствовать другой Pixel Intensity Relationship LUT, если создатель состояния представления мог создать преобразование из значений пикселей DISP в логарифмическое пространство для вычитания, либо Pixel Intensity Relationship LUT в состоянии представления будет тождественным преобразованием, если известно, что значения пикселей DISP уже являются логарифмическими значениями, требуемыми для вычитания.

    В случае улучшенного изображения XA или XRF, если Pixel Intensity Relationship (0028,1040) в изображении равен OTHER, то, хотя Pixel Intensity Relationship LUT может присутствовать или не присутствовать для этого кадра (для преобразования значений пикселей обратно в линейную интенсивность рентгеновского излучения), в состоянии представления для этого кадра будет присутствовать другой Pixel Intensity Relationship LUT, если создатель состояния представления мог создать преобразование из значений пикселей OTHER в логарифмическое пространство для вычитания, либо Pixel Intensity Relationship LUT в состоянии представления будет тождественным преобразованием, если известно, что значения пикселей OTHER уже являются логарифмическими значениями, требуемыми для вычитания.

  5. Примечания 2, 3 и 4 обобщены в Table N.2.5.1-1

Таблица N.2.5.1-1. Сводка предоставления функции LUT для вычитания

Атрибут Pixel Intensity Relationship (0028,1040) экземпляра SOP, на который есть ссылка

Содержимое Pixel Intensity Relationship LUT Sequence (0028,9422) в модуле XA/XRF Presentation State Mask Module

LIN

предоставлен TO_LOG LUT

LOG

отсутствует

DISP or OTHER

предоставлен TO_LOG LUT, может быть тождественным


N.2.5.2 Повышение резкости краёв

Преобразование повышения резкости краёв состоит из операций фильтрации для улучшения отображения данных пикселей, как указано атрибутом Display Filter Percentage модуля XA/XRF Presentation State Presentation Module.

N.2.6 Расширенные преобразования смешивания

Модель расширенного преобразования смешивания применяется к нескольким входным данным цвета RGB и использует смешивание переднего плана (foreground blending) или равное смешивание (equal blending).

Несколько преобразований в этой модели воздействуют на входные данные до их использования в смешивании, как показано на Figure N.2.6-1.

Для входных данных в оттенках серого, для которых в состоянии представления указаны преобразования серой шкалы (Modality LUT, VOI LUT) и преобразования палитры цвета (Palette Color LUT), эти преобразования должны применяться, как указано в Section N.2.4.2, для получения значений RGB.

Входные данные в оттенках серого, для которых не указана связанная информация Palette Color LUT ни в состоянии представления, ни в экземпляре изображения, на который есть ссылка, должны быть преобразованы в полноцветное изображение путём установки R равным G равным B.

Color and Threshold Application

Рисунок N.2.6-1. Применение цвета и порога


Пиксели заполнения (padding) во входных данных получают нулевое значение непрозрачности и должны быть установлены в 0 для красного, зелёного и синего.

Метод переднего плана смешивает два входных набора данных. Первый входной набор использует непрозрачность Relative Opacity (0070,0403), а второй входной набор использует непрозрачность (1 - Relative Opacity (0070,0403)).

Если оба входных значения являются значениями заполнения, результатом является значение заполнения.

Если одно из значений является значением заполнения, результатом является значение, не являющееся заполнением.

Если оба пикселя имеют значения, результат равен Relative Opacity * первое значение + (1 - Relative Opacity) * второе значение.

Foreground Blending

Рисунок N.2.6-2. Смешивание переднего плана


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

Если входное значение пикселя является значением заполнения, то Relative Opacity для этого входного пикселя равна нулю.

Если входное значение пикселя не является значением заполнения, то Relative Opacity для этого пикселя равна 1 / (число входных пикселей, не являющихся заполнением).

Результирующее значение — это сумма по всем входным пикселям произведения входного значения пикселя на Relative Opacity.

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

Equal Blending

Рисунок N.2.6-3. Равное смешивание


N.3 Поведение SCP

В дополнение к поведению для класса услуг хранения, указанному в Section B.2.2 «Поведение SCP», для классов SOP хранения состояния представления в виде мягкой копии указаны следующие дополнительные требования:

  • устройство отображения, действующее как SCP этих классов SOP, должно делать все обязательные атрибуты представления доступными для применения к изображениям, на которые есть ссылка, по усмотрению пользователя устройства отображения, для всех классов SOP хранения изображений, определённых в заявлении о соответствии, для которых поддерживается класс SOP хранения состояния представления в виде мягкой копии.

  • устройство отображения, действующее как SCP этих классов SOP и поддерживающее составные типы графики, должно отображать графику, описанную в Compound Graphic Sequence (0070,0209), и не должно отображать элементы в Text Object Sequence (0070,0008) и Graphic Object Sequence (0070,0009), имеющие то же значение Compound Graphic Instance ID (0070,0226).

Примечание

Хотя это не требуется, устройство отображения, действующее как SCP класса SOP хранения состояния представления смешивания в виде мягкой копии или класса SOP хранения состояния представления расширенного смешивания, может поддерживать класс SOP хранения пространственной регистрации для преобразования одной системы координат (Frame of Reference) в другую или для явного указания взаимосвязи между членами двух наборов изображений и может быть способно передискретизировать базовые и накладываемые наборы изображений, отличающиеся друг от друга ориентацией и пространственным разрешением внутри плоскости и между плоскостями.

N.4 Соответствие

В дополнение к требованиям заявления о соответствии для класса услуг хранения, указанным в Section B.4.3, для классов SOP хранения состояния представления в виде мягкой копии указаны следующие дополнительные требования:

N.4.1 Заявление о соответствии для SCU

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

  • Для SCU класса SOP хранения состояния представления в виде мягкой копии, создающего экземпляр SOP этого класса SOP, — способ, которым атрибуты, связанные с представлением, получаются из отображаемого изображения, вмешательства оператора или значений по умолчанию, и то, как они включаются в IOD.

  • Для SCU класса SOP хранения состояния представления в виде мягкой копии — классы SOP хранения изображений, также поддерживаемые SCU и на которые могут ссылаться экземпляры класса SOP хранения состояния представления в виде мягкой копии.

  • Для SCU класса SOP хранения состояния представления в виде мягкой копии — поддерживает ли он Compound Graphic Sequence (0070,0209), и с указанием того, какие составные типы графики могут быть сгенерированы, включая дополнительные частные определённые типы составной графики.

N.4.2 Заявление о соответствии для SCP

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

  • Для SCP класса SOP хранения состояния представления в виде мягкой копии, отображающего изображение, на которое ссылается экземпляр SOP этого класса SOP, — способ, которым атрибуты, связанные с представлением, используются для влияния на отображение изображения.

  • Для SCP класса SOP хранения состояния представления в виде мягкой копии — классы SOP хранения изображений, также поддерживаемые SCP и на которые могут ссылаться экземпляры класса SOP хранения состояния представления в виде мягкой копии.

  • Для SCP класса SOP хранения состояния представления в виде мягкой копии — поддерживает ли он Compound Graphic Sequence (0070,0209), и какие составные типы графики могут быть визуализированы, включая дополнительные частные определённые типы составной графики.

O Классы SOP хранения структурированных отчётов

O.1 Обзор

Классы SOP хранения структурированных отчётов расширяют функциональность класса услуг хранения (определённого в Annex B) дополнительным поведением и требованиями соответствия.

O.2 Поведение SCU и SCP класса SOP хранения структурированных отчётов

O.2.1 Поведение SCU

O.2.1.1 Классы SOP CAD SR

Модификаторы концепции Rendering Intent в объектах Mammography CAD SR, Chest CAD SR и Colon CAD SR должны быть согласованы. Элементы содержимого, отмеченные «For Presentation» (для представления), не должны быть подчинены элементам содержимого, отмеченным «Not for Presentation» (не для представления) или «Presentation Optional» (представление необязательно) в дереве содержимого. Аналогично, элементы содержимого, отмеченные «Presentation Optional», не должны быть подчинены элементам содержимого, отмеченным «Not for Presentation» в дереве содержимого.

Элементы содержимого, на которые есть ссылка из другого экземпляра объекта SR, такого как предыдущий Mammography CAD SR, Chest CAD SR или Colon CAD SR, должны быть вставлены по значению (by-value) в новый экземпляр объекта SR с соответствующим исходным контекстом наблюдения. Необходимо обновить Rendering Intent и идентификаторы элементов содержимого, на которые есть ссылка, для отношений по ссылке (by-reference), в элементах содержимого, перефразированных из другого источника.

O.2.1.2 Класс SOP расширяемого SR

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

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

O.2.2 Поведение SCP

SCP, намеревающийся отобразить или иным образом визуализировать структурированный отчёт, должен передавать его полный смысл однозначным образом, за исключением случаев, описанных в Section O.2.2.2.

Примечание

«Полный смысл» включает не только дерево содержимого (то есть элементы Content Sequence), но и все атрибуты набора данных, необходимые для правильной интерпретации структурированного отчёта. Это включает атрибуты, устанавливающие исходный контекст наблюдения (Observation Context) для дерева содержимого, то есть идентификаторы пациента, процедуры и наблюдателя, а также статус завершения (Completion status) и статус верификации (Verification status) структурированного отчёта.

Значковое изображение (Icon Image) в ссылке IMAGE не имеет смысла и не обязано визуализироваться.

Для устройства, являющегося одновременно SCU и SCP этих классов SOP хранения, в дополнение к поведению для класса услуг хранения, указанному в Section B.2.2, для классов SOP хранения структурированных отчётов указаны следующие дополнительные требования:

  • SCP этого класса SOP должен поддерживать уровень хранения 2 (Полный), как определено в Section B.4.1.

Примечание

Это требование означает, что все атрибуты типа 1, типа 2 и типа 3, определённые в дефиниции информационного объекта (Information Object Definition), связанной с классом SOP, будут сохранены и доступны.

O.2.2.1 Классы SOP CAD SR

Объекты Mammography CAD SR, Chest CAD SR и Colon CAD SR содержат данные не только для представления клиницисту, но и данные, предназначенные исключительно для использования в последующих анализах CAD для маммографии.

SCU предоставляет рекомендации по визуализации через модификаторы концепции «Rendering Intent», связанные с элементами содержимого «Individual Impression/Recommendation», «Composite Feature» и «Single Image Finding». Полный смысл SR обеспечивается, если все элементы содержимого, отмеченные «Presentation Required» (представление обязательно), визуализируются вплоть до первого экземпляра «Not for Presentation» или «Presentation Optional» для каждой ветви дерева. Рекомендуется использовать заявление о соответствии SCU, если дальнейшее расширение смысла SR может быть достигнуто визуализацией некоторых или всех данных, отмеченных «Presentation Optional». Данные, отмеченные «Not for Presentation», не должны визуализироваться SCP; они встроены в дерево содержимого как входные данные для последующих рабочих шагов анализа CAD.

SCP может дополнительно интерпретировать, визуализировать ли Single Image Finding, имеющий Rendering Intent «Presentation Optional», интерпретируя значение элемента содержимого CAD Operating Point, подчинённого Rendering Intent, если он присутствует. Если элемент содержимого CAD Operating Point отсутствует, то визуализация Single Image Finding может основываться на рекомендациях в заявлении о соответствии DICOM создателя. Дополнительную информацию о предполагаемом использовании CAD Operating Point см. в Section E.4 “CAD Operating Point” in PS3.17 .

O.2.2.2 Класс SOP расширяемого SR

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

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

Поскольку из-за нераспознанного содержимого может оказаться невозможным однозначно визуализировать всё содержимое целиком, SCP, намеревающийся отобразить или иным образом визуализировать экземпляр SOP расширяемого SR,

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

  • должен указывать в своём заявлении о соответствии своё поведение при столкновении с неподдерживаемым содержимым

O.3 Изменение содержимого документа SR

Устройство, являющееся SCU класса SOP хранения SR, может изменять информацию в экземпляре SOP, который оно ранее отправило или получило. Когда этот экземпляр SOP изменяется и отправляется SCP, ему должен быть присвоен новый SOP Instance UID, если выполняется любое из следующих условий:

  • добавление, удаление или обновление любого атрибута в модуле SR Document General Module или SR Document Content Module;

  • изменение Series Instance UID (0020,000E);

  • изменение Study Instance UID (0020,000D).

O.4 Соответствие

В дополнение к требованиям заявления о соответствии для класса услуг хранения, указанным в Section B.4.3, для классов SOP хранения структурированных отчётов указаны следующие дополнительные требования:

O.4.1 Заявление о соответствии для SCU

В заявлении о соответствии любой реализации, заявляющей о соответствии классам SOP хранения структурированных отчётов в роли SCU, должно быть документировано следующее:

  • Классы SOP хранения изображений или других составных объектов, также поддерживаемые SCU и на которые могут ссылаться экземпляры класса SOP хранения структурированных отчётов.

  • Диапазон типов значений и типов взаимосвязей, поддерживаемых SCU.

  • Условия, при которых для существующего документа SR генерируется новый SOP Instance UID.

  • Если реализация предоставляет функциональность Query/Retrieve экземпляров SOP структурированных отчётов в роли SCU — поддерживает ли она необязательные ключи Concept Name Code Sequence или Content Template Sequence.

Примечание

Описание типов значений и типов взаимосвязей, поддерживаемых SCU, особенно важно для класса SOP расширяемого SR.

O.4.1.1 Классы SOP CAD SR

В заявлении о соответствии любой реализации, заявляющей о соответствии классу SOP Mammography CAD SR в роли SCU, должно быть документировано следующее:

  • Какие типы обнаружений и/или анализов устройство способно выполнять:

    • Из обнаружений, перечисленных в контекстной группе 6014 Mammography Single Image Finding

    • Из анализов, перечисленных в контекстной группе 6043 Types of Mammography CAD Analysis

В заявлении о соответствии любой реализации, заявляющей о соответствии классу SOP Chest CAD SR в роли SCU, должно быть документировано следующее:

  • Какие типы обнаружений и/или анализов устройство способно выполнять:

    • Из обнаружений, перечисленных в Context ID 6101 Chest Finding or Feature или Context ID 6102 Chest Finding or Feature Modifier

    • Из анализов, перечисленных в Context ID 6137 Types of CAD Analysis

В заявлении о соответствии любой реализации, заявляющей о соответствии классу SOP Colon CAD SR в роли SCU, должно быть документировано следующее:

  • Какие типы обнаружений и/или анализов устройство способно выполнять:

    • Из обнаружений, перечисленных в Context ID 6201 Colon Finding or Feature

    • Из анализов, перечисленных в Context ID 6137 Types of CAD Analysis

В заявлении о соответствии любой реализации, заявляющей о соответствии классам SOP Mammography CAD SR, Chest CAD SR или Colon CAD SR в роли SCU, создающего экземпляры, должно быть документировано следующее:

  • Какие необязательные элементы содержимого поддерживаются

  • Условия, при которых элементам содержимого присваивается Rendering Intent «Presentation Optional», и будет ли значение CAD Operating Point включено с каждым Single Image Finding, имеющим Rendering Intent «Presentation Optional»

  • Рекомендации по условиям, при которых элементы содержимого с Rendering Intent «Presentation Optional» следует визуализировать, на основе CAD Operating Point или иным образом

  • Условия, при которых элементам содержимого присваивается Rendering Intent «Not for Presentation»

O.4.1.2 Классы SOP ультразвукового SR

В заявлении о соответствии любой реализации создателя SR, заявляющей о соответствии классу SOP Simplified Adult Echo SR в роли SCU, должно быть документировано следующее:

O.4.2 Заявление о соответствии для SCP

В заявлении о соответствии любой реализации, заявляющей о соответствии классу SOP хранения структурированных отчётов в роли SCP, должно быть документировано следующее:

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

  • Для SCP класса SOP хранения структурированных отчётов — классы SOP хранения изображений или других составных объектов, также поддерживаемые SCP и на которые могут ссылаться экземпляры класса SOP хранения структурированных отчётов, и будут ли они отображаться или иным образом визуализироваться.

  • Для SCP класса SOP хранения структурированных отчётов, отображающего или иным образом визуализирующего изображение или другой составной объект, на который ссылается экземпляр SOP этого класса SOP, — способ, которым атрибуты, связанные со структурированным отчётом (такие как пространственные координаты и состояния представления, на которые есть ссылка), используются для влияния на отображение изображения или объекта.

  • Если реализация поддерживает функциональность Query/Retrieve экземпляров SOP структурированных отчётов в роли SCP — поддерживает ли она необязательные ключи Concept Name Code Sequence или Content Template Sequence.

O.4.2.1 Классы SOP CAD SR

В заявлении о соответствии любой реализации, заявляющей о соответствии классам SOP Mammography CAD SR, Chest CAD SR или Colon CAD SR в роли SCP, должно быть документировано следующее:

  • Условия, при которых SCP будет визуализировать элементы содержимого с модификатором концепции Rendering Intent, установленным в «Presentation Optional»

O.4.2.2 Класс SOP расширяемого SR

В заявлении о соответствии любой реализации, заявляющей о соответствии классу SOP расширяемого SR в роли SCP, должно быть документировано следующее:

  • Поведение и предупреждения, генерируемые при столкновении с неподдерживаемыми элементами содержимого, типами значений и типами взаимосвязей

P Класс услуг журналирования событий приложения

P.1 Обзор

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

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

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

Примечание

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

P.1.2 Определение услуги

Два равноправных AE DICOM реализуют класс SOP класса услуг журналирования событий приложения, при этом одно выступает в роли SCU, а другое — в роли SCP. Классы SOP класса услуг журналирования событий приложения реализуются с использованием услуги DIMSE-N N-ACTION, как определено в PS3.7.

Услуга N-ACTION передаёт следующую семантику:

  • SCU уведомляет SCP о том, что произошло событие, которое SCP должен записать в журнал. Action Information запроса N-ACTION-RQ содержит информацию о событии.

  • SCP отвечает подтверждением статуса действия записи.

Процедура согласования ассоциации используется для согласования поддерживаемых классов SOP. PS3.7 определяет процедуру ассоциации. Класс услуг журналирования событий приложения не поддерживает расширенное согласование.

Освобождение ассоциации не должно оказывать никакого влияния на содержимое журнала, управляемого SCP.

P.2 Определение класса SOP журналирования процедурных событий

Класс SOP журналирования процедурных событий позволяет SCU сообщать SCP о событиях, которые должны быть записаны в экземпляр SOP журнала процедуры, как описано в PS3.3. Это позволяет нескольким устройствам, участвующим в исследовании (Study), совместно строить журнал событий, происходящих во время этого исследования.

Множественные процедурные события, сообщаемые через этот класс SOP, связаны Patient ID, Study Instance UID, Study ID и/или Performed Location. Механизм, посредством которого несколько устройств получают эти общие идентификаторы, не определён этим классом SOP.

Примечание

Для этой цели могут использоваться классы SOP Modality Worklist или UPS. Для простых устройств, не способных поддерживать классы SOP рабочего списка, SCP может быть в состоянии использовать Performed Location или AE Title SCU для соотнесения использования устройства с конкретной процедурой.

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

Примечание

Сетевой адрес и/или AE Title SCU могут использоваться для идентификации устройства как участника конкретной процедуры.

P.2.1 Группа услуг DIMSE

Услуги DIMSE-N, применимые к классу SOP журналирования процедурных событий, показаны в Table P.2-1.

Таблица P.2-1. Группа услуг DIMSE, применимая к журналированию процедурных событий

Элемент службы сообщений DICOM

Использование (SCU/SCP)

N-ACTION

M/M


Услуги и протокол DIMSE-N определены в PS3.7.

P.2.2 Работа

AE DICOM, заявляющие о соответствии этому классу SOP в роли SCU, должны инициировать запрос N-ACTION. AE DICOM, заявляющие о соответствии этому классу SOP в роли SCP, должны поддерживать запрос N-ACTION.

P.2.2.1 Информация о действии (Action Information)

AE DICOM, заявляющие о соответствии этому классу SOP в роли SCU и/или SCP, должны поддерживать Action Type и Action Information в N-ACTION-RQ, как указано в Table P.2-2.

Таблица P.2-2. Информация о действии журналирования процедурных событий

Имя типа действия

Идентификатор типа действия

Имя атрибута

Tag

Использование (SCU/SCP)

Record Procedural Event

1

Specific Character Set

(0008,0005)

1C/1C

(Обязательно, если используется расширенный или заменяющий набор символов)

Patient ID

(0010,0020)

2/2

Study Instance UID

(0020,000D)

2/2

Study ID

(0020,0010)

2/2

Synchronization Frame of Reference UID

(0020,0200)

2/2

Performed Location

(0040,0243)

2/2

All other Attributes of the SR Document Content Module using Procedure Log IOD Content Constraints

См. Раздел P.2.2.1.3


P.2.2.1.1 Атрибуты сопоставления исследования

SCU может предоставить атрибуты Patient ID (0010,0020), Study Instance UID (0020,000D), Study ID (0020,0010) и/или Performed Location (0040,0243), чтобы позволить SCP сопоставить N-ACTION с исследованием, для которого создаётся журнал процедуры.

P.2.2.1.2 Synchronization Frame of Reference UID

Атрибут Synchronization Frame of Reference UID (0020,0200) определяет временную систему координат (frame of reference) для атрибутов Observation DateTime (0040,A032) в записи Procedural Event. Если значения атрибута Observation DateTime не синхронизированы в идентифицируемой системе координат, атрибут должен иметь нулевую длину.

P.2.2.1.3 Ограничения атрибутов модуля SR Document Content Module

Запись Procedural Event должна передаваться в (верхнеуровневом) элементе содержимого и подчинённых элементах содержимого, как указано определением модуля SR Document Content Module в PS3.3.

Верхнеуровневый и подчинённые элементы содержимого должны быть построены в соответствии с Procedure Log IOD Content Constraints из PS3.3.

Примечание

  1. Эти ограничения определяют использование BTID 3001 Procedure Log, определённого в PS3.16, а также конкретное особое использование атрибутов Observation DateTime (0040,A032).

  2. TID 3001 требует явного указания контекста наблюдателя (Observer Context) верхнеуровневого CONTAINER через TID 1002.

  3. В одном сообщении N-ACTION-RQ может быть включено несколько событий (подчинённых элементов содержимого).

P.2.2.2 Поведение пользователя класса услуг

SCU должен запрашивать журналирование событий, происходящих во время исследования, используя примитив запроса N-ACTION.

SCU должен получать ответы N-ACTION. Действия, предпринимаемые при коде статуса ответа об ошибке (Failure) или при отсутствии ответа SCP, зависят от реализации.

P.2.2.3 Поведение поставщика класса услуг

SCP должен управлять созданием экземпляров SOP услуги хранения журнала процедуры. Он должен получать через примитив запроса N-ACTION запросы на журналирование событий, происходящих во время исследования. SCP должен (в соответствии с ограничениями, зависящими от приложения) включать эти записи событий в экземпляр SOP журнала процедуры для указанного исследования.

SCP должен возвращать через примитив ответа N-ACTION код статуса ответа N-ACTION, применимый к соответствующему запросу действия.

P.2.2.4 Коды статуса

Table P.2-3 определяет конкретные значения кодов статуса, которые могут быть возвращены в ответе N-ACTION. Дополнительные общие коды статуса ответа см. в PS3.7.

Таблица P.2-3. Статус ответа

Статус службы

Дополнительное значение

Код статуса

Успех

0000

Предупреждение

Указанный Synchronization Frame of Reference UID не совпадает с Synchronization Frame of Reference SCP

B101

Приведение (coercion) Study Instance UID; событие записано под другим Study Instance UID

B102

Идентификаторы несогласованы при сопоставлении с текущим исследованием; событие записано

B104

Отказ

Отказано: журналирование процедуры недоступно для указанного Study Instance UID

C101

Отказано: информация о событии не соответствует шаблону

C102

Отказано: невозможно сопоставить событие с текущим исследованием

C103

Отказано: идентификаторы несогласованы при сопоставлении с текущим исследованием; событие не записано

C104


P.2.2.5 Ответ на действие (Action Reply)

При любом статусе ответа, указывающем на успех или предупреждение, идентификаторы исследования, в которое было записано событие, должны быть возвращены в Action Reply N-ACTION-RSP, как указано в Table P.2-4.

Таблица P.2-4. Ответ на действие журналирования процедурных событий

Имя типа действия

Идентификатор типа действия

Имя атрибута

Tag

Использование (SCU/SCP)

Record Procedural Event

1

Study Instance UID

(0020,000D)

3/1

Patient ID

(0010,0020)

3/1


P.2.3 UID класса SOP журналирования процедурных событий

Класс SOP журналирования процедурных событий должен однозначно идентифицироваться UID класса SOP журналирования процедурных событий, который должен иметь значение «1.2.840.10008.1.40».

P.2.4 Идентификация экземпляра журналирования процедурных событий

Общеизвестный (well-known) UID экземпляра SOP журналирования процедурных событий должен иметь значение «1.2.840.10008.1.40.1».

P.2.5 Требования соответствия

Заявление о соответствии AE DICOM должно быть оформлено, как определено в PS3.2.

P.2.5.1 Соответствие SCU

SCU должен документировать в своём заявлении о соответствии поведение и действия, которые заставляют SCU генерировать примитив N-ACTION (уведомление о процедурном событии). Он должен указать шаблон, используемый для построения информации о событии, и схемы кодирования, используемые для кодированных записей в информации о событии.

SCU должен документировать идентификаторы, которые он отправляет для целей сопоставления, и способ получения этих атрибутов (например, через запрос Modality Worklist, ручной ввод и т. д.).

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

SCU должен документировать механизмы, используемые для установления синхронизации времени и указания Synchronization Frame of Reference UID.

P.2.5.2 Соответствие SCP

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

SCP должен документировать поведение и действия, которые заставляют SCP генерировать статус успеха, предупреждения или отказа для полученного N-ACTION.

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

SCP должен документировать способ присвоения значения атрибуту Observation Datetime (0040,A032), когда Synchronization Frame of Reference UID, предоставленный SCU, отсутствует или отличается от такового у SCP.

P.3 Определение класса SOP журналирования введения веществ

Класс SOP журналирования введения веществ позволяет SCU сообщать SCP о событиях, подлежащих записи в журнал введения лекарственных препаратов пациента (Medication Administration Record, MAR) или аналогичный журнал, определение которого выходит за рамки Стандарта. Это позволяет устройствам с интерфейсами протокола DICOM сообщать о введении диагностических средств (включая контрастные вещества) и терапевтических препаратов, а также об имплантации устройств.

Введение вещества, о котором сообщается через этот класс SOP, связано с MAR посредством Patient ID или Admission ID. Механизм, посредством которого SCU получает этот идентификатор, не определён этим классом SOP.

Запись в журнал MAR авторизуется как минимум одним из операторов, указанных в Operator Identification Sequence. Механизм, посредством которого SCU получает эти идентификаторы, не определён этим классом SOP. SCP может отказать в записи в журнал, если ни один из указанных операторов не авторизован добавлять записи в MAR. Механизм, посредством которого SCP проверяет такую авторизацию, не определён этим классом SOP.

Примечание

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

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

  3. Авторизация операторов на уровне приложения для целей записи в MAR отличается от любого механизма контроля доступа на транспортном уровне (см. профили ассоциации идентификации пользователя в PS3.15).

P.3.1 Группа услуг DIMSE

Услуги DIMSE-N, применимые к классу SOP журналирования введения веществ, показаны в Table P.3-1.

Таблица P.3-1. Группа услуг DIMSE, применимая к журналированию введения веществ

Элемент службы сообщений DICOM

Использование (SCU/SCP)

N-ACTION

M/M


Услуги и протокол DIMSE-N определены в PS3.7.

P.3.2 Работа

AE DICOM, заявляющие о соответствии этому классу SOP в роли SCU, должны инициировать запрос N-ACTION. AE DICOM, заявляющие о соответствии этому классу SOP в роли SCP, должны поддерживать запрос N-ACTION.

P.3.2.1 Информация о действии журналирования введения веществ

Эта операция позволяет SCU отправить элемент или запись журнала введения лекарственных препаратов, предоставляя информацию о конкретном реальном акте введения вещества, относящемся к компетенции SCU. Эта операция должна инициироваться через услугу DIMSE N-ACTION.

Атрибуты информации о действии определены модулем Substance Administration Log Module, указанным в PS3.3. AE DICOM, заявляющие о соответствии этому классу SOP в роли SCU и/или SCP, должны поддерживать Action Type и атрибуты Action Information в N-ACTION-RQ, как указано в Table P.3-2.

Таблица P.3-2. Информация N-ACTION журналирования введения веществ

Имя типа действия

Идентификатор типа действия

Имя атрибута

Tag

Использование (SCU/SCP)

Record Substance Administration Event

1

Specific Character Set

(0008,0005)

1C/1C

(Обязательно, если используется расширенный или заменяющий набор символов)

Patient ID

(0010,0020)

1C/1C

SCU должен предоставить Patient ID и/или Admission ID; SCP должен поддерживать атрибут, если он предоставлен

Issuer of Patient ID

(0010,0021)

3/2

Patient's Name

(0010,0010)

2/2

Admission ID

(0038,0010)

1C/1C

SCU должен предоставить Patient ID и/или Admission ID; SCP должен поддерживать атрибут, если он предоставлен

Issuer of Admission ID

(0038,0011)

3/2

Product Package Identifier

(0044,0001)

1C/1C

SCU должен предоставить Product Package Identifier и/или Product Name; SCP должен поддерживать атрибут, если он предоставлен

Product Name

(0044,0008)

1C/1C

SCU должен предоставить Product Package Identifier и/или Product Name; SCP должен поддерживать атрибут, если он предоставлен

Product Description

(0044,0009)

3/3

Substance Administration DateTime

(0044,0010)

1/1

Substance Administration Notes

(0044,0011)

3/2

Substance Administration Device ID

(0044,0012)

3/3

Administration Route Code Sequence

(0054,0302)

2/2

>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

Substance Administration Parameter Sequence

(0044,0019)

3/3

>All Attributes of the Substance Administration Parameter Sequence

3/3

Operator Identification Sequence

(0008,1072)

1/1

>Person Identification Code Sequence

(0040,1101)

1/1

>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”


P.3.2.2 Поведение пользователя класса услуг

SCU должен запрашивать журналирование событий введения веществ для указанного пациента, используя примитив запроса N-ACTION.

SCU должен получать ответы N-ACTION. Действия, предпринимаемые при коде статуса ответа об ошибке или при отсутствии ответа SCP, зависят от реализации.

P.3.2.3 Поведение поставщика класса услуг

SCP должен получать через примитив запроса N-ACTION запросы на журналирование событий введения веществ. SCP должен включать эти записи событий в журнал введения лекарственных препаратов или аналогичный журнал для указанного пациента.

Примечание

Идентификация пациента может передаваться явно посредством Patient ID (0010,0020) или неявно посредством Admission (то есть Visit) ID (0038,0010). Учреждение обычно выбирает один из этих идентификаторов в качестве основного идентификатора пациента в месте оказания помощи, например, напечатанный на браслете со штрихкодом, использование которого может облегчить ввод данных для записи в журнал. Однако в «Модели реального мира для целей интерфейса Modality-IS» (см. PS3.3) визит (Visit) подчинён пациенту; следовательно, Admission ID (0038,0010) может быть уникальным только в контексте пациента, а не в контексте учреждения. Использование атрибута Admission ID (0038,0010) для идентификации пациента эффективно только в том случае, если Admission ID (0038,0010) уникален в контексте учреждения.

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

Примечание

SCP может преобразовывать кодированные данные в свободный текст в журнале с потерей конкретных значений кода, если журнал не поддерживает такие кодированные данные.

SCP должен возвращать через примитив ответа N-ACTION код статуса ответа N-ACTION, применимый к соответствующему запросу действия.

P.3.2.4 Коды статуса

Table P.3-3 определяет конкретные значения кодов статуса, которые могут быть возвращены в ответе N-ACTION. Дополнительные общие коды статуса ответа см. в PS3.7.

Таблица P.3-3. Статус ответа

Статус службы

Дополнительное значение

Код статуса

Успех

0000

Отказ

Отказано: оператор отклонён: не авторизован для добавления записи в журнал введения лекарственных препаратов

C10E

Отказано: пациент не может быть идентифицирован по Patient ID (0010,0020) или Admission ID (0038,0010)

C110

Отказано: не удалось обновить журнал введения лекарственных препаратов

C111


P.3.3 UID класса SOP журналирования введения веществ

Класс SOP журналирования введения веществ должен однозначно идентифицироваться UID класса SOP журналирования введения веществ, который должен иметь значение «1.2.840.10008.1.42».

P.3.4 UID экземпляра журналирования введения веществ

Общеизвестный UID экземпляра SOP журналирования введения веществ должен иметь значение «1.2.840.10008.1.42.1».

P.3.5 Требования соответствия

Заявление о соответствии AE DICOM должно быть оформлено, как определено в PS3.2.

P.3.5.1 Соответствие SCU

SCU должен документировать в своём заявлении о соответствии поведение и действия, которые заставляют SCU генерировать примитив N-ACTION-RQ.

SCU должен документировать способ получения атрибута Patient ID (0010,0020) или Admission ID (0038,0010) (например, через запрос Modality Worklist, сканирование штрихкода, ручной ввод и т. д.).

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

P.3.5.2 Соответствие SCP

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

SCP должен документировать поведение и действия, которые заставляют SCP генерировать статус успеха или отказа для полученного N-ACTION-RQ.

Q Класс услуг запроса релевантной информации о пациенте

Q.1 Обзор

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

Информационная модель запроса состоит из двух сущностей с отношением «один к одному»: пациент (Patient) и информация о пациенте (Patient Information).

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

Q.2 Группа услуг DIMSE-C

Одна услуга DIMSE-C используется при построении классов SOP класса услуг запроса релевантной информации о пациенте. Используется следующая операция DIMSE-C.

  • C-FIND

Q.2.1 Операция C-FIND

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

Q.2.1.1 Параметры услуги C-FIND

Q.2.1.1.1 SOP Class UID

SOP Class UID определяет модель релевантной информации о пациенте и шаблон, относительно которых должен выполняться C-FIND. Поддержка SOP Class UID подразумевается Abstract Syntax UID контекста представления, используемого этой операцией C-FIND.

Q.2.1.1.2 Приоритет (Priority)

Атрибут Priority определяет запрошенный приоритет операции C-FIND относительно других операций DIMSE, выполняемых тем же SCP.

Обработка запросов приоритета не требуется от SCP. Поддерживает ли SCP обработку приоритета и значение различных уровней приоритета должны быть указаны в заявлении о соответствии SCP.

Q.2.1.1.3 Идентификатор (Identifier)

И запрос, и ответ C-FIND содержат идентификатор, закодированный как набор данных (см. PS3.5).

Q.2.1.1.3.1 Структура идентификатора запроса

Идентификатор в запросе C-FIND должен содержать:

  • Ключевые атрибуты (Key Attributes) со значениями, подлежащими сопоставлению со значениями атрибутов, указанных в классе SOP.

  • Content Template Sequence (0040,A504), который должен включать один элемент последовательности, содержащий атрибуты Template Identifier (0040,DB00) и Mapping Resource (0008,0105), для указания структуры шаблона, используемой в соответствующих ответах C-FIND.

  • Условно — атрибут Specific Character Set (0008,0005). Этот атрибут должен быть включён, если в любых атрибутах идентификатора запроса могут использоваться расширенные или заменяющие наборы символов. В противном случае он не должен включаться.

Ключевые атрибуты и допустимые для запроса значения определены в дефиниции класса SOP для модели релевантной информации о пациенте.

Q.2.1.1.3.2 Структура идентификатора ответа

Ответ C-FIND не должен содержать атрибуты, которые отсутствовали в запросе или не указаны в этом разделе.

Идентификатор в ответе C-FIND должен содержать:

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

  • Content Template Sequence (0040,A504), который должен включать один элемент последовательности, содержащий атрибуты Template Identifier (0040,DB00) и Mapping Resource (0008,0105), для указания структуры шаблона, использованной в ответе C-FIND. Значения должны совпадать с указанными в идентификаторе запроса.

  • Условно — атрибут Specific Character Set (0008,0005). Этот атрибут должен быть включён, если в любых атрибутах идентификатора ответа могут использоваться расширенные или заменяющие наборы символов. В противном случае он не должен включаться. SCP C-FIND не обязан возвращать ответы в наборе символов Specific Character Set, запрошенном SCU, если этот набор символов не поддерживается SCP. SCP может возвращать ответы с другим набором символов Specific Character Set.

Q.2.1.1.3.3 Шаблоны релевантной информации о пациенте

Шаблоны, используемые в запросе релевантной информации о пациенте, определены в PS3.16.

Шаблон, указанный в идентификаторе запроса, не должен использовать отношения по ссылке (by-reference).

Q.2.1.1.4 Статус

Table Q.2-1 определяет значения кодов статуса, которые могут быть возвращены в ответе C-FIND. Общие значения кодов статуса и поля, связанные со значениями кодов статуса, определены для услуги DIMSE C-FIND в PS3.7.

Таблица Q.2-1. Значения статуса ответа C-FIND

Статус службы

Дополнительное значение

Коды статуса

Связанные поля

Отказ

Отказано: нехватка ресурсов

A700

(0000,0902)

Ошибка: набор данных не соответствует классу SOP

A900

(0000,0901)

(0000,0902)

Отказано: невозможно обработать

C000

(0000,0901)

(0000,0902)

Отказано: найдено более одного совпадения

C100

(0000,0901)

(0000,0902)

Отказано: невозможно поддержать запрошенный шаблон

C200

(0000,0901)

(0000,0902)

Отмена

Сопоставление прервано из-за запроса отмены

FE00

Нет

Успех

Успех. Сопоставление завершено — окончательный идентификатор не предоставляется.

0000

Нет

В ожидании

Предоставляется текущее совпадение.

FF00

Идентификатор


Примечание

Коды статуса возвращаются в сообщениях ответа DIMSE (см. PS3.7). Значения кодов, указанные в столбце «Коды статуса», возвращаются в элементе команды Status (0000,0900).

Q.3 Согласование ассоциации

Установление ассоциации является первой фазой любого экземпляра связи между равноправными AE DICOM. Для согласования поддерживаемого класса SOP должна использоваться процедура согласования ассоциации, указанная в PS3.7.

Расширенное согласование класса SOP не определено для этого класса услуг.

Q.4 Услуга DIMSE-C C-FIND

Услуга DIMSE-C C-FIND — это операция, посредством которой запрашивается и предоставляется релевантная информация о пациенте.

Q.4.1 Соглашения

Ключевые атрибуты в идентификаторе запроса служат двум целям. Они могут использоваться как ключевые атрибуты сопоставления (Matching Key Attributes) и ключевые атрибуты возврата (Return Key Attributes). Ключевые атрибуты сопоставления могут использоваться для сопоставления (критерии, используемые в запросе C-FIND для определения того, соответствует ли сущность запросу). Ключевые атрибуты возврата могут использоваться для указания желаемых возвращаемых атрибутов (какие элементы, помимо ключевых атрибутов сопоставления, должны быть возвращены в ответе C-FIND).

Ключевые атрибуты сопоставления могут иметь тип «обязательный» (R) или «необязательный» (O). Ключевые атрибуты возврата могут иметь тип 1, 1C, 2, 2C, 3, как определено в PS3.5.

Q.4.2 Определение услуги

Два равноправных AE DICOM реализуют этот класс услуг запроса релевантной информации о пациенте, при этом одно выступает в роли SCU, а другое — в роли SCP. Класс SOP реализуется с использованием услуги DIMSE-C C-FIND, как определено в PS3.7.

В этом классе услуг используется только базовое поведение DIMSE-C C-FIND.

Услуга C-FIND передаёт следующую семантику:

  • SCU запрашивает у SCP выполнить сопоставление по ключам сопоставления и вернуть значения для ключей возврата, указанных в идентификаторе запроса, относительно релевантной информации о пациенте, которой располагает SCP.

    Примечание

    В этом приложении термин «идентификатор» относится к параметру услуги Identifier услуги C-FIND, как определено в PS3.7.

  • SCP генерирует ответ C-FIND не более чем для одного совпадения с идентификатором, содержащим значения всех ключевых атрибутов сопоставления и всех известных запрошенных ключевых атрибутов возврата. Ответ содержит один экземпляр релевантной информации о пациенте в форме, соответствующей запрошенному шаблону. Этот ответ должен содержать статус «В ожидании» (Pending).

  • Когда процесс сопоставления завершён, с нулём или одним совпадением, отправляется ответ C-FIND со статусом «Успех» и без идентификатора.

  • Ответ «Отказ» на запрос C-FIND указывает на то, что SCP не может обработать запрос. Это должно использоваться для указания на то, что запрошенный шаблон не поддерживается SCP, или что SCP обнаружил более одного совпадения.

  • SCU может отменить услугу C-FIND, выдав запрос C-CANCEL-FIND в любой момент во время обработки услуги C-FIND. SCP прервёт всё сопоставление и вернёт статус «Отмена».

    Примечание

    SCU должен быть готов к получению ответов C-FIND, отправляемых SCP, до тех пор, пока SCP окончательно не обработает запрос C-CANCEL-FIND.

Q.4.3 Классы SOP модели релевантной информации о пациенте

Q.4.3.1 Модель релевантной информации о пациенте

Для того чтобы выступать в качестве поставщика класса услуг (SCP) одного или нескольких классов SOP модели релевантной информации о пациенте, прикладной объект (Application Entity, AE) DICOM располагает релевантной информацией о пациентах. Эта информация организована в модель релевантной информации о пациенте.

Классы SOP состоят как из информационной модели, так и из группы услуг DIMSE-C.

Q.4.3.1.1 Модель E/R

Модель E/R состоит из пациента (Patient) и структурированной информации (Structured Information) без отношения к другим информационным сущностям в информационной модели DICOM.

Relevant Patient Information E/R Model

Рисунок Q.4-1. Модель E/R релевантной информации о пациенте


IE Patient включает атрибуты модулей Patient Identification и Patient Demographics.

IE Structured Information включает атрибуты, не связанные по своей природе с сущностью реального мира, а интерпретируемые через их кодированное содержимое. Сюда входят атрибуты модуля Structured Document Content Module, содержимое которого в случае услуги запроса релевантной информации о пациенте ограничено указанными шаблонами для передачи информации, связанной с пациентом. Также в IE Structured Information включены атрибуты модулей SOP Common и Common Instance Reference, поддерживающие интерпретацию кодированных данных или доступ к информационным объектам, на которые есть ссылка, идентифицированным в кодированных данных.

Q.4.3.1.2 Атрибуты релевантной информации о пациенте

Table Q.4-1 определяет атрибуты модели релевантной информации о пациенте:

Таблица Q.4-1. Атрибуты модели релевантной информации о пациенте

Описание / Модуль

Tag

Тип ключа сопоставления

Тип возвращаемого ключа

Примечание / Тип сопоставления

Patient

Patient's Name

(0010,0010)

-

1

Patient ID

(0010,0020)

R

1

Должен присутствовать в идентификаторе запроса.

Должен извлекаться с использованием сопоставления единичного значения (Single Value Matching).

Примечание

Поскольку ожидается только один ответ, это уникальный ключ.

Issuer of Patient ID

(0010,0021)

R

2

Должен извлекаться с использованием сопоставления единичного значения (Single Value Matching).

В ситуациях, когда существует несколько эмитентов (issuers), этот ключ ограничивает сопоставление Patient ID (0010,0020) доменом, в котором Patient ID (0010,0020) уникален.

Patient's Birth Date

(0010,0030)

-

2

Patient's Sex

(0010,0040)

-

2

All other Attributes of the Patient Identification Module

-

3

All other Attributes of the Patient Demographic Module

-

3

Structured Information (SR Document Content Module)

Observation DateTime

(0040,A032)

-

1

Value Type

(0040,A040)

-

1

См. Раздел Q.4.3.1.2.1.

Concept Name Code Sequence

(0040,A043)

-

1

См. Раздел Q.4.3.1.2.1.

>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support”

Content Sequence

(0040,A730)

-

2

См. Section Q.4.3.1.2.1.

>All Attributes of the Content Sequence

-

-

Элементы содержимого, предоставленные SCP. Требования к типам атрибутов элементов содержимого должны соответствовать определениям в модуле SR Document Content Module.

HL7 Structured Document Reference Sequence

(0040,A390)

-

1C

>Referenced SOP Class UID

(0008,1150)

-

1

>Referenced SOP Instance UID

(0008,1155)

-

1

>HL7 Instance Identifier

(0040,E001)

-

1

>Retrieve URI

(0040,E010)

-

3

Structured Information (Common Instance Reference Module)

Studies Containing Other Referenced Instances Sequence

(0008,1200)

-

1C

Требуется, если Content Sequence (0040,A390) включает элементы содержимого, ссылающиеся на экземпляры SOP, использующие информационную модель Patient/Study/Series/Instance.

>Referenced Series Sequence

(0008,1115)

-

1

>>Series Instance UID

(0020,000E)

-

1

>>Referenced Instance Sequence

(0008,114A)

-

1

>>>Referenced SOP Class UID

(0008,1150)

-

1

>>>Referenced SOP Instance UID

(0008,1155)

-

1


Атрибуты в Table Q.4-2 не являются частью информационной модели; их включение в идентификатор запроса и ответа C-FIND регулируется правилами в разделах Section Q.2.1.1.3.1 и Section Q.2.1.1.3.2 соответственно.

Таблица Q.4-2. Дополнительные атрибуты идентификатора C-FIND

Имя атрибута

Tag

Тип в идентификаторе запроса

Тип в идентификаторе ответа

Примечание

Content Template Sequence

(0040,A504)

1

1

>Mapping Resource

(0008,0105)

1

1

>Template Identifier

(0040,DB00)

1

1

Specific Character Set

(0008,0005)

1C

1C

Требуется, если используются расширенные или заменяющие наборы символов. См. Section Q.2.1.1.3,


Q.4.3.1.2.1 Описания атрибутов релевантной информации о пациенте

Concept Name Code Sequence (0040,A043) в ответе C-FIND должен иметь один элемент последовательности, идентифицирующий концепцию корневого узла возвращаемой структуры. Он должен совпадать с Concept Name первой строки шаблона, указанного в Content Template Sequence (0040,A504) в идентификаторе. Concept Name Code Sequence (0040,A043) всегда должен отправляться с нулевой длиной в идентификаторе запроса.

Value Type (0040,A040) применяется к Concept Name Code Sequence (0040,A043) и должен совпадать с Value Type (0040,A040) первой строки шаблона, указанного в Content Template Sequence (0040,A504) в идентификаторе.

Content Sequence (0040,A730) — это потенциально рекурсивно вложенная последовательность элементов, как описано в PS3.3, модуль SR Document Content Module. Content Sequence всегда должна отправляться с нулевой длиной в идентификаторе запроса. Content Sequence в наборе данных ответа должна содержать элементы содержимого запрошенного шаблона.

Q.4.3.2 Требования соответствия

Реализация может соответствовать классам SOP модели релевантной информации о пациенте в роли SCU и/или SCP.

Заявление о соответствии должно быть оформлено в формате, определённом в PS3.2.

Q.4.3.2.1 Соответствие SCU

Реализация, соответствующая одному или нескольким классам SOP модели релевантной информации о пациенте, должна поддерживать запросы к модели релевантной информации о пациенте, описанной в Section Q.4.3.1, используя базовое поведение SCU C-FIND, описанное в Section Q.4.2.

Реализация, соответствующая одному или нескольким классам SOP модели релевантной информации о пациенте в роли SCU, должна указать в своём заявлении о соответствии, какой класс(-ы) SOP она поддерживает, и какой(-ие) корневой(-ые) шаблон(-ы) она может запрашивать, если это не указано классом SOP. Заявление о соответствии должно также указывать определение любых поддерживаемых расширений шаблона.

Q.4.3.2.2 Соответствие SCP

Реализация, соответствующая одному или нескольким классам SOP модели релевантной информации о пациенте, должна поддерживать запросы к модели релевантной информации о пациенте, описанной в Section Q.4.3.1, используя базовое поведение SCP C-FIND, описанное в Section Q.4.2.

Реализация, соответствующая одному или нескольким классам SOP модели релевантной информации о пациенте в роли SCP, должна указать в своём заявлении о соответствии, какой класс(-ы) SOP она поддерживает, и какой(-ие) корневой(-ые) шаблон(-ы) она будет поддерживать в ответе на запрос, если это не указано классом SOP. Заявление о соответствии должно также указывать определение любых поддерживаемых расширений шаблона.

Реализация, соответствующая одному или нескольким классам SOP модели релевантной информации о пациенте в роли SCP, должна указать в своём заявлении о соответствии, как она использует Specific Character Set (0008,0005) при интерпретации запросов, выполнении сопоставления и кодировании ответов.

Q.4.3.3 Классы SOP

Классы SOP модели релевантной информации о пациенте в классе услуг запроса релевантной информации о пациенте идентифицируют модель релевантной информации о пациенте и поддерживаемую операцию DIMSE-C. В некоторых случаях указан корневой шаблон. Стандартные классы SOP определены в Table Q.4-3:

Таблица Q.4-3. Классы SOP модели релевантной информации о пациенте

SOP Class Name

SOP Class UID

Root Template

General Relevant Patient Information Query

1.2.840.10008.5.1.4.37.1

TID 9007 General Relevant Patient Information, or from the list in PS3.16

Breast Imaging Relevant Patient Information Query

1.2.840.10008.5.1.4.37.2

TID 9000 Relevant Patient Information for Breast Imaging

Cardiac Relevant Patient Information Query

1.2.840.10008.5.1.4.37.3

TID 3802 Cardiovascular Patient History


Примечание

Список корневых шаблонов для General Relevant Patient Information Query является расширяемым.

Q.5 Пример запроса релевантной информации о пациенте (Информативное)

Перемещено в PS3.17.

R Класс услуг уведомления о доступности экземпляра

R.1 Обзор

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

Класс услуг уведомления о доступности экземпляра определяет класс услуг на уровне приложения, который позволяет одному AE DICOM уведомить другой AE DICOM о наличии и доступности экземпляров SOP, которые могут быть извлечены. AE, у которого впоследствии могут быть извлечены такие экземпляры SOP, может как совпадать, так и не совпадать с SCU, выполняющим уведомление.

Примечание

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

Реализация SCU определяет условия, при которых она предоставляет уведомление. Некоторые SCU могут предоставлять уведомление для произвольных наборов экземпляров SOP, в то время как другие SCU могут предоставлять уведомление, когда они определяют, что экземпляры, связанные с шагом процедуры (Procedure Step) или запрошенной процедурой (Requested Procedure), доступны. SCU обязан документировать в своём заявлении о соответствии характер своих решений об уведомлении (например, частоту уведомлений, возможности извлечения и задержку и т. д.).

После того как SCU предоставил уведомление о доступности экземпляров SOP, SCP может использовать эту информацию для направления дальнейшего рабочего процесса, например, для заполнения Input Information Sequence при формировании унифицированного шага процедуры (Unified Procedure Step). Такие виды политик выходят за рамки настоящего Стандарта, однако SCP обязан документировать эти политики в своём заявлении о соответствии.

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

Примечание

  1. Атрибут Performed Workitem Code Sequence (0040,4019) экземпляра шага процедуры, на который есть ссылка, может предоставлять конкретное описание рабочего элемента, вызвавшего уведомление о доступности экземпляра.

  2. Уведомление о доступности экземпляра обычно является услугой SCP хранения составного экземпляра, поскольку это приложение отвечает за обеспечение доступности экземпляров. Уведомление о доступности экземпляра позволяет этому приложению сообщать конкретный Retrieve AE Title, который может отличаться от AE Title услуги хранения и может варьироваться в зависимости от различных классов SOP экземпляров или изменяться со временем.

R.2 Обзор соответствия

Класс услуг уведомления о доступности экземпляра состоит из одного класса SOP: класса SOP уведомления о доступности экземпляра.

Класс SOP определяет атрибуты, операции и поведение, применимые к классу SOP. Требования соответствия должны быть указаны в терминах поставщика класса услуг (SCP) и пользователя класса услуг (SCU).

Класс услуг уведомления о доступности экземпляра использует IOD уведомления о доступности экземпляра, определённый в PS3.3, и услугу DIMSE N-CREATE, указанную в PS3.7.

R.3 Класс SOP уведомления о доступности экземпляра

R.3.1 Группа услуг DIMSE

Услуги DIMSE, показанные в Table R.3.1-1, применимы к IOD уведомления о доступности экземпляра в рамках класса SOP уведомления о доступности экземпляра.

Таблица R.3.1-1. Группа услуг DIMSE, применимая к уведомлению о доступности экземпляра

Элемент службы сообщений DICOM

Использование (SCU/SCP)

N-CREATE

M/M


Услуги и протоколы DIMSE определены в PS3.7.

Примечание

Хотя для этого класса услуг используется термин «уведомление» (notification), уведомление фактически выполняется через операции (Operations), а не через уведомления (Notifications).

R.3.2 Операции

Прикладному объекту (Application Entity), заявляющему о соответствии этому классу SOP в роли SCU, должно быть разрешено инициировать следующие операции, а прикладной объект, заявляющий о соответствии в роли SCP, должен быть способен предоставлять следующие операции.

R.3.2.1 N-CREATE экземпляра SOP уведомления о доступности экземпляра

Эта операция позволяет SCU создать экземпляр класса SOP уведомления о доступности экземпляра и предоставить информацию о доступности экземпляров, находящихся под управлением SCU. Эта операция должна инициироваться через услугу DIMSE N-CREATE.

R.3.2.1.1 Атрибуты

Список атрибутов N-CREATE определён, как показано в Table R.3.2-1.

Таблица R.3.2-1. Атрибуты N-CREATE класса SOP уведомления о доступности экземпляра

Имя атрибута

Tag

Использование N-CREATE (SCU/SCP)

Specific Character Set

(0008,0005)

1C/1C

(Обязательно, если используется расширенный или заменяющий набор символов)

All other Attributes of the SOP Common Module

3/3

Referenced Performed Procedure Step Sequence

(0008,1111)

2/2

>Referenced SOP Class UID

(0008,1150)

1/1

>Referenced SOP Instance UID

(0008,1155)

1/1

>Performed Workitem Code Sequence

(0040,4019)

2/2

>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

Study Instance UID

(0020,000D)

1/1

Referenced Series Sequence

(0008,1115)

1/1

>Series Instance UID

(0020,000E)

1/1

>Referenced SOP Sequence

(0008,1199)

1/1

>>Referenced SOP Class UID

(0008,1150)

1/1

>>Reference SOP Instance UID

(0008,1155)

1/1

>>Instance Availability

(0008,0056)

1/1

>>Retrieve AE Title

(0008,0054)

1/1

>>Retrieve Location UID

(0040,E011)

3/3

>>Retrieve URI

(0040,E010)

3/3

>>Retrieve URL

(0008,1190)

3/3

>>Storage Media File-Set ID

(0088,0130)

3/3

>>Storage Media File-Set UID

(0088,0140)

3/3


R.3.2.1.2 Пользователь класса услуг

SCU должен указывать в примитиве запроса N-CREATE SOP Class UID и SOP Instance UID экземпляра SOP уведомления о доступности экземпляра, который создаётся и для которого должны быть предоставлены значения атрибутов.

SCU должен предоставлять значения атрибутов для атрибутов класса SOP уведомления о доступности экземпляра, как указано в Table R.3.2-1.

Использование дополнительных необязательных атрибутов SCU запрещено.

Примечание

Причина запрета необязательных атрибутов — предотвратить использование стандартных расширенных классов SOP, которые могли бы добавлять контекстную информацию, такую как идентификаторы пациента и процедуры.

Правила кодирования атрибутов уведомления о доступности экземпляра указаны в спецификации примитива запроса N-CREATE в PS3.7.

Не существует требований относительно того, когда должны выполняться запросы N-CREATE.

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

R.3.2.1.3 Поставщик класса услуг

SCP должен возвращать через примитив ответа N-CREATE код статуса ответа N-CREATE, применимый к соответствующему запросу.

R.3.2.1.4 Коды статуса

Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.

R.3.3 UID класса SOP уведомления о доступности экземпляра

Класс SOP уведомления о доступности экземпляра должен однозначно идентифицироваться UID класса SOP уведомления о доступности экземпляра, который должен иметь значение «1.2.840.10008.5.1.4.33».

R.3.4 Требования соответствия

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

Реализация может соответствовать этому классу SOP в роли SCU или SCP. Заявление о соответствии должно быть оформлено в формате, определённом в PS3.2.

R.3.4.1 Соответствие SCU

Реализация, соответствующая этому классу SOP в роли SCU, должна удовлетворять требованиям соответствия для операций, которые она инициирует.

R.3.4.1.1 Операции

Любые атрибуты, для которых значения могут быть предоставлены (с использованием N-CREATE) SCU, должны быть перечислены в заявлении о соответствии SCU. Заявление о соответствии SCU должно быть оформлено в формате, определённом в PS3.2.

Реализация, соответствующая этому классу SOP в роли SCU, должна указывать, при каких условиях в ходе выполнения реальных действий она будет создавать экземпляр класса SOP.

Заявление о соответствии SCU должно указывать, что подразумевается под каждым сообщаемым значением Instance Availability (0008,0056).

Заявление о соответствии SCU должно описывать взаимосвязь между уведомлением о доступности экземпляра и классами SOP выполненного шага процедуры (Performed Procedure Step), если последние поддерживаются.

R.3.4.2 Соответствие SCP

Реализация, соответствующая этому классу SOP в роли SCP, должна удовлетворять требованиям соответствия для операций, которые она выполняет.

R.3.4.2.1 Операции

Заявление о соответствии SCP должно быть оформлено в формате, определённом в PS3.2.

Заявление о соответствии SCP должно предоставлять информацию о поведении SCP (в терминах реальных действий) для каждого сообщаемого значения Instance Availability (0008,0056).

Заявление о соответствии SCP должно описывать поведенческую взаимосвязь между уведомлением о доступности экземпляра и классами SOP выполненного шага процедуры, если последние поддерживаются.

S Класс услуг управления созданием носителя

S.1 Обзор

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

Класс услуг управления созданием носителя определяет механизм, посредством которого SCU может дать указание устройству создать носитель обмена (Interchange Media), содержащий набор составных экземпляров SOP, которые уже переданы на устройство создания носителя с использованием класса услуг хранения.

Этот класс услуг не рассматривает требования архивного хранения. Он предназначен только для управления устройствами создания носителя. Стандарт не требует, чтобы SCP этого класса услуг брал на себя ответственность за архивирование составных экземпляров, позволяя SCU затем удалить их. Такое поведение полностью выходит за рамки Стандарта. Другими словами, создание носителя не подразумевает подтверждения хранения (Storage Commitment).

Профиль(-и) приложения для набора экземпляров, определяющий(-ие) форму создаваемого носителя (то есть CD, DVD или MOD), может(-гут) быть либо оставлен(ы) на усмотрение SCP, либо явно указан(ы) в запросе на создание носителя. В последнем случае, если устройство не способно создать запрошенные профили, должна быть возвращена ошибка.

Примечание

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

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

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

Примечание

  1. SCP может быть физически не способен наносить этикетку на носитель. Эта возможность выходит за рамки соответствия Стандарту. Невозможность создать этикетку не является ошибкой.

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

Класс услуг обладает ограниченной возможностью возврата информации о статусе. Запрос на создание носителя может изначально либо завершиться неудачей, либо быть принят. Впоследствии SCU может опрашивать SCP о статусе запроса (ожидание, выполняется/создается, успешно или неудачно) в рамках той же или отдельной ассоциации. Асинхронное уведомление отсутствует. Нет зависимости от продолжительности или сохранения ассоциации.

Примечание

Не предъявляется требований по обработке временных сбоев (например, отсутствия чистых носителей, этикеток или чернил). Ставит ли SCP в очередь сохраненные экземпляры и запросы в таких случаях или отклоняет запрос — остается за рамками Стандарта.

S.2 Обзор соответствия

Услуги прикладного уровня, рассматриваемые данным классом услуг, определяются через SOP-класс управления созданием носителя.

SOP-класс управления созданием носителя определяет атрибуты, операции и поведение, применимые к данному SOP-классу. Требования соответствия должны определяться в терминах поставщика класса услуг (SCP) и пользователя класса услуг (SCU).

Класс услуг управления созданием носителя использует IOD управления созданием носителя, определенный в PS3.3, и услуги N-CREATE, N-ACTION и N-GET, определенные в PS3.7.

S.2.1 Согласование ассоциации

Установление ассоциации является первой фазой любого экземпляра взаимодействия между равноправными DICOM AE. Правила согласования ассоциации, определенные в PS3.7, должны использоваться для согласования поддерживаемых SOP-классов.

Поддержка согласования выбора ролей SCP/SCU не применима. Расширенное согласование SOP-класса для данного класса услуг не определено.

S.3 SOP-класс управления созданием носителя

SCU передает SOP-экземпляры на SCP с использованием класса услуг хранения. Запрос на создание носителя передается на SCP и содержит список ссылок на один или несколько SOP-экземпляров. Успех или неудача создания носителя впоследствии указывается SCU путем запроса статуса у SCP в рамках той же или отдельной ассоциации.

S.3.1 Группа услуг DIMSE

Следующие услуги DIMSE-N применимы к SOP-классу управления созданием носителя.

Table S.3.1-1. DIMSE Service Group Applicable to Media Creation Management

Элемент службы сообщений DICOM

Использование (SCU/SCP)

N-CREATE

M/M

N-ACTION

M/M

N-GET

U/M


Услуги DIMSE-N и протокол определены в PS3.7.

S.3.2 Операции

DICOM AE, заявляющие соответствие данному SOP-классу в роли SCU, должны использовать операции N-CREATE и N-ACTION. DICOM AE, заявляющие соответствие данному SOP-классу в роли SCP, должны поддерживать операции N-CREATE, N-ACTION и N-GET.

S.3.2.1 Создание запроса на создание носителя

Операция создания запроса на создание носителя позволяет SCU создать экземпляр SOP-класса управления созданием носителя и инициализировать атрибуты этого SOP-класса. SCP использует эту операцию для создания нового запроса на создание носителя, содержащего набор SOP-экземпляров, которые должны быть включены в носитель обмена (Interchange Media). Эта операция должна вызываться через примитив N-CREATE.

S.3.2.1.1 Атрибуты

DICOM AE, заявляющие соответствие данному SOP-классу в роли SCU, могут по своему усмотрению предоставлять подмножество атрибутов, поддерживаемых SCP. DICOM AE, заявляющие соответствие данному SOP-классу в роли SCP, должны поддерживать подмножество управления созданием носителя, указанное в Table S.3.2.1.1-1.

Table S.3.2.1.1-1. Media Creation Management - N-CREATE Attributes

Имя атрибута

Tag

Использование (SCU/SCP)

Specific Character Set

(0008,0005)

1C/1C (требуется, если используется расширенный или заменяющий набор символов)

Storage Media File-Set ID

(0088,0130)

3/3

См. Section S.3.2.1.1.1.

Storage Media File-Set UID

(0088,0140)

3/3

См. Section S.3.2.1.1.1.

Label Using Information Extracted From Instances

(2200,0001)

3/1C

См. Section S.3.2.1.1.4.

Label Text

(2200,0002)

3/1C

См. Section S.3.2.1.1.4.

Label Style Selection

(2200,0003)

3/1C

См. Section S.3.2.1.1.4.

Barcode Value

(2200,0005)

3/3

См. Section S.3.2.1.1.4

Barcode Symbology

(2200,0006)

3/3

См. Section S.3.2.1.1.4

Media Disposition

(2200,0004)

3/3

См. Section S.3.2.1.1.5.

Allow Media Splitting

(2200,0007)

3/1C

См. Section S.3.2.1.1.6

Allow Lossy Compression

(2200,000F)

3/1C

См. Section S.3.2.1.1.9

Include Non-DICOM Objects

(2200,0008)

3/1C

См. Section S.3.2.1.1.7

Include Display Application

(2200,0009)

3/1C

См. Section S.3.2.1.1.8

Preserve Composite Instances After Media Creation

(2200,000A)

3/3

Referenced SOP Sequence

(0008,1199)

1/1

>Referenced SOP Class UID

(0008,1150)

1/1

>Referenced SOP Instance UID

(0008,1155)

1/1

>Requested Media Application Profile

(2200,000C)

3/1

См. Section S.3.2.1.1.2.

>Icon Image Sequence

(0088,0200)

3/1C

См. Section S.3.2.1.1.3.


S.3.2.1.1.1 Атрибуты набора файлов носителя хранения

Если присутствуют, Storage Media File-Set ID (0088,0130) и Storage Media File-Set UID (0088,0140) должны использоваться на создаваемом носителе. Если отсутствуют, носитель должен содержать значения, сгенерированные SCP.

Если запрос на носитель не помещается на одном томе (одном экземпляре или стороне носителя), то игнорирует ли SCP Storage Media File-Set ID (0088,0130) или использует его как префикс, добавляя информацию для различения томов, зависит от реализации. Для разных томов должны использоваться разные значения Storage Media File-Set UID (0088,0140).

Если запрошено несколько копий, на всех копиях должны использоваться одни и те же Storage Media File-Set ID (0088,0130) и Storage Media File-Set UID (0088,0140).

Примечание

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

S.3.2.1.1.2 Запрошенный профиль приложения носителя

Requested Media Application Profile (2200,000C), если присутствует, должен использоваться SCP для указанного SOP-экземпляра. Если отсутствует для конкретного экземпляра, выбор профиля хранения на носителе (Media Storage Application Profile) для этого экземпляра остается на усмотрение SCP.

Примечание

  1. Для разных экземпляров на одном и том же носителе могут использоваться разные профили хранения на носителе (Media Storage Application Profile).

  2. Форма записей каталога DICOMDIR, которые должен создать SCP, может существенно зависеть от используемых профилей хранения на носителе.

S.3.2.1.1.3 Последовательность значков (Icon Image Sequence)

Icon Image Sequence (0088,0200), если присутствует:

  • должен использоваться SCP для включения в запись каталога DICOM уровня экземпляра для указанного SOP-экземпляра, если профиль хранения на носителе требует его включения и значок, предоставленный SCU, соответствует требованиям профиля

  • может использоваться SCP для включения в запись каталога DICOM уровня экземпляра для указанного SOP-экземпляра, если профиль хранения на носителе не требует его включения

Если отсутствует для конкретного экземпляра, выбор профиля хранения на носителе для этого экземпляра определяет, обязан ли SCP создавать собственную последовательность значков Icon Image Sequence (0088,0200) из содержимого SOP-экземпляра.

Примечание

  1. Некоторые профили хранения на носителе требуют включения Icon Image Sequence (0088,0200) в записи каталога.

  2. Некоторые профили хранения на носителе задают ограничения на форму Icon Image Sequence (0088,0200).

  3. SCP может по своему усмотрению расширить профиль хранения на носителе, генерируя и включая значки в любом случае.

S.3.2.1.1.4 Нанесение этикетки

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

Атрибут Label Using Information Extracted From Instances (2200,0001) является флагом, указывающим SCP, следует ли создавать этикетку с использованием информации о пациенте и исследовании, содержащейся в самих экземплярах.

Примечание

SCP может реализовать любое подмножество атрибутов любых модулей сущностей Patient, Specimen и Study информационной модели DICOM, определенной в PS3.3, которое считает подходящим. Обычно включаются такие атрибуты, как Patient Name (0010,0010), Patient ID (0010,0020), Study ID (0020,0010) и Study Date (0008,0020).

Атрибут Label Text (2200,0002) представляет собой дополнительный текст, который SCP должен включить в любую этикетку, либо в дополнение, либо вместо извлеченных демографических данных, в зависимости от значения Label Using Information Extracted From Instances (2200,0001).

Атрибут Label Style Selection (2200,0003) представляет собой строку кода, которая, если присутствует, может использоваться SCP для выбора одного или нескольких зависящих от реализации стилей этикетирования.

Barcode Value (2200,0005) и Barcode Symbology (2200,0006), если присутствуют, могут использоваться SCP для печати штрих-кода на этикетке.

Примечание. SCU несет ответственность за передачу значения атрибута Barcode Value (2200,0005), согласованного по длине и содержанию с запрошенной Barcode Symbology (2200,0006).

S.3.2.1.1.5 Media Disposition (назначение носителя)

Media Disposition (2200,0004), если присутствует, может использоваться SCP для определения того, куда и кому отправить носитель после завершения.

Примечание

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

S.3.2.1.1.6 Разрешение разделения носителя

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

Атрибут Allow Media Splitting (2200,0007) должен использоваться SCP для определения того, разрешено ли разделять этот запрос на несколько частей носителя.

Примечание

  1. Если размер набора файлов превышает емкость носителя, а этот флаг установлен в NO, SCP должен отказать в обработке запроса.

  2. Если запрошенный профиль хранения на носителе допускает сжатие без потерь, а изображения еще не сжаты, такое сжатие может быть применено SCP, чтобы уместить все экземпляры на одной части носителя. Это также применимо к сжатию с потерями, если оно разрешено значением Allow Lossy Compression (2200,000F).

S.3.2.1.1.7 Включение не-DICOM объектов

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

Include Non-DICOM Objects (2200,0008) должен использоваться для запроса SCP на добавление дополнительных не-DICOM объектов на создаваемый носитель.

От SCP не требуется способность добавлять такие файлы. Невозможность добавить не-DICOM объекты не является ошибкой.

Если Include Non-DICOM Objects (2200,0008) установлен в NO, SCP не должен включать дополнительные не-DICOM объекты на носитель.

S.3.2.1.1.8 Включение приложения просмотра

SCP может обладать или не обладать возможностью включения в создаваемый носитель приложения для просмотра DICOM-экземпляров. Если обладает, применяется следующее поведение SCP, и указанные атрибуты должны поддерживаться SCP.

Include Display Application (2200,0009) должен использоваться для запроса SCP на добавление приложения для просмотра DICOM-экземпляров на создаваемый носитель.

От SCP не требуется способность добавлять такое приложение. Невозможность добавить приложение просмотра не является ошибкой.

Способность приложения просмотра отображать все сохраненные экземпляры выходит за рамки Стандарта.

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

Какие платформы поддерживаются приложением(-ями) просмотра, выходит за рамки Стандарта.

Примечание

Для поддержки приложения просмотра на носитель может потребоваться включить несколько файлов, а не единственный исполняемый файл, и они могут присутствовать, даже если атрибут Include Non-DICOM Objects (2200,0008) имеет значение NO.

Если Include Display Application (2200,0009) установлен в NO, SCP не должен включать приложение просмотра на носитель.

S.3.2.1.1.9 Разрешение сжатия с потерями

Если Allow Lossy Compression (2200,000F) имеет значение YES, SCP разрешается выполнять сжатие с потерями при следующих обстоятельствах:

  • если он получает несжатые или сжатые без потерь изображения, но запрошено использование профиля, требующего сжатия с потерями, либо

  • если Allow Media Splitting (2200,0007) имеет значение NO, а запрос иначе потребовалось бы разделить на несколько носителей.

Если Allow Lossy Compression (2200,000F) имеет значение YES, но запрошенный профиль не допускает сжатие с потерями, сжатие с потерями выполняться не должно.

Уровень сжатия остается на усмотрение SCP.

SCP не должен распаковывать и повторно сжимать уже сжатые с потерями изображения, но может использовать изображения, уже сжатые с потерями.

От SCP никогда не требуется выполнять сжатие с потерями.

Если Allow Lossy Compression (2200,000F) имеет значение NO, SCP не разрешается выполнять сжатие с потерями. Если Allow Lossy Compression (2200,000F) имеет значение NO, а запрошенный профиль требует сжатия с потерями, должна быть возвращена ошибка.

S.3.2.1.2 Поведение пользователя класса услуг

SCU должен использовать примитив N-CREATE, чтобы уведомить SCP о размещении нового запроса на создание носителя и передать свойства этого запроса. Свойства запроса (например, набор SOP-экземпляров, которые должен содержать создаваемый носитель обмена) указываются в атрибутах IOD, как определено в Table S.3.2.1.1-1.

После получения от SCP успешного кода состояния ответа N-CREATE SCU узнает, что SCP получил запрос N-CREATE и новый запрос на создание носителя создан.

После получения от SCP кода состояния ответа N-CREATE о неудаче SCU узнает, что SCP не будет обрабатывать запрос. Действия, предпринимаемые SCU при получении такого статуса, выходят за рамки настоящего Стандарта.

В любой момент после получения ответа N-CREATE SCU может освободить ассоциацию, по которой был отправлен запрос N-CREATE.

Примечание

N-GET соответствующего экземпляра SOP-класса управления созданием носителя может быть выполнен в рамках той же или последующей ассоциации.

S.3.2.1.3 Поведение поставщика класса услуг

После получения запроса N-CREATE SCP должен вернуть через примитив ответа N-CREATE код состояния ответа N-CREATE, применимый к соответствующему запросу. Статус успеха означает, что SCP успешно получил запрос N-CREATE.

Статусы предупреждения (Warning) не должны возвращаться.

Любой другой статус (то есть статус неудачи) означает, что SCP не обрабатывает запрос на создание носителя.

Примечание

  1. Стандарт не определяет, какие проверки SCP должен выполнить после приема примитива запроса N-CREATE и перед возвратом ответа N-CREATE. Реализациям не рекомендуется выполнять расширенную проверку содержимого запроса N-CREATE, такую как доступность ссылочных составных SOP-экземпляров, поддержка запрошенных профилей и т. д. В случае неудачи N-CREATE SCU не сможет выполнить N-GET для определения подробных причин неудачи и позволить операторам применить подходящие корректирующие действия, чтобы сделать запрос обрабатываемым (например, повторно отправить недостающие составные SOP-экземпляры). Такие проверки лучше отложить до получения запроса N-ACTION, после чего может быть выполнен N-GET.

  2. Стандарт не требует от SCP постановки нескольких запросов в очередь, хотя реализациям рекомендуется это делать. Как следствие, новый запрос, поданный до завершения предыдущего, может немедленно завершиться неудачей либо вернуть успешный ответ и быть поставлен в очередь. Размер такой очереди выходит за рамки Стандарта.

  3. Как долго экземпляр SOP-класса управления созданием носителя сохраняется после установки Execution Status (2100,0020) в значение IDLE, выходит за рамки Стандарта.

N-CREATE неявно создает атрибуты Execution Status (2100,0020) и Execution Status Info (2100,0030), которые впоследствии могут быть получены через N-GET.

S.3.2.1.4 Коды состояния

Table S.3.2.2.4-1 определяет конкретные значения кодов состояния, которые могут быть возвращены в ответе N-CREATE. Общие коды состояния ответа см. в PS3.7.

Table S.3.2.2.4-1. SOP Class Status Values

Статус службы

Дополнительное значение

Status Code

Failure

Неудача: для этого SOP-экземпляра уже получено действие Initiate Media Creation.

A510


S.3.2.2 Инициирование создания носителя

Операция инициирования создания носителя позволяет SCU запросить у SCP создание носителя обмена в соответствии с уже созданным экземпляром SOP-класса управления созданием носителя. SCP должен использовать эту операцию для планирования создания носителя обмена. Эта операция должна вызываться через примитив N-ACTION.

S.3.2.2.1 Информация о действии

DICOM AE, заявляющие соответствие данному SOP-классу в роли SCU и/или SCP, должны поддерживать типы действий и информацию о действии, указанные в Table S.3.2.2.1-1.

Table S.3.2.2.1-1. Media Creation Request - Action Information

Имя типа действия

Идентификатор типа действия

Имя атрибута

Tag

Использование (SCU/SCP)

Initiate Media Creation

1

Number of Copies

(2000,0010)

3/1

Request Priority

(2200,0020)

3/3

См. Section S.3.2.2.1.1


S.3.2.2.1.1 Приоритет

Request Priority (2200,0020), если присутствует, может использоваться SCP для приоритизации запроса с более высоким приоритетом над другими ожидающими запросами с более низким приоритетом.

S.3.2.2.2 Поведение пользователя класса услуг

SCU должен использовать примитив N-ACTION для запроса SCP на создание носителя обмена в соответствии с уже созданным экземпляром SOP-класса управления созданием носителя. Информация о действии указана в Table S. 3.2.2.1-1.

После получения от SCP успешного кода состояния ответа N-ACTION SCU узнает, что SCP получил запрос N-ACTION Initiate Media Creation и будет обрабатывать запрос.

После получения от SCP кода состояния ответа N-ACTION о неудаче SCU узнает, что SCP не будет обрабатывать запрос Initiate Media Creation. Действия, предпринимаемые SCU при получении такого статуса, выходят за рамки настоящего Стандарта.

В любой момент после получения ответа N-ACTION SCU может освободить ассоциацию, по которой был отправлен запрос N-ACTION.

Примечание

  1. N-GET соответствующего экземпляра SOP-класса управления созданием носителя может быть выполнен в рамках той же или последующей ассоциации.

  2. Длительность, в течение которой SOP Instance UID экземпляра SOP-класса управления созданием носителя остается активным после завершения или неудачи запроса, зависит от реализации, но должна быть достаточно большой, чтобы позволить SCU определить окончательный результат запроса.

S.3.2.2.3 Поведение поставщика класса услуг

После получения запроса N-ACTION Initiate Media Creation SCP должен вернуть через примитив ответа N-ACTION код состояния ответа N-ACTION, применимый к соответствующему запросу. Статус успеха означает, что SCP успешно запланировал запрос.

Примечание

  1. Степень проверки содержимого запроса, доступность ссылочных составных SOP-экземпляров, поддержка запрошенных профилей и другие проверки, которые могут определить итоговый успех или неудачу запроса, Стандартом не определяются. В частности, запрос может быть немедленно успешно принят, но впоследствии завершиться неудачей по какой-либо причине, либо примитив ответа N-ACTION может содержать статус, отражающий более тщательную (и продолжительную) проверку.

  2. Как долго сохраняются составные экземпляры, переданные SCP через класс услуг хранения для целей запроса на создание носителя, выходит за рамки Стандарта. Флаг Preserve Composite Instances After Media Creation (2200,000A) предоставляется только как подсказка. Даже если этот флаг установлен, последующий запрос, ссылающийся на некоторые или все те же экземпляры, может завершиться неудачей, если у SCP была причина очистить кэш экземпляров в промежутке, и SCU может потребоваться быть готовым повторно отправить их.

  3. Как долго экземпляр SOP-класса управления созданием носителя сохраняется после установки Execution Status (2100,0020) в значение DONE или FAILED, выходит за рамки Стандарта.

N-ACTION неявно создает или обновляет атрибуты Execution Status (2100,0020), Execution Status Info (2100,0030), Total Number of Pieces of Media Created (2200,000B), Failed SOP Sequence (0008,1198) и Referenced Storage Media Sequence (2200,000D), которые впоследствии могут быть получены через N-GET.

S.3.2.2.4 Коды состояния

Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.

S.3.2.3 Отмена создания носителя

Операция отмены создания носителя позволяет SCU запросить у SCP отмену запроса на создание носителя независимо от того, начал ли он обрабатываться. Эта операция должна вызываться через примитив N-ACTION.

S.3.2.3.1 Информация о действии

DICOM AE, заявляющие соответствие данному SOP-классу в роли SCU и/или SCP, должны поддерживать типы действий и информацию о действии, указанные в Table S.3.2.3.1-1.

Table S.3.2.3.1-1. Media Creation Request - Action Information

Имя типа действия

Идентификатор типа действия

Имя атрибута

Tag

Использование (SCU/SCP)

Cancel Media Creation

2


S.3.2.3.2 Поведение пользователя класса услуг

SCU должен использовать примитив N-ACTION для запроса у SCP отмены запроса на создание носителя, соответствующего Affected SOP Instance UID в примитиве запроса N-ACTION, независимо от того, был ли он инициирован запросом N-ACTION Initiate Media Creation, и независимо от того, начал ли он обрабатываться (то есть находится в ожидании или в процессе выполнения).

После получения от SCP успешного кода состояния ответа N-ACTION SCU узнает, что SCP получил запрос N-ACTION Cancel Media Creation, отменил любое ожидающее или выполняемое создание носителя и удалил экземпляр SOP-класса управления созданием носителя.

Примечание

Успешная отмена означает, что последующий N-GET соответствующего экземпляра SOP-класса управления созданием носителя завершится неудачей.

После получения от SCP кода состояния ответа N-ACTION о неудаче SCU узнает, что SCP не будет обрабатывать запрос Cancel Media Creation. Действия, предпринимаемые SCU при получении такого статуса, выходят за рамки настоящего Стандарта.

Примечание

Неудача отмены означает, что создание носителя уже завершено (успешно или нет) либо будет продолжено. Статус запроса на создание носителя все еще может быть получен через N-GET, если только причиной неудачи не было отсутствие SOP-экземпляра.

S.3.2.3.3 Поведение поставщика класса услуг

После получения запроса N-ACTION Cancel Media Creation SCP должен вернуть через примитив ответа N-ACTION код состояния ответа N-ACTION, применимый к соответствующему запросу. Статус успеха означает, что SCP успешно отменил запрос.

Статус неудачи означает, что SCP не смог отменить запрос; в этом случае атрибуты Execution Status (2100,0020), Execution Status Info (2100,0030), Total Number of Pieces of Media Created (2200,000B), Failed SOP Sequence (0008,1198) и Referenced Storage Media Sequence (2200,000D) впоследствии могут быть получены через N-GET.

S.3.2.3.4 Коды состояния

Table S.3.2.3.4-1 определяет конкретные значения кодов состояния, которые могут быть возвращены в ответе N-ACTION. Общие коды состояния ответа см. в PS3.7.

Table S.3.2.3.4-1. Response Statuses

Статус службы

Дополнительное значение

Status Codes

Failure

Неудача: запрос на создание носителя уже завершен.

C201

Неудача: запрос на создание носителя уже выполняется и не может быть прерван.

C202

Неудача: в отмене отказано по неуказанной причине.

C203


S.3.2.4 Получение результата создания носителя

Операция получения результата создания носителя позволяет SCU запросить у SCP статус запроса на создание носителя. Эта операция должна вызываться через примитив N-GET, используемый совместно с соответствующим экземпляром SOP-класса управления созданием носителя, соответствующим запросу на создание.

S.3.2.4.1 Атрибуты

Прикладной объект (Application Entity), заявляющий соответствие данному SOP-классу в роли SCU, может по своему усмотрению интерпретировать атрибуты, поддерживаемые SCP, которые SCU получает через операции данного SOP-класса. Прикладной объект, заявляющий соответствие данному SOP-классу в роли SCP, должен поддерживать атрибуты, указанные в Table S.3.2.4.1-1.

Table S.3.2.4.1-1. Media Creation Management SOP Class N-GET Attributes

Имя атрибута

Tag

Использование (SCU/SCP)

Specific Character Set

(0008,0005)

3/1C

(требуется, если используется расширенный или заменяющий набор символов)

Execution Status

(2100,0020)

3/1

Execution Status Info

(2100,0030)

3/1

Total Number of Pieces of Media Created

(2200,000B)

3/1

Failed SOP Sequence

(0008,1198)

3/2

Referenced Storage Media Sequence

(2200,000D)

3/2

All other Attributes of the Media Creation Management Module

3/3


S.3.2.4.2 Пользователь класса услуг

The SCU shall specify in the N-GET request primitive the UID of the Media Creation Management SOP Instance for which Attribute Values are to be returned. The SCU shall be permitted to request that Attribute Values be returned for any Media Creation Management SOP Class Attribute specified in Section S.3.2.1.1. Additionally, values may be requested for optional Media Creation Management Module Attributes.

SCU должен указать список атрибутов SOP-класса управления созданием носителя, для которых должны быть возвращены значения атрибутов. Правила кодирования для этого списка определены в примитиве запроса N-GET, указанном в PS3.7.

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

SCU должен быть способен принимать все запрошенные значения атрибутов, предоставленные SCP в ответ на примитив индикации N-GET. SCU может запрашивать значения атрибутов для необязательных атрибутов, не поддерживаемых SCP. В таком случае SCU должен функционировать правильно независимо от того, вернет ли SCP значения для этих атрибутов или нет. Данная спецификация класса услуг не устанавливает требований к тому, что SCU должен делать в результате получения этой информации.

Примечание

Для точной интерпретации набора символов, используемого в возвращаемых значениях атрибутов, рекомендуется запрашивать значение атрибута Specific Character Set (0008,0005) в примитиве запроса N-GET.

S.3.2.4.3 Поставщик класса услуг

Эта операция позволяет SCU запросить у SCP выбранные значения атрибутов для конкретного экземпляра SOP-класса управления созданием носителя. Эта операция должна вызываться с использованием услуги DIMSE N-GET совместно с соответствующим экземпляром SOP-класса управления созданием носителя.

SCP должен вернуть через примитив ответа N-GET код состояния ответа N-GET, применимый к соответствующему запросу. В зависимости от статуса ответа N-GET SCP должен вернуть через примитив ответа N-GET значения атрибутов для всех запрошенных атрибутов, поддерживаемых SCP (см. Table S.3.2.4.1-1). SCP не должен возвращать элементы данных для необязательных атрибутов, не поддерживаемых SCP.

SCP должен вернуть все содержимое последовательности, если запрошен атрибут последовательности.

S.3.2.4.4 Коды состояния

Table S.3.2.4.4-1 defines the specific Status Code values that might be returned in a N-GET response.

Общие коды состояния ответа см. в PS3.7.

Table S.3.2.4.4-1. Response Statuses

Статус службы

Дополнительное значение

Response Status Codes

Warning

Запрошенные необязательные атрибуты не поддерживаются

0001


S.3.3 UID SOP-класса управления созданием носителя

SOP-класс управления созданием носителя должен однозначно идентифицироваться SOP Class UID управления созданием носителя, который должен иметь значение "1.2.840.10008.5.1.1.33".

S.4 Требования соответствия

Реализации, заявляющие стандартное соответствие SOP-классу управления созданием носителя, должны соответствовать описанию в данном разделе и включать в свое заявление о соответствии (Conformance Statement) информацию, описанную в данном разделе и его подразделах.

Реализация может заявлять соответствие данному SOP-классу в роли SCU, SCP или обеих ролей. Заявление о соответствии должно иметь формат, определенный в PS3.2.

S.4.1 Соответствие SCU

Реализация, соответствующая данному SOP-классу в роли SCU, должна удовлетворять требованиям соответствия для

  • операций и действий, которые она инициирует

Механизмы, используемые SCU для передачи SOP-экземпляров на SCP с использованием класса услуг хранения перед инициированием операции запроса, также должны быть задокументированы, в частности синтаксисы передачи, которые могут быть предложены.

S.4.1.1 Операции

SCU должен задокументировать в заявлении о соответствии действия и поведение, вызывающие генерацию SCU примитива N-CREATE (Create Media Creation Request), примитива N-ACTION (Initiate Media Creation и Cancel Media Creation) или примитива N-GET (Get Media Creation Result).

SCU должен указать SOP Class UID, для которых он может запрашивать создание носителя.

SCU должен указать профиль хранения на носителе, для которого он может запрашивать создание носителя.

SCU должен указать, поддерживает ли он необязательные атрибуты Storage Media File-Set ID и UID в N-CREATE.

SCU должен указать, поддерживает ли он необязательные атрибуты Icon Image Sequence в N-CREATE.

SCU должен описать использование расширенных или заменяющих наборов символов как в N-CREATE, N-GET, так и при использовании класса услуг хранения для составных экземпляров.

SCU должен указать, повторяет ли он неудачные запросы.

Примечание

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

Заявление о соответствии должно быть оформлено в формате, определенном в PS3.2

S.4.2 Соответствие SCP

Реализация, соответствующая данному SOP-классу в роли SCP, должна удовлетворять требованиям соответствия для

  • операций и действий, которые она выполняет

Механизмы класса услуг хранения, принимаемые SCP перед получением операции запроса, также должны быть задокументированы, в частности синтаксисы передачи, которые могут быть приняты.

S.4.2.1 Операции

SCP должен задокументировать в заявлении о соответствии поведение и действия SCP при получении примитива N-CREATE (Create Media Creation Request), примитива N-ACTION (Initiate Media Creation и Cancel Media Creation) или примитива N-GET (Get Media Creation Result).

SCP должен указать SOP Class UID, для которых он будет принимать запросы на создание носителя.

SCP должен указать профиль хранения на носителе, для которого он будет принимать запросы на создание носителя, и какие профили по умолчанию он будет использовать, если они не указаны SCU.

Примечание

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

SCP должен указать, поддерживает ли он создание необязательных атрибутов Icon Image Sequence в DICOMDIR, если они не предоставлены SCU.

SCP должен указать способ использования информации об этикетке, в частности, какие:

  • Атрибуты извлекаются из составных экземпляров при соответствующем указании

  • символогии штрих-кодов (если таковые есть) поддерживаются

SCP должен описать использование расширенных или заменяющих наборов символов как в N-CREATE, N-GET, так и при извлечении информации из составных экземпляров для включения в DICOMDIR и на этикетку носителя. SCP должен описать использование атрибутов как в N-CREATE и N-ACTION, так и в составных экземплярах для создания этикетки носителя.

SCP должен указать, поддерживает ли он и каким образом следующие необязательные атрибуты в N-CREATE и N-ACTION:

  • Storage Media File-Set ID (0088,0130) и Storage Media File-Set UID (0088,0140)

  • Media Disposition (2200,0004)

  • Priority (2000,0020)

  • Preserve Composite Instances After Media Creation (2200,000A)

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

SCP должен указать, как долго он будет сохранять:

  • результат создания носителя после успешного или неуспешного завершения запроса

  • экземпляры управления созданием носителя, статус которых IDLE.

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

Примечание

Например, сколько раз SCP будет повторять попытку записи новой части носителя перед установкой Execution Status (2100,0020) в значение FAILURE, сколько запросов на создание носителя SCP способен поставить в очередь, поведение SCP при заполнении очереди запросов, если таковая имеется.

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

SCP должен указать, способен ли он добавлять на создаваемый носитель не-DICOM объекты (например, HTML-файлы, изображения JPEG), как эти объекты организованы и как он интерпретирует атрибут Include Non-DICOM Objects (2200,0008).

SCP должен указать, способен ли он добавлять на создаваемый носитель DICOM-приложения для просмотра, и как он интерпретирует атрибут Include Display Application (2200,0009).

Заявление о соответствии должно быть оформлено в формате, определенном в PS3.2.

T Класс услуг хранения протокола размещения (Hanging Protocol)

См. Annex GG.

Примечание

Требования данного раздела были объединены с классом услуг хранения объектов, не связанных с пациентом (Non-Patient Object Storage Service Class) (см. Section GG.6.1).

U Класс услуг запроса/получения протокола размещения (Hanging Protocol)

U.1 Обзор

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

Класс услуг запроса/получения протокола размещения определяет класс услуг прикладного уровня, облегчающий доступ к составным объектам протокола размещения. Он предоставляет возможности запроса и получения/передачи, аналогичные классу услуг управления базовым рабочим списком (Basic Worklist Management Service Class) и классу услуг запроса/получения (Query/Retrieve Service Class).

U.1.2 Соглашения

См. класс услуг управления базовым рабочим списком, раздел K.1.2 «Соглашения».

U.1.3 Информационная модель запроса/получения

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

U.1.4 Определение услуги

Два равноправных DICOM AE реализуют SOP-класс класса услуг запроса/получения протокола размещения, при этом один выступает в роли SCU, а другой — в роли SCP. SOP-классы класса услуг запроса/получения протокола размещения реализуются с использованием услуг DIMSE-C C-FIND, C-MOVE и C-GET, определенных в PS3.7.

Семантика услуг C-FIND и C-GET совпадает с определенной в разделе «Определение услуги» класса услуг управления базовым рабочим списком.

Семантика услуги C-MOVE совпадает с определенной в разделе «Определение услуги» класса услуг запроса/получения, за исключением того, что существует только один уровень получения.

U.2 Определение информационной модели протокола размещения

Информационная модель протокола размещения идентифицируется SOP-классом, согласованным во время установления ассоциации. SOP-класс состоит как из информационной модели, так и из группы услуг DIMSE-C.

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

U.3 Информационная модель протокола размещения

Информационная модель протокола размещения основана на одноуровневой сущности:

  • Экземпляр объекта протокола размещения (Hanging Protocol object instance)

Экземпляр объекта протокола размещения содержит атрибуты, связанные с IE объекта Hanging Protocol составных IOD, определенных в PS3.3.

U.4 Группы услуг DIMSE-C

U.4.1 Операция C-FIND

См. определение операции C-FIND для класса услуг управления базовым рабочим списком (K.4.1), заменив «Worklist» на «Hanging Protocol». Должен использоваться метод поиска «Worklist».

SOP Class UID идентифицирует информационную модель протокола размещения, относительно которой выполняется C-FIND. Ключевые атрибуты и допустимые для запроса значения определены в определении SOP-класса для информационной модели протокола размещения.

U.4.2 Операция C-MOVE

См. определение операции C-MOVE для класса услуг запроса/получения (C.4.2). Для класса услуг запроса/получения протокола размещения не определены ни расширенное поведение, ни реляционное получение (Relational-Retrieve).

Query/Retrieve Level (0008,0052) не применим к классу услуг запроса/получения протокола размещения и, следовательно, не должен присутствовать в идентификаторе. Единственным уникальным ключевым атрибутом идентификатора должен быть SOP Instance UID (0008,0018). SCU должен предоставить один UID или список UID.

Примечание

Может быть получена более чем одна сущность с использованием сопоставления по списку UID (List of UID matching).

U.4.3 Операция C-GET

См. определение операции C-GET для класса услуг запроса/получения (C.4.3). Для класса услуг запроса/получения протокола размещения не определены ни расширенное поведение, ни реляционное получение (Relational-Retrieve).

Query/Retrieve Level (0008,0052) не применим к классу услуг запроса/получения протокола размещения и, следовательно, не должен присутствовать в идентификаторе. Единственным уникальным ключевым атрибутом идентификатора должен быть SOP Instance UID (0008,0018). SCU должен предоставить один UID или список UID.

Примечание

Может быть получена более чем одна сущность с использованием сопоставления по списку UID (List of UID matching).

U.5 Согласование ассоциации

См. определение согласования ассоциации для класса услуг управления базовым рабочим списком (K.5).

U.6 Определения SOP-классов

U.6.1 Информационная модель протокола размещения

U.6.1.1 Модель «сущность-связь» (E/R Model)

Информационная модель протокола размещения состоит из единственной сущности. В ответ на данный запрос C-FIND SCP должен отправить один ответ C-FIND на каждый соответствующий экземпляр протокола размещения.

Hanging Protocol Information Model E-R Diagram

Рисунок U.6-1. Диаграмма «сущность-связь» информационной модели протокола размещения


U.6.1.2 Атрибуты протокола размещения

Table U.6-1 определяет атрибуты информационной модели протокола размещения:

Таблица U.6-1. Атрибуты информационной модели протокола размещения

Description / Module

Tag

Тип ключа сопоставления

Тип возвращаемого ключа

Remark / Matching Type

SOP Common

Specific Character Set

(0008,0005)

-

1C

Этот атрибут обязателен, если используются расширенные или замещающие наборы символов. См. Раздел C.2.2.2 и Раздел C.4.1.1.

SOP Class UID

(0008,0016)

R

1

SOP Instance UID

(0008,0018)

U

1

Hanging Protocol Definition

Hanging Protocol Name

(0072,0002)

R

1

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

Hanging Protocol Description

(0072,0004)

-

1

Hanging Protocol Level

(0072,0006)

R

1

Должен извлекаться с использованием сопоставления единичного значения (Single Value Matching) или универсального сопоставления (Universal Matching).

Hanging Protocol Creator

(0072,0008)

-

1

Hanging Protocol Creation DateTime

(0072,000A)

-

1

Hanging Protocol Definition Sequence

(0072,000C)

R

1

Должен извлекаться с использованием сопоставления последовательности (Sequence Matching) или универсального сопоставления (Universal Matching).

>Modality

(0008,0060)

R

2

Должен извлекаться с использованием сопоставления единичного значения (Single Value Matching) или универсального сопоставления (Universal Matching).

>Anatomic Region Sequence

(0008,2218)

R

2

Должен извлекаться с использованием сопоставления последовательности (Sequence Matching) или универсального сопоставления (Universal Matching).

>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

>Laterality

(0020,0060)

R

2

Должен извлекаться с использованием сопоставления единичного значения (Single Value Matching) или универсального сопоставления (Universal Matching).

>Procedure Code Sequence

(0008,1032)

R

2

Должен извлекаться с использованием сопоставления последовательности (Sequence Matching) или универсального сопоставления (Universal Matching).

>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

>Reason for Requested Procedure Code Sequence

(0040,100A)

R

2

Должен извлекаться с использованием сопоставления последовательности (Sequence Matching) или универсального сопоставления (Universal Matching).

>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

Number of Priors Referenced

(0072,0014)

R

1

Должен извлекаться с использованием сопоставления единичного значения (Single Value Matching) или универсального сопоставления (Universal Matching).

Hanging Protocol User Identification Code Sequence

(0072,000E)

R

2

Должен извлекаться с использованием сопоставления последовательности (Sequence Matching) или универсального сопоставления (Universal Matching).

>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

Hanging Protocol User Group Name

(0072,0010)

R

3

Hanging Protocol Environment

Number of Screens

(0072,0100)

R

2

Nominal Screen Definition Sequence

(0072,0102)

-

2

>Number of Vertical Pixels

(0072,0104)

-

1

>Number of Horizontal Pixels

(0072,0106)

-

1

>Display Environment Spatial Position

(0072,0108)

-

1

>Screen Minimum Grayscale Bit Depth

(0072,010A)

-

1C

Требуется, если Screen Minimum Color Bit Depth (0072,010C) отсутствует.

>Screen Minimum Color Bit Depth

(0072,010C)

-

1C

Требуется, если Screen Minimum Grayscale Bit Depth (0072,010A) отсутствует.

>Application Maximum Repaint Time

(0072,010E)

-

3


U.6.1.3 Требования соответствия

Реализация может соответствовать одному из SOP-классов информационной модели протокола размещения в роли SCU, SCP или обоих. Заявление о соответствии должно быть в формате, определенном в PS3.2.

U.6.1.3.1 Соответствие SCU
U.6.1.3.1.1 Соответствие SCU для C-FIND

Реализация, соответствующая одному из SOP-классов информационной модели протокола размещения, должна поддерживать запросы к информационной модели протокола размещения с использованием поведения SCU для C-FIND, описанного для класса услуг управления базовым рабочим списком (см. Section K.4.1.2 and Section U.4.1).

Реализация, соответствующая одному из SOP-классов информационной модели протокола размещения в роли SCU, должна указать в своем заявлении о соответствии, запрашивает ли она возвращаемые ключевые атрибуты типа 3, и должна перечислить эти необязательные возвращаемые ключевые атрибуты.

Реализация, соответствующая одному из SOP-классов информационной модели протокола размещения в роли SCU, должна указать в своем заявлении о соответствии, как она использует Specific Character Set (0008,0005) при кодировании запросов и интерпретации ответов.

U.6.1.3.1.2 Соответствие SCU для C-MOVE

Реализация, соответствующая одному из SOP-классов информационной модели протокола размещения в роли SCU, должна поддерживать передачу для информационной модели протокола размещения с использованием базового поведения SCU для C-MOVE, описанного для класса услуг запроса/получения (см. Section C.4.2.2.1 and Section U.4.2).

U.6.1.3.1.3 Соответствие SCU для C-GET

Реализация, соответствующая SOP-классу Hanging Protocol Information Model - GET в роли SCU, должна поддерживать передачу для информационной модели протокола размещения с использованием базового поведения SCU для C-GET, описанного для класса услуг запроса/получения (см. Section C.4.3.2.1 and Section U.4.3).

U.6.1.3.2 Соответствие SCP
U.6.1.3.2.1 Соответствие SCP для C-FIND

Реализация, соответствующая одному из SOP-классов информационной модели протокола размещения в роли SCP, должна поддерживать запросы к информационной модели протокола размещения с использованием поведения SCP для C-FIND, описанного для класса услуг управления базовым рабочим списком (см. Section K.4.1.3).

Реализация, соответствующая одному из SOP-классов информационной модели протокола размещения в роли SCP, должна указать в своем заявлении о соответствии, поддерживает ли она возвращаемые ключевые атрибуты типа 3, и должна перечислить эти необязательные возвращаемые ключевые атрибуты.

Реализация, соответствующая одному из SOP-классов информационной модели протокола размещения в роли SCP, должна указать в своем заявлении о соответствии, как она использует Specific Character Set (0008,0005) при интерпретации запросов, выполнении сопоставления и кодировании ответов.

U.6.1.3.2.2 Соответствие SCP для C-MOVE

Реализация, соответствующая одному из SOP-классов информационной модели протокола размещения в роли SCP, должна поддерживать передачу для информационной модели протокола размещения с использованием базового поведения SCP для C-MOVE, описанного для класса услуг запроса/получения (см. Section C.4.2.3.1).

Реализация, соответствующая одному из SOP-классов информационной модели протокола размещения в роли SCP, генерирующая передачи с использованием операции C-MOVE, должна указать в своем заявлении о соответствии SOP-класс класса услуг хранения протокола размещения, в рамках которого она будет поддерживать подоперации C-STORE, генерируемые операцией C-MOVE.

U.6.1.3.2.3 Соответствие SCP для C-GET

Реализация, соответствующая SOP-классу Hanging Protocol Information Model - GET в роли SCP, должна поддерживать передачу для информационной модели протокола размещения с использованием базового поведения SCP для C-GET, описанного для класса услуг запроса/получения (см. Section C.4.3.3.1).

Реализация, соответствующая SOP-классу Hanging Protocol Information Model - GET в роли SCP, генерирующая передачи с использованием операции C-GET, должна указать в своем заявлении о соответствии SOP-класс класса услуг хранения протокола размещения, в рамках которого она будет поддерживать подоперации C-STORE, генерируемые операцией C-GET.

U.6.1.4 SOP-классы

SOP-классы информационной модели протокола размещения в классе услуг запроса/получения протокола размещения идентифицируют информационную модель протокола размещения и поддерживаемые операции DIMSE-C. Определены следующие стандартные SOP-классы:

Table U.6.1.4-1. Hanging Protocol SOP Classes

Имя SOP-класса

SOP Class UID

Hanging Protocol Information Model - FIND

1.2.840.10008.5.1.4.38.2

Hanging Protocol Information Model - MOVE

1.2.840.10008.5.1.4.38.3

Hanging Protocol Information Model - GET

1.2.840.10008.5.1.4.38.4


V Класс услуг запроса на введение веществ (Substance Administration Query)

V.1 Обзор

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

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

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

Примечание

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

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

V.1.2 Соглашения

Ключевые атрибуты служат двум целям: они могут использоваться как ключевые атрибуты сопоставления и как возвращаемые ключевые атрибуты. Ключевые атрибуты сопоставления могут использоваться для сопоставления (критерии, используемые в запросе C-FIND для определения соответствия сущности запросу). Возвращаемые ключевые атрибуты могут использоваться для указания желаемых возвращаемых атрибутов (какие элементы, помимо ключевых атрибутов сопоставления, должны быть возвращены в ответе C-FIND).

Ключевые атрибуты сопоставления могут иметь тип «обязательный» (required, R) или «необязательный» (optional, O). Возвращаемые ключевые атрибуты могут иметь тип 1, 1C, 2, 2C, 3, как определено в PS3.5.

V.1.3 Информационная модель запроса на введение веществ

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

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

V.1.4 Определение услуги

Два равноправных DICOM AE реализуют SOP-класс класса услуг запроса на введение веществ, при этом один выступает в роли SCU, а другой — в роли SCP. SOP-классы класса услуг запроса на введение веществ реализуются с использованием услуги DIMSE-C C-FIND, определенной в PS3.7.

В данном классе услуг используется только базовое поведение DIMSE-C C-FIND. Расширенное согласование не используется.

Приведенное ниже описание услуги DIMSE-C C-FIND дает краткий обзор семантики SCU/SCP.

Услуга C-FIND несет следующую семантику:

  • SCU запрашивает у SCP выполнение сопоставления по ключам сопоставления и возврат значений возвращаемых ключей, указанных в идентификаторе запроса, относительно информации, которой обладает SCP применительно к информационной модели, указанной в SOP-классе.

Примечание

В данном приложении термин «идентификатор» относится к параметру услуги Identifier услуги C-FIND, как определено в PS3.7.

  • SCP генерирует не более одного ответа C-FIND на совпадение с идентификатором, содержащим значения всех ключевых атрибутов сопоставления и всех известных запрошенных возвращаемых ключевых атрибутов. Этот ответ должен содержать статус Pending.

  • По завершении процесса сопоставления, с нулевым или одним совпадением, отправляется ответ C-FIND со статусом Success и без идентификатора.

  • Ответ Failure на запрос C-FIND означает, что SCP не может обработать запрос.

  • SCU может отменить услугу C-FIND, выдав запрос C-CANCEL-FIND в любой момент во время обработки услуги C-FIND. SCP прервет всё сопоставление и вернет статус Cancel.

    Примечание

    SCU должен быть готов получать ответы C-FIND, отправляемые SCP, до тех пор, пока SCP окончательно не обработает запрос C-CANCEL-FIND.

Примечание

SCU должен быть готов получать ответы C-FIND, отправляемые SCP, до тех пор, пока SCP окончательно не обработает запрос C-CANCEL-FIND.

V.2 Определение информационной модели запроса на введение веществ

Информационная модель запроса на введение веществ идентифицируется SOP-классом, согласованным во время установления ассоциации. SOP-класс состоит как из информационной модели, так и из группы услуг DIMSE-C.

Определения информационных моделей для стандартных SOP-классов класса услуг запроса на введение веществ определены в данном приложении. Определение информационной модели запроса на введение веществ содержит:

  • определение модели «сущность-связь»

  • определение ключевых атрибутов.

V.2.1 Определение модели «сущность-связь»

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

V.2.2 Определение атрибутов

Атрибуты определены для каждой сущности во внутренней модели «сущность-связь». Идентификатор в запросе C-FIND должен содержать значения для сопоставления с атрибутами сущностей в информационной модели запроса на введение веществ. Для любого запроса набор сущностей, для которых возвращаются атрибуты, определяется набором ключевых атрибутов сопоставления и возвращаемых ключевых атрибутов, указанных в идентификаторе.

V.2.2.1 Типы атрибутов

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

V.2.2.1.1 Ключевые атрибуты сопоставления

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

V.2.2.1.1.1 Обязательные ключевые атрибуты сопоставления

SCP услуги запроса на введение веществ должен поддерживать сопоставление на основе значений всех обязательных ключевых атрибутов сопоставления запроса C-FIND.

V.2.2.1.1.2 Необязательные ключевые атрибуты сопоставления

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

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

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

Примечание

  1. Заявление о соответствии SCP перечисляет необязательные ключевые атрибуты сопоставления, поддерживаемые для сопоставления.

  2. SCU не может рассчитывать на то, что SCP поддерживает сопоставление по необязательному ключу сопоставления.

V.2.2.1.2 Возвращаемые ключевые атрибуты

Значения возвращаемых ключевых атрибутов, которые должны быть получены с запросом, указываются в запросе C-FIND с нулевой длиной (универсальное сопоставление). SCP должны поддерживать возвращаемые ключевые атрибуты, определенные информационной моделью запроса на введение веществ, в соответствии с типом элемента данных (1, 1C, 2, 2C, 3), как определено в PS3.5.

Каждый ключевой атрибут сопоставления также должен рассматриваться как возвращаемый ключевой атрибут. Поэтому ответ C-FIND должен содержать, помимо значений запрошенных возвращаемых ключевых атрибутов, значения запрошенных ключевых атрибутов сопоставления.

Примечание

  1. Заявление о соответствии SCP перечисляет поддерживаемые возвращаемые ключевые атрибуты типа 3.

  2. SCU может по своему усмотрению предоставить любое подмножество возвращаемых ключевых атрибутов.

  3. SCU не может рассчитывать на получение каких-либо возвращаемых ключевых атрибутов типа 3.

  4. Возвращаемые ключевые атрибуты с VR типа SQ могут быть указаны либо с нулевой длиной, либо с элементом нулевой длины в последовательности.

V.2.2.2 Сопоставление атрибутов

Следующие типы сопоставления, определенные классом услуг запроса/получения в Annex C, могут выполняться для ключевых атрибутов сопоставления в классе услуг запроса на введение веществ. Различные ключевые атрибуты сопоставления могут подлежать разным типам сопоставления. Информационная модель запроса на введение веществ определяет тип сопоставления для каждого обязательного ключевого атрибута сопоставления. Заявление о соответствии SCP должно определять тип сопоставления для каждого необязательного ключевого атрибута сопоставления. Типы сопоставления:

  • Сопоставление единичного значения (Single Value Matching)

  • Сопоставление последовательности (Sequence Matching)

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

  • Универсальное сопоставление (Universal Matching)

См. Section C.2.2.2 и последующие разделы для получения конкретных правил, регулирующих кодирование ключевых атрибутов сопоставления и выполнение различных типов сопоставления.

Атрибут Specific Character Set (0008,0005) может присутствовать в идентификаторе, но никогда не участвует в сопоставлении, т.е. не считается ключевым атрибутом сопоставления. См. Section C.2.2.2 для получения подробностей.

V.3 Информационные модели запроса

Каждая информационная модель запроса на введение веществ связана с одним SOP-классом. Определены следующие информационные модели запроса на введение веществ:

  • Информационная модель запроса характеристик продукта (Product Characteristics Query)

  • Информационная модель запроса разрешения на вещество (Substance Approval Query)

V.4 Группа услуг DIMSE-C

Одна услуга DIMSE-C используется при построении SOP-классов класса услуг запроса на введение веществ. Используется следующая операция DIMSE-C.

  • C-FIND

V.4.1 Операция C-FIND

SCP SOP-классов класса услуг запроса на введение веществ способны обрабатывать запросы с использованием операции C-FIND, как описано в PS3.7. Операция C-FIND является механизмом, посредством которого выполняются запросы. Совпадения по ключам, присутствующим в идентификаторе, возвращаются в ответах C-FIND.

V.4.1.1 Параметры услуги C-FIND

V.4.1.1.1 SOP Class UID

SOP Class UID идентифицирует информационную модель запроса на введение веществ, относительно которой выполняется C-FIND. Поддержка SOP Class UID подразумевается Abstract Syntax UID контекста представления, используемого данной операцией C-FIND.

V.4.1.1.2 Приоритет

Атрибут Priority определяет запрошенный приоритет операции C-FIND по отношению к другим операциям DIMSE, выполняемым тем же SCP.

Обработка запросов приоритета не является обязательной для SCP. Поддерживает ли SCP обработку приоритета и значение различных уровней приоритета должно быть указано в заявлении о соответствии SCP.

V.4.1.1.3 Идентификатор

И запрос, и ответ C-FIND содержат идентификатор, закодированный как набор данных (см. PS3.5).

V.4.1.1.3.1 Структура идентификатора запроса

Идентификатор в запросе C-FIND должен содержать

  • Значения ключевых атрибутов для сопоставления со значениями атрибутов, указанных в данном SOP-классе.

  • Условно — атрибут Specific Character Set (0008,0005). Этот атрибут должен быть включен, если расширенные или заменяющие наборы символов могут использоваться в любом из атрибутов идентификатора запроса. В противном случае он не должен включаться.

Примечание

Это означает, что Specific Character Set (0008,0005) включается, если SCU поддерживает расширенные или заменяющие наборы символов в контексте данной услуги. Он не будет включен, если SCU не поддерживает расширенные или заменяющие наборы символов.

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

V.4.1.1.3.2 Структура идентификатора ответа

Ответ C-FIND не должен содержать атрибуты, которых не было в запросе или которые не указаны в данном разделе.

Идентификатор в ответе C-FIND должен содержать:

  • Ключевые атрибуты со значениями, соответствующими ключевым атрибутам, содержащимся в идентификаторе запроса (ключевые атрибуты, как определено в Section V.2.2.1.)

  • Условно — атрибут Specific Character Set (0008,0005). Этот атрибут должен быть включен, если расширенные или заменяющие наборы символов могут использоваться в любом из атрибутов идентификатора ответа. В противном случае он не должен включаться. SCP C-FIND не обязан возвращать ответы в наборе символов Specific Character Set, запрошенном SCU, если этот набор символов не поддерживается SCP. SCP может возвращать ответы с другим набором символов Specific Character Set.

Примечание

Это означает, что Specific Character Set (0008,0005) включается, если SCP поддерживает расширенные или заменяющие наборы символов в контексте данной услуги. Он не будет включен, если SCP не поддерживает расширенные или заменяющие наборы символов.

  • Условно — атрибут HL7 Structured Document Reference Sequence (0040,A390) и его вложенные элементы последовательности, как указано в модуле SOP Common (см. PS3.3). Этот атрибут должен быть включен, если в идентификаторе присутствуют ссылки на структурированные документы HL7, например, в Pertinent Documents Sequence (0038,0100).

V.4.1.1.4 Статус

Table V.4-1 определяет значения кодов состояния, которые могут быть возвращены в ответе C-FIND. Общие значения кодов состояния и связанные с ними поля определены для услуги DIMSE C-FIND в PS3.7.

Таблица V.4-1. Значения статуса ответа C-FIND

Статус службы

Дополнительное значение

Коды состояния

Связанные поля

Failure

Refused: Out of resources (Отказано: недостаточно ресурсов)

A700

(0000,0902)

Error: Data Set does not match SOP Class (Ошибка: набор данных не соответствует SOP-классу)

A900

(0000,0901)

(0000,0902)

Failed: Unable to process (Ошибка: невозможно обработать)

Cxxx

(0000,0901)

(0000,0902)

Cancel

Сопоставление прервано из-за запроса Cancel

FE00

Отсутствует

Success

Сопоставление завершено — итоговый идентификатор не предоставляется.

0000

Отсутствует

Pending

Сопоставление продолжается — предоставлено текущее совпадение, и любые необязательные ключи обрабатывались так же, как обязательные ключи.

FF00

Идентификатор

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

FF01

Идентификатор


Примечание

Коды состояния возвращаются в сообщениях-ответах DIMSE (см. PS3.7). Значения кодов, указанные в столбце «Коды состояния», возвращаются в элементе команды Status Command Element (0000,0900).

Некоторые коды состояния Failure зависят от реализации.

Реализация SCP должна назначать конкретные коды состояния Failure, заменяя каждый символ 'x' шестнадцатеричной цифрой в диапазоне от 0 до F. Реализация SCP, желающая различать причины значения Failure «Failed: Unable to process», должна назначать этим причинам конкретные значения кодов состояния в допустимом диапазоне, указанном в Table V.4-1.

Реализация SCU должна распознавать любой код состояния Failure в диапазоне значений, указанном в Table V.4-1 как индикатор значения Failure, указанного в таблице. Реализация SCU не обязана различать конкретные коды состояния в пределах допустимого диапазона.

V.4.1.2 Поведение SCU для C-FIND

Все SCU для C-FIND должны быть способны генерировать запросы, удовлетворяющие требованиям метода поиска Query (см. Section V.4.1.3.1).

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

SCU передает следующую семантику с помощью запросов и ответов C-FIND:

  • SCU запрашивает у SCP выполнение сопоставления всех ключей, указанных в идентификаторе запроса, с информацией, которой он обладает применительно к запросу, указанному в запросе.

  • SCU должен интерпретировать ответы Pending как передающие атрибуты совпадения элемента.

  • SCU должен интерпретировать ответ со статусом Success, Failure или Cancel как означающий окончание ответов Pending.

  • SCU должен интерпретировать ответ Failure на запрос C-FIND как указание на то, что SCP не может обработать запрос.

  • SCU может отменить услугу C-FIND, выдав запрос C-CANCEL-FIND в любой момент во время обработки C-FIND. SCU должен распознавать статус Cancel как указание на то, что C-CANCEL-FIND был успешным.

    Примечание

    SCU должен быть готов получать ответы C-FIND, отправляемые SCP, до тех пор, пока SCP окончательно не обработает запрос C-CANCEL-FIND.

V.4.1.3 Поведение SCP для C-FIND

Все SCP для C-FIND должны быть способны обрабатывать запросы, удовлетворяющие требованиям поиска Query (см. Section V.4.1.3.1).

SCP передает следующую семантику с помощью запросов и ответов C-FIND:

  • От SCP требуется выполнить сопоставление всех ключей, указанных в идентификаторе запроса, с информацией, которой он обладает. Сопоставление атрибутов выполняется с использованием значений ключей, указанных в идентификаторе запроса C-FIND, как определено в Section V.2.

  • SCP генерирует не более одного ответа C-FIND на совпадение с использованием метода поиска «Query». Такой ответ должен содержать идентификатор, атрибуты которого содержат значения из совпадения. Ответ должен содержать статус Pending.

  • По завершении сопоставления и отправке всех совпадений SCP генерирует ответ C-FIND со статусом Success. Статус Success означает, что ответ был отправлен для каждого совпадения, известного SCP.

Примечание

  1. Ответ со статусом Success не содержит идентификатора. Полное определение см. в PS3.7.

  2. Если совпадений нет, ответы со статусом Pending не отправляются, отправляется только один ответ со статусом Success.

  • SCP должен генерировать ответ со статусом Failure, если он не может обработать запрос. Ответ Failure не должен содержать идентификатора.

  • Если SCP получает индикацию C-CANCEL-FIND до завершения обработки совпадений, он должен прервать процесс сопоставления и вернуть статус Cancel.

V.4.1.3.1 Метод поиска Query

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

Ключевые атрибуты сопоставления, содержащиеся в идентификаторе запроса C-FIND, сопоставляются со значениями ключевых атрибутов для каждой сущности запроса. Для каждой сущности, у которой атрибуты соответствуют всем указанным атрибутам сопоставления, строится идентификатор. Этот идентификатор должен содержать все значения атрибутов данной сущности, соответствующие указанным в запросе C-FIND. Для каждого такого идентификатора возвращается ответ. Если ключи сопоставления отсутствуют, совпадений нет; возвращается ответ со статусом Success и без идентификатора.

V.5 Согласование ассоциации

Установление ассоциации является первой фазой любого экземпляра взаимодействия между равноправными DICOM AE. Процедура согласования ассоциации, определенная в PS3.7 должна использоваться для согласования поддерживаемых SOP-классов.

Поддержка согласования выбора ролей SCP/SCU является необязательной. Расширенное согласование SOP-класса не используется данным классом услуг.

V.6 Определения SOP-классов

V.6.1 SOP-класс запроса характеристик продукта (Product Characteristics Query)

V.6.1.1 Обзор SOP-класса запроса характеристик продукта

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

SOP-класс запроса характеристик продукта поддерживает следующие примеры вариантов использования:

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

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

  • Получение сетевой ссылки на онлайн-копию «этикетки продукта» (регламентированных данных о назначении и применении) для препарата, контрастного вещества или устройства.

V.6.1.2 Информационная модель запроса характеристик продукта

V.6.1.2.1 Модель «сущность-связь» (E/R Model)

Информационная модель запроса характеристик продукта представлена диаграммой «сущность-связь», показанной на рисунке Section V.6 -1.

Product Characteristics E-R Diagram

Рисунок V.6-1. Диаграмма «сущность-связь» характеристик продукта


В модели присутствует только одна информационная сущность — Product. Атрибуты Product можно найти в следующем модуле в PS3.3.

  • Product Characteristics Module

V.6.1.2.2 Атрибуты запроса характеристик продукта

Table V.6-1 определяет атрибуты информационной модели запроса характеристик продукта:

Таблица V.6-1. Атрибуты информационной модели запроса характеристик продукта

Description / Module

Tag

Тип ключа сопоставления

Тип возвращаемого ключа

Примечание / Тип сопоставления

Product Package Identifier

(0044,0001)

R

1

Должен извлекаться только с использованием сопоставления единичного значения (Single Value Matching).

Product Type Code Sequence

(0044,0007)

-

1

>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support”

Product Name

(0044,0008)

-

1

Product Expiration DateTime

(0044,000B)

-

2

Product Parameter Sequence

(0044,0013)

-

2

>Value Type

(0040,A040)

-

1

>Concept Name Code Sequence

(0040,A043)

-

1

>>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support”

>All other Attributes of the Product Parameter Sequence

-

1C

Зависит от значения Value Type (0040,A040); см. макрос Content Item Macro в PS3.3.

All other Attributes of the Product Characteristics Module

-

3


Product Package Identifier (0044,0001) может не быть глобально уникальным и может конфликтовать с другими идентификаторами, используемыми в рамках учреждения.

Примечание

Идентификаторы упаковки обычно уникальны в рамках систем управления введением веществ. Это предупреждение о том, что они не являются UID.

V.6.1.3 Требования соответствия

Реализация может соответствовать SOP-классу запроса характеристик продукта в роли SCU или SCP. Заявление о соответствии должно быть в формате, определенном в PS3.2.

V.6.1.3.1 Соответствие SCU

Реализация, соответствующая SOP-классу запроса характеристик продукта, должна поддерживать запросы к информационной модели, описанной в Section V.6.1.2 с использованием базового поведения SCU для C-FIND, описанного в Section V.4.1.2.

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

Реализация, соответствующая SOP-классу запроса характеристик продукта в роли SCU, должна указать в своем заявлении о соответствии, как она использует Specific Character Set (0008,0005) при кодировании запросов и интерпретации ответов.

V.6.1.3.2 Соответствие SCP

Реализация, соответствующая SOP-классу запроса характеристик продукта, должна поддерживать запросы к информационной модели запроса характеристик продукта, описанной в Section V.6.1.2 с использованием поведения SCP для C-FIND, описанного в Section V.4.1.3.

Реализация, соответствующая SOP-классу запроса характеристик продукта в роли SCP, должна указать в своем заявлении о соответствии поддерживаемые возвращаемые ключевые атрибуты.

Реализация, соответствующая SOP-классу запроса характеристик продукта в роли SCP, должна указать в своем заявлении о соответствии, как она использует Specific Character Set (0008,0005) при кодировании ответов.

V.6.1.4 SOP-класс

SOP-класс запроса характеристик продукта в классе услуг запроса на введение веществ идентифицирует информационную модель запроса характеристик продукта и поддерживаемые операции DIMSE-C. Определен следующий стандартный SOP-класс:

Таблица V.6.1.4-1. SOP-классы запроса характеристик продукта

Имя SOP-класса

SOP Class UID

Product Characteristics Query Information Model - FIND

1.2.840.10008.5.1.4.41


V.6.2 SOP-класс запроса разрешения на вещество (Substance Approval Query)

V.6.2.1 Обзор SOP-класса запроса разрешения на вещество

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

SOP-класс запроса разрешения на вещество поддерживает следующие примеры вариантов использования:

  • Получение подтверждения того, что введение конкретного препарата или контрастного вещества для получения изображения допустимо для пациента

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

SOP-класс запроса разрешения на вещество не определяет механизм, используемый SCP для проверки такого соответствия введения (например, посредством сравнения с информацией об аллергии в электронной медицинской карте пациента). Продолжительность действия разрешения после момента ответа не определяется Стандартом.

V.6.2.2 Информационная модель запроса разрешения на вещество

V.6.2.2.1 Модель «сущность-связь» (E/R Model)

Информационная модель запроса разрешения на вещество представлена диаграммой «сущность-связь», показанной на Figure V.6-2.

Substance Approval E-R Diagram

Рисунок V.6-2. Диаграмма «сущность-связь» разрешения на вещество


Figure V.6-2

Атрибуты информационных сущностей можно найти в следующих модулях в PS3.3.

  • Patient Identification Module

  • Patient Demographics Module

  • Visit Identification Module

  • Substance Administration Module

  • Substance Approval Module

  • Product Characteristics Module

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

Информационная модель используется в запросе по принципу «снизу вверх»: то есть, имея Product и Patient, либо, в качестве альтернативы, Product и Visit, для предполагаемого акта Substance Administration в текущий момент времени, найти Approval.

IE Visit включена в информационную модель для поддержки тех учреждений, которые идентифицируют пациентов (например, по браслету со штрихкодом) по Admission ID (т.е. идентификатору визита), а не по Patient ID. Это позволяет автоматизировать построение запроса путем сканирования Admission ID. Admission ID может быть сопоставлен с Patient ID со стороны SCP для целей выполнения сопоставления запроса.

Примечание

  1. Visit идентифицируется атрибутом Admission ID (0038,0010), однако в «Модели реального мира для целей интерфейса Modality-IS» (см. PS3.3), Visit является подчиненной по отношению к Patient; следовательно, Admission ID может быть уникальным только в контексте пациента, а не в контексте учреждения. Использование атрибута Admission ID для идентификации Visit (и, следовательно, Patient) эффективно только в том случае, если Admission ID уникален в контексте учреждения.

  2. Некоторые учреждения, например амбулаторные центры визуализации, не выполняющие «поступление» пациентов, могут использовать Imaging Service Request Identifier или Accession Number в качестве эквивалента Admission ID. SCU данной услуги запроса не обязан знать истинное происхождение или природу идентификатора — достаточно того, что он передается в запросе в атрибуте Admission ID (0038,0010).

  3. Концептуально у акта Substance Administration есть атрибут даты и времени введения, который в данном SOP-классе неявно принимается равным примерно моменту выполнения запроса.

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

V.6.2.2.2 Атрибуты запроса разрешения на вещество

Table V.6-2 определяет атрибуты информационной модели запроса разрешения на вещество.

Таблица V.6-2. Атрибуты информационной модели запроса разрешения на вещество

Description / Module

Tag

Тип ключа сопоставления

Тип возвращаемого ключа

Примечание / Тип сопоставления

Patient

Patient's Name

(0010,0010)

O

2

Patient ID

(0010,0020)

R

1

Должен извлекаться только с использованием сопоставления единичного значения (Single Value Matching).

Один или оба атрибута Patient ID (0010,0020) и Admission ID (0038,0010) должны присутствовать в запросе в качестве ключа сопоставления

Issuer of Patient ID

(0010,0021)

O

2

Issuer of Patient ID Qualifiers Sequence

(0010,0024)

O

3

>All Attributes of the Issuer of Patient ID Qualifiers Sequence

O

3

Patient's Birth Date

(0010,0030)

-

2

Patient's Sex

(0010,0040)

-

2

Visit

Admission ID

(0038,0010)

R

2

Должен извлекаться только с использованием сопоставления единичного значения (Single Value Matching).

Один или оба атрибута Patient ID (0010,0020) и Admission ID (0038,0010) должны присутствовать в запросе в качестве ключа сопоставления

Issuer of Admission ID Sequence

(0038,0014)

O

3

>Local Namespace Entity ID

(0040,0031)

O

1C

Обязательно, если Universal Entity ID (0040,0032) отсутствует; может присутствовать в остальных случаях

>Universal Entity ID

(0040,0032)

O

1C

Обязательно, если Local Namespace Entity ID (0040,0031) отсутствует; может присутствовать в остальных случаях.

>Universal Entity ID Type

(0040,0033)

O

1C

Обязательно, если присутствует Universal Entity ID (0040,0032).

Product

Product Package Identifier

(0044,0001)

R

1

Должен извлекаться только с использованием сопоставления единичного значения (Single Value Matching). Должен присутствовать в запросе в качестве ключа сопоставления.

Substance Administration

Administration Route Code Sequence

(0054,0302)

R

1

Должен присутствовать в запросе в качестве ключа сопоставления.

>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

Approval

Substance Administration Approval

(0044,0002)

-

1

Approval Status Further Description

(0044,0003)

-

2

Approval Status DateTime

(0044,0004)

-

1


Один или оба атрибута Patient ID (0010,0020) и Admission ID (0038,0010) должны присутствовать в запросе в качестве ключа сопоставления.

Product Package Identifier (0044,0001) должен присутствовать в запросе в качестве ключа сопоставления. Product Package Identifier может не быть глобально уникальным и может конфликтовать с другими идентификаторами, используемыми в рамках учреждения.

Примечание

Идентификаторы упаковки обычно уникальны в рамках систем управления введением веществ. Это предупреждение о том, что они не являются UID.

Administration Route Code Sequence (0054,0302) должен присутствовать в запросе в качестве ключа сопоставления, и в этой последовательности должен присутствовать единственный элемент с Code Value (0008,0100) и Coding Scheme Designator (0008,0102) в качестве ключей сопоставления.

V.6.2.2.3 Ответы запроса разрешения на вещество

Ответ на запрос может иметь статус Success или Failure (см. Section V.4.1.1.4). Ответ Failure не несет никакой семантики о существовании или статусе разрешения на Substance Administration.

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

Примечание

Отсутствие ответов Pending может возникать из-за невозможности SCP сопоставить идентификатор пациента, идентификатор продукта или путь введения.

В случае одного ответа Pending соответствующая сущность Approval будет явно передавать значение Substance Administration Approval (0044,0002): APPROVED, WARNING или CONTRA_INDICATED.

V.6.2.3 Требования соответствия

Реализация может соответствовать SOP-классу запроса разрешения на вещество в роли SCU или SCP. Заявление о соответствии должно быть в формате, определенном в PS3.2.

V.6.2.3.1 Соответствие SCU

Реализация, соответствующая SOP-классу запроса разрешения на вещество, должна поддерживать запросы к информационной модели, описанной в Section V.6.2.2 с использованием базового поведения SCU для C-FIND, описанного в Section V.4.1.2.

Реализация, соответствующая SOP-классу запроса разрешения на вещество в роли SCU, должна указать в своем заявлении о соответствии, как атрибуты запроса используются в приложении и как приложение отображает возвращенные атрибуты, в частности значения Substance Administration Approval (0044,0002) и Approval Status Further Description (0044,0003). Она должна указать, как отображается ответ на запрос с нулевым числом элементов Pending или статусом Failure.

Реализация, соответствующая SOP-классу запроса разрешения на вещество в роли SCU, должна указать в своем заявлении о соответствии, как она использует Specific Character Set (0008,0005) при кодировании запросов и интерпретации ответов.

V.6.2.3.2 Соответствие SCP

Реализация, соответствующая SOP-классу запроса разрешения на вещество, должна поддерживать запросы к информационной модели запроса разрешения на вещество, описанной в Section V.6.2.2 с использованием поведения SCP для C-FIND, описанного в Section V.4.1.3. Она должна поддерживать все атрибуты, указанные в информационной модели.

Реализация, соответствующая SOP-классу запроса разрешения на вещество в роли SCP, должна указать в своем заявлении о соответствии, как она обрабатывает обязательные и необязательные ключевые атрибуты сопоставления. Она должна указать, как получает значения для возвращаемых ключевых атрибутов.

Реализация, соответствующая SOP-классу запроса разрешения на вещество в роли SCP, должна указать в своем заявлении о соответствии, как она использует Specific Character Set (0008,0005) при интерпретации запросов, выполнении сопоставления и кодировании ответов.

V.6.2.4 SOP-класс

SOP-класс запроса разрешения на вещество в классе услуг запроса на введение веществ идентифицирует информационную модель запроса разрешения на вещество и поддерживаемые операции DIMSE-C. Определен следующий стандартный SOP-класс:

Таблица V.6.2.4-1. SOP-классы запроса разрешения на вещество

Имя SOP-класса

SOP Class UID

Substance Approval Query Information Model - FIND

1.2.840.10008.5.1.4.42


W Класс услуг хранения цветовой палитры

См. Annex GG.

Примечание

Требования этого раздела были объединены в класс услуг хранения объектов, не относящихся к пациенту (см. Раздел GG.6.2).

X Класс услуг запроса/получения цветовой палитры

X.1 Обзор

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

Класс услуг запроса/получения цветовой палитры (Color Palette Query/Retrieve Service Class) определяет класс услуг прикладного уровня, обеспечивающий доступ к составным объектам цветовой палитры (Color Palette).

X.1.2 Соглашения

См. класс услуг базового управления списком заданий (Basic Worklist Management Service Class), Раздел K.1.2 Соглашения.

X.1.3 Информационная модель запроса/получения

Чтобы выступать в роли SCP класса услуг запроса/получения цветовой палитры, DICOM AE обладает информацией об атрибутах ряда составных SOP-экземпляров цветовой палитры. Эта информация организована в информационную модель цветовой палитры (Color Palette Information Model).

X.1.4 Определение услуги

Два равноправных DICOM AE реализуют SOP-класс класса услуг запроса/получения цветовой палитры, при этом один выступает в роли SCU, а другой — в роли SCP. SOP-классы класса услуг запроса/получения цветовой палитры реализуются с использованием услуг DIMSE-C C-FIND, C-MOVE и C-GET, определённых в PS3.7.

Семантика услуги C-FIND совпадает с определённой в разделе «Определение услуги» класса услуг базового управления списком заданий.

Семантика услуг C-MOVE и C-GET совпадает с определённой в разделе «Определение услуги» класса услуг запроса/получения (Query/Retrieve Service Class), за исключением того, что существует только один уровень получения.

X.2 Определение информационной модели цветовой палитры

Информационная модель цветовой палитры идентифицируется SOP-классом, согласованным при установлении ассоциации. SOP-класс состоит из информационной модели и группы услуг DIMSE-C.

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

X.3 Информационная модель цветовой палитры

Информационная модель цветовой палитры основана на одноуровневой сущности:

  • Экземпляр объекта цветовой палитры

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

X.4 Группы услуг DIMSE-C

X.4.1 Операция C-FIND

См. определение операции C-FIND для класса услуг базового управления списком заданий (K.4.1), заменяя «Worklist» на «Color Palette». Должен использоваться метод поиска «Worklist».

SOP Class UID идентифицирует информационную модель цветовой палитры, в отношении которой должен выполняться C-FIND. Ключевые атрибуты и допустимые для запроса значения определены в определении SOP-класса информационной модели цветовой палитры.

X.4.2 Операция C-MOVE

См. определение операции C-MOVE для класса услуг запроса/получения (C.4.2). Расширенное поведение (Extended Behavior) и реляционное получение (Relational-Retrieve) для класса услуг запроса/получения цветовой палитры не определены.

Query/Retrieve Level (0008,0052) не относится к классу услуг запроса/получения цветовой палитры и поэтому не должен присутствовать в идентификаторе. Единственным уникальным ключевым атрибутом идентификатора должен быть SOP Instance UID (0008,0018). SCU должен предоставить один UID или список UID.

Примечание

Может быть получена более чем одна сущность с использованием сопоставления по списку UID.

X.4.3 Операция C-GET

См. определение операции C-GET для класса услуг запроса/получения (C.4.3). Расширенное поведение (Extended Behavior) и реляционное получение (Relational-Retrieve) для класса услуг запроса/получения цветовой палитры не определены.

Query/Retrieve Level (0008,0052) не относится к классу услуг запроса/получения цветовой палитры и поэтому не должен присутствовать в идентификаторе. Единственным уникальным ключевым атрибутом идентификатора должен быть SOP Instance UID (0008,0018). SCU должен предоставить один UID или список UID.

Примечание

Может быть получена более чем одна сущность с использованием сопоставления по списку UID.

X.5 Согласование ассоциации

См. определение согласования ассоциации для класса услуг базового управления списком заданий (K.5).

X.6 Определения SOP-классов

X.6.1 Информационная модель цветовой палитры

X.6.1.1 Модель E/R

Информационная модель цветовой палитры состоит из единственной сущности. В ответ на данный запрос C-FIND SCP должен отправить один ответ C-FIND на каждый подходящий экземпляр цветовой палитры.

Color Palette Information Model E-R Diagram

Figure X.6-1. Color Palette Information Model E-R Diagram


X.6.1.2 Атрибуты цветовой палитры

Table X.6-1 defines the Attributes of the Color Palette Information Model:

Table X.6-1. Attributes for the Color Palette Information Model

Описание / Модуль

Tag

Тип ключа сопоставления

Тип возвращаемого ключа

Примечание / Тип сопоставления

SOP Common

Specific Character Set

(0008,0005)

-

1C

Этот атрибут обязателен, если используются расширенные или замещающие наборы символов. См. Раздел C.2.2.2 и Раздел C.4.1.1.

SOP Class UID

(0008,0016)

R

1

Этот атрибут должен извлекаться с использованием сопоставления единичного значения.

SOP Instance UID

(0008,0018)

U

1

Этот атрибут должен извлекаться с использованием сопоставления единичного значения.

Color Palette Definition

Content Label

(0070,0080)

R

1

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

Content Description

(0070,0081)

-

2

Content Creator's Name

(0070,0084)

-

2

Alternate Content Description Sequence

(0070,0087)

-

3

>Content Description

(0070,0081)

-

1

>Language Code Sequence

(0008,0006)

-

1

>>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support”


X.6.1.3 Требования соответствия

Реализация может соответствовать одному из SOP-классов информационной модели цветовой палитры в роли SCU, SCP или обеих ролей. Заявление о соответствии (Conformance Statement) должно быть оформлено в формате, определённом в PS3.2.

X.6.1.3.1 Соответствие SCU
X.6.1.3.1.1 Соответствие SCU для C-FIND

Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры, должна поддерживать запросы к информационной модели цветовой палитры с использованием поведения SCU C-FIND, описанного для класса услуг базового управления списком заданий (см. Раздел K.4.1.2 и Раздел X.4.1).

Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCU, должна указать в своём заявлении о соответствии, запрашивает ли она возвращаемые ключевые атрибуты типа 3, и перечислить эти необязательные возвращаемые ключевые атрибуты.

Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCU, должна указать в своём заявлении о соответствии, каким образом она использует Specific Character Set (0008,0005) при кодировании запросов и интерпретации ответов.

X.6.1.3.1.2 Соответствие SCU для C-MOVE

Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCU, должна поддерживать передачу данных в отношении информационной модели цветовой палитры с использованием базового поведения SCU C-MOVE, описанного для класса услуг запроса/получения (см. Раздел C.4.2.2.1 и Раздел X.4.2).

X.6.1.3.1.3 Соответствие SCU для C-GET

Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCU, должна поддерживать передачу данных в отношении информационной модели цветовой палитры с использованием базового поведения SCU C-GET, описанного для класса услуг запроса/получения (см. Раздел C.4.3.2.1 и Раздел X.4.3).

X.6.1.3.2 Соответствие SCP
X.6.1.3.2.1 Соответствие SCP для C-FIND

Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCP, должна поддерживать запросы к информационной модели цветовой палитры с использованием поведения SCP C-FIND, описанного для класса услуг базового управления списком заданий (см. Раздел K.4.1.3).

Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCP, должна указать в своём заявлении о соответствии, поддерживает ли она возвращаемые ключевые атрибуты типа 3, и перечислить эти необязательные возвращаемые ключевые атрибуты.

Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCP, должна указать в своём заявлении о соответствии, каким образом она использует Specific Character Set (0008,0005) при интерпретации запросов, выполнении сопоставления и кодировании ответов.

X.6.1.3.2.2 Соответствие SCP для C-MOVE

Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCP, должна поддерживать передачу данных в отношении информационной модели цветовой палитры с использованием базового поведения SCP C-MOVE, описанного для класса услуг запроса/получения (см. Раздел C.4.2.3.1).

Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCP, генерирующая передачи с использованием операции C-MOVE, должна указать в своём заявлении о соответствии SOP-класс класса услуг хранения цветовой палитры, в рамках которого она поддерживает подоперации C-STORE, порождаемые C-MOVE.

X.6.1.3.2.3 Соответствие SCP для C-GET

Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCP, должна поддерживать передачу данных в отношении информационной модели цветовой палитры с использованием базового поведения SCP C-GET, описанного для класса услуг запроса/получения (см. Раздел C.4.3.3.1).

Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCP, генерирующая передачи с использованием операции C-GET, должна указать в своём заявлении о соответствии SOP-класс класса услуг хранения цветовой палитры, в рамках которого она поддерживает подоперации C-STORE, порождаемые C-GET.

X.6.1.4 SOP-классы

SOP-классы информационной модели цветовой палитры в классе услуг запроса/получения цветовой палитры идентифицируют информационную модель цветовой палитры и поддерживаемые операции DIMSE-C. Определены следующие стандартные SOP-классы:

Table X.6.1.4-1. Color Palette SOP Classes

Имя SOP-класса

SOP Class UID

Color Palette Information Model - FIND

1.2.840.10008.5.1.4.39.2

Color Palette Information Model - MOVE

1.2.840.10008.5.1.4.39.3

Color Palette Information Model - GET

1.2.840.10008.5.1.4.39.4


Y Класс услуг Composite Instance Root Retrieve

Y.1 Обзор

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

Composite Instance Root Retrieve Service — это услуга в составе класса услуг запроса/получения DICOM (DICOM Query/Retrieve Service Class), определённого в Приложении C. Возможность получения (retrieve) этой услуги позволяет DICOM AE получать составные экземпляры (Composite Instances) или выбранные кадры от удалённого DICOM AE в рамках единой ассоциации либо запрашивать у удалённого DICOM AE инициирование передачи экземпляров составных объектов или выбранных кадров из объектов изображений другому DICOM AE.

Опция расширенного согласования Enhanced Multi-Frame Image Conversion класса услуг запроса/получения DICOM, определённого в Приложении C, также поддерживается для Composite Instance Root Retrieve Service.

Y.1.2 Информационная модель Composite Instance Root Retrieve

Получение данных реализуется в отношении информационной модели Composite Instance Root Retrieve, определённой в настоящем Приложении Стандарта DICOM. Конкретный SOP-класс класса услуг запроса/получения состоит из определения информационной модели и группы услуг DIMSE-C.

Y.1.3 Определение услуги

Два равноправных DICOM AE реализуют SOP-класс услуги Composite Instance Root Retrieve, при этом один выступает в роли SCU, а другой — в роли SCP. SOP-классы услуги Composite Instance Root Retrieve реализуются с использованием услуг DIMSE-C C-MOVE и C-GET, определённых в PS3.7.

Приведённые ниже описания услуг DIMSE-C C-GET и C-MOVE дают краткий обзор семантики SCU/SCP:

  1. Услуга C-MOVE несёт следующую семантику:

    • SCU предоставляет значения уникальных ключей и ключей диапазона кадров (Frame Range Key) для идентификации запрошенного(-ых) SOP-экземпляра(-ов). SCP при необходимости создаёт новые SOP-экземпляры и затем инициирует подоперации C-STORE для соответствующих SOP-экземпляров хранения. Эти подоперации C-STORE выполняются в рамках ассоциации, отличной от ассоциации услуги C-MOVE. Роль SCP SOP-класса получения и роль SCU SOP-класса хранения могут выполняться разными приложениями, которые могут находиться как на одной, так и на разных системах. Механизм инициирования подопераций C-STORE выходит за рамки Стандарта DICOM.

    • SCP может опционально генерировать ответы на C-MOVE со статусом Pending в процессе выполнения подопераций C-STORE. Эти ответы C-MOVE указывают количество оставшихся подопераций C-STORE и количество подопераций C-STORE, вернувших статус Success, Warning и Failure.

    • Когда количество оставшихся подопераций C-STORE достигает нуля, SCP генерирует финальный ответ со статусом Success, Warning или Failure. Этот ответ должен указывать количество подопераций C-STORE, вернувших статус Success, Warning и Failure. Если хотя бы одна из подопераций завершилась успешно, должен быть возвращён список успешных UID. Если статус подоперации C-STORE был Failure, должен быть возвращён список UID.

    • SCU может отменить услугу C-MOVE, отправив запрос C-CANCEL-MOVE в любой момент в процессе выполнения C-MOVE. SCP прекращает все незавершённые подоперации C-STORE и возвращает статус Cancel.

  2. Услуга C-GET несёт следующую семантику:

    • SCU предоставляет значения уникальных ключей и ключей диапазона кадров для идентификации запрошенного(-ых) SOP-экземпляра(-ов). SCP при необходимости создаёт новые SOP-экземпляры и затем генерирует подоперации C-STORE для соответствующих SOP-экземпляров хранения. Эти подоперации C-STORE выполняются в рамках той же ассоциации, что и услуга C-GET, при этом роли SCU/SCP для C-STORE меняются местами.

    • SCP может опционально генерировать ответы на C-GET со статусом Pending в процессе выполнения подопераций C-STORE. Эти ответы C-GET указывают количество оставшихся подопераций C-STORE и количество подопераций C-STORE, вернувших статус Success, Warning и Failure.

    • Когда количество оставшихся подопераций C-STORE достигает нуля, SCP генерирует финальный ответ со статусом Success, Warning или Failure. Этот ответ должен указывать количество подопераций C-STORE, вернувших статус Success, Warning и Failure. Если статус какой-либо подоперации C-STORE был Failed, должен быть возвращён список UID.

    • SCU может отменить услугу C-GET, отправив запрос C-CANCEL-GET в любой момент в процессе выполнения C-GET. SCP прекращает все незавершённые подоперации C-STORE и возвращает статус Cancel.

Y.2 Определение информационной модели Composite Instance Root Retrieve

Информационная модель Composite Instance Root Retrieve идентифицируется SOP-классом, согласованным при установлении ассоциации. SOP-класс состоит из информационной модели и группы услуг DIMSE-C.

Примечание

Этот SOP-класс идентифицирует класс информационной модели Composite Instance Root Retrieve (т.е. не SOP-класс сохранённых SOP-экземпляров, о которых у SCP есть информация).

Определения информационных моделей для стандартных SOP-классов услуги Composite Instance Root Retrieve определены в данном Приложении. Определение информационной модели Composite Instance Root Retrieve содержит:

  • Определение модели «сущность-связь» (Entity-Relationship Model Definition)

  • Определение ключевых атрибутов (Key Attributes Definition)

Y.2.1 Определение модели «сущность-связь»

Для любой информационной модели Composite Instance Root Retrieve модель «сущность-связь» определяет иерархию сущностей с атрибутами, определёнными для каждого уровня иерархии (например, Composite Instance, Frame).

Y.2.2 Определение атрибутов

Атрибуты и сопоставление должны определяться в соответствии с Разделом C.2.2

Y.3 Стандартная информационная модель Composite Instance Root Retrieve

В данном Приложении определена одна стандартная информационная модель Composite Instance Root Retrieve. Информационная модель Composite Instance Root Retrieve связана с рядом SOP-классов. Определена следующая иерархическая информационная модель Composite Instance Root Retrieve:

  • Composite Instance Root

Y.3.1 Информационная модель Composite Instance Root

Информационная модель Composite Instance Root основана на двухуровневой иерархии:

  • Composite Instance

  • Frame

Уровень Composite Instance является верхним уровнем и содержит только SOP Instance UID. Уровень Frame расположен ниже уровня Composite Instance и содержит только атрибуты, относящиеся к выбору кадров из одного многокадрового объекта изображения.

Y.3.2 Построение и интерпретация ключей диапазона кадров

Следующие правила использования ключей диапазона кадров (Frame Range Keys) применяются как к SCU, создающему такие ключи, так и к SCP, интерпретирующему их.

Y.3.2.1 Определения списка кадров

Выбор кадров, подлежащих включению во вновь созданный SOP-экземпляр в ответ на запрос Composite Instance Root Retrieve уровня FRAME, должен определяться одним из механизмов, определённых в данном разделе, а полученный таким образом список кадров именуется «списком кадров» (Frame List).

Примечание

  1. Изменение порядка кадров не поддерживается, порядок кадров в списке кадров всегда будет таким же, как в исходном SOP-экземпляре.

  2. Новые допустимые механизмы выбора кадров могут быть определены в будущем путём добавления новых SOP-классов

Y.3.2.1.1 Simple Frame List

Simple Frame List (0008,1161) — многозначный атрибут, содержащий список номеров кадров, каждый из которых указывает кадр, подлежащий включению в возвращаемый объект. Первый кадр исходного экземпляра обозначается как кадр номер 1.

Номера кадров в списке не должны содержать дубликатов и должны монотонно возрастать.

Примечание

Вследствие использования VR UL для этого элемента может быть указано максимум 16383 значения, поскольку при использовании явного VR синтаксиса передачи доступна длина только в 2 байта.

Y.3.2.1.2 Calculated Frame List

Calculated Frame List (0008,1162) — многозначный атрибут, содержащий список 3-элементных кортежей, каждый из которых представляет поддиапазон кадров, подлежащих включению в возвращаемый объект. Первый кадр исходного экземпляра обозначается как кадр номер 1. Для каждого 3-элементного кортежа:

  • Первое число должно быть номером первого кадра поддиапазона.

  • Второе число должно быть верхней границей поддиапазона и должно быть больше или равно первому числу.

  • Третье число должно быть шагом между запрошенными кадрами поддиапазона. Оно должно быть больше нуля.

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

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

Если первое число больше количества кадров в упомянутом SOP-экземпляре, этот поддиапазон должен игнорироваться.

Поддиапазоны не должны пересекаться, так что последовательность номеров кадров, полученная объединением всех поддиапазонов, не должна содержать дубликатов и должна монотонно возрастать. Значение FFFFFFFFH или любое значение, превышающее количество кадров в упомянутом SOP-экземпляре, в качестве второго значения обозначает конец набора кадров в упомянутом SOP-экземпляре и может встречаться только в последнем 3-элементном кортеже.

Примечание

Например, если Calculated Frame List содержит 6 значений: 2, 9, 3, 12, FFFFFFFFH, 5 — и применяется к экземпляру, содержащему 25 кадров, результирующий список кадров будет содержать значения 2, 5, 8, 12, 17 и 22.

Y.3.2.1.3 Time Range

Time Range (0008,1163) содержит время начала и окончания, подлежащее включению в возвращаемый объект. Время указывается в секундах относительно значения Content Time (0008,0033) в родительском объекте.

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

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

Примечание

Для MPEG-2, MPEG-4 AVC/H.264 и HEVC/H.265 это будет ближайшие окружающие ключевые кадры (Key Frames).

Для JPEG 2000 Part 2 это будет ближайшая окружающая граница региона (precinct) или тайла

Time Range должен использоваться только для указания извлечения из SOP-экземпляров, где время кадров может быть определено с использованием одного или нескольких из следующих атрибутов:

  • Frame Time (0018,1063)

  • Frame Time Vector (0018,1065)

  • Frame Reference DateTime (0018,9151) в Frame Content Sequence (0020,9111)

Y.3.3 Создание нового экземпляра на уровне кадра

Когда операция C-MOVE или C-GET выполняется в отношении исходного составного экземпляра на уровне FRAME, SCP должен создать новый составной экземпляр в соответствии со следующими правилами:

  • Новый составной экземпляр должен быть извлечён из исходного составного экземпляра, указанного уникальным ключом SOP Instance UID, присутствующим на уровне Composite Instance.

  • Новый составной экземпляр должен быть экземпляром того же SOP-класса, что и исходный составной экземпляр.

  • Новый составной экземпляр должен иметь новый SOP Instance UID.

  • Новый составной экземпляр должен быть допустимым SOP-экземпляром.

Примечание

Новый составной экземпляр обязан быть внутренне согласованным и допустимым. Это может потребовать от SCP согласованно изменить любые атрибуты, ссылающиеся на кадры или связи между ними, такие как время начала, временные смещения, а также изменить Per-Frame Functional Group Sequence (5200,9230).

  • Новый составной экземпляр должен содержать кадры из исходного составного объекта, запрошенные в Requested Frame List. Requested Frame List должен интерпретироваться согласно правилам Раздела Y.3.2. Кадры должны следовать в том же порядке, что и в исходном составном экземпляре.

  • Новый составной экземпляр должен включать модуль Frame Extraction Module, содержащий соответствующие атрибуты из идентификатора запроса C-GET или C-MOVE, вызвавшего создание этого экземпляра. Если модуль Frame Extraction Module уже существует в исходном составном экземпляре, то в Frame Extraction Sequence должен быть добавлен новый элемент.

  • Новый составной экземпляр должен содержать Contributing Equipment Sequence (0018,A001). Если исходный составной объект содержит Contributing Equipment Sequence, то к копии последовательности в новом составном экземпляре должен быть добавлен новый элемент; если исходный составной объект не содержит Contributing Equipment Sequence, она должна быть создана и содержать один новый элемент. В любом случае новый элемент должен описывать оборудование, выполняющее извлечение кадров, а Purpose of Reference Code Sequence (0040,A170) в этом элементе должна иметь значение (109105, DCM, "Frame Extracting Equipment").

Примечание

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

  • Новый составной экземпляр должен иметь ту же информацию уровня Patient, Study и Series, что и исходный экземпляр, включая Study и Series Instance UID.

  • Новый составной экземпляр должен иметь те же значения атрибутов модуля Image Pixel Module, что и исходный составной экземпляр, за исключением того, что атрибут Pixel Data Provider URL (0028,7FE0) не должен присутствовать, Pixel Data (7FE0,0010) должен быть заменён подмножеством кадров согласно Разделу Y.3.3, а Number of Frames (0028,0008) должен содержать количество кадров в новом составном экземпляре.

  • Новый составной экземпляр должен иметь те же значения для прочих атрибутов уровня Image типа 1 и типа 2, не оговорённых иначе. В новый составной экземпляр могут быть включены другие атрибуты, если это согласуется с новым составным экземпляром.

Примечание

В большинстве случаев частные атрибуты не следует копировать, если их полное значение неизвестно. Дополнительные указания см. в Приложении MM «Considerations For Applications Creating New Images From Multi-frame Images» в PS3.17.

  • Новый составной экземпляр не должен входить в конкатенацию (Concatenation). Это означает, что он не должен содержать атрибут Concatenation UID (0020,9161) или другие атрибуты конкатенации. Если существующий составной экземпляр содержит такие атрибуты, они не должны включаться в новый составной экземпляр.

Y.4 Группы услуг DIMSE-C

При построении SOP-классов услуги Composite Instance Root Retrieve используется единая услуга DIMSE-C. Используется следующая операция DIMSE-C:

  • C-MOVE

  • C-GET

Y.4.1 Операция C-MOVE

SCU услуги Composite Instance Root Retrieve должны выполнять получение данных с использованием операции C-MOVE, как описано в PS3.7. Операция C-MOVE позволяет прикладному объекту дать указание другому прикладному объекту передать сохранённые SOP-экземпляры или новые SOP-экземпляры, извлечённые из таких сохранённых SOP-экземпляров, третьему прикладному объекту с использованием операции C-STORE. Поддержка услуги C-MOVE должна быть согласована при установлении ассоциации как SCU, так и SCP C-MOVE, чтобы операция C-MOVE могла выполняться в рамках данной ассоциации. Подоперации C-STORE всегда должны выполняться в рамках ассоциации, отличной от ассоциации, в рамках которой выполняется операция C-MOVE. Таким образом, SCP класса услуг запроса/получения выступает в роли SCU класса услуг хранения.

Примечание

Прикладной объект, получающий сохранённые SOP-экземпляры, может как быть, так и не быть инициатором операции C-MOVE.

Запрос C-MOVE может выполняться на любом уровне информационной модели Composite Object Instance Root Retrieve, и ожидаемое поведение SCP зависит от выбранного уровня.

Y.4.1.1 Параметры услуги C-MOVE

Y.4.1.1.1 SOP Class UID

SOP Class UID идентифицирует информационную модель запроса/получения, в отношении которой должен выполняться C-MOVE. Поддержка SOP Class UID подразумевается Abstract Syntax UID контекста представления, используемого данной операцией C-MOVE.

Y.4.1.1.2 Priority

Атрибут Priority определяет запрошенный приоритет операции C-MOVE и соответствующих подопераций C-STORE относительно других DIMSE-операций, выполняемых тем же SCP.

Обработка запросов приоритета не является обязательной для SCP. Поддерживает ли SCP обработку приоритета и смысл различных уровней приоритета должны быть указаны в заявлении о соответствии SCP. Один и тот же приоритет должен использоваться для всех подопераций C-STORE.

Y.4.1.1.3 Идентификатор

Запрос C-MOVE должен содержать идентификатор. Ответ C-MOVE должен условно содержать идентификатор согласно требованиям Раздела C.4.3.1.3.2.

Примечание

Идентификатор указан как U в определении примитива C-MOVE в PS3.7, но специализирован для использования с данной услугой.

Y.4.1.1.3.1 Структура идентификатора запроса

Идентификатор в запросе C-MOVE должен содержать:

  • Query/Retrieve Level (0008,0052), определяющий уровень получения

  • SOP Instance UID(s) (0008,0018)

  • Один из ключей диапазона кадров (Frame Range Keys), если он присутствует в информационной модели для уровня получения

  • Условно, атрибут Query/Retrieve View (0008,0053). Этот атрибут может быть включён, если Enhanced Multi-Frame Image Conversion было согласовано в процессе расширенного согласования ассоциации. В противном случае он не должен включаться.

Specific Character Set (0008,0005) не должен присутствовать.

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

Y.4.1.1.4 Статус

Table Y.4-1 defines the Status Code values that might be returned in a C-MOVE response. General Status Code values and fields related to Status Code values are defined for C-MOVE DIMSE Service in PS3.7.

Table Y.4-1. C-MOVE Response Status Values for Composite Instance Root Retrieve

Статус службы

Дополнительное значение

Status Codes

Связанные поля

Failure

Отказано: нехватка ресурсов — невозможно вычислить количество совпадений

A701

(0000,0902)

Отказано: нехватка ресурсов — невозможно выполнить подоперации

A702

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)

Отказано: получатель перемещения неизвестен

A801

(0000,0902)

Ошибка: набор данных не соответствует SOP-классу

A900

(0000,0901)

(0000,0902)

Ошибка: невозможно обработать

Cxxx

(0000,0901)

(0000,0902)

Ошибка: ни один из запрошенных кадров не найден в SOP-экземпляре

AA00

(0000,0902)

Ошибка: невозможно создать новый объект для данного SOP-класса

AA01

(0000,0902)

Ошибка: невозможно извлечь кадры

AA02

(0000,0902)

Ошибка: получен запрос по времени для исходного SOP-экземпляра, не являющегося временны́м.

AA03

(0000,0902)

Ошибка: недопустимый запрос

AA04

(0000,0901)

(0000,0902)

Cancel

Подоперации прерваны вследствие индикации отмены (Cancel)

FE00

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)

Warning

Подоперации завершены — есть один или более сбоев или предупреждений

B000

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)

Success

Подоперации завершены — сбоев и предупреждений нет

0000

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)

Pending

Подоперации продолжаются

FF00

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)


Некоторые коды состояния сбоя зависят от реализации.

Реализация SCP должна назначать конкретные коды состояния сбоя путём замены каждого символа 'x' шестнадцатеричной цифрой в диапазоне от 0 до F. Реализация SCP, желающая различать причины значения сбоя «Ошибка: невозможно обработать», должна назначить этим причинам конкретные значения кодов состояния в допустимом диапазоне, указанном в Таблице Y.4-1.

Реализация SCU должна распознавать любой код состояния сбоя в пределах диапазона значений, указанного в Таблице Y.4-1, как индикатор значения сбоя, указанного в таблице. Требование к реализации SCU различать конкретные коды состояния в пределах допустимого диапазона отсутствует.

Y.4.1.1.5 Number of Remaining Sub-Operations

Включение Number of Remaining Sub-Operations должно осуществляться согласно Разделу C.4.2.1.6

Y.4.1.1.6 Number of Completed Sub-Operations

Включение Number of Completed Sub-Operations должно осуществляться согласно Разделу C.4.2.1.7

Y.4.1.1.7 Number of Failed Sub-Operations

Включение Number of Failed Sub-Operations должно осуществляться согласно Разделу C.4.2.1.8

Y.4.1.1.8 Number of Warning Sub-Operations

Включение Number of Warning Sub-Operations должно осуществляться согласно Разделу C.4.2.1.9.

Y.4.1.2 Поведение SCU для C-MOVE

Y.4.1.2.1 Базовое поведение SCU

SCU несёт следующую семантику с запросом C-MOVE:

  • Если Retrieve Level (0000,0052) равен IMAGE, SCU должен указать один SOP Instance UID или список SOP Instance UID.

  • Если Retrieve Level (0000,0052) равен FRAME, SCU должен указать единственный SOP Instance UID элемента, из которого должен быть извлечён новый составной SOP-экземпляр, а также запрошенный список кадров (Requested Frame List). Requested Frame List должен быть построен согласно Разделу Y.3.2.

  • SCU должен принимать ответы C-MOVE со статусом Pending в процессе выполнения подопераций C-STORE. Эти ответы указывают количество оставшихся, завершённых, неудачных и предупреждающих подопераций C-STORE.

  • SCU должен интерпретировать ответ C-MOVE со статусом Success, Warning или Failure как финальный ответ. Финальный ответ указывает количество завершённых подопераций и количество неудачных подопераций C-STORE, возникших в результате операции C-MOVE. SCU должен интерпретировать статус:

    • Success — как указание, что все подоперации завершились успешно

    • Failure — как указание, что все подоперации завершились неуспешно

    • Warning — во всех остальных случаях. Для получения более подробной информации могут использоваться Number of Completed Sub-Operations (0000,1021), Number of Warning Sub-Operations (0000,1023), Number of Failed Sub-Operations (0000,1022).

  • SCU может отменить операцию C-MOVE, отправив запрос C-CANCEL-MOVE в любой момент в процессе выполнения запроса C-MOVE. Ответ C-MOVE со статусом Cancel должен указывать SCU, что получение было отменено. Опционально ответ C-MOVE со статусом Cancel должен указывать количество завершённых, неудачных и предупреждающих подопераций C-STORE. Если присутствует, счётчик оставшихся подопераций должен содержать количество подопераций C-STORE, не инициированных вследствие запроса C-CANCEL-MOVE.

Примечание

Для операций C-MOVE уровня FRAME приложение, принимающее подоперации C-STORE, получит новый SOP-экземпляр с SOP Instance UID, отличным от указанного в запросе C-MOVE. Если требуется связать полученный экземпляр с запросом, может потребоваться изучить Frame Extraction Sequence полученного экземпляра, чтобы сравнить исходный Instance UID и Requested Frame List с указанными в запросе.

Y.4.1.2.2 Расширенное поведение SCU

Расширенное поведение SCU должно соответствовать Разделу C.4.2.2.2, за исключением того, что реляционное получение (Relational-retrieve) не поддерживается.

Y.4.1.3 Поведение SCP для C-MOVE

Y.4.1.3.1 Базовое поведение SCP

SCP несёт следующую семантику с ответом C-MOVE:

  • Если Retrieve Level (0000,0052) равен IMAGE, SCP должен определить набор сущностей на уровне передачи на основе значений уникальных ключей в идентификаторе запроса C-MOVE.

  • Если Retrieve Level (0000,0052) равен FRAME, SCP должен создать новый составной экземпляр согласно правилам Раздела Y.3.2. С вновь созданным SOP-экземпляром следует обращаться так же, как с набором сущностей, указанным выше.

  • SCP должен либо повторно использовать установленную и совместимую ассоциацию, либо установить новую ассоциацию для подопераций C-STORE

  • SCP должен инициировать подоперации C-STORE в рамках ассоциации для идентифицированных или вновь созданных SOP-экземпляров.

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

  • Опционально SCP может генерировать ответы на C-MOVE со статусом Pending в процессе выполнения подопераций C-STORE. Эти ответы должны указывать количество оставшихся, завершённых, неудачных и предупреждающих подопераций C-STORE.

  • Когда количество оставшихся подопераций достигает нуля, SCP должен сгенерировать финальный ответ со статусом Success, Warning или Failure. Статус, содержащийся в ответе C-MOVE, должен содержать:

    • Success — если все подоперации завершились успешно

    • Failure — если все подоперации завершились неуспешно

    • Warning — во всех остальных случаях.

  • SCP может получить запрос C-CANCEL-MOVE в любой момент в процессе выполнения запроса C-MOVE. SCP должен прервать обработку всех подопераций C-STORE и вернуть статус Cancel в ответе C-MOVE. Ответ C-MOVE со статусом Cancel должен содержать количество завершённых, неудачных и предупреждающих подопераций C-STORE. Если присутствует, счётчик оставшихся подопераций должен содержать количество подопераций C-STORE, не инициированных вследствие запроса C-CANCEL-MOVE.

  • Если SCP управляет изображениями в нескольких альтернативных кодировках (см. Раздел C.6.1.1.5.1), в качестве исходного SOP-экземпляра, из которого извлекаются кадры, должна использоваться только одна из альтернативных кодировок изображения.

Y.4.1.3.2 Расширенное поведение SCP

Расширенное поведение SCP должно соответствовать Разделу C.4.2.3.2, за исключением того, что реляционное получение (Relational-retrieve) не поддерживается.

Y.4.2 Операция C-GET

SCU услуги Composite Instance Root Retrieve должны выполнять получение данных с использованием операции C-GET, как описано в PS3.7. Операция C-GET позволяет прикладному объекту дать указание другому прикладному объекту передать сохранённые SOP-экземпляры или новые SOP-экземпляры, производные от таких сохранённых SOP-экземпляров, инициирующему прикладному объекту с использованием операции C-STORE. Поддержка услуги C-GET должна быть согласована при установлении ассоциации как SCU, так и SCP C-GET, чтобы операция C-GET могла выполняться в рамках данной ассоциации. Подоперации C-STORE должны выполняться в рамках той же ассоциации, что и операция C-GET. Таким образом, SCP класса услуг запроса/получения выступает в роли SCU класса услуг хранения.

Примечание

Прикладной объект, получающий сохранённые SOP-экземпляры, всегда является инициатором операции C-GET.

Запрос C-GET может выполняться на любом уровне информационной модели Composite Instance Root Retrieve, и ожидаемое поведение SCP зависит от выбранного уровня.

Y.4.2.1 Параметры услуги C-GET

Y.4.2.1.1 SOP Class UID

SOP Class UID идентифицирует информационную модель запроса/получения, в отношении которой должен выполняться C-GET. Поддержка SOP Class UID подразумевается Abstract Syntax UID контекста представления, используемого данной операцией C-GET.

Y.4.2.1.2 Priority

Атрибут Priority определяет запрошенный приоритет операции C-GET и соответствующих подопераций C-STORE относительно других DIMSE-операций, выполняемых тем же SCP.

Обработка запросов приоритета не является обязательной для SCP. Поддерживает ли SCP обработку приоритета и смысл различных уровней приоритета должны быть указаны в заявлении о соответствии SCP. Один и тот же приоритет должен использоваться для всех подопераций C-STORE.

Y.4.2.1.3 Идентификатор

Запрос C-GET должен содержать идентификатор. Ответ C-GET должен условно содержать идентификатор согласно требованиям Раздела C.4.3.1.3.2.

Примечание

Идентификатор указан как U в определении примитива C-GET в PS3.7, но специализирован для использования с данной услугой.

Y.4.2.1.3.1 Структура идентификатора запроса

Идентификатор в запросе C-GET должен содержать:

  • Query/Retrieve Level (0008,0052), определяющий уровень получения

  • SOP Instance UID(s) (0008,0018)

  • Один из ключей диапазона кадров (Frame Range Keys), если он присутствует в информационной модели для уровня получения

  • Условно, атрибут Query/Retrieve View (0008,0053). Этот атрибут может быть включён, если Enhanced Multi-Frame Image Conversion было согласовано в процессе расширенного согласования ассоциации. В противном случае он не должен включаться.

Specific Character Set (0008,0005) не должен присутствовать.

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

Y.4.2.1.4 Статус

Значения кодов состояния, которые могут возвращаться в ответе C-GET, должны соответствовать Таблице Y.4-2

Table Y.4-2. C-GET Response Status Values for Composite Instance Root Retrieve

Статус службы

Дополнительное значение

Status Codes

Связанные поля

Failure

Отказано: нехватка ресурсов — невозможно вычислить количество совпадений

A701

(0000,0902)

Отказано: нехватка ресурсов — невозможно выполнить подоперации

A702

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)

Ошибка: набор данных не соответствует SOP-классу

A900

(0000,0901)

(0000,0902)

Ошибка: невозможно обработать

Cxxx

(0000,0901)

(0000,0902)

Ошибка: ни один из запрошенных кадров не найден в SOP-экземпляре

AA00

(0000,0902)

Ошибка: невозможно создать новый объект для данного SOP-класса

AA01

(0000,0902)

Ошибка: невозможно извлечь кадры

AA02

(0000,0902)

Ошибка: получен запрос по времени для исходного SOP-экземпляра, не являющегося временны́м.

AA03

(0000,0902)

Ошибка: недопустимый запрос

AA04

(0000,0901)

(0000,0902)

Cancel

Подоперации прерваны вследствие индикации отмены (Cancel)

FE00

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)

Warning

Подоперации завершены — есть один или более сбоев или предупреждений

B000

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)

Success

Подоперации завершены — сбоев и предупреждений нет

0000

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)

Pending

Подоперации продолжаются

FF00

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)


Y.4.2.1.5 Number of Remaining Sub-Operations

Включение Number of Remaining Sub-Operations должно осуществляться согласно Разделу C.4.3.1.5

Y.4.2.1.6 Number of Completed Sub-Operations

Включение Number of Completed Sub-Operations должно осуществляться согласно Разделу C.4.3.1.6

Y.4.2.1.7 Number of Failed Sub-Operations

Включение Number of Failed Sub-Operations должно осуществляться согласно Разделу C.4.3.1.7

Y.4.2.1.8 Number of Warning Sub-Operations

Включение Number of Warning Sub-Operations должно осуществляться согласно Разделу C.4.3.1.8.

Y.4.2.2 Поведение SCU для C-GET

Y.4.2.2.1 Базовое поведение SCU

SCU несёт следующую семантику с запросом C-GET:

  • Если Retrieve Level (0000,0052) равен IMAGE, SCU должен указать один SOP Instance UID или список SOP Instance UID.

  • Если Retrieve Level (0000,0052) равен FRAME, SCU должен указать единственный SOP Instance UID элемента, из которого должен быть извлечён новый составной SOP-экземпляр, а также Requested Frame List. Requested Frame List должен быть построен как список кадров согласно Разделу Y.3.2.

  • SCU должен предложить достаточное количество контекстов представления при установлении ассоциации, чтобы обеспечить ожидаемые подоперации C-STORE, выполняемые в рамках той же ассоциации. SCU класса услуг запроса/получения должен выступать в роли SCP класса услуг хранения.

  • SCU должен принимать ответы C-GET со статусом Pending в процессе выполнения подопераций C-STORE. Эти ответы указывают количество оставшихся, завершённых, неудачных и предупреждающих подопераций C-STORE.

  • SCU должен интерпретировать ответ C-GET со статусом Success, Warning или Failure как финальный ответ. Финальный ответ указывает количество завершённых подопераций и количество неудачных подопераций C-STORE, возникших в результате операции C-GET. SCU должен интерпретировать статус:

    • Success — как указание, что все подоперации завершились успешно

    • Failure — как указание, что все подоперации завершились неуспешно

    • Warning — во всех остальных случаях. Для получения более подробной информации могут использоваться Number of Completed Sub-Operations (0000,1021), Number of Warning Sub-Operations (0000,1023), Number of Failed Sub-Operations (0000,1022).

  • SCU может отменить операцию C-GET, отправив запрос C-CANCEL-GET в любой момент в процессе выполнения запроса C-GET. Ответ C-GET со статусом Cancel должен указывать SCU, что получение было отменено. Опционально ответ C-GET со статусом Cancel должен указывать количество завершённых, неудачных и предупреждающих подопераций C-STORE. Если присутствует, счётчик оставшихся подопераций должен содержать количество подопераций C-STORE, не инициированных вследствие запроса C-CANCEL-GET.

Y.4.2.2.2 Расширенное поведение SCU

Расширенное поведение SCU должно соответствовать Разделу C.4.3.2.2, за исключением того, что реляционное получение (Relational-retrieve) не поддерживается.

Y.4.2.3 Поведение SCP для C-GET

Y.4.2.3.1 Базовое поведение SCP

SCP несёт следующую семантику с ответом C-GET:

  • Если Retrieve Level (0000,0052) равен IMAGE, SCP должен определить набор сущностей на уровне передачи на основе значений уникальных ключей в идентификаторе запроса C-GET.

  • Если Retrieve Level (0000,0052) равен FRAME, SCP должен создать новый составной экземпляр согласно правилам Раздела Y.3.3. С вновь созданным SOP-экземпляром следует обращаться так же, как с набором сущностей, указанным выше.

  • SCP должен инициировать подоперации C-STORE для идентифицированных или вновь созданных SOP-экземпляров. SCP класса услуг запроса/получения должен выступать в роли SCU класса услуг хранения.

  • SCP должен инициировать подоперации C-STORE в рамках той же ассоциации для всех идентифицированных или вновь созданных SOP-экземпляров, указанных в запросе C-GET.

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

  • Подоперация считается неудачной (Failure), если SCP не может инициировать подоперацию C-STORE, поскольку SCU класса услуг запроса/получения не предложил подходящий контекст представления для данного сохранённого SOP-экземпляра.

  • Опционально SCP может генерировать ответы на C-GET со статусом Pending в процессе выполнения подопераций C-STORE. Эти ответы должны указывать количество оставшихся, завершённых, неудачных и предупреждающих подопераций C-STORE.

  • Когда количество оставшихся подопераций достигает нуля, SCP должен сгенерировать финальный ответ со статусом Success, Warning или Failure. Статус, содержащийся в ответе C-GET, должен содержать:

    • Success — если все подоперации завершились успешно

    • Failure — если все подоперации завершились неуспешно

    • Warning — во всех остальных случаях.

  • SCP может получить запрос C-CANCEL-GET в любой момент в процессе выполнения запроса C-GET. SCP должен прервать обработку всех подопераций C-STORE и вернуть статус Cancel в ответе C-GET. Ответ C-GET со статусом Cancel должен содержать количество завершённых, неудачных и предупреждающих подопераций C-STORE. Если присутствует, счётчик оставшихся подопераций должен содержать количество подопераций C-STORE, не инициированных вследствие запроса C-CANCEL-GET.

  • Если SCP управляет изображениями в нескольких альтернативных кодировках (см. Раздел C.6.1.1.5.1), в качестве исходного SOP-экземпляра, из которого извлекаются кадры, должна использоваться только одна из альтернативных кодировок изображения.

Y.4.2.3.2 Расширенное поведение SCP

Расширенное поведение SCP должно соответствовать Разделу C.4.3.3.2, за исключением того, что реляционное получение (Relational-retrieve) не поддерживается.

Y.5 Согласование ассоциации

Установление ассоциации — это первая фаза любого экземпляра взаимодействия между равноправными DICOM AE. AE, поддерживающие SOP-классы DICOM Query/Retrieve, используют согласование при установлении ассоциации, определяя использование информации ассоциации приложения (Application Association Information). Обзор согласования ассоциации см. в PS3.7.

SOP-классы услуги Composite Instance Root Retrieve, включающие услуги получения на основе операций C-MOVE и C-GET, используют подэлемент выбора ролей SCP/SCU (SCP/SCU Role Selection Sub-Item) для идентификации SOP-классов, которые могут использоваться для получения.

Y.5.1 Согласование ассоциации для SOP-классов C-MOVE и C-GET

Правила указаны в Разделе C.5.3, за исключением того, что подэлемент расширенного согласования (Extended Negotiation), если используется, должен использоваться так, как определено в Разделе Y.5.1.1.

Примечание

  1. Хотя преобразованные изображения могут быть указаны по их SOP Instance UID в идентификаторе запроса, который всегда находится на уровне экземпляра или ниже, сохраняется необходимость расширенного согласования и указания Query/Retrieve View, чтобы обеспечить сохранение ссылочной целостности в возвращаемых SOP-экземплярах (например, чтобы ссылка на SOP Instance UID указывала на преобразованное изображение или нет, в зависимости от ситуации).

  2. Реляционное получение (Relational-retrieval) неприменимо к данным SOP-классам, поэтому подэлемент расширенного согласования не включает использование этого байта.

Y.5.1.1 Расширенное согласование SOP-класса

Расширенное согласование SOP-класса позволяет равноправным DICOM AE при установлении ассоциации обмениваться информацией ассоциации приложения, определённой конкретными SOP-классами. Это достигается путём определения поля service-class-application-information. Поле service-class-application-information используется для определения поддержки Enhanced Multi-Frame Image Conversion.

Данное согласование не является обязательным. Если оно отсутствует, по умолчанию действует следующее условие:

  • поддержка Enhanced Multi-Frame Image Conversion отсутствует

Инициатор ассоциации (Association-requestor) может использовать по одному подэлементу расширенного согласования SOP-класса на каждый SOP-класс. SOP-класс идентифицируется соответствующим именем абстрактного синтаксиса (Abstract Syntax Name, как определено в PS3.7), за которым следует поле service-class-application-information. Это поле определяет:

  • поддержку Enhanced Multi-Frame Image Conversion инициатором ассоциации

Получатель ассоциации (Association-acceptor) для каждого предложенного подэлемента расширенного согласования SOP-класса либо принимает предложение инициатора ассоциации, вернув то же значение (1), либо отклоняет предложение, вернув значение (0).

Если подэлемент расширенного согласования SOP-класса не возвращён получателем ассоциации, поддержка Enhanced Multi-Frame Image Conversion отсутствует (условие по умолчанию).

Если подэлементы расширенного согласования SOP-класса отсутствуют в индикации A-ASSOCIATE, они должны быть опущены в ответе A-ASSOCIATE.

Y.5.1.1.1 Структура подэлемента расширенного согласования SOP-класса (A-ASSOCIATE-RQ)

Подэлемент расширенного согласования SOP-класса состоит из последовательности обязательных полей, определённых в PS3.7. Таблица Y.5.1-1 определяет поле service-class-application-information для операций C-MOVE и C-GET.

Table Y.5.1-1. SOP Class Extended Negotiation Sub-Item (Service-Class-Application-Information Field) - A-ASSOCIATE-RQ

Байты элемента

Имя поля

Описание поля

1

Unused

Резерв — должен быть 0

2

Enhanced Multi-Frame Image Conversion

Это байтовое поле определяет, должен ли атрибут Query/Retrieve View (0008,0053) использоваться для корректировки представления, возвращаемого в запросах, с учётом преобразования в Enhanced Multi-Frame Image или из него. Оно должно кодироваться как беззнаковое двоичное целое число и должно принимать одно из следующих значений

0 — Query/Retrieve View не поддерживается

1 — Query/Retrieve View поддерживается


Y.5.1.1.2 Структура подэлемента расширенного согласования SOP-класса (A-ASSOCIATE-AC)

Подэлемент расширенного согласования SOP-класса состоит из последовательности обязательных полей, определённых в PS3.7. Таблица Y.5.1-2 определяет поле service-class-application-information для операций C-MOVE и C-GET.

Table Y.5.1-2. SOP Class Extended Negotiation Sub-Item (Service-Class-Application-Information Field) - A-ASSOCIATE-AC

Байты элемента

Имя поля

Описание поля

1

Unused

Резерв — не должен проверяться.

2

Enhanced Multi-Frame Image Conversion

Это байтовое поле определяет, должен ли атрибут Query/Retrieve View (0008,0053) использоваться для корректировки представления, возвращаемого в запросах, с учётом преобразования в Enhanced Multi-Frame Image или из него. Оно должно кодироваться как беззнаковое двоичное целое число и должно принимать одно из следующих значений

0 — Query/Retrieve View не поддерживается

1 — Query/Retrieve View поддерживается


Y.6 Определения SOP-классов

Y.6.1 Группа SOP-классов Composite Instance Root

В информационной модели Composite Instance Root Retrieve Only информация организована в два уровня, соответствующих одному из двух значений элемента (0008,0052), показанных в Таблице Y.6.1-1.

Table Y.6.1-1. Retrieve Level Values for Composite Instance Root Retrieve

Retrieve Level

Значение в (0008,0052)

Composite Instance

IMAGE

Frame

FRAME


Примечание

Использование слова «IMAGE», а не «Composite Instance», обусловлено историческими причинами для обеспечения обратной совместимости с предыдущими редакциями Стандарта. Это не следует понимать так, что составные экземпляры (Composite Instances) типов, отличных от изображения, не включаются на уровне, обозначаемом значением IMAGE.

Y.6.1.1 Информационная модель Composite Instance Root Retrieve Only

Y.6.1.1.1 Модель E/R

Информационная модель Composite Instance Root Retrieve Only может быть представлена диаграммой «сущность-связь», показанной на Рисунке Y.6-1

Composite Instance Root Retrieve Information Model E-R Diagram

Figure Y.6-1. Composite Instance Root Retrieve Information Model E-R Diagram


Y.6.1.1.2 Уровень Composite Instance

Table Y.6-1 defines the keys at the Composite Instance level of the Composite Instance Root Query/Retrieve Information model.

Table Y.6-1. Composite Instance Level Keys for the Composite Instance Root Retrieve Information Model

Имя атрибута

Tag

Тип ключа сопоставления

SOP Instance UID

(0008,0018)

U


Y.6.1.1.3 Уровень Frame

Table Y.6-2 defines the keys at the Frame level of the Composite Instance Root Query/Retrieve Information Model. One and only one of the frame level keys listed in Table Y.6-2 shall be present in a FRAME level request

Table Y.6-2. Frame Level Keys for the Composite Instance Root Retrieve Information Model

Имя атрибута

Tag

Condition

Simple Frame List

(0008,1161)

Обязателен, если Calculated Frame List и Time Range отсутствуют

Calculated Frame List

(0008,1162)

Обязателен, если Simple Frame List и Approximate Frame Range отсутствуют

Time Range

(0008,1163)

Обязателен, если Simple Frame List и Calculated Frame List отсутствуют


Y.6.1.1.4 Область действия команд и подопераций C-MOVE и C-GET

Запрос C-MOVE или C-GET может выполняться на любом уровне модели запроса/получения. C-MOVE или C-GET, для которого уровень запроса/получения:

IMAGE — означает, что должны быть переданы выбранные отдельные составные экземпляры (Composite Instances)

FRAME — означает, что должен быть создан и передан единственный новый составной экземпляр

Примечание

Может быть получена более чем одна сущность, если Query/Retrieve Level равен IMAGE, с использованием сопоставления по списку UID; но если Query/Retrieve Level равен FRAME, может быть получена только одна сущность.

Y.6.1.2 Требования соответствия

Реализация может соответствовать одному из SOP-классов Composite Instance Root Retrieve в роли SCU, SCP или обеих ролей. Заявление о соответствии должно быть оформлено в формате, определённом в PS3.2.

Y.6.1.2.1 Соответствие SCU
Y.6.1.2.1.1 Соответствие SCU для C-MOVE

Реализация, соответствующая одному из SOP-классов Composite Instance Root Retrieve в роли SCU, должна поддерживать передачу данных в отношении информационной модели получения, описанной в Разделе Y.6.1.1, с использованием поведения SCU C-MOVE, описанного в Разделе Y.4.1.2. Реализация, соответствующая одному из SOP-классов группы SOP-классов Composite Instance Root в роли SCU и генерирующая получение данных с использованием операции C-MOVE, должна указать в своём заявлении о соответствии SOP-классы класса услуг хранения, в рамках которых она поддерживает подоперации C-STORE, порождаемые C-MOVE.

Y.6.1.2.1.2 Соответствие SCU для C-GET

Реализация, соответствующая одному из SOP-классов Composite Instance Root Retrieve в роли SCU, должна поддерживать получение данных в отношении информационной модели получения, описанной в Разделе Y.6.1.1, с использованием поведения SCU C-GET, описанного в Разделе Y.4.2.2. Реализация, соответствующая одному из SOP-классов группы SOP-классов Composite Instance Root в роли SCU и генерирующая получение данных с использованием операции C-GET, должна указать в своём заявлении о соответствии SOP-классы класса услуг хранения, в рамках которых она поддерживает подоперации C-STORE, порождаемые C-GET.

Y.6.1.2.2 Соответствие SCP

Реализация, соответствующая одному из SOP-классов Composite Instance Root Retrieve в роли SCP для операций C-GET, должна: 1) поддерживать оба уровня информационной модели Composite Instance Root Retrieve Only

2) поддерживать все три ключа уровня Frame

3) описать в своём заявлении о соответствии преобразования, которые она применяет к многокадровому составному экземпляру при создании нового составного экземпляра, как определено в Разделе Y.3.3.

Y.6.1.2.2.1 Соответствие SCP для C-MOVE

Реализация, соответствующая одному из SOP-классов Composite Instance Root Retrieve в роли SCP, должна поддерживать получение данных на обоих уровнях информационной модели получения, описанной в Разделе Y.6.1.1, с использованием поведения SCP C-MOVE, описанного в Разделе Y.4.1.3. Реализация, соответствующая одному из SOP-классов группы SOP-классов Composite Instance Root в роли SCP и удовлетворяющая запросы получения с использованием операции C-MOVE, должна указать в своём заявлении о соответствии SOP-классы класса услуг хранения, в рамках которых она поддерживает подоперации C-STORE, порождаемые C-MOVE.

Y.6.1.2.2.2 Соответствие SCP для C-GET

Реализация, соответствующая одному из SOP-классов Composite Instance Root Retrieve в роли SCP, должна поддерживать получение данных на обоих уровнях информационной модели получения, описанной в Разделе Y.6.1.1, с использованием поведения SCP C-GET, описанного в Разделе Y.4.2.3. Реализация, соответствующая одному из SOP-классов группы SOP-классов Composite Instance Root в роли SCP и удовлетворяющая запросы получения с использованием операции C-GET, должна указать в своём заявлении о соответствии SOP-классы класса услуг хранения, в рамках которых она поддерживает подоперации C-STORE, порождаемые C-GET.

Y.6.1.3 SOP-классы

SOP-классы группы SOP-классов Composite Instance Root класса услуг запроса/получения идентифицируют информационную модель Composite Instance Root Retrieve Only и поддерживаемые операции DIMSE-C. Стандартные SOP-классы перечислены в Таблице Y.6.1.3-1.

Table Y.6.1.3-1. SOP Classes for Composite Instance Root Retrieve

Имя SOP-класса

SOP Class UID

Composite Instance Root Retrieve - MOVE

1.2.840.10008.5.1.4.1.2.4.2

Composite Instance Root Retrieve - GET

1.2.840.10008.5.1.4.1.2.4.3


Z Класс сервиса извлечения композитного экземпляра без объёмных данных

Z.1 Обзор

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

Служба извлечения композитного экземпляра без объёмных данных (Composite Instance Retrieve Without Bulk Data) — это служба в составе класса услуг DICOM «Запрос/получение» (Query/Retrieve), определённого в Приложении C. Возможность получения, предоставляемая данной службой, позволяет прикладному объекту DICOM (AE) получать композитные экземпляры без их пиксельных данных или других потенциально больших атрибутов, определённых в Разделе Z.1.3.

Опция расширенного согласования Enhanced Multi-Frame Image Conversion класса услуг DICOM «Запрос/получение», определённого в Приложении C, также поддерживается для службы извлечения композитного экземпляра без объёмных данных.

Z.1.2 Информационная модель извлечения композитного экземпляра без объёмных данных

Получение выполняется в отношении информационной модели извлечения композитного экземпляра без объёмных данных, определённой в данном Приложении стандарта DICOM. Конкретный SOP-класс класса услуг «Запрос/получение» состоит из определения информационной модели и группы услуг DIMSE-C.

Z.1.3 Не включённые атрибуты

Атрибуты, которые не должны включаться на верхнем уровне набора данных, отправляемого SCP данной службы, определены в Таблице Z.1-1

Table Z.1-1. Attributes Not to Be Included in Instances Sent

Имя атрибута

Tag

Pixel Data

(7FE0,0010)

Float Pixel Data

(7FE0,0008)

Double Float Pixel Data

(7FE0,0009)

Pixel Data Provider URL

(0028,7FE0)

Spectroscopy Data

(5600,0020)

Overlay Data

(60xx,3000)

Curve Data

(50xx,3000)

Audio Sample Data

(50xx,200C)

Encapsulated Document

(0042,0011)


Примечание

Это подразумевает, что пиксельные данные внутри элементов Icon Image Sequence (0088,0200) будут сохранены.

Атрибут Waveform Data (5400,1010) не должен включаться внутри Waveform Sequence (5400,0100).

Приватные атрибуты могут сохраняться или отбрасываться SCP службы хранения, как определено в Разделе B.4.1. SCP службы хранения, заявляющий соответствие уровню хранения 2 (полный) класса услуг хранения, может по своему усмотрению возвращать приватные атрибуты в службе извлечения без объёмных данных или нет. Возвращаются ли конкретные приватные атрибуты, должно быть документировано в заявлении о соответствии.

Примечание

Решение о том, возвращать ли конкретный приватный атрибут, может зависеть от его размера.

Z.1.4 Определение сервиса

Два равноправных прикладных объекта DICOM (AE) реализуют SOP-класс службы извлечения композитного экземпляра без объёмных данных, при этом один выступает в роли SCU, а другой — в роли SCP. SOP-классы службы извлечения композитного экземпляра без объёмных данных реализуются с использованием услуги DIMSE-C C-GET, как определено в PS3.7.

Приведённые ниже описания услуги DIMSE-C C-GET дают краткий обзор семантики SCU/SCP:

  1. Услуга C-GET несёт следующую семантику:

    • SCP должен определить набор сущностей на уровне получения на основе значений уникальных ключей в идентификаторе запроса C-GET. Затем SCP должен сгенерировать подоперации C-STORE для соответствующих сохранённых SOP-экземпляров, но не должен включать в отправляемые в ходе этих подопераций данные атрибуты, описанные в Разделе Z.1.3. Эти подоперации C-STORE выполняются в рамках той же ассоциации, что и услуга C-GET, при этом роли SCU/SCP для C-STORE меняются местами.

      Примечание

      Если исходный экземпляр не содержит ни одного из атрибутов, описанных в Разделе Z.1.3, то версия, отправленная посредством подоперации C-STORE, будет идентична исходным данным. Это не является ошибкой.

    • SCP может опционально генерировать ответы на C-GET со статусом Pending в процессе выполнения подопераций C-STORE. Эти ответы C-GET указывают количество оставшихся подопераций C-STORE и количество подопераций C-STORE, вернувших статус Success, Warning и Failure.

    • Когда количество оставшихся подопераций C-STORE достигает нуля, SCP генерирует финальный ответ со статусом Success, Warning или Failure. Этот ответ должен указывать количество подопераций C-STORE, вернувших статус Success, Warning и Failure. Если статус какой-либо подоперации C-STORE был Failure, должен быть возвращён список UID.

    • SCU может отменить услугу C-GET, отправив запрос C-CANCEL-GET в любой момент в процессе выполнения C-GET. SCP прерывает все незавершённые подоперации C-STORE и возвращает статус Cancel.

Z.2 Определение информационной модели извлечения композитного экземпляра без объёмных данных

Информационная модель извлечения композитного экземпляра без объёмных данных идентифицируется SOP-классом, согласованным при установлении ассоциации. SOP-класс состоит как из информационной модели, так и из группы услуг DIMSE-C.

Примечание

Этот SOP-класс идентифицирует класс информационной модели извлечения композитного экземпляра без объёмных данных (то есть не SOP-класс сохранённых SOP-экземпляров, о которых располагает информацией SCP).

Определения информационной модели для стандартных SOP-классов службы извлечения композитного экземпляра без объёмных данных определены в данном Приложении. Определение информационной модели извлечения композитного экземпляра без объёмных данных содержит:

  • Определение модели «сущность-связь»

  • Определение ключевых атрибутов

Z.2.1 Определение модели «сущность-связь»

Для любой информационной модели извлечения композитного экземпляра без объёмных данных модель «сущность-связь» определяет иерархию сущностей с атрибутами, определёнными для каждого уровня иерархии (например, Composite Instance, Frame).

Z.2.2 Определение атрибутов

Атрибуты и сопоставление должны соответствовать Разделу C.2.2

Z.3 Стандартная информационная модель извлечения композитного экземпляра без объёмных данных

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

  • Retrieve Without Bulk Data

Z.3.1 Информационная модель извлечения композитного экземпляра без объёмных данных

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

  • Composite Instance

Информационная модель извлечения без объёмных данных может быть представлена диаграммой «сущность-связь», показанной на Рисунке Z.3.1-1.

Retrieve Without Bulk Data Information Model E-R Diagram

Figure Z.3.1-1. Retrieve Without Bulk Data Information Model E-R Diagram


Уровень Composite Instance является единственным уровнем и содержит только SOP Instance UID.

Z.4 Группы сервисов DIMSE-C

Для построения SOP-классов службы извлечения композитного экземпляра без объёмных данных используется единственная услуга DIMSE-C. Используется следующая операция DIMSE-C:

  • C-GET

Z.4.1 Не используется

Z.4.2 Операция C-GET

SCU службы извлечения композитного экземпляра без объёмных данных должны выполнять получение с использованием операции C-GET, как описано в PS3.7. Операция C-GET позволяет прикладному объекту дать указание другому прикладному объекту передать SOP-экземпляры без атрибутов, описанных в Разделе Z.1.3, инициирующему прикладному объекту с использованием операции C-STORE. Поддержка услуги C-GET должна быть согласована при установлении ассоциации как SCU, так и SCP C-GET, чтобы операция C-GET могла выполняться в рамках данной ассоциации. Подоперации C-STORE должны выполняться в рамках той же ассоциации, что и операция C-GET. Таким образом, SCP класса услуг запроса/получения выступает в роли SCU класса услуг хранения.

Примечание

Прикладной объект, получающий сохранённые SOP-экземпляры, всегда является инициатором операции C-GET.

Z.4.2.1 Параметры службы C-GET

Z.4.2.1.1 UID SOP-класса

SOP Class UID идентифицирует информационную модель запроса/получения, в отношении которой должен выполняться C-GET. Поддержка SOP Class UID подразумевается Abstract Syntax UID контекста представления, используемого данной операцией C-GET.

Z.4.2.1.2 Приоритет

Атрибут Priority определяет запрошенный приоритет операции C-GET и соответствующих подопераций C-STORE относительно других DIMSE-операций, выполняемых тем же SCP.

Обработка запросов приоритета не является обязательной для SCP. Поддерживает ли SCP обработку приоритета и смысл различных уровней приоритета должны быть указаны в заявлении о соответствии SCP. Один и тот же приоритет должен использоваться для всех подопераций C-STORE.

Z.4.2.1.3 Идентификатор

Запрос C-GET должен содержать идентификатор. Ответ C-GET должен условно содержать идентификатор согласно требованиям Раздела C.4.3.1.3.2.

Примечание

Идентификатор указан как U в определении примитива C-GET в PS3.7, но специализирован для использования с данной услугой.

Z.4.2.1.3.1 Структура идентификатора запроса

Идентификатор в запросе C-GET должен содержать:

  • Query/Retrieve Level (0008,0052), определяющий уровень получения

  • SOP Instance UID(s) (0008,0018)

  • Условно, атрибут Query/Retrieve View (0008,0053). Этот атрибут может быть включён, если Enhanced Multi-Frame Image Conversion было согласовано в процессе расширенного согласования ассоциации. В противном случае он не должен включаться.

Query/Retrieve Level (0008,0052) должен быть IMAGE.

Specific Character Set (0008,0005) не должен присутствовать.

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

Z.4.2.1.4 Состояние

Таблица Z.4-1 определяет значения кодов состояния, которые могут возвращаться в ответе C-GET. Общие значения кодов состояния и поля, связанные со значениями кодов состояния, определены для услуги DIMSE C-GET в PS3.7.

Table Z.4-1. C-GET Response Status Values for Composite Instance Retrieve Without Bulk Data

Статус службы

Дополнительное значение

Коды состояния

Связанные поля

Failure

Отказано: нехватка ресурсов — невозможно вычислить количество совпадений

A701

(0000,0902)

Отказано: нехватка ресурсов — невозможно выполнить подоперации

A702

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)

Ошибка: набор данных не соответствует SOP-классу

A900

(0000,0901)

(0000,0902)

Ошибка: невозможно обработать

Cxxx

(0000,0901)

(0000,0902)

Cancel

Подоперации прерваны вследствие индикации отмены (Cancel)

FE00

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)

Warning

Подоперации завершены — есть один или более сбоев или предупреждений

B000

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)

Success

Подоперации завершены — сбоев и предупреждений нет

0000

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)

Pending

Подоперации продолжаются

FF00

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)


Некоторые коды состояния Failure зависят от реализации.

Реализация SCP должна назначать конкретные коды состояния Failure, заменяя каждый символ 'x' шестнадцатеричной цифрой в диапазоне от 0 до F. Реализация SCP, желающая различать причины значения Failure «Ошибка: невозможно обработать», должна назначать этим причинам конкретные значения кодов состояния в пределах допустимого диапазона, указанного в Таблице Y.4-2.

Реализация SCU должна распознавать любой код состояния Failure в пределах диапазона значений, указанного в Таблице Y.4-2, как индикатор значения Failure, указанного в таблице. Требование различать конкретные коды состояния в пределах допустимого диапазона для реализации SCU отсутствует.

Z.4.2.1.5 Количество оставшихся подопераций

Включение Number of Remaining Sub-Operations должно осуществляться согласно Разделу C.4.3.1.5

Z.4.2.1.6 Количество завершённых подопераций

Включение Number of Completed Sub-Operations должно осуществляться согласно Разделу C.4.3.1.6

Z.4.2.1.7 Количество неудачных подопераций

Включение Number of Failed Sub-Operations должно осуществляться согласно Разделу C.4.3.1.7

Z.4.2.1.8 Количество подопераций с предупреждением

Включение Number of Warning Sub-Operations должно осуществляться согласно Разделу C.4.3.1.8.

Z.4.2.2 Поведение SCU C-GET и SCP C-STORE

Z.4.2.2.1 Базовое поведение SCU

SCU несёт следующую семантику с запросом C-GET:

  • SCU должен указать один Instance UID или список Instance UID.

  • SCU должен предложить достаточное количество контекстов представления при установлении ассоциации, чтобы обеспечить ожидаемые подоперации C-STORE, выполняемые в рамках той же ассоциации. SCU класса услуг запроса/получения должен выступать в роли SCP класса услуг хранения.

  • SCP класса услуг хранения не должен сохранять неполный SOP-экземпляр; поведение в этом случае определяется реализацией.

  • SCU должен принимать ответы C-GET со статусом Pending в процессе выполнения подопераций C-STORE. Эти ответы указывают количество оставшихся, завершённых, неудачных и предупреждающих подопераций C-STORE.

  • SCU должен интерпретировать ответ C-GET со статусом Success, Warning или Failure как финальный ответ. Финальный ответ указывает количество завершённых подопераций и количество неудачных подопераций C-STORE, возникших в результате операции C-GET. SCU должен интерпретировать статус:

    • Success — как указание, что все подоперации завершились успешно

    • Failure — как указание, что все подоперации завершились неуспешно

    • Warning — во всех остальных случаях. Для получения более подробной информации могут использоваться Number of Completed Sub-Operations (0000,1021), Number of Warning Sub-Operations (0000,1023), Number of Failed Sub-Operations (0000,1022).

  • SCU может отменить операцию C-GET, отправив запрос C-CANCEL-GET в любой момент в процессе выполнения запроса C-GET. Ответ C-GET со статусом Cancel должен указывать SCU, что получение было отменено. Опционально ответ C-GET со статусом Cancel должен указывать количество завершённых, неудачных и предупреждающих подопераций C-STORE. Если присутствует, счётчик оставшихся подопераций должен содержать количество подопераций C-STORE, не инициированных вследствие запроса C-CANCEL-GET.

  • SCP класса услуг хранения не должен возвращать код состояния A9xxH «Ошибка: набор данных не соответствует SOP-классу» или B007 «Предупреждение: набор данных не соответствует SOP-классу» из-за отсутствия атрибутов, описанных в Разделе Z.1.3.

Z.4.2.2.2 Расширенное поведение SCU

Расширенное поведение SCU должно соответствовать Разделу C.4.3.2.2, за исключением того, что реляционное получение (Relational-retrieve) не поддерживается.

Z.4.2.3 Поведение SCP C-GET и SCU C-STORE

Z.4.2.3.1 Базовое поведение SCP

SCP несёт следующую семантику с ответом C-GET:

  • SCP должен определить набор сущностей на уровне передачи на основе значений уникальных ключей в идентификаторе запроса C-GET.

  • SCP должен инициировать подоперации C-STORE для идентифицированных SOP-экземпляров, но не должен включать в эту подоперацию C-STORE атрибуты, описанные в Разделе Z.1.3. SCP класса услуг запроса/получения должен выступать в роли SCU класса услуг хранения.

  • За исключением атрибутов, перечисленных в Разделе Z.1.3, SOP-экземпляр, отправляемый посредством подоперации C-STORE, должен оставаться неизменным, и никакие соответствующие изменения других атрибутов не должны вноситься.

Примечание

В частности, Study, Series и SOP Instance UID, а также SOP Class UID изменяться не будут.

  • SCP должен инициировать подоперации C-STORE в рамках той же ассоциации для всех SOP-экземпляров, указанных в запросе C-GET.

  • Подоперация считается неудачной (Failure), если SCP не может инициировать подоперацию C-STORE, поскольку SCU класса услуг запроса/получения не предложил подходящий контекст представления для данного сохранённого SOP-экземпляра.

  • Опционально SCP может генерировать ответы на C-GET со статусом Pending в процессе выполнения подопераций C-STORE. Эти ответы должны указывать количество оставшихся, завершённых, неудачных и предупреждающих подопераций C-STORE.

  • Когда количество оставшихся подопераций достигает нуля, SCP должен сгенерировать финальный ответ со статусом Success, Warning или Failure. Статус, содержащийся в ответе C-GET, должен содержать:

    • Success — если все подоперации завершились успешно

    • Failure — если все подоперации завершились неуспешно

    • Warning — во всех остальных случаях.

  • SCP может получить запрос C-CANCEL-GET в любой момент в процессе выполнения запроса C-GET. SCP должен прервать обработку всех подопераций C-STORE и вернуть статус Cancel в ответе C-GET. Ответ C-GET со статусом Cancel должен содержать количество завершённых, неудачных и предупреждающих подопераций C-STORE. Если присутствует, счётчик оставшихся подопераций должен содержать количество подопераций C-STORE, не инициированных вследствие запроса C-CANCEL-GET.

  • Если SCP управляет изображениями в нескольких альтернативных кодировках (см. Раздел C.6.1.1.5.1), в качестве исходного SOP-экземпляра, из которого извлекаются кадры, должна использоваться только одна из альтернативных кодировок изображения.

Z.4.2.3.2 Расширенное поведение SCP

Расширенное поведение SCP должно соответствовать Разделу C.4.3.3.2, за исключением того, что реляционное получение (Relational-retrieve) не поддерживается.

Z.5 Согласование ассоциации

Установление ассоциации является первой фазой любого сеанса взаимодействия между равноправными прикладными объектами DICOM. Прикладные объекты, поддерживающие SOP-классы DICOM «Запрос/получение», используют согласование при установлении ассоциации, определяя использование информации о прикладной ассоциации. См. обзор согласования ассоциации в PS3.7.

SOP-классы службы извлечения композитного экземпляра без объёмных данных, которые включают услуги получения на основе операции C-GET, используют подэлемент выбора роли SCP/SCU (SCP/SCU Role Selection Sub-Item) для идентификации SOP-классов, которые могут использоваться для получения.

Z.5.1 Согласование ассоциации для SOP-классов C-GET

Правила соответствуют указанным в Разделе C.5.3, за исключением того, что подэлемент расширенного согласования, если он используется, должен использоваться, как определено в Разделе Y.5.1.1.

Примечание

  1. Хотя преобразованные изображения могут быть указаны по их SOP Instance UID в идентификаторе запроса, который всегда находится на уровне экземпляра, сохраняется потребность в расширенном согласовании и указании Query/Retrieve View, чтобы обеспечить сохранение ссылочной целостности в возвращаемых SOP-экземплярах (например, чтобы было понятно, ссылается ли SOP Instance UID на преобразованное изображение или нет, в зависимости от ситуации).

  2. Реляционное получение (Relational-retrieval) неприменимо к данному SOP-классу, поэтому подэлемент расширенного согласования не включает использование этого байта.

Z.6 Определения SOP-классов

Z.6.1 Группа SOP-классов извлечения составных экземпляров без массивов данных

В информационной модели Composite Instance Retrieve Without Bulk Data Only используется только один уровень получения (Retrieve Level).

Таблица Z.6.1-1. Значение уровня получения для извлечения композитного экземпляра без объёмных данных

Retrieve Level

Значение в (0008,0052)

Composite Instance

IMAGE


Примечание

Использование слова «IMAGE», а не «Composite Instance», обусловлено историческими причинами для обеспечения обратной совместимости с предыдущими редакциями Стандарта. Это не следует понимать так, что композитные экземпляры типов, отличных от изображений, не включаются на уровне, обозначенном значением IMAGE.

Z.6.1.1 Информационная модель извлечения составных экземпляров без массивов данных

Z.6.1.1.1 Модель E/R

Информационная модель Composite Instance Retrieve Without Bulk Data Only имеет только один уровень: IMAGE.

Z.6.1.1.2 Уровень составного экземпляра

Таблица Z.6-1 определяет ключи на уровне Composite Instance информационной модели запроса/получения извлечения композитного экземпляра без объёмных данных.

Table Z.6-1. Composite Instance Level Keys for the Composite Instance Retrieve Without Bulk Data Information Model

Имя атрибута

Tag

Тип ключа сопоставления

SOP Instance UID

(0008,0018)

U


Z.6.1.1.3 Область применения команд C-GET и подопераций

Запрос C-GET может выполняться только на уровне IMAGE модели запроса/получения. C-GET указывает, что должны быть переданы выбранные отдельные композитные экземпляры без атрибутов объёмных данных.

Z.6.1.2 Требования к соответствию

Реализация может соответствовать одному из SOP-классов группы SOP-классов извлечения композитного экземпляра без объёмных данных в роли SCU, SCP или обеих ролях. Заявление о соответствии должно быть оформлено в формате, определённом в PS3.2.

Z.6.1.2.1 Соответствие SCU

Реализация, соответствующая одному из SOP-классов группы SOP-классов извлечения композитного экземпляра без объёмных данных в роли SCU, должна поддерживать получение в отношении информационной модели запроса/получения, описанной в Разделе Z.6.1.1, с использованием поведения SCU для C-GET, описанного в Разделе Z.4.2.2. Реализация, соответствующая одному из SOP-классов группы SOP-классов извлечения композитного экземпляра без объёмных данных в роли SCU и генерирующая получения с использованием операции C-GET, должна указать в своём заявлении о соответствии SOP-классы класса услуг хранения, в отношении которых она будет поддерживать подоперации C-STORE, генерируемые C-GET.

Z.6.1.2.2 Соответствие SCP

Реализация, соответствующая одному из SOP-классов группы SOP-классов извлечения композитного экземпляра без объёмных данных в роли SCP, должна поддерживать получение в отношении обоих уровней информационной модели получения, описанной в Разделе Z.6.1.1, с использованием поведения SCP для C-GET, описанного в Разделе Z.4.2.3. Реализация, соответствующая одному из SOP-классов группы SOP-классов извлечения композитного экземпляра без объёмных данных в роли SCP и удовлетворяющая получения с использованием операции C-GET, должна указать в своём заявлении о соответствии SOP-классы класса услуг хранения, в отношении которых она будет поддерживать подоперации C-STORE, генерируемые C-GET.

Z.6.1.3 SOP-классы

SOP-классы в группе SOP-классов извлечения композитного экземпляра без объёмных данных класса услуг «Запрос/получение» идентифицируют информационную модель Composite Instance Retrieve Without Bulk Data Only и поддерживаемые операции DIMSE-C. Стандартные SOP-классы перечислены в Таблице Z.6.1.3-1.

Table Z.6.1.3-1. SOP Classes for Composite Instance Retrieve Without Bulk Data

SOP Class Name

SOP Class UID

Composite Instance Retrieve Without Bulk Data - GET

1.2.840.10008.5.1.4.1.2.5.3


AA Ophthalmic Refractive Measurements Storage SOP Classes

AA.1 Scope

Refractive instruments are the most commonly used instruments in eye care. At present many of them have the capability for digital output, but their data is most often addressed by manual input into a paper or electronic record. Lensometry, Autorefraction, Keratometry, Subjective Refraction, and Visual Acuity Measurements Storage SOP Classes support devices such as lensometers, auto-refractors, keratometers, autophoropters, and autoprojectors.

AA.2 Behavior of an SCP

For a device that is both an SCU and an SCP of the aforementioned Storage SOP Classes, in addition to the behavior for the Storage Service Class specified in Section B.2.2, the following additional requirements are specified for Ophthalmic Refractive Measurements SOP Classes:

  • An SCP of these SOP Classes shall support Storage Level 2 (Full) as defined in Section B.4.1.

Примечание

This requirement means that all Type 1, Type 2, and Type 3 Attributes defined in the Information Object Definition and Private Attributes associated with the SOP Class will be stored and may be accessed.

BB Классы сервисов запроса/получения шаблона импланта

BB.1 Обзор

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

Классы сервисов запроса/получения шаблона импланта определяют классы сервисов прикладного уровня, обеспечивающие доступ к композитным объектам Implant Template и Implant Assembly Template.

BB.1.2 Соглашения

Ключевые атрибуты служат двум целям: они могут использоваться как ключевые атрибуты сопоставления или как возвращаемые ключевые атрибуты. Ключевые атрибуты сопоставления используются для сопоставления (критерии, применяемые в запросе C-FIND для определения того, соответствует ли сущность запросу). Возвращаемые ключевые атрибуты используются для указания желаемых возвращаемых атрибутов (какие элементы, помимо ключевых атрибутов сопоставления, должны быть возвращены в ответе C-FIND).

Примечание

Ключи сопоставления обычно используются в предложении SQL «where». Возвращаемые ключи обычно используются в предложении SQL «select» для передачи значений атрибутов.

Ключевые атрибуты сопоставления могут иметь Тип «обязательный» (R) или «необязательный» (O). Возвращаемые ключевые атрибуты могут иметь Тип 1, 1C, 2, 2C, 3, как определено в PS3.5.

BB.1.3 Информационная модель запроса/получения

Для того чтобы служить SCP класса сервиса запроса/получения шаблона импланта, DICOM AE обладает информацией об атрибутах ряда композитных экземпляров SOP Implant Template или Implant Assembly Template. Эта информация организована в информационную модель. Информационные модели для различных классов SOP, указанных в настоящем Приложении, определены в Section BB.6.

BB.1.4 Определение сервиса

Два равноправных DICOM AE реализуют класс SOP класса сервиса запроса/получения Implant Template или Implant Assembly Template, причём один выступает в роли SCU, а другой — в роли SCP. Классы SOP классов сервисов запроса/получения Implant Template и Implant Assembly Template реализуются с использованием сервисов DIMSE-C C-FIND, C-MOVE и C-GET, как определено в PS3.7.

SCP этого класса SOP должен поддерживать уровень хранения 2 (полный), определённый в Section B.4.1.

Семантика сервиса C-FIND совпадает с семантикой, определённой в разделе «Определение сервиса» класса сервиса базового управления рабочим списком.

Семантика сервиса C-MOVE совпадает с семантикой, определённой в разделе «Определение сервиса» сервисного класса запроса/получения, за исключением того, что имеется только один уровень получения.

Семантика сервиса C-GET совпадает с семантикой, определённой в разделе «Определение сервиса» сервисного класса запроса/получения, за исключением того, что имеется только один уровень получения.

BB.2 Определения информационных моделей шаблона импланта

Информационные модели Implant Template, Implant Assembly Template и Implant Template Group определяются классом SOP, согласованным во время установления ассоциации. Каждый класс SOP состоит из информационной модели и группы сервисов DIMSE-C.

Информационные модели Implant Template, Implant Assembly Template и Implant Template Group определены в Section BB.6, with the Entity-Relationship Model Definition and Key Attributes Definition analogous to those defined in the Worklist Information Model Definition of the Basic Worklist Management Service.

BB.3 Информационные модели шаблона импланта

Информационные модели Implant Template основаны на одноуровневой сущности:

  • Экземпляр объекта Implant Template.

Экземпляр объекта Implant Template содержит атрибуты, связанные с информационной сущностью (IE) объекта Implant Template композитных IOD, как определено в PS3.3.

Информационная модель Implant Assembly Template основана на одноуровневой сущности:

  • Экземпляр объекта Implant Assembly Template.

Экземпляр объекта Implant Assembly Template содержит атрибуты, связанные с информационной сущностью (IE) объекта Implant Assembly Template композитных IOD, как определено в PS3.3.

Информационная модель Implant Template Group основана на одноуровневой сущности:

  • Экземпляр объекта Implant Template Group.

Экземпляр объекта Implant Template Group содержит атрибуты, связанные с информационной сущностью (IE) объекта Implant Template Group композитных IOD, как определено в PS3.3.

BB.4 Группы сервисов DIMSE-C

BB.4.1 Операция C-FIND

См. определение операции C-FIND для класса сервиса базового управления рабочим списком (K.4.1), заменив «Worklist» на «Implant Template». Должен использоваться метод поиска «Worklist».

UID класса SOP определяет соответственно информационную модель Implant Template или Implant Assembly Template, относительно которой выполняется C-FIND. Ключевые атрибуты и допустимые для запроса значения определены в определениях классов SOP для информационной модели Implant Template и Implant Assembly Template.

BB.4.1.1 Поведение пользователя класса сервиса

При получении нескольких экземпляров Implant Template с одинаковым Implant Part Number принимающее приложение должно использовать Effective DateTime (0068,6226) для определения нужного экземпляра.

BB.4.1.2 Поведение поставщика класса сервиса

SCP этого класса SOP должен поддерживать уровень хранения 2 (полный), определённый в Section B.4.1.

BB.4.2 Операция C-MOVE

См. определение операции C-MOVE для сервисного класса запроса/получения (C.4.2). Для классов сервисов запроса/получения Implant Template и Implant Assembly Template не определены ни расширенное поведение, ни реляционное получение.

Query/Retrieve Level (0008,0052) не имеет отношения к классам сервисов запроса/получения Implant Template и Implant Assembly Template и поэтому не должен присутствовать в идентификаторе. Единственным уникальным ключевым атрибутом идентификатора должен быть SOP Instance UID (0008,0018). SCU должен предоставить один UID или список UID.

Примечание

Может быть получена более чем одна сущность с использованием сопоставления по списку UID.

BB.4.3 Операция C-GET

См. определение операции C-GET для сервисного класса запроса/получения (C.4.2). Для классов сервисов запроса/получения Implant Template и Implant Assembly Template не определены ни расширенное поведение, ни реляционное получение.

Примечание

Может быть получена более чем одна сущность с использованием сопоставления по списку UID.

BB.5 Согласование ассоциации

См. определение согласования ассоциации для класса сервиса базового управления рабочим списком (K.5).

BB.6 Определения классов SOP

BB.6.1 Информационная модель шаблона импланта

BB.6.1.1 Модели «сущность-связь»

Информационная модель Implant Template состоит из одной сущности. В ответ на заданный запрос C-FIND SCP должен отправить один ответ C-FIND на каждый подходящий экземпляр Implant Template.

Implant Template Information Model E-R Diagram

Figure BB.6-1. Implant Template Information Model E-R Diagram


Информационная модель Implant Assembly Template состоит из одной сущности. В ответ на заданный запрос C-FIND SCP должен отправить один ответ C-FIND на каждый подходящий экземпляр Implant Assembly Template.

Implant Assembly Template Information Model E-R Diagram

Figure BB.6-2. Implant Assembly Template Information Model E-R Diagram


Информационная модель Implant Template Group состоит из одной сущности. В ответ на заданный запрос C-FIND SCP должен отправить один ответ C-FIND на каждый подходящий экземпляр Implant Template Group.

Implant Template Group Information Model E-R Diagram

Figure BB.6-3. Implant Template Group Information Model E-R Diagram


BB.6.1.2 Атрибуты шаблона импланта

BB.6.1.2.1 Атрибуты общего шаблона импланта

Table BB.6-1 defines the Attributes of the Generic Implant Template Information Model:

Table BB.6-1. Attributes for the Implant Template Information Model

Description / Module

Tag

Тип ключа сопоставления

Тип возвращаемого ключа

Remark / Matching Type

SOP Common

Specific Character Set

(0008,0005)

-

1C

Этот атрибут обязателен, если используются расширенные или заменяющие наборы символов. См. Section C.2.2.2 and Section C.4.1.1.

SOP Class UID

(0008,0016)

R

1

SOP Instance UID

(0008,0018)

U

1

Implant Template

Manufacturer

(0008,0070)

R

1

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

Implant Name

(0022,1095)

R

1

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

Implant Size

(0068,6210)

R

2

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

Implant Part Number

(0022,1097)

R

1

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

Replaced Implant Template Sequence

(0068,6222)

R

2

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

>Referenced SOP Class UID

(0008,1150)

R

1

Должен быть получен с использованием сопоставления по списку UID.

>Referenced SOP Instance UID

(0008,1155)

R

1

Должен быть получен с использованием сопоставления по списку UID.

Derivation Implant Template Sequence

(0068,6224)

R

2

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

>Referenced SOP Class UID

(0008,1150)

R

1

Должен быть получен с использованием сопоставления по списку UID.

>Referenced SOP Instance UID

(0008,1155)

R

1

Должен быть получен с использованием сопоставления по списку UID.

Effective DateTime

(0068,6226)

R

1

Должен быть получен с использованием сопоставления по единственному значению или сопоставления диапазона.

Original Implant Template Sequence

(0068,6225)

R

2

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

>Referenced SOP Class UID

(0008,1150)

R

1

Должен быть получен с использованием сопоставления по списку UID.

>Referenced SOP Instance UID

(0008,1155)

R

1

Должен быть получен с использованием сопоставления по списку UID.

Implant Target Anatomy Sequence

(0068,6230)

R

2

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

>Anatomic Region Sequence

(0008,2218)

R

1

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

>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

Implant Regulatory Disapproval Code Sequence

(0068,62A0)

R

2

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

>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

Material Code Sequence

(0068,63A0)

R

1

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

>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

Coating Materials Code Sequence

(0068,63A4)

R

1

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

>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”


BB.6.1.2.2 Атрибуты шаблона сборки импланта

Table BB.6-2 defines the Attributes of the Implant Assembly Template Information Model:

Table BB.6-2. Attributes for the Implant Assembly Template Information Model

Description / Module

Tag

Тип ключа сопоставления

Тип возвращаемого ключа

Remark / Matching Type

SOP Common

Specific Character Set

(0008,0005)

-

1C

Этот атрибут обязателен, если используются расширенные или заменяющие наборы символов. См. Section C.2.2.2 and Section C.4.1.1.

SOP Class UID

(0008,0016)

R

1

SOP Instance UID

(0008,0018)

U

1

Implant Assembly Template

Implant Assembly Template Name

R

1

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

Manufacturer

(0008,0070)

R

1

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

Procedure Type Code Sequence

(0076,0020)

R

1

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

>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

Replaced Implant Assembly Template Sequence

(0076,0008)

R

1

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

>Referenced SOP Class UID

(0008,1150)

R

1

Должен быть получен с использованием сопоставления по списку UID.

>Referenced SOP Instance UID

(0008,1155)

R

1

Должен быть получен с использованием сопоставления по списку UID.

Original Implant Assembly Template Sequence

(0076,000C)

R

1

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

>Referenced SOP Class UID

(0008,1150)

R

1

Должен быть получен с использованием сопоставления по списку UID.

>Referenced SOP Instance UID

(0008,1155)

R

1

Должен быть получен с использованием сопоставления по списку UID.

Derivation Implant Assembly Template Sequence

(0076,000E)

R

1

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

>Referenced SOP Class UID

(0008,1150)

R

1

Должен быть получен с использованием сопоставления по списку UID.

>Referenced SOP Instance UID

(0008,1155)

R

1

Должен быть получен с использованием сопоставления по списку UID.

Surgical Technique

(0076,0030)

R

2

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


BB.6.1.2.3 Атрибуты группы шаблонов имплантов

Table BB.6-3 defines the Attributes of the Implant Template Group Information Model:

Table BB.6-3. Attributes for the Implant Template Group Information Model

Description / Module

Tag

Тип ключа сопоставления

Тип возвращаемого ключа

Remark / Matching Type

SOP Common

Specific Character Set

(0008,0005)

-

1C

Этот атрибут обязателен, если используются расширенные или заменяющие наборы символов. См. Section C.2.2.2 and Section C.4.1.1.

SOP Class UID

(0008,0016)

R

1

SOP Instance UID

(0008,0018)

U

1

Implant Template Group

Implant Template Group Name

(0078,0000)

R

1

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

Implant Template Group Description

(0078,0010)

-

2

Implant Template Group Issuer

(0078,0020)

R

1

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

Effective DateTime

(0068,6226)

R

1

Должен быть получен с использованием сопоставления по единственному значению или сопоставления диапазона.

Replaced Implant Template Group Sequence

(0078,0026)

R

2

Должен быть получен с использованием сопоставления последовательностей или универсального сопоставления

>Referenced SOP Class UID

(0008,1150)

R

1

Должен быть получен с использованием сопоставления по списку UID.

>Referenced SOP Instance UID

(0008,1155)

R

1

Должен быть получен с использованием сопоставления по списку UID.


BB.6.1.3 Требования соответствия

Реализация может соответствовать одному из классов SOP информационных моделей Implant Template, Implant Assembly Template или Implant Template Group в роли SCU, SCP, любой комбинации из двух этих ролей или всех трёх. Заявление о соответствии должно иметь формат, определённый в PS3.2.

BB.6.1.3.1 Соответствие SCU
BB.6.1.3.1.1 Соответствие C-FIND SCU

Реализация, соответствующая одному из классов SOP информационных моделей Implant Template, Implant Assembly Template или Implant Template Group, должна поддерживать запросы к соответствующей информационной модели с использованием поведения C-FIND SCU, описанного для класса сервиса базового управления рабочим списком (см. Section K.4.1.2 and Section BB.4.1).

Реализация, соответствующая одному из классов SOP информационных моделей Implant Template, Implant Assembly Template или Implant Template Group, в роли SCU должна указать в своём заявлении о соответствии, запрашивает ли она возвращаемые ключевые атрибуты Типа 3, и должна перечислить эти необязательные возвращаемые ключевые атрибуты.

Реализация, соответствующая одному из классов SOP информационных моделей Implant Template, Implant Assembly Template или Implant Template Group, в роли SCU должна указать в своём заявлении о соответствии, каким образом она использует Specific Character Set (0008,0005) при кодировании запросов и интерпретации ответов.

BB.6.1.3.1.2 Соответствие C-MOVE SCU

Реализация, соответствующая одному из классов SOP информационных моделей Implant Template, Implant Assembly Template или Implant Template Group, в роли SCU должна поддерживать передачи к соответствующей информационной модели с использованием базового поведения C-MOVE SCU, описанного для сервисного класса запроса/получения (см. Section C.4.2.2.1 and Section BB.4.2).

BB.6.1.3.1.3 Соответствие C-GET SCU

Реализация, соответствующая одному из классов SOP информационных моделей Implant Template, Implant Assembly Template или Implant Template Group, в роли SCU должна поддерживать передачи к соответствующей информационной модели с использованием базового поведения C-GET SCU, описанного для сервисного класса запроса/получения (см. Section C.4.3.2).

BB.6.1.3.2 Соответствие SCP
BB.6.1.3.2.1 Соответствие C-FIND SCP

Реализация, соответствующая одному из классов SOP информационных моделей Implant Template, Implant Assembly Template или Implant Template Group, в роли SCP должна поддерживать запросы к соответствующей информационной модели шаблона с использованием поведения C-FIND SCP, описанного для класса сервиса базового управления рабочим списком (см. Section K.4.1.3).

Реализация, соответствующая одному из классов SOP информационных моделей Implant Template, Implant Assembly Template или Implant Template Group, в роли SCP должна указать в своём заявлении о соответствии, поддерживает ли она возвращаемые ключевые атрибуты Типа 3, и должна перечислить эти необязательные возвращаемые ключевые атрибуты.

Реализация, соответствующая одному из классов SOP информационных моделей Implant Template, Implant Assembly Template или Implant Template Group, в роли SCP должна указать в своём заявлении о соответствии, каким образом она использует Specific Character Set (0008,0005) при интерпретации запросов, выполнении сопоставления и кодировании ответов.

BB.6.1.3.2.2 Соответствие C-MOVE SCP

Реализация, соответствующая одному из классов SOP информационных моделей Implant Template, Implant Assembly Template или Implant Template Group, в роли SCP должна поддерживать передачи к соответствующей информационной модели с использованием базового поведения C-MOVE SCP, описанного для сервисного класса запроса/получения (см. Section C.4.2.3.1).

Реализация, соответствующая одному из классов SOP информационных моделей Implant Template, Implant Assembly Template или Implant Template Group, в роли SCP, генерирующая передачи с использованием операции C-MOVE, должна указать в своём заявлении о соответствии соответствующий сервисный класс хранения, в рамках которого она будет поддерживать субоперации C-STORE, порождаемые C-MOVE.

BB.6.1.3.2.3 Соответствие C-GET SCP

Реализация, соответствующая одному из классов SOP группы классов SOP информационных моделей Implant Template, Implant Assembly Template или Implant Template Group, в роли SCP должна поддерживать получение относительно информационной модели запроса/получения, описанной в Section C.6.1.1 using the C-GET SCP Behavior described in Section C.4.3.3.

BB.6.1.4 Классы SOP

Классы SOP информационных моделей Implant Template в классе сервиса запроса/получения Implant Template определяют информационные модели Implant Template и поддерживаемые операции DIMSE-C. Классы SOP информационных моделей Implant Assembly Template в классе сервиса запроса/получения Implant Assembly Template определяют информационные модели Implant Assembly Template и поддерживаемые операции DIMSE-C. Классы SOP информационных моделей Implant Template Group в классе сервиса запроса/получения Implant Template Group определяют информационные модели Implant Template Group и поддерживаемые операции DIMSE-C. Определены следующие стандартные классы SOP:

Table BB.6.1.4-1. Implant Template SOP Classes

SOP Class Name

SOP Class UID

Generic Implant Template Information Model - FIND

1.2.840.10008.5.1.4.43.2

Generic Implant Template Information Model - MOVE

1.2.840.10008.5.1.4.43.3

Generic Implant Template Information Model - GET

1.2.840.10008.5.1.4.43.4

Implant Assembly Template Information Model - FIND

1.2.840.10008.5.1.4.44.2

Implant Assembly Template Information Model - MOVE

1.2.840.10008.5.1.4.44.3

Implant Assembly Template Information Model - GET

1.2.840.10008.5.1.4.44.4

Implant Template Group Information Model - FIND

1.2.840.10008.5.1.4.45.2

Implant Template Group Information Model - MOVE

1.2.840.10008.5.1.4.45.3

Implant Template Group Information Model - GET

1.2.840.10008.5.1.4.45.4


CC Служба и SOP-классы единого этапа процедуры

CC.1 Обзор

Настоящее приложение определяет сервис и классы SOP, связанные с унифицированным рабочим списком и этапом процедуры (Unified Worklist and Procedure Step).

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

Рабочий список — это список экземпляров унифицированного этапа процедуры (UPS). Каждый экземпляр UPS объединяет сведения рабочего списка для одного запрошенного этапа процедуры вместе со сведениями о результатах соответствующего выполненного этапа процедуры. Между запросом этапа процедуры и выполненным этапом процедуры существует связь «один к одному».

Экземпляры унифицированного этапа процедуры могут использоваться для представления различных запланированных задач, таких как: обработка изображений, контроль качества, компьютерное обнаружение (Computer Aided Detection), интерпретация, транскрипция, верификация отчёта или печать.

Экземпляр UPS может содержать сведения о запрошенной задаче, такие как время, на которое она запланирована, или коды рабочего элемента (Workitem Codes), описывающие запрошенные действия. UPS также может содержать сведения о входной информации, необходимой исполнителю для выполнения задачи, и о выходных данных, созданных исполнителем, таких как: текущие изображения, предыдущие изображения, отчёты, плёнки, состояния презентации или аудиозаписи.

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

Класс SOP UPS Push позволяет SCU дать указание SCP создать новый экземпляр UPS, фактически позволяя системе поместить («протолкнуть») новый рабочий элемент в рабочий список SCP. Важно отметить, что SCP может быть менеджером рабочих списков, который ведёт рабочий список для других систем, которые будут выполнять работу, либо SCP может сам быть выполняющей системой, ведущей внутренний рабочий список.

Класс SOP UPS Pull позволяет SCU запрашивать у менеджера рабочих списков (SCP) подходящие экземпляры UPS и давать указание SCP обновить состояние и содержимое выбранных элементов (экземпляров UPS). Фактически SCU извлекает («вытягивает») рабочие задания из рабочего списка. По мере выполнения работы SCU фиксирует сведения о выполненных действиях и полученных результатах в экземпляре UPS.

Класс SOP UPS Query позволяет SCU запрашивать менеджера рабочих списков (SCP), но не предполагает иного взаимодействия с экземплярами UPS.

Класс SOP UPS Watch позволяет SCU подписываться на события обновления состояния и получать сведения о рабочих элементах (экземплярах UPS), которыми управляет SCP.

Класс SOP UPS Event позволяет SCP предоставлять фактические события обновления состояния для управляемых им рабочих элементов заинтересованным (то есть подписанным) SCU.

Each of these services has an equivalent HTTP operation defined by the UPS-RS Worklist Service (see Section 11 “Worklist Service and Resources” in PS3.18).

Хотя SCP сервисного класса унифицированного этапа процедуры не обязан поддерживать UPS-RS, SCP может по своему выбору поддерживать один или несколько сервисов UPS-RS в качестве исходного сервера (origin server). В этом случае SCP/исходный сервер должен придерживаться одинакового внутреннего поведения для всех рабочих элементов независимо от того, возник ли запрос из DIMSE-запроса или HTTP-запроса. DIMSE-запрос и эквивалентный ему HTTP-запрос с одинаковыми параметрами должны давать одинаковый результат.

Например:

  • A Workitem instance created via DIMSE N-CREATE can be retrieved via HTTP requests and vice-versa

  • A Workitem instance created via DIMSE N-CREATE can be updated, have its state changed or be canceled via HTTP requests and vice-versa

  • Запрос C-FIND и HTTP-запрос SearchForUPS с одинаковыми параметрами должны возвращать один и тот же набор результатов

  • SCU сервиса N-EVENT-REPORT, также поддерживающий HTTP-подписки, будет фиксировать, использует ли данный подписчик DIMSE или WebSockets, и отправлять уведомление в соответствующей форме этому подписчику

  • Изменение, внесённое в экземпляр рабочего элемента (Workitem), приведёт к одинаковым уведомлениям о событиях независимо от того, был ли запрос на изменение выполнен через DIMSE или HTTP

  • Запрос глобальной подписки (Global Subscription) или запрос фильтрованной глобальной подписки (Filtered Global Subscription) подпишет SCU (или пользовательский агент) на экземпляры, созданные как через DIMSE, так и через HTTP-запросы

  • Подписчик событий DIMSE будет получать уведомления о соответствующих изменениях, внесённых через HTTP-запросы

  • Подписчик событий HTTP будет получать уведомления о соответствующих изменениях, внесённых через DIMSE-запросы

Соответствие между операциями DIMSE UPS и сервисами UPS-RS определено в Раздел 11 “Worklist Service and Resources” in PS3.18.

CC.1.1 Состояния унифицированного этапа процедуры

Рисунок CC.1.1-1, Таблица CC.1.1-1 и Таблица CC.1.1-2 определяют, как должны обрабатываться изменения состояния унифицированного этапа процедуры.

Unified Procedure Step State Diagram

Figure CC.1.1-1. Unified Procedure Step State Diagram


Следующие взаимодействия представляют собой пример последовательности событий и переходов состояний. Обратите внимание, что описанные здесь сервисы DIMSE оперируют одним и тем же IOD. Таким образом, множественные классы SOP UPS действуют согласованно, как это определено в настоящем приложении.

Чтобы создать UPS, SCU использует N-CREATE для помещения UPS в рабочий список SCP. SCP отвечает на такие запросы созданием унифицированного этапа процедуры (UPS) с начальным состоянием SCHEDULED.

Примечание

Все экземпляры UPS являются экземплярами класса SOP UPS Push, хотя остальные три класса SOP (UPS Pull, UPS Watch и UPS Event) также могут оперировать данным экземпляром.

Чтобы подписаться на получение N-EVENT-REPORT для UPS или отменить подписку, чтобы прекратить их получение, SCU использует запрос N-ACTION. SCU может быть той же системой, которая создала UPS в роли Push SCU, либо некоторой другой системой, имеющей основание отслеживать ход выполнения и результаты запланированного этапа.

Чтобы информировать заинтересованные системы о состоянии UPS или о состоянии самого SCP, SCP выдаёт N-EVENT-REPORT подписанным SCU.

Чтобы найти интересующий его UPS, SCU использует C-FIND для запроса SCP на предмет соответствующих экземпляров UPS.

Чтобы «заявить права» на UPS и начать работу над ним, SCU (далее именуемый «выполняющим SCU», Performing SCU) использует запрос N-ACTION Change State для установки состояния UPS в значение IN PROGRESS и предоставления Transaction UID (далее именуемого «блокирующим UID», Locking UID). Для UPS в состоянии SCHEDULED SCP отвечает изменением состояния UPS на IN PROGRESS и записывает Transaction UID для дальнейшего использования. Для UPS с иным состоянием SCP отклоняет запрос.

SCP не допускает установки состояния UPS SCHEDULED сразу в значение COMPLETED или CANCELED без предварительного перехода в состояние IN PROGRESS.

Чтобы изменить сведения о выполняемой процедуре, выполняющий SCU использует запрос N-SET к SCP (предоставляя блокирующий UID для UPS). Запросы N-SET к UPS в состоянии IN PROGRESS, в которых блокирующий UID в наборе данных N-SET не совпадает с блокирующим UID в UPS, отклоняются SCP.

Чтобы изменить состояние этапа процедуры, выполняющий SCU использует запрос N-ACTION Change State к SCP (предоставляя блокирующий UID для UPS). Запросы N-ACTION Change State, в которых блокирующий UID в наборе данных N-ACTION не совпадает с блокирующим UID в UPS, отклоняются SCP.

Блокирующий UID фактически ограничивает управление состоянием UPS в состоянии IN PROGRESS только SCP и выполняющим SCU. SCP не проверяет совпадение IP-адресов, AE-Titles или иных параметров, кроме блокирующего UID, для определения наличия у SCU соответствующих прав.

Когда выполняющий SCU завершает работу над UPS, он выполняет N-SET всех значений, необходимых для выполнения требований конечного состояния вTable CC.2.5-3, then uses an N-ACTION request (providing the Locking UID for the UPS during both steps) for the SCP to change the UPS state to COMPLETED.

Когда выполняющий SCU прекращает работу над незавершённым UPS, он выполняет N-SET всех значений, необходимых для выполнения требований конечного состояния вTable CC.2.5-3, then uses an N-ACTION request (providing the Locking UID for the UPS) for the SCP to change the UPS state to CANCELED.

To request cancellation of a UPS, non-performing SCUs use an N-ACTION Request Cancel (see Section GGG.2.4 “Third Party Cancel” in PS3.17 and Section GGG.2.5 “Radiation Therapy Dose Calculation Push Workflow” in PS3.17 for example cases).

  • Если UPS всё ещё находится в состоянии SCHEDULED, SCP сначала изменяет состояние UPS на IN PROGRESS, а затем на CANCELED, выдавая соответствующие N-EVENT-REPORT.

  • Если UPS уже находится в состоянии IN PROGRESS и SCP сам выполняет данный UPS, он может по своему усмотрению отменить UPS, как описано в предыдущем абзаце.

  • Если UPS уже находится в состоянии IN PROGRESS, а SCP не является исполнителем, он не изменяет состояние UPS на CANCELED, а вместо этого отвечает выдачей N-EVENT-REPORT о запросе отмены всем подписанным SCU. Если выполняющий SCU отслеживает N-EVENT-REPORT, он может по своему усмотрению отменить UPS, как описано выше.

Table CC.1.1-1 describes the valid UPS states

Table CC.1.1-1. Unified Procedure Step (UPS) States

Состояние

Описание

SCHEDULED

UPS запланирован к выполнению.

IN PROGRESS

UPS был заявлен исполнителем, установлен Locking UID. Выполнение UPS, вероятно, уже началось.

CANCELED

UPS был окончательно остановлен до или во время выполнения этапа. Это может быть результатом добровольного или вынужденного действия человека или машины. Любая дальнейшая работа, требуемая для завершения запланированной задачи, должна выполняться путём планирования другого (нового) UPS.

COMPLETED

UPS был завершён.


COMPLETED и CANCELED являются «конечными состояниями» (Final States), которые влекут за собой определённые требования к UPS, как описано в Раздел CC.2.5.1.1.

Таблица CC.1.1-2 описывает допустимые переходы состояний (строка таблицы определяет, что должно происходить в ответ на определённое событие для каждого исходного состояния). Подробности о том, как должны выполняться операции, перечисленные в таблице, описаны в Раздел CC.2.

Table CC.1.1-2. Unified Procedure Step State Transition Table

Состояния

События

null

SCHEDULED

IN PROGRESS

COMPLETED

CANCELED

Получен N-CREATE для данного SOP Instance UID

Создать экземпляр SOP с пустым Transaction UID, изменить состояние на SCHEDULED

Код состояния Failure 0111H

Код состояния Failure 0111H

Код состояния Failure 0111H

Код состояния Failure 0111H

N-ACTION для изменения состояния на IN PROGRESS с правильным Transaction UID

Код состояния Failure C307H

Сообщить об изменении состояния, зафиксировать Transaction UID, изменить состояние на IN PROGRESS

Код состояния Failure C302H

Код состояния Failure C300H

Код состояния Failure C300H

N-ACTION для изменения состояния на IN PROGRESS без правильного Transaction UID

Код состояния Failure C307H

Код состояния Failure C301H

Код состояния Failure C301H

Код состояния Failure C301H

Код состояния Failure C301H

N-ACTION для изменения состояния на SCHEDULED

Код состояния Failure C307H

Код состояния Failure C303H

Код состояния Failure C303H

Код состояния Failure C303H

Код состояния Failure C303H

N-ACTION для изменения состояния на COMPLETED с правильным Transaction UID

Код состояния Failure C307H

Код состояния Failure C310H

Если требования конечного состояния выполнены — (сообщить об изменении состояния, изменить состояние на COMPLETED); иначе — код состояния Failure C304H

Код состояния Warning B306H

Код состояния Failure C300H

N-ACTION для изменения состояния на COMPLETED без правильного Transaction UID

Код состояния Failure C307H

Код состояния Failure C301H

Код состояния Failure C301H

Код состояния Failure C301H

Код состояния Failure C301H

N-ACTION для запроса отмены (Request Cancel)

Код состояния Failure C307H

Сообщить об изменении состояния на IN-PROGRESS, сообщить об изменении состояния на CANCELED, изменить состояние на CANCELED

Сообщить, что прикладная сущность запросила отмену.

Код состояния Failure C311H

Код состояния Warning B304H

N-ACTION для изменения состояния на CANCELED с правильным Transaction UID

Код состояния Failure C307H

Код состояния Failure C310H

Если требования конечного состояния выполнены — (сообщить об изменении состояния, изменить состояние на CANCELED); иначе — код состояния Failure C304H

Код состояния Failure C300H

Код состояния Warning B304H

N-ACTION для изменения состояния на CANCELED без правильного Transaction UID

Код состояния Failure C307H

Код состояния Failure C301H

Код состояния Failure C301H

Код состояния Failure C301H

Код состояния Failure C301H


CC.2 Группы сервисов DIMSE

Сервисы DIMSE, показанные в Таблица CC.2-1, Таблица CC.2-2, Таблица CC.2-3, Таблица CC.2-4 и Таблица CC.2-5, применимы к IOD унифицированного этапа процедуры (UPS) в рамках классов SOP UPS Push, UPS Pull, UPS Watch, UPS Event и UPS Query соответственно.

Table CC.2-1. DIMSE Service Group Applicable to UPS Push

Элемент службы сообщений DICOM

Использование (SCU/SCP)

N-CREATE

M/M

N-ACTION - Request UPS Cancel

U/M

N-GET

U/M


Table CC.2-2. DIMSE Service Group Applicable to UPS Pull

Элемент службы сообщений DICOM

Использование (SCU/SCP)

C-FIND

M/M

N-GET

M/M

N-SET

M/M

N-ACTION - Change UPS State

M/M


Table CC.2-3. DIMSE Service Group Applicable to UPS Watch

Элемент службы сообщений DICOM

Использование (SCU/SCP)

N-ACTION - Un/Subscribe

M/M

N-GET

M/M

C-FIND

U/M

N-ACTION - Request UPS Cancel

U/M


Table CC.2-4. DIMSE Service Group Applicable to UPS Event

Элемент службы сообщений DICOM

Использование (SCU/SCP)

N-EVENT-REPORT

M/M


Table CC.2-5. DIMSE Service Group Applicable to UPS Query

Элемент службы сообщений DICOM

Использование (SCU/SCP)

C-FIND

M/M


CC.2.1 Изменение состояния UPS (N-ACTION)

Данная операция позволяет SCU запросить у SCP изменение состояния экземпляра унифицированного этапа процедуры (UPS). Данная операция вызывается SCU посредством DIMSE-сервиса N-ACTION.

CC.2.1.1 Информация о действии

DICOM AE, заявляющие соответствие классу SOP UPS Pull в роли SCU и/или SCP, должны поддерживать типы действий и информацию о действии, указанные в Таблица CC.2.1-1.

Table CC.2.1-1. Change UPS State - Action Information

Имя типа действия

Идентификатор типа действия

Имя атрибута

Tag

Использование (SCU/SCP)

Change UPS State

1

Procedure Step State

(0074,1000)

1/1

Transaction UID

(0008,1195)

1/1


CC.2.1.2 Поведение пользователя сервисного класса (SCU)

SCU использует N-ACTION, чтобы запросить у SCP изменение состояния экземпляра UPS, как показано на Рисунок CC.1.1-1. Поскольку все UPS создаются как экземпляры класса SOP UPS Push, Requested SOP Class UID (0000,0003) в запросе N-ACTION должен быть UID класса SOP UPS Push. См. Раздел CC.3.1 для получения дополнительных сведений.

Чтобы взять под контроль UPS в состоянии SCHEDULED, SCU должен сгенерировать Transaction UID и отправить изменение состояния на IN PROGRESS, включив этот Transaction UID в отправляемый запрос. SCU должен сохранить и использовать этот Transaction UID в последующих запросах N-ACTION и N-SET для данного экземпляра UPS.

Примечание

  1. Выполняющий SCU может пожелать сохранить Transaction UID в энергонезависимой памяти. Это позволило бы SCU сохранить контроль над UPS после восстановления после сбоя.

  2. Если два SCU пытаются взять под контроль один UPS, второй SCU получит статус Failure, поскольку первый SCU установил правильный Transaction UID, и, следовательно, Transaction UID, предоставленный вторым SCU, окажется неверным.

По завершении контролируемого им UPS в состоянии IN PROGRESS SCU должен отправить изменение состояния на COMPLETED, включив Transaction UID данного экземпляра UPS.

Чтобы отменить UPS в состоянии IN PROGRESS, для которого у него имеется Transaction UID, SCU должен отправить изменение состояния на CANCELED, включив Transaction UID данного экземпляра UPS.

Примечание

  1. Перед отправкой изменения состояния на CANCELED выполняющий SCU может выполнить N-SET значений Reason For Cancellation, Procedure Step Discontinuation Reason Code Sequence, Contact Display Name или Contact URI, чтобы предоставить наблюдающим SCU сведения об обстоятельствах отмены.

  2. Чтобы запросить отмену UPS в состоянии IN PROGRESS, для которого у него нет Transaction UID, SCU использует действие Request UPS Cancel, как описано вSection CC.2.2, rather than a Change UPS State action.

Перед отправкой изменения состояния на COMPLETED или CANCELED для контролируемого им экземпляра UPS SCU должен выполнить все N-SET, необходимые для соответствия UPS требованиям конечного состояния, как описано вSection CC.2.5.1.1.

В любой момент после получения ответа N-ACTION SCU может освободить ассоциацию, по которой он отправил запрос N-ACTION.

CC.2.1.3 Поведение поставщика сервисного класса (SCP)

SCP должен выполнить отправленное изменение состояния для идентифицированного экземпляра UPS, установив Procedure Step State (0074,1000) в запрошенное значение, либо сообщить соответствующий код ответа об отказе.

После успешного изменения состояния экземпляра UPS на IN PROGRESS SCP должен записать предоставленный SCU Transaction UID в атрибут Transaction UID (0008,1195) данного экземпляра UPS.

По завершении обработки запроса N-ACTION SCP должен вернуть, посредством примитива ответа N-ACTION, применимый к данному запросу код состояния N-ACTION, как показано вTable CC.2.1-2.

SCP должен выполнять только допустимые изменения состояния, как описано в Таблица CC.1.1-2.

SCP должен отклонить запросы на изменение состояния UPS, находящегося в состоянии IN PROGRESS, если в запросе не предоставлен Transaction UID данного экземпляра UPS.

SCP должен отклонить запросы на изменение состояния UPS в состоянии IN PROGRESS на COMPLETED или CANCELED, если не выполнены требования конечного состояния, описанные в Таблица CC.2.5-3.

После изменения состояния экземпляра UPS на COMPLETED или CANCELED SCP не должен удалять данный экземпляр, пока не будут сняты все блокировки удаления (deletion locks).

Примечание

См. Section CC.2.3.2 for a description of how SCUs place and remove deletion locks and see Section GGG.1 “Introduction” in PS3.17 Reliable Watchers and Deletion Locks for further discussion.

SCP также может самостоятельно изменять Procedure Step State (0074,1000) экземпляра UPS независимо от запроса N-ACTION, например, если SCP сам выполняет данный этап процедуры, либо если установлено, что выполняющий SCU вышел из строя.

Примечание

Если SCP не выполняет данный этап процедуры сам, это следует делать с осторожностью.

После успешного изменения состояния экземпляра UPS SCP должен выполнить соответствующее поведение по отправке N-EVENT-REPORT, как описано вSection CC.2.4.3 if it supports the UPS Event SOP Class as an SCP.

Двусторонняя аутентификация машин/пользователей/приложений возможна на этапе установления ассоциации (см. PS3.7 и PS3.15). PS3.7 предоставляет код состояния Failure 0124H «Refused: Not authorized». Дальнейшее требование или документирование функций аутентификации и/или авторизации со стороны SCU или SCP выходит за рамки данного класса SOP.

CC.2.1.4 Коды состояния

Таблица CC.2.1-2 определяет значения кодов состояния, которые могут возвращаться в ответе N-ACTION. Общие значения кодов состояния и поля, связанные со значениями кодов состояния, определены для сервиса DIMSE N-ACTION в PS3.7.

Table CC.2.1-2. N-ACTION Response Status Values [for Change UPS State]

Статус службы

Дополнительное значение

Status Code

Успех

Запрошенное изменение состояния выполнено

0000

Предупреждение

UPS уже находится в запрошенном состоянии CANCELED

B304

UPS уже находится в запрошенном состоянии COMPLETED

B306

Отказ

Отказано: UPS больше не может быть обновлён

C300

Отказано: не предоставлен правильный Transaction UID

C301

Отказано: UPS уже находится в состоянии IN PROGRESS

C302

Отказано: UPS может перейти в состояние SCHEDULED только посредством N-CREATE, а не N-SET или N-ACTION

C303

Отказано: UPS не соответствует требованиям конечного состояния для запрошенного изменения состояния

C304

Отказано: указанный SOP Instance UID не существует либо не является экземпляром UPS, управляемым данным SCP

C307

Отказано: UPS ещё не находится в состоянии «IN PROGRESS»

C310


CC.2.2 Запрос отмены UPS (N-ACTION)

Данная операция позволяет SCU, не контролирующему данный экземпляр унифицированного этапа процедуры (UPS), запросить у SCP отмену этого экземпляра. Данная операция вызывается SCU посредством DIMSE-сервиса N-ACTION.

CC.2.2.1 Информация о действии

DICOM AE, заявляющие соответствие классу SOP UPS Push в роли SCU или SCP, должны поддерживать типы действий и информацию о действии, указанные в Таблица CC.2.2-1. DICOM AE, заявляющие соответствие классу SOP UPS Watch в роли SCP, либо заявляющие соответствие классу SOP UPS Watch в роли SCU и решившие реализовать Request UPS Cancel, должны поддерживать типы действий и информацию о действии, указанные в Таблица CC.2.2-1.

Table CC.2.2-1. Request UPS Cancel - Action Information

Имя типа действия

Идентификатор типа действия

Имя атрибута

Tag

Использование (SCU/SCP)

Request UPS Cancel

2

Reason For Cancellation

(0074,1238)

3/1

Procedure Step Discontinuation Reason Code Sequence

(0074,100e)

3/1

>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

Contact URI

(0074,100a)

3/1

Contact Display Name

(0074,100c)

3/1


CC.2.2.2 Поведение пользователя сервисного класса (SCU)

SCU использует N-ACTION, чтобы запросить у SCP изменение состояния экземпляра UPS на CANCELED, как показано на Рисунок CC.1.1-1. Поскольку все UPS создаются как экземпляры класса SOP UPS Push, Requested SOP Class UID (0000,0003) в запросе N-ACTION должен быть UID класса SOP UPS Push. См. Раздел CC.3.1 для получения дополнительных сведений.

SCU может включить Reason For Cancellation и/или предлагаемую Procedure Step Discontinuation Reason Code Sequence.

SCU также может предоставить Contact Display Name и/или Contact URI лица, с которым можно обсудить запрос на отмену.

Примечание

Код состояния N-ACTION, указывающий на успех, означает, что запрос был принят, а не то, что UPS был отменён. Система, выполняющая UPS, не обязана удовлетворять запрос на отмену, и в некоторых сценариях может даже не получить уведомление о нём. См.Section CC.2.4.

В любой момент после получения ответа N-ACTION SCU может освободить ассоциацию, по которой он отправил запрос N-ACTION.

Чтобы отменить UPS в состоянии IN PROGRESS, который SCU выполняет сам, SCU должен вместо этого использовать действие Change UPS State, как описано вSection CC.2.1.

CC.2.2.3 Поведение поставщика сервисного класса (SCP)

SCP должен отправить соответствующие сообщения N-EVENT-REPORT «UPS Cancel Requested», как описано вSection CC.2.4.3 or shall report the appropriate failure response code.

Примечание

Предоставленные Reason For Cancellation, предлагаемая Procedure Step Discontinuation Reason Code Sequence, Contact Display Name и Contact URI лица, ответственного за запрос отмены, могут быть полезны при принятии решения об отмене UPS либо могут быть показаны оператору, чтобы он мог связаться с этим лицом для уточнения или подтверждения запроса отмены. Если SCP является исполнителем и решает фактически отменить UPS, он может по своему усмотрению установить Procedure Step Discontinuation Reason Code Sequence в экземпляре UPS на основе предоставленных соответствующих значений.

Если Procedure Step State (0074,1000) экземпляра UPS всё ещё имеет значение SCHEDULED, SCP должен изменить Procedure Step State, как описано вSection CC.2.1.3, first to IN PROGRESS and then to CANCELED, ensuring that the Final State requirements, described in Section CC.2.5.1.1, are met.

Если Procedure Step State (0074,1000) экземпляра UPS имеет значение IN PROGRESS, и SCP сам является исполнителем UPS, SCP может по своему усмотрению отменить UPS, как описано вSection CC.2.1.3.

Если SCP является исполнителем UPS и решает не отменять его, либо если нет никакой возможности проинформировать выполняющий SCU о запросе отмены (например, список подписки для UPS пуст, либо SCP определил, что выполняющий SCU вышел из строя), SCP может вернуть отказ.

По завершении обработки запроса N-ACTION SCP должен вернуть, посредством примитива ответа N-ACTION, применимый к данному запросу код состояния N-ACTION, как показано вTable CC.2.2-2.

Двусторонняя аутентификация машин/пользователей/приложений возможна на этапе установления ассоциации (см. PS3.7 и PS3.15). PS3.7 предоставляет код состояния Failure 0124H «Refused: Not authorized». Дальнейшее требование или документирование функций аутентификации и/или авторизации со стороны SCU или SCP выходит за рамки данного класса SOP.

CC.2.2.4 Коды состояния

Таблица CC.2.2-2 определяет значения кодов состояния, которые могут возвращаться в ответе N-ACTION. Общие значения кодов состояния и поля, связанные со значениями кодов состояния, определены для сервиса DIMSE N-ACTION в PS3.7.

Table CC.2.2-2. N-ACTION Response Status Values [for Request UPS Cancel]

Статус службы

Дополнительное значение

Status Code

Успех

Запрос на отмену подтверждён

0000

Предупреждение

UPS уже находится в запрошенном состоянии CANCELED

B304

Отказ

Отказано: UPS уже находится в состоянии COMPLETED

C311

Отказано: исполнитель отказывается выполнить отмену

C313

Отказано: указанный SOP Instance UID не существует либо не является экземпляром UPS, управляемым данным SCP

C307

Отказано: не удаётся связаться с исполнителем

C312


CC.2.3 Подписка/отмена подписки на получение отчётов о событиях UPS (N-ACTION)

Данная операция позволяет SCU подписаться у SCP для получения N-EVENT-REPORT о последующих изменениях состояния экземпляра UPS либо отменить подписку, чтобы больше не получать такие N-EVENT-REPORT. Данная операция вызывается SCU посредством DIMSE-сервиса N-ACTION.

CC.2.3.1 Информация о действии

DICOM AE, заявляющие соответствие классу SOP UPS Watch в роли SCU и/или SCP, должны поддерживать типы действий и информацию о действии, указанные в Таблица CC.2.3-1.

Table CC.2.3-1. Subscribe/Unsubscribe to Receive UPS Event Reports - Action Information

Имя типа действия

Идентификатор типа действия

Имя атрибута

Tag

Использование (SCU/SCP)

Subscribe to Receive UPS Event Reports

3

Receiving AE

(0074,1234)

1/1

Deletion Lock

(0074,1230)

1/1

Matching Keys (see Section CC.2.3.1)

1/1

Unsubscribe from Receiving UPS Event Reports

4

Receiving AE

(0074,1234)

1/1

Suspend Global Subscription

5

Receiving AE

(0074,1234)

1/1


Каждая AE может находиться в одном из трёх состояний подписки UPS (UPS Subscription State) для каждого существующего экземпляра UPS: Not Subscribed, Subscribed with Deletion Lock или Subscribed w/o Deletion Lock. Состояние подписки UPS определяет, будут ли N-EVENT-REPORT, относящиеся к данному экземпляру UPS, отправляться данной AE.

Каждая AE также может находиться в одном из трёх глобальных состояний подписки (Global Subscription State) для данного SCP: No Global Subscription, Globally Subscribed with Deletion Lock, Globally Subscribed w/o Deletion Lock. Глобальное состояние подписки в основном определяет начальное состояние подписки UPS для AE и новых экземпляров UPS, создаваемых SCP. Изменения глобального состояния подписки также могут изменять состояние подписки UPS для существующих экземпляров UPS, как описано вTable CC.2.3-2.

Три действия подписки в Таблица CC.2.3-1 используются для управления состоянием подписки UPS и глобальным состоянием подписки AE.

Таблица CC.2.3-2 описывает переходы состояния подписки UPS для AE применительно к данному экземпляру UPS. Каждая строка таблицы определяет, что должно происходить в ответ на действие подписки либо на событие создания UPS с учётом исходного состояния. Таблица также показывает, когда AE должно быть отправлено начальное сообщение о событии, описывающее «текущее состояние UPS».

Примечание

В общем случае инструкции для конкретного экземпляра имеют приоритет над глобальными инструкциями. Исключением является инструкция Unsubscribe Globally, которая удаляет все подписки — как глобальные, так и относящиеся к конкретным экземплярам. Чтобы просто прекратить глобальную подписку на новые экземпляры без удаления подписок на конкретные экземпляры, используется сообщение Suspend Global Subscription.

Большинство действий влияют только на состояние подписки UPS одного экземпляра UPS. Однако глобальные действия потенциально влияют на все существующие экземпляры UPS, которыми управляет SCP, что в следующей таблице обозначается словом «All». Например, в строке «AE Subscribes Globally with Lock» содержимое ячейки «Not Subscribed» означает, что помимо установки для данной AE глобального состояния подписки «Global Subscription with Lock», состояние подписки UPS для всех существующих экземпляров UPS, у которых состояние подписки UPS для данной принимающей AE — «Not Subscribed», будет изменено на «Subscribed with Lock», и для каждого экземпляра принимающей AE будет отправлено событие.

Table CC.2.3-2. UPS Subscription State Transition Table

States (for a specific UPS and AE)

События

null

Not Subscribed

Subscribed with Lock

Subscribed w/o Lock

UPS создаётся, когда состояние глобальной подписки AE — «No Global Subscription»

Перейти в состояние Not Subscribed

N/A

N/A

N/A

UPS создаётся, когда состояние глобальной подписки AE — «Global Subscription with Lock»

Перейти в состояние Subscribed with Lock; отправить начальное событие

N/A

N/A

N/A

UPS создаётся, когда состояние глобальной подписки AE — «Global Subscription w/o Lock»

Перейти в состояние Subscribed w/o Lock; отправить начальное событие

N/A

N/A

N/A

AE подписывается глобально с блокировкой (with Lock)

N/A

Глобальное состояние AE теперь «Global Sub. with Lock»; все переходят в состояние Subscribed with Lock; для всех отправляется начальное событие

Глобальное состояние AE теперь «Global Sub. with Lock»; изменения состояния UPS не происходит;

Глобальное состояние AE теперь «Global Sub. with Lock»; изменения состояния UPS не происходит;

AE подписывается глобально без блокировки (w/o Lock)

N/A

Глобальное состояние AE теперь «Global Sub. w/o Lock»; все переходят в состояние Subscribed w/o Lock;

Глобальное состояние AE теперь «Global Sub. w/o Lock»; изменения состояния UPS не происходит;

Глобальное состояние AE теперь «Global Sub. w/o Lock»; изменения состояния UPS не происходит;

AE подписывается на конкретный UPS с блокировкой (with Lock)

N/A

Перейти в состояние Subscribed with Lock; отправить начальное событие

Изменения состояния UPS не происходит; отправляется начальное событие

Перейти в состояние Subscribed with Lock; отправить начальное событие

AE подписывается на конкретный UPS без блокировки (without Lock)

N/A

Перейти в состояние Subscribed w/o Lock; отправить начальное событие

Перейти в состояние Subscribed w/o Lock; отправить начальное событие

Изменения состояния UPS не происходит; отправляется начальное событие

AE отменяет подписку на конкретный UPS

N/A

Изменения состояния UPS не происходит

Перейти в состояние Not Subscribed

Перейти в состояние Not Subscribed

AE отменяет глобальную подписку

N/A

Глобальное состояние AE теперь «No Global Subscription»; изменения состояния UPS не происходит;

Глобальное состояние AE теперь «No Global Subscription»; все переходят в состояние Not Subscribed;

Глобальное состояние AE теперь «No Global Subscription»; все переходят в состояние Not Subscribed;

AE приостанавливает глобальную подписку

N/A

Глобальное состояние AE теперь «No Global Subscription»; изменения состояния UPS не происходит;

Глобальное состояние AE теперь «No Global Subscription»; изменения состояния UPS не происходит;

Глобальное состояние AE теперь «No Global Subscription»; изменения состояния UPS не происходит;


See Section GGG.1 “Introduction” in PS3.17 Reliable Watchers and Deletion Locks for further discussion of deletion locks.

CC.2.3.2 Поведение пользователя сервисного класса (SCU)

SCU, подписывающийся для отслеживания хода выполнения и результатов запланированного этапа процедуры, может быть той же системой, которая создала UPS как SCU класса SOP UPS Push, либо это может быть какой-либо другой заинтересованный наблюдатель.

SCU должен использовать примитив N-ACTION, чтобы запросить у SCP подписку AE (обычно самого запрашивающего SCU) на получение отчётов о событиях, относящихся к экземплярам UPS, которыми управляет SCP. Поскольку все UPS создаются как экземпляры класса SOP UPS Push, Requested SOP Class UID (0000,0003) в запросе N-ACTION должен быть UID класса SOP UPS Push. См.Section CC.3.1 for further details.

SCU также должен использовать примитив N-ACTION, чтобы запросить у SCP отмену подписки AE, чтобы прекратить получение отчётов о событиях, относящихся к экземплярам UPS, которыми управляет SCP. Информация о действии указана вTable CC.2.3-1. The SCU shall always provide the AE Title that is to receive (or stop receiving) the N-EVENT-REPORTs.

To subscribe for events relating to a single specific UPS instance managed by the SCP, the SCU shall use Идентификатор типа действия 3 (Subscribe to Receive UPS Event Reports) and provide the SOP Instance UID of the specific UPS instance in the N-ACTION primitive request. The SCU shall indicate a need for the UPS instance to persist after its state has changed to COMPLETED or CANCELED by setting the value of the Deletion Lock to TRUE. Otherwise the SCU shall set the value of the Deletion Lock to FALSE.

To unsubscribe for events relating to a single specific UPS instance managed by the SCP, the SCU shall use Идентификатор типа действия 4 (Unsubscribe from Receiving UPS Event Reports) and provide the SOP Instance UID of the specific UPS instance in the N-ACTION primitive request.

To subscribe for events relating to all current and subsequently created UPS instances managed by the SCP, the SCU shall use Идентификатор типа действия 3 (Subscribe to Receive UPS Event Reports) and provide the well-known UID 1.2.840.10008.5.1.4.34.5 in the N-ACTION primitive request. The SCU shall indicate a need for UPS instances to persist after their states have changed to COMPLETED or CANCELED by setting the value of the Deletion Lock to TRUE. Otherwise the SCU shall set the value of the Deletion Lock to FALSE.

Примечание

Такая «глобальная подписка» полезна для SCU, желающих отслеживать всю активность без необходимости регулярно выполнять запросы C-FIND для выявления новых экземпляров UPS.

To subscribe for events relating to a filtered subset of all current and subsequently created UPS instances (Filtered Global Subscription) managed by the SCP, the SCU shall use Идентификатор типа действия 3 (Subscribe to Receive UPS Event Reports) and provide both the well-known UID 1.2.840.10008.5.1.4.34.5.1 and a set of Matching Keys and values in the N-ACTION primitive request (see Section CC.2.3.3.1). The SCU shall indicate a need for UPS instances to persist after their states have changed to COMPLETED or CANCELED by setting the value of the Deletion Lock to TRUE. Otherwise the SCU shall set the value of the Deletion Lock to FALSE.

Примечание

Общеизвестный UID для фильтрованной глобальной подписки (Filtered Global Subscription) отличается от общеизвестного UID глобальной подписки.

To unsubscribe for events relating to all current UPS instances managed by the SCP and also stop being subscribed to subsequently created UPS instances, the SCU shall use Идентификатор типа действия 4 (Unsubscribe from Receiving UPS Event Reports) and provide the well-known UID 1.2.840.10008.5.1.4.34.5 in the N-ACTION primitive request.

Примечание

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

To just stop being subscribed to subsequently created UPS instances, but still continue to receive events for currently subscribed instances managed by the SCP, the SCU shall use Идентификатор типа действия 5 (Suspend Global Subscription) and provide the well-known UID 1.2.840.10008.5.1.4.34.5 in the N-ACTION primitive request.

Для каждого экземпляра UPS, на который SCU установил блокировку удаления — явно для конкретного экземпляра или неявно посредством глобальной подписки с блокировкой, — SCU должен снять блокировку удаления после получения всех необходимых сведений о конечном состоянии данного экземпляра. Блокировка удаления может быть снята либо путём отмены подписки, либо путём подписки со значением Deletion Lock, равным FALSE.

Примечание

SCP будет удерживать экземпляры UPS в состоянии COMPLETED или CANCELED до тех пор, пока не будут сняты все блокировки удаления. Невыполнение SCU снятия блокировки удаления может создавать проблемы для SCP. SCU, не имеющие существенной потребности в сведениях о конечном состоянии либо не способные надёжно снимать блокировки удаления, не должны использовать блокировки удаления.

Успешный код состояния ответа N-ACTION означает, что SCP получил запрос N-ACTION, и состояние подписки для данной AE было успешно изменено.

Примечание

  1. При подписке на конкретный экземпляр SCU также может ожидать получения начального N-EVENT-REPORT, содержащего текущее состояние данного экземпляра UPS. При глобальной подписке со значением Deletion Lock, равным TRUE, SCU может ожидать получения начальных N-EVENT-REPORT для каждого экземпляра, которым в данный момент управляет SCP. Начальные N-EVENT-REPORT для вновь созданных экземпляров, полученные в результате глобальной подписки, будут представлены как переходы в состояние SCHEDULED.

  2. Пользовательский агент UPS-RS отвечает за открытие канала связи для N-EVENT-REPORT (см. Раздел 8.10.4 “Open Notification Connection Transaction” in PS3.18 ). Пользовательский агент UPS-RS также отвечает за повторное установление канала связи для N-EVENT-REPORT в случае его разрыва. Это отличается от подхода DIMSE, при котором SCP UPS открывает ассоциацию для сообщений N-EVENT-REPORT по мере необходимости.

Код состояния ответа N-ACTION со значением Warning «Deletion Lock not granted» означает, что запрошенная SCU подписка AE выполнена успешно, но блокировка удаления не была установлена.

Код состояния ответа N-ACTION со значением Failure означает, что запрошенное изменение состояния подписки не будет обработано, и никакие состояния подписки не были изменены. Действия, предпринимаемые SCU при получении такого статуса, выходят за рамки настоящего стандарта.

В любой момент после получения ответа N-ACTION SCU может освободить ассоциацию, по которой он отправил запрос N-ACTION.

CC.2.3.3 Поведение поставщика сервисного класса (SCP)

По получении запроса N-ACTION SCP должен попытаться обновить глобальное состояние подписки и/или состояние подписки UPS указанной AE в отношении указанного SOP Instance UID, как описано вTable CC.2.3-2 and then return, via the N-ACTION response primitive, the appropriate N-ACTION Response Status Code.

SCP может опционально позволить прикладной сущности подписаться глобально на отфильтрованное множество экземпляров UPS. В этом случае прикладная сущность будет подписана только на существующие и будущие экземпляры UPS, соответствующие критериям поиска, указанным в ключах сопоставления (Matching Keys) запроса N-ACTION (см.Section CC.2.3.3.1). If the SCP does not support Filtered Global Subscription it will return a Failure Status Code of C307H "Failed: Specified SOP Instance UID does not exist or is not a UPS Instance managed by this SCP" (see Table CC.2.3-3).

Статус Success означает, что глобальное состояние подписки и/или состояние подписки UPS для AE, указанной в Receiving AE (0074,1234), было успешно изменено SCP. AE Title, указанный в Receiving AE (0074,1234), может отличаться от AE Title, использованного SCU при согласовании ассоциации. SCP должен использовать AE Title, указанный в Receiving AE (0074,1234). Это позволяет системам подписывать другие системы, которые, как им известно, заинтересованы в событиях для определённого UPS.

Для всех экземпляров UPS, которыми управляет SCP, SCP должен отправлять N-EVENT-REPORT (как описано вSection CC.2.4.3) to AEs that have a UPS Subscription State of "Subscribed with Lock" or "Subscribed w/o Lock". If the SCP also supports the HTTP CreateSubscription service as an origin server, the SCP shall also send HTTP SendEventReport messages (see Section 8.10.5 “Send Event Report Transaction” in PS3.18 ).

После успешной обработки действия по подписке SCP должен отправить начальные N-EVENT-REPORT типа UPS State Report, как указано вTable CC.2.3-2, providing the current status of the UPS Instance to the Receiving AE.

SCP также может отказать как в конкретных, так и в глобальных запросах на подписку, вернув код состояния отказа N-ACTION 0124H «Refused: Not authorized», если отказ обусловлен правами, связанными с задачами или запрашивающей стороной, либо C315H «Failed: SCP does not support Event Reports», если SCP не поддерживает отправку событий. SCP должен документировать в своём заявлении о соответствии, может ли он отказывать в запросах на подписку.

SCP может снимать существующие блокировки удаления, изменяя состояние подписки UPS для AE с «Subscribed with Lock» на «Subscribed w/o Lock» и/или изменяя глобальное состояние подписки для AE с «Global Subscription with Lock» на «Global Subscription w/o Lock». Это предназначено для того, чтобы позволить SCP справляться со сбоями SCU. SCP должен документировать в своём заявлении о соответствии, может ли он снимать блокировку удаления.

SCP также может отказать в части запроса на подписку, касающейся блокировки удаления, — как для конкретной, так и для глобальной подписки. Например, запрос на изменение состояния подписки UPS для AE на «Subscribed with Lock» вместо этого приведёт к состоянию подписки UPS «Subscribed w/o Lock» и статусу Warning (см.Table CC.2.3-3) returned to the requesting SCU. This is intended to deal with Security and related policy restrictions. The SCP must document in its Conformance Statement if it might refuse a Deletion Lock.

Двусторонняя аутентификация машин/пользователей/приложений возможна на этапе установления ассоциации (см. PS3.7 и PS3.15). PS3.7 предоставляет код состояния Failure 0124H «Refused: Not authorized». Дальнейшее требование или документирование функций аутентификации и/или авторизации со стороны SCU или SCP выходит за рамки данного класса SOP.

CC.2.3.3.1 Фильтрованная глобальная подписка

SCP, поддерживающий фильтрованную глобальную подписку (Filtered Global Subscription), должен создавать подписку экземпляра для каждого экземпляра UPS, который соответствовал бы запросу C-FIND с ключами сопоставления, предоставленными в запросе подписки.

SCP должен поддерживать ту же логику сопоставления, что используется для C-FIND (см. Раздел CC.2.8.3).

CC.2.3.4 Коды состояния

Таблица CC.2.3-3 определяет значения кодов состояния, которые могут возвращаться в ответе N-ACTION. Общие значения кодов состояния и поля, связанные со значениями кодов состояния, определены для сервиса DIMSE N-ACTION в PS3.7.

Table CC.2.3-3. N-ACTION Response Status Values [for Subscribe/Unsubscribe to Receive UPS sEvent Reports]

Статус службы

Дополнительное значение

Status Code

Успех

Запрошенное изменение состояния подписки выполнено

0000

Предупреждение

Deletion Lock не предоставлен.

B301

Отказ

Отказано: указанный SOP Instance UID не существует либо не является экземпляром UPS, управляемым данным SCP

C307

Отказано: Receiving AE Title неизвестен данному SCP

C308

Отказано: указанное действие не подходит для указанного экземпляра

C314

Отказано: SCP не поддерживает отчёты о событиях (Event Reports)

C315


CC.2.4 Сообщение об изменении состояния UPS (N-EVENT-REPORT)

Данная операция позволяет SCP уведомить SCU об изменении состояния экземпляра UPS либо об изменении состояния самого SCP. Данная операция вызывается SCP посредством DIMSE-сервиса N-EVENT-REPORT.

CC.2.4.1 Информация отчёта о событии

DICOM AE, заявляющие соответствие классу SOP UPS Event в роли SCU и/или SCP, должны поддерживать Event Type ID и атрибуты отчёта о событии, указанные в Таблица CC.2.4-1.

Table CC.2.4-1. Report a Change in UPS Status - Event Report Information

Имя типа события

Идентификатор типа события

Имя атрибута

Tag

Использование (SCP)

UPS State Report

1

Procedure Step State

(0074,1000)

1

Input Readiness State

(0040,4041)

1

Reason For Cancellation

(0074,1238)

3

Procedure Step Discontinuation Reason Code Sequence

(0074,100e)

3

>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support”

UPS Cancel Requested

2

Requesting AE

(0074,1236)

1

Reason For Cancellation

(0074,1238)

1C

Обязательно, если указано в вызывающем N-ACTION

Procedure Step Discontinuation Reason Code Sequence

(0074,100e)

1C

Обязательно, если указано в вызывающем N-ACTION

>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support”

Contact URI

(0074,100a)

1C

Обязательно, если указано в вызывающем N-ACTION

Contact Display Name

(0074,100c)

1C

Обязательно, если указано в вызывающем N-ACTION

UPS Progress Report

3

Procedure Step Progress Information Sequence

(0074,1002)

1

>Procedure Step Progress

(0074,1004)

3

>Procedure Step Progress Description

(0074,1006)

3

>Procedure Step Progress Parameters Sequence

(0074,1007)

3

>Procedure Step Communications URI Sequence

(0074,1008)

3

>>Contact URI

(0074,100a)

1

>>Contact Display Name

(0074,100c)

3

SCP Status Change

4

SCP Status

(0074,1242)

1

Subscription List Status

(0074,1244)

1

Unified Procedure Step List Status

(0074,1246)

1

UPS Assigned

5

Scheduled Station Name Code Sequence

(0040,4025)

1C

Обязательно, если заполнено в экземпляре UPS

>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support”

Human Performer Code Sequence

(0040,4009)

1C

Обязательно, если заполнено в экземпляре UPS

>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support”

Human Performer's Organization

(0040,4036)

1C

Обязательно, если заполнено в экземпляре UPS


Примечание

Значения атрибутов Progress Information в контексте конкретной задачи не определены, и эти значения могут утратить актуальность после перехода UPS в состояние COMPLETED или CANCELED.

CC.2.4.2 Поведение пользователя сервисного класса (SCU)

SCU должен вернуть, посредством примитива ответа N-EVENT-REPORT, применимый к данному запросу код состояния ответа N-EVENT-REPORT. См.PS3.7 for general response Status Codes.

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

Примечание

SCU может получить N-EVENT-REPORT с Event Type ID, равным 1 (UPS State Report), как в результате изменения состояния UPS, так и в ответ на начальную подписку на UPS (возможно, при первоначальном создании UPS). См.Section CC.2.3.3.

Если SCU, выполняющий UPS, получает для данного экземпляра N-EVENT-REPORT с Event Type ID, равным 2 (UPS Cancel Requested), то этот SCU может по своему усмотрению отменить UPS, как описано вSection CC.2.1.2.

Примечание

  1. Уведомление UPS Cancel Requested включает AE запрашивающего SCU, что может быть полезно выполняющему SCU при оценке значимости/полномочности запроса на отмену.

  2. В уведомлении также могут быть предоставлены Reason For Cancellation, предлагаемая Procedure Step Discontinuation Reason Code Sequence, Contact Display Name и Contact URI лица, ответственного за запрос отмены. Некоторые выполняющие SCU могут найти эту информацию полезной при принятии решения об отмене UPS либо могут предоставить эту информацию оператору, чтобы он мог связаться с этим лицом для уточнения или подтверждения запроса отмены. Если выполняющий SCU решает отменить UPS, он может по своему усмотрению установить Procedure Step Discontinuation Reason Code Sequence в экземпляре UPS на основе предоставленных соответствующих значений.

Если SCU получает для экземпляра N-EVENT-REPORT с Event Type ID, равным 5 (UPS Assigned), и устройство или человек, указанные в уведомлении, соответствуют данному SCU, то UPS был назначен этому SCU.

SCU, желающий начать/прекратить получение N-EVENT-REPORT об экземплярах UPS, может подписаться/отменить подписку, как описано в Раздел CC.2.3.2.

Если SCU получает N-EVENT-REPORT с Event Type ID, равным 4 (SCP Status Change), он не обязан предпринимать какие-либо действия на основе этой информации, однако SCU может рассмотреть такие действия, как: повторная подписка, если список подписки подвергся холодному запуску (Cold Started), проверка (и при необходимости повторное создание) запланированных UPS, если список UPS подвергся холодному запуску, и т. п.

Примечание

SCU может получать события SCP State Change от любого SCP, на который он в данный момент подписан — глобально либо на конкретный UPS.

CC.2.4.3 Поведение поставщика сервисного класса (SCP)

SCP должен указать в примитиве запроса N-EVENT-REPORT Event Type ID и UID экземпляра UPS, с которым связано данное событие. Поскольку все UPS создаются как экземпляры класса SOP UPS Push, Affected SOP Class UID (0000,0002) в запросе N-EVENT-REPORT должен быть UID класса SOP UPS Push. См.Section CC.3.1 for further details. The SCP shall additionally include Attributes related to the event as defined in Table CC.2.4-1.

Каждый раз, когда SCP завершает действие Subscribe to Receive UPS Event Reports (см. Раздел CC.2.3.1) для конкретного экземпляра UPS, SCP должен отправить принимающей AE событие UPS State Report и предоставить текущее значение атрибутов Procedure Step State (0074,1000) и Input Readiness State (0040,4041) для данного экземпляра UPS.

Каждый раз, когда SCP завершает действие Subscribe to Receive UPS Event Reports (см. Раздел CC.2.3.1) для общеизвестного UID 1.2.840.10008.5.1.4.34.5 со значением Deletion Lock, равным TRUE (то есть глобальная подписка с блокировкой), SCP должен отправить принимающей AE событие UPS State Report для каждого экземпляра UPS, которым управляет SCP, и предоставить текущее значение атрибутов Procedure Step State (0074,1000) и Input Readiness State (0040,4041).

Каждый раз при создании SCP нового экземпляра UPS SCP должен отправить событие UPS State Report, указывающее на изменение состояния на SCHEDULED и начальное значение Input Readiness State (0040,4041), всем AE с глобальным состоянием подписки «Global Subscription with Lock» или «Global Subscription w/o Lock». (см.Section CC.2.3)

Каждый раз при создании SCP нового экземпляра UPS, если при этом заполнена Scheduled Station Name Code Sequence (0040,4025) или Scheduled Human Performers Sequence (0040,4034), SCP также должен отправить событие UPS Assigned с текущим содержимым Scheduled Station Name Code Sequence (0040,4025) и Scheduled Human Performers Sequence (0040,4034) всем AE с глобальным состоянием подписки «Global Subscription with Lock» или «Global Subscription w/o Lock».

Далее по тексту «подписанные SCU» означает все AE, для которых состояние подписки UPS данного экземпляра UPS — «Subscribed with Lock» или «Subscribed w/o Lock» (см. Раздел CC.2.3). Если SCP также поддерживает сервис HTTP CreateSubscription в качестве исходного сервера, «подписанные SCU» также включают всех пользовательских агентов CreateSubscription, для которых состояние подписки UPS данного экземпляра UPS — «Subscribed with Lock» или «Subscribed w/o Lock» (см. Раздел 11.10 “Subscribe Transaction” in PS3.18 ).

Каждый раз при изменении SCP атрибута Procedure Step State (0074,1000) экземпляра UPS SCP должен отправить подписанным SCU событие UPS State Report.

Каждый раз при изменении SCP атрибута Input Readiness State (0040,4041) экземпляра UPS SCP должен отправить подписанным SCU событие UPS State Report.

Each time the SCP receives an N-ACTION with an Идентификатор типа действия of 2 (Request UPS Cancel), the SCP shall send a UPS Cancel Requested Event to subscribed SCUs. The SCP shall include the AE Title of the triggering N-ACTION SCU in the Requesting AE Attribute. The SCP shall include the Reason For Cancellation, Contact Display Name and Contact URI Attributes if they were provided in the triggering N-ACTION.

Каждый раз при обновлении SCP Scheduled Station Name Code Sequence (0040,4025) или Scheduled Human Performers Sequence (0040,4034) для экземпляра UPS SCP должен отправить подписанным SCU событие UPS Assigned с текущим содержимым Scheduled Station Name Code Sequence (0040,4025) и Scheduled Human Performers Sequence (0040,4034).

Каждый раз при обновлении SCP Procedure Step Progress (0074,1004), Procedure Step Progress Description (0074,1006) либо содержимого Procedure Step Communications URI Sequence (0074,1008) для экземпляра UPS SCP должен отправить подписанным SCU событие UPS Progress с текущим содержимым Procedure Step Progress Information Sequence (0074,1002).

Каждый раз при перезапуске SCP SCP должен отправить событие SCP Status Change. Если SCP заранее известно, что он будет отключён, он может отправить дополнительное событие SCP Status Change перед отключением. Поскольку списки подписки могут быть неполными или отсутствовать в случае перезапуска, SCP должен вести резервный список AE (например, в виде конфигурационного файла или из LDAP-сервера). SCP должен отправлять события SCP Status Change:

  • всем AE из резервного списка, а также

  • всем AE с глобальным состоянием подписки «Global Subscription with Lock» или «Global Subscription w/o Lock», а также

  • all AEs with a UPS Subscription State of "Subscribed with Lock" or "Subscribed w/o Lock" for any UPS Instance managed by the SCP

Примечание

SCP может по своему усмотрению не отправлять повторяющиеся сообщения одной и той же AE.

Значение SCP Status (0074,1242) должно быть RESTARTED, если SCP отправляет данное сообщение по причине перезапуска, и GOING DOWN, если SCP будет вскоре отключён.

Примечание

SCP, сообщающие о состоянии GOING DOWN, могут прекратить приём новых взаимодействий от SCU до тех пор, пока не перезапустятся.

Когда SCP Status (0074,1242) имеет значение RESTARTED, значение Subscription List Status (0074,1244) должно быть WARM START, если SCP сохранил список подписки в меру своих возможностей, и COLD START, если SCP не сохранил список подписки.

Когда SCP Status (0074,1242) имеет значение RESTARTED, значение Unified Procedure Step List Status (0074,1246) должно быть WARM START, если SCP сохранил список UPS в меру своих возможностей, и COLD START, если SCP не сохранил список UPS.

Если SCP не может успешно доставить N-EVENT-REPORT данному SCU, SCP не обязан ставить сообщение в очередь или повторять попытку, и это не должно подразумевать какого-либо влияния на список подписки или блокировки удаления.

CC.2.4.4 Коды состояния

Для сервиса N-EVENT-REPORT не определены специфичные для сервисного класса значения состояния. См.PS3.7 for general response Status Codes.

CC.2.5 Создание унифицированного этапа процедуры (N-CREATE)

Данная операция позволяет SCU дать указание SCP создать унифицированный этап процедуры. Данная операция вызывается SCU посредством DIMSE-сервиса N-CREATE.

CC.2.5.1 Спецификация атрибутов унифицированного этапа процедуры

Прикладная сущность, заявляющая соответствие классу SOP UPS Push в роли SCU, должна предоставлять все обязательные атрибуты, указанные в Таблица CC.2.5-3. Могут также предоставляться дополнительные атрибуты, определённые IOD UPS.

Прикладная сущность, заявляющая соответствие классу SOP UPS Push в роли SCP, должна поддерживать все обязательные атрибуты, указанные в Таблица CC.2.5-3. Также могут поддерживаться дополнительные атрибуты, определённые IOD UPS.

CC.2.5.1.1 Требования к конечному состоянию UPS

COMPLETED и CANCELED являются конечными состояниями (Final States) экземпляра UPS. Атрибуты и значения экземпляра UPS должны соответствовать определённым требованиям, прежде чем он сможет быть переведён в одно из конечных состояний.

Примечание

При создании экземпляр UPS находится в состоянии SCHEDULED. См.Section CC.1.1 for rules governing state transitions.

Значения атрибутов должны соответствовать кодам конечного состояния (Final State Codes) в столбце Final State Таблица CC.2.5-3, прежде чем Procedure Step State (0074,1000) сможет быть установлен в значение COMPLETED или CANCELED (то есть конечное состояние).

Выполняющим системам рекомендуется обеспечивать, чтобы значения всех атрибутов разумно отражали то, что было сделано, и конечное состояние UPS. Это может включать обнуление атрибутов, которым разрешено быть пустыми и для которых невозможно определить разумное значение. Содержимое UPS должно ясно показывать, был ли этап завершён, какая работа была выполнена, какие результаты были получены и пригодны ли эти результаты к использованию. См.Section GGG.3.1 “What Was Scheduled Vs. What Was Performed” in PS3.17 for a discussion of methods to convey things like partial completion.

Примечание

SCU может по своему усмотрению не распространять либо иным образом не предоставлять некоторые или все экземпляры, созданные в ходе этапа процедуры и указанные в Output Information Sequence (0040,4033).

Table CC.2.5-1. Final State Codes

Код конечного состояния

Значение

R

Состояние UPS не должно устанавливаться в значение COMPLETED или CANCELED, если этот атрибут не имеет значения.

RC

Состояние UPS не должно устанавливаться в значение COMPLETED или CANCELED, если условие выполнено, а этот атрибут не имеет значения.

P

Состояние UPS не должно устанавливаться в значение COMPLETED, если этот атрибут не имеет значения, но может быть установлено в значение CANCELED.

X

Состояние UPS не должно устанавливаться в значение CANCELED, если этот атрибут не имеет значения, но может быть установлено в значение COMPLETED.

O

Состояние UPS может быть установлено в значение COMPLETED или CANCELED, если этот атрибут не имеет значения.


CC.2.5.1.2 Макросы UPS

Для уменьшения объёма и сложности Таблица CC.2.5-3 используется макро-нотация.

Например, вTable CC.2.5-3, a table entry specifying "Include Table CC.2.5-2a “UPS Code Sequence Macro”" should be interpreted as including the following table of text as a substitution. The nesting level for the sequence inclusion is indicated by the nesting level on the reference to the macro. Where the Matching Key type requirement is "*" it should be replaced with the Matching Key type requirement of the sequence Attribute that incorporates this macro.

Для последовательностей кодов, к которым предъявляются требования по поведению N-CREATE, N-SET, N-GET или C-FIND, отличающиеся от требований макроса, содержимое последовательности кодов явно перечислено в таблице, а не задано указанием включения макроса.

Table CC.2.5-2a. UPS Code Sequence Macro

Имя атрибута

Tag

Использование N-CREATE (SCU/SCP)

Использование N-SET (SCU/SCP)

Конечное состояние

Использование N-GET (SCU/SCP)

Тип ключа сопоставления

Тип возвращаемого ключа

Примечание / Тип сопоставления

Code Value

(0008,0100)

1C/1C

1C/1C

-/1C

*

1C

Code Value должен извлекаться с использованием сопоставления по одному значению (Single Value Matching).

Обязательно, если длина значения кода составляет 16 символов или менее, и значение кода не является URN или URL.

Coding Scheme Designator

(0008,0102)

1C/1C

1C/1C

-/1C

*

1C

Coding Scheme Designator должен извлекаться с использованием сопоставления по одному значению (Single Value Matching).

Должно присутствовать, если присутствует Code Value (0008,0100) или Long Code Value (0008,0119). Может присутствовать в остальных случаях.

Coding Scheme Version

(0008,0103)

1C/1C

1C/1C

-/1C

-

1C

Обязательно, если значения Coding Scheme Designator (0008,0102) недостаточно для однозначной идентификации Code Value (0008,0100).

Не должно присутствовать, если Coding Scheme Designator (0008,0102) отсутствует. Может присутствовать в остальных случаях.

Code Meaning

(0008,0104)

1/1

1/1

-/1

-

1

Code Meaning не должен использоваться в качестве ключа сопоставления.

Long Code Value

(0008,0119)

1C/1C

1C/1C

-/1C

*

1C

Long Code Value должен извлекаться с использованием сопоставления по одному значению (Single Value Matching).

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода не является URN или URL.

URN Code Value

(0008,0120)

1C/1C

1C/1C

-/1C

*

1C

Long Code Value должен извлекаться с использованием сопоставления по одному значению (Single Value Matching).

Должно присутствовать, если Code Value (0008,0100) отсутствует, и значение кода является URN или URL.

Mapping Resource

(0008,0105)

3/3

3/3

-/3

-

3

Mapping Resource UID

(0008,0118)

3/3

3/3

-/3

-

3

Context Group Version

(0008,0106)

3/3

3/3

-/3

-

3

Context Group Extension Flag

(0008,010B)

3/3

3/3

-/3

-

3

Context Group Local Version

(0008,0107)

3/3

3/3

-/3

-

3

Context Group Extension Creator UID

(0008,010D)

3/3

3/3

-/3

-

3


Table CC.2.5-2b. UPS Content Item Macro

Имя атрибута

Tag

Использование N-CREATE (SCU/SCP)

Использование N-SET (SCU/SCP)

Конечное состояние

Использование N-GET (SCU/SCP)

Тип ключа сопоставления

Тип возвращаемого ключа

Примечание / Тип сопоставления

Value Type

(0040,A040)

1/1

1/1

-/1

*

1

Тип значения, закодированного в данном элементе «имя-значение».

Перечислимые значения:

DATETIME

DATE

TIME

PNAME

UIDREF

TEXT

CODE

NUMERIC

Concept Name Code Sequence

(0040,A043)

1/1

1/1

-/1

*

1

Кодированное имя понятия данного элемента «имя-значение».

>Include Table CC.2.5-2a “UPS Code Sequence Macro”

Базовый CID не определён.

DateTime

(0040,A120)

1C/1C

1/1

-/1

*

1C

Значение даты и времени для данного элемента «имя-значение».

Требуется, если Value Type (0040,A040) равен DATETIME.

Date

(0040,A121)

1C/1C

1/1

-/1

*

1C

Значение даты для данного элемента «имя-значение».

Требуется, если Value Type (0040,A040) равен DATE.

Time

(0040,A122)

1C/1C

1/1

-/1

*

1C

Значение времени для данного элемента «имя-значение».

Требуется, если Value Type (0040,A040) равен TIME.

Person Name

(0040,A123)

1C/1C

1/1

-/1

*

1C

Значение имени лица для данного элемента «имя-значение».

Требуется, если Value Type (0040,A040) равен PNAME.

UID

(0040,A124)

1C/1C

1/1

-/1

*

1C

Значение UID для данного элемента «имя-значение».

Требуется, если Value Type (0040,A040) равен UIDREF.

Text Value

(0040,A160)

1C/1C

1/1

-/1

*

1C

Текстовое значение для данного элемента «имя-значение».

Требуется, если Value Type (0040,A040) равен TEXT.

Concept Code Sequence

(0040,A168)

1C/1C

1/1

-/1

*

1C

Кодированное значение понятия данного элемента «имя-значение».

Требуется, если Value Type (0040,A040) равен CODE.

>Include Table CC.2.5-2a “UPS Code Sequence Macro”

Базовый CID не определён.

Numeric Value

(0040,A30A)

1C/1C

1/1

-/1

*

1C

Числовое значение для данного элемента «имя-значение».

Требуется, если Value Type (0040,A040) равен NUMERIC.

Measurement Units Code Sequence

(0040,08EA)

1C/1C

1/1

-/1

*

1C

Единицы измерения числового значения данного элемента «имя-значение».

Требуется, если Value Type (0040,A040) равен NUMERIC.

>Include Table CC.2.5-2a “UPS Code Sequence Macro”

Базовый CID 82 “Measurement Unit”


Table CC.2.5-2c. Referenced Instances and Access Macro

Имя атрибута

Tag

Использование N-CREATE (SCU/SCP)

Использование N-SET (SCU/SCP)

Конечное состояние

Использование N-GET (SCU/SCP)

Тип ключа сопоставления

Тип возвращаемого ключа

Примечание / Тип сопоставления

Type of Instances

(0040,E020)

1/1

1/1

-/1

O

1

Study Instance UID

(0020,000D)

1C/1

1C/1

-/1

O

1C

Обязательно, если Type of Instances (0040,E020) равен DICOM, а информационная модель эталонного экземпляра содержит IE Study

Series Instance UID

(0020,000E)

1C/1

1C/1

-/1

O

1C

Обязательно, если Type of Instances (0040,E020) равен DICOM, а информационная модель эталонного экземпляра содержит IE Series

Referenced SOP Sequence

(0008,1199)

1/1

1/1

-/1

O

1

>Referenced SOP Class UID

(0008,1150)

1/1

1/1

-/1

O

1

>Referenced SOP Instance UID

(0008,1155)

1/1

1/1

-/1

O

1

>HL7 Instance Identifier

(0040,E001)

1C/1

1C/1

-/1

O

1C

Обязательно, если Type of Instances (0040,E020) равен CDA.

>Referenced Frame Number

(0008,1160)

1C/1

1C/1

-/2

O

1C

Обязательно, если эталонный экземпляр SOP является многокадровым изображением, ссылка применяется не ко всем кадрам, и Referenced Segment Number (0062,000B) отсутствует.

>Referenced Segment Number

(0062,000B)

1C/1

1C/1

-/2

O

1C

Обязательно, если эталонный экземпляр SOP является сегментацией, ссылка применяется не ко всем сегментам, и Referenced Frame Number (0008,1160) отсутствует.

DICOM Retrieval Sequence

(0040,E021)

1C/1

1C/1

-/1

O

1C

Обязательно, если отсутствуют DICOM Media Retrieval Sequence (0040,E022), WADO Retrieval Sequence (0040,E023), WADO-RS Retrieval Sequence (0040,E025) и XDS Retrieval Sequence (0040,E024). Может присутствовать в остальных случаях.

>Retrieve AE Title

(0008,0054)

1/1

1/1

-/1

O

1

DICOM Media Retrieval Sequence

(0040,E022)

1C/1

1C/1

-/1

O

1C

Обязательно, если отсутствуют DICOM Retrieval Sequence (0040,E021), WADO Retrieval Sequence (0040,E023), WADO-RS Retrieval Sequence (0040,E025) и XDS Retrieval Sequence (0040,E024). Может присутствовать в остальных случаях.

>Storage Media File-Set ID

(0088,0130)

2/2

2/2

-/2

O

2

>Storage Media File-Set UID

(0088,0140)

1/1

1/1

-/1

O

1

WADO Retrieval Sequence

(0040,E023)

1C/1

1C/1

-/1

O

1C

Обязательно, если отсутствуют DICOM Retrieval Sequence (0040,E021), DICOM Media Retrieval Sequence (0040,E022), WADO-RS Retrieval Sequence (0040,E025) и XDS Retrieval Sequence (0040,E024). Может присутствовать в остальных случаях.

>Retrieve URI

(0040,E010)

1/1

1/1

-/1

O

1

XDS Retrieval Sequence

(0040,E024)

1C

1C/1

-/1

O

1C

Обязательно, если отсутствуют DICOM Retrieval Sequence (0040,E021), DICOM Media Retrieval Sequence (0040,E022), WADO-RS Retrieval Sequence (0040,E025) и WADO Retrieval Sequence (0040,E023). Может присутствовать в остальных случаях.

>Repository Unique ID

(0040,E030)

1/1

1/1

-/1

O

1

>Home Community ID

(0040,E031)

3/2

3/2

3/2

O

2

WADO-RS Retrieval Sequence

(0040,E025)

1C/1

1C/1

-/1

O

1C

Обязательно, если отсутствуют DICOM Retrieval Sequence (0040,E021), DICOM Media Retrieval Sequence (0040,E022), WADO Retrieval Sequence (0040,E023) и XDS Retrieval Sequence (0040,E024). Может присутствовать в остальных случаях.

>Retrieve URL

(0008,1190)

1/1

1/1

-/1

O

1

URL, указывающий расположение эталонного(ых) экземпляра(ов).


Table CC.2.5-2d. HL7V2 Hierarchic Designator Macro

Имя атрибута

Tag

Использование N-CREATE (SCU/SCP)

Использование N-SET (SCU/SCP)

Конечное состояние

Использование N-GET (SCU/SCP)

Тип ключа сопоставления

Тип возвращаемого ключа

Примечание / Тип сопоставления

Local Namespace Entity ID

(0040,0031)

1C/1

-/-

-/1

*

1C

Обязательно при создании, если Universal Entity ID (0040,0032) отсутствует; может присутствовать в остальных случаях.

Ключ возврата обязателен, если задан.

Universal Entity ID

(0040,0032)

1C/1

-/-

-/1

*

1C

Обязательно при создании, если Local Namespace Entity ID (0040,0031) отсутствует; может присутствовать в остальных случаях.

Ключ возврата обязателен, если задан.

Universal Entity ID Type

(0040,0033)

1C/1

-/-

-/1

*

1C

Обязательно при создании, если присутствует Universal Entity ID (0040,0032).

Ключ возврата обязателен, если задан.


Table CC.2.5-2e has been retired. See PS3.4-2025d.

Table CC.2.5-2f. SOP Instance Reference Macro

Имя атрибута

Tag

Использование N-CREATE (SCU/SCP)

Использование N-SET (SCU/SCP)

Конечное состояние

Использование N-GET (SCU/SCP)

Тип ключа сопоставления

Тип возвращаемого ключа

Примечание / Тип сопоставления

Referenced SOP Class UID

(0008,1150)

1/1

1/1

-/1

*

1

Referenced SOP Instance UID

(0008,1155)

1/1

1/1

-/1

*

1


Table CC.2.5-2g. Storage Macro

Имя атрибута

Tag

Использование N-CREATE (SCU/SCP)

Использование N-SET (SCU/SCP)

Конечное состояние

Использование N-GET (SCU/SCP)

Тип ключа сопоставления

Тип возвращаемого ключа

Примечание / Тип сопоставления

Referenced SOP Class UID

(0008,1150)

1C/1

1C/1

-/1

O

1C

Обязательно, если запрос на сохранение применяется только к конкретному классу SOP.

DICOM Storage Sequence

(0040,4071)

1C/1

1C/1

-/1

O

1C

Обязательно, если отсутствуют STOW-RS Storage Sequence (0040,4072) и XDS Storage Sequence (0040,4074). Может присутствовать в остальных случаях.

>Destination AE

(2100,0140)

1/1

1/1

-/1

*

1

STOW-RS Storage Sequence

(0040,4072)

1C/1

1C/1

-/1

O

1C

Обязательно, если отсутствуют DICOM Storage Sequence (0040,4071) и XDS Storage Sequence (0040,4074). Может присутствовать в остальных случаях.

>Storage URL

(0040,4073)

1/1

1/1

-/1

*

1

XDS Storage Sequence

(0040,4074)

1C/1

1C/1

-/1

O

1C

Обязательно, если отсутствуют DICOM Storage Sequence (0040,4071) и STOW-RS Storage Sequence (0040,4072). Может присутствовать в остальных случаях.

>Repository Unique ID

(0040,E030)

1/1

1/1

-/1

*

1

>Home Community ID

(0040,E031)

3/2

3/2

3/2

*

2


Table CC.2.5-2h. Issuer of Patient ID Qualifiers Macro

Имя атрибута

Tag

Использование N-CREATE (SCU/SCP)

Использование N-SET (SCU/SCP)

Конечное состояние

Использование N-GET (SCU/SCP)

Тип ключа сопоставления

Тип возвращаемого ключа

Примечание / Тип сопоставления

Universal Entity ID

(0040,0032)

2/2

-/-

O

3/2

O

2

Universal Entity ID Type

(0040,0033)

1C/1

-/-

O

3/2

O

1C

Обязательно, если Universal Entity ID (0040,0032) присутствует в данном элементе со значением.

Identifier Type Code

(0040,0035)

2/2

-/-

O

3/2

O

2

Assigning Facility Sequence

(0040,0036)

2/2

-/-

O

3/2

O

2

Атрибуты Assigning Facility Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching).

>Include Table CC.2.5-2d “HL7V2 Hierarchic Designator Macro”

Assigning Jurisdiction Code Sequence

(0040,0039)

2/2

-/-

O

3/2

O

2

Атрибуты Assigning Jurisdiction Code Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching).

>Include Table CC.2.5-2a “UPS Code Sequence Macro”

Базовый CID 5001 “Country” для кодов стран.

Assigning Agency or Department Code Sequence

(0040,003A)

2/2

-/-

O

3/2

O

2

Атрибуты Assigning Agency or Department Code Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching).

>Include Table CC.2.5-2a “UPS Code Sequence Macro”

Базовый CID не определён.


CC.2.5.1.3 Требования сервиса к атрибутам UPS

Данная таблица объединяет требования к атрибутам для нескольких сервисов DIMSE (N-CREATE, N-SET, N-GET, C-FIND), чтобы обеспечить согласованность требований.

См. Section 5.4.2 for the meaning of the requirement codes used in the N-CREATE, N-SET, N-GET and Return Key columns in the following table.

См. Section C.1.2 for the meaning of the requirement codes used in the Matching Key column in the following table.

См. Table CC.2.5-1 for the meaning of the requirement codes used in the Final State column of the following table.

Table CC.2.5-3. UPS SOP Class N-CREATE/N-SET/N-GET/C-FIND Attributes

Имя атрибута

Tag

Использование N-CREATE (SCU/SCP)

Использование N-SET (SCU/SCP)

Конечное состояние

Использование N-GET (SCU/SCP)

Тип ключа сопоставления

Тип возвращаемого ключа

Примечание / Тип сопоставления

Transaction UID

(0008,1195)

2/2

Должно быть пустым

(see CC.2.6.3)

O

Не допускается

-

-

Не может быть запрошено.

SOP Common Module

Specific Character Set

(0008,0005)

1C/1C

1C/1C

RC

3/1

-

1C

Обязательно, если используется расширенный или заменяющий набор символов

SOP Class UID

(0008,0016)

См. CC.2.5.1.3.1

Не допускается

R

Не допускается

O

1

Однозначно идентифицирует класс SOP унифицированного этапа процедуры.

См. Section CC.3.1 for further explanation.

SOP Instance UID

(0008,0018)

Not allowed.

Экземпляр SOP передаётся в Affected SOP Instance UID (0000,1000)

Not allowed.

Экземпляр SOP передаётся в Requested SOP Instance UID (0000,1001)

R

Not allowed.

Экземпляр SOP передаётся в Requested SOP Instance UID (0000,1001)

U

1

Однозначно идентифицирует экземпляр SOP UPS.

SOP Instance UID должен извлекаться с использованием сопоставления по одному значению (Single Value Matching).

All other Attributes of the SOP Common Module

3/3

3/3

O

3/3

-

-

Unified Procedure Step Scheduled Procedure Information Module

Scheduled Procedure Step Priority

(0074,1200)

1/1

3/1

R

3/1

R

1

Scheduled Procedure Step Priority должен извлекаться с использованием сопоставления по одному значению (Single Value Matching).

Scheduled Procedure Step Modification DateTime

(0040,4010)

-/1

SCP должен использовать время выполнения CREATE

-/1

SCP должен использовать время выполнения SET

R

3/1

O

3

Scheduled Procedure Step Modification DateTime должен извлекаться с использованием сопоставления по одному значению (Single Value Matching) или сопоставления по диапазону (Range Matching).

Procedure Step Label

(0074,1204)

1/1

3/1

O

3/1

R

1

Worklist Label

(0074,1202)

2/1

Если значение не предоставлено SCU, SCP должен заполнить Worklist Label, например, используя значение по умолчанию либо назначив экземпляр UPS логическому рабочему списку.

3/1

O

3/1

R

1

Scheduled Processing Parameters Sequence

(0074,1210)

2/2

3/2

O

3/2

-

2

>Include Table CC.2.5-2b “UPS Content Item Macro”

Scheduled Station Name Code Sequence

(0040,4025)

2/2

3/2

O

3/2

R

2

Атрибуты Scheduled Station Name Code Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching).

Примечание

В сценарии Push SCP-исполнитель должен создать атрибут пустым, но может впоследствии заполнить его самостоятельно.

>Include Table CC.2.5-2a “UPS Code Sequence Macro”

Scheduled Station Class Code Sequence

(0040,4026)

2/2

3/2

O

3/2

R

2

Атрибуты Scheduled Station Class Code Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching).

>Include Table CC.2.5-2a “UPS Code Sequence Macro”

Scheduled Station Geographic Location Code Sequence

(0040,4027)

2/2

3/2

O

3/2

R

2

Атрибуты Scheduled Station Geographic Location Code Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching).

>Include Table CC.2.5-2a “UPS Code Sequence Macro”

Scheduled Human Performers Sequence

(0040,4034)

2C/2C

3/2

O

3/2

R

2

Атрибуты Scheduled Human Performers Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching).

Обязательно, если указан исполнитель-человек.

>Human Performer Code Sequence

(0040,4009)

1/1

1/1

O

-/1

R

1

Атрибуты Scheduled Human Performers Code Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching).

>>Include Table CC.2.5-2a “UPS Code Sequence Macro”

>Human Performer's Name

(0040,4037)

1/1

1/1

O

-/1

O

3

>Human Performer's Organization

(0040,4036)

1/1

1/1

O

-/1

O

3

Scheduled Procedure Step Start DateTime

(0040,4005)

1/1

3/1

R

3/1

R

1

Scheduled Procedure Step Start DateTime должен извлекаться с использованием сопоставления по одному значению (Single Value Matching) или сопоставления по диапазону (Range Matching).

Expected Completion DateTime

(0040,4011)

3/1

3/1

O

3/1

R

3

Expected Completion DateTime должен извлекаться с использованием сопоставления по одному значению (Single Value Matching) или сопоставления по диапазону (Range Matching).

Scheduled Procedure Step Expiration DateTime

(0040,4008)

3/3

3/3

O

3/3

O

3

Scheduled Procedure Step Expiration DateTime должен извлекаться с использованием сопоставления по одному значению (Single Value Matching) или сопоставления по диапазону (Range Matching).

Scheduled Workitem Code Sequence

(0040,4018)

2/2

3/1

O

3/1

R

2

Атрибуты Scheduled Workitem Code Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching).

>Include Table CC.2.5-2a “UPS Code Sequence Macro”

Comments on the Scheduled Procedure Step

(0040,0400)

2/2

3/1

O

3/1

O

3

Input Readiness State

(0040,4041)

1/1

3/1

R

3/1

R

1

Input Readiness State должен извлекаться с использованием сопоставления по одному значению (Single Value Matching).

Input Information Sequence

(0040,4021)

2/2

3/2

O

3/2

O

2

Атрибуты Input Information Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching).

>Include Table CC.2.5-2c “Referenced Instances and Access Macro”

Study Instance UID

(0020,000D)

1C/2

3/2

O

3/2

O

2

Обязательно, если ожидается, что рабочий элемент приведёт к созданию каких-либо составных экземпляров DICOM, чей IOD содержит IE Study.

Возможны ситуации, когда исполнитель не использует Study Instance UID, предложенный планировщиком.

Output Destination Sequence

(0040,4070)

3/3

3/3

O

3/3

O

3

Атрибуты Output Destination Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching).

>Include Table CC.2.5-2g “Storage Macro”

All other Attributes of the Unified Procedure Step Scheduled Procedure Information Module

3/3

3/3

O

3/3

-

-

Unified Procedure Step Relationship Module

Patient's Name

(0010,0010)

2/2

Не допускается

O

3/2

R

2

Patient ID

(0010,0020)

1C/2

Не допускается

O

3/2

R

2

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

См. раздел C.30.4.1 “Patient Identification” в PS3.3

Issuer of Patient ID

(0010,0021)

2/2

-/-

O

3/2

R

2

Issuer of Patient ID Qualifiers Sequence

(0010,0024)

2/2

-/-

O

3/2

O

2

>Include Table CC.2.5-2h “Issuer of Patient ID Qualifiers Macro”

Other Patient IDs Sequence

(0010,1002)

2/2

3/3

O

3/2

O

2

>Patient ID

(0010,0020)

1/1

1/1

O

-/1

O

1

>Issuer of Patient ID

(0010,0021)

2/2

-/-

O

-/2

R

2

>Issuer of Patient ID Qualifiers Sequence

(0010,0024)

2/2

-/-

O

-/2

O

2

>>Include Table CC.2.5-2h “Issuer of Patient ID Qualifiers Macro”

>Type of Patient ID

(0010,0022)

3/3

3/3

O

3/3

O

3

Patient's Birth Date

(0010,0030)

2/2

Не допускается

O

3/2

R

2

Patient's Sex

(0010,0040)

2/2

Не допускается

O

3/2

R

2

Gender Identity Sequence

(0010,0041)

3/3

-/-

O

3/3

O

3

>Gender Identity Code Sequence

(0010,0044)

1/1

-/-

O

-/1

O

1

>Include Table CC.2.5-2a “UPS Code Sequence Macro”

DCID 7458 “Person Gender Identity”

>Effective Start DateTime

(0040,A034)

3/3

-/-

O

-/3

O

3

>Effective Stop DateTime

(0040,A035)

3/3

-/-

O

-/3

O

3

>Gender Identity Comment

(0010,0045)

3/3

-/-

O

-/3

O

3

Sex Parameters for Clinical Use Category Sequence

(0010,0043)

3/3

-/-

O

3/3

O

3

>Sex Parameters for Clinical Use Category Code Sequence

(0010,0046)

1/1

-/-

O

-/1

O

1

>Include Table CC.2.5-2a “UPS Code Sequence Macro”

DCID 7459 “Category of Sex Parameters for Clinical Use”

>Effective Start DateTime

(0040,A034)

3/3

-/-

O

-/3

O

3

>Effective Stop DateTime

(0040,A035)

3/3

-/-

O

-/3

O

3

>Sex Parameters for Clinical Use Category Comment

(0010,0042)

2C/2C

-/-

O

-/2C

O

3

Обязательно, если Sex Parameters for Clinical Use Category Code Sequence (0010,0046) равен (131232, DCM, «Specified»). Может присутствовать в остальных случаях.

>Sex Parameters for Clinical Use Category Reference

(0010,0047)

2C/2C

-/-

O

-/2C

O

3

Обязательно, если Sex Parameters for Clinical Use Category Code Sequence (0010,0046) равен (131232, DCM, «Specified»). Может присутствовать в остальных случаях.

Person Names to Use Sequence

(0010,0011)

3/3

-/-

O

3/3

O

3

>Name to Use

(0010,0012)

1/1

-/-

O

-/1

O

1

>Effective Start DateTime

(0040,A034)

3/3

-/-

O

-/3

O

3

>Effective Stop DateTime

(0040,A035)

3/3

-/-

O

-/3

O

3

>Name to Use Comment

(0010,0013)

3/3

-/-

O

-/3

O

3

Third Person Pronouns Sequence

(0010,0014)

3/3

-/-

O

3/3

O

3

>Pronoun Code Sequence

(0010,0015)

1/1

-/-

O

-/1

O

1

>Include Table CC.2.5-2a “UPS Code Sequence Macro”

DCID 7448 “Third Person Pronoun Set”

>Effective Start DateTime

(0040,A034)

3/3

-/-

O

-/3

O

3

>Effective Stop DateTime

(0040,A035)

3/3

-/-

O

-/3

O

3

>Pronoun Comment

(0010,0016)

3/3

-/-

O

-/3

O

3

Referenced Patient Photo Sequence

(0010,1100)

3/3

3/3

O

3/3

-

3

>Include Table CC.2.5-2c “Referenced Instances and Access Macro”

Admission ID

(0038,0010)

2/2

Не допускается

O

3/2

R

2

Issuer of Admission ID Sequence

(0038,0014)

2/2

Не допускается

O

3/2

R

2

>Include Table CC.2.5-2d “HL7V2 Hierarchic Designator Macro”

Admitting Diagnoses Description

(0008,1080)

2/2

Не допускается

O

3/2

O

2

Admitting Diagnoses Code Sequence

(0008,1084)

2/2

Не допускается

O

3/2

O

2

Атрибуты Admitting Diagnoses Code Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching).

>Include Table CC.2.5-2a “UPS Code Sequence Macro”.

Referenced Request Sequence

(0040,A370)

2/2

Не допускается

O

3/2

R

2

Может быть «изменено», пока UPS находится в состоянии SCHEDULED, путём отмены и повторного создания с «правильными» значениями.

>Study Instance UID

(0020,000D)

1/1

Не допускается

O

-/1

O

1

>Accession Number

(0008,0050)

2/2

Не допускается

O

-/2

R

2

>Issuer of Accession Number Sequence

(0008,0051)

2/2

Не допускается

O

-/2

R

2

Order Placer Identifier Sequence должен получаться только с помощью сопоставления последовательности (Sequence Matching).

>>Include Table CC.2.5-2d “HL7V2 Hierarchic Designator Macro”

>Placer Order Number/Imaging Service Request

(0040,2016)

3/1

Не допускается

O

-/1

O

1C

Обязательно, если задано.

>Order Placer Identifier Sequence

(0040,0026)

2/2

Не допускается

O

-/2

O

2

Атрибуты Order Placer Identifier Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching).

>>Include Table CC.2.5-2d “HL7V2 Hierarchic Designator Macro”

>Filler Order Number/Imaging Service Request

(0040,2017)

3/1

Не допускается

O

-/1

O

1C

Обязательно, если задано.

>Order Filler Identifier Sequence

(0040,0027)

2/2

Не допускается

O

-/2

O

2

Атрибуты Order Filler Identifier Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching).

>>Include Table CC.2.5-2d “HL7V2 Hierarchic Designator Macro”

>Requested Procedure ID

(0040,1001)

2/2

Не допускается

O

-/2

R

2

>Requested Procedure Description

(0032,1060)

2/2

Не допускается

O

-/2

O

2

>Requested Procedure Code Sequence

(0032,1064)

2/2

Не допускается

O

-/2

O

2

>>Include Table CC.2.5-2a “UPS Code Sequence Macro”

>Reason for the Requested Procedure

(0040,1002)

3/3

3/3

O

-/3

O

3

>Reason for Requested Procedure Code Sequence

(0040,100A)

3/3

3/3

O

-/3

O

3

>>Include Table CC.2.5-2a “UPS Code Sequence Macro”

>Requested Procedure Comments

(0040,1400)

3/3

3/3

O

-/3

O

1C

Обязательно, если задано.

>Confidentiality Code

(0040,1008)

3/3

3/3

O

-/3

O

3

>Names of Intended Recipients of Results

(0040,1010)

3/3

3/3

O

-/3

O

3

>Imaging Service Request Comments

(0040,2400)

3/3

3/3

O

-/3

O

3

>Requesting Physician

(0032,1032)

3/3

3/3

O

-/3

O

3

>Requesting Service

(0032,1033)

3/1

3/1

O

-/3

R

3

>Requesting Service Code Sequence

(0032,1034)

3/3

3/3

O

-/3

O

3

>>Include Table CC.2.5-2a “UPS Code Sequence Macro”

>Issue Date of Imaging Service Request

(0040,2004)

3/3

3/3

O

-/3

O

3

>Issue Time of Imaging Service Request

(0040,2005)

3/3

3/3

O

-/3

O

3

>Referring Physician's Name

(0008,0090)

3/3

3/3

O

-/3

O

3

Replaced Procedure Step Sequence

(0074,1224)

1C/1C

Не допускается

O

3/2

R

3

Обязательно, если UPS заменяет другой этап процедуры.

>Include Table CC.2.5-2f “SOP Instance Reference Macro”

All other Attributes of the Unified Procedure Step Relationship Module

3/3

3/3

O

3/3

-

-

Patient Demographic Module

All Attributes of the Patient Demographic Module

3/3

3/3

O

3/3

-

-

Patient Medical Module

Medical Alerts

(0010,2000)

3/2

3/2

O

3/2

O

2C

Обязательно, если присутствует.

Pregnancy Status

(0010,21C0)

3/2

3/2

O

3/2

O

2C

Обязательно, если присутствует.

Special Needs

(0038,0050)

3/2

3/2

O

3/2

O

2C

Обязательно, если присутствует.

All other Attributes of the Patient Medical Module

3/3

3/3

O

3/3

O

3

Visit Identification Module

All Attributes of the Visit Identification Module

3/3

3/3

O

3/3

-

-

Visit Status Module

All Attributes of the Visit Status Module

3/3

3/3

O

3/3

-

-

Visit Admission Module

All Attributes of the Visit Admission Module

3/3

3/3

O

3/3

-

-

Unified Procedure Step Progress Information Module

Procedure Step State

(0074,1000)

1/1

Должно быть создано со значением «SCHEDULED»

-/-.

Use N-ACTION

R

3/1

R

1

Procedure Step State должен извлекаться с использованием сопоставления по одному значению (Single Value Matching)

Procedure Step Progress Information Sequence

(0074,1002)

2/2

Должно быть пустым

3/2

X

3/2

2

>Procedure Step Progress

(0074,1004)

-/-

3/1

O

-/1

-

-

>Procedure Step Progress Description

(0074,1006)

-/-

3/1

O

-/1

-

-

>Procedure Step Progress Parameters Sequence

(0074,1007)

-/-

3/3

O

-/3

>>Include Table CC.2.5-2b “UPS Content Item Macro”

>>Content Item Modifier Sequence

(0040,0441)

-/-

3/3

O

-/3

>>>Include Table CC.2.5-2b “UPS Content Item Macro”

>Procedure Step Communications URI Sequence

(0074,1008)

-/-

3/1

O

-/1

-

-

>>Contact URI

(0074,100a)

-/-

1/1

O

-/1

-

-

>>Contact Display Name

(0074,100c)

-/-

3/1

O

-/1

-

-

>Procedure Step Cancellation DateTime

(0040,4052)

-/-

3/1

X

-/1

-

-

Если UPS State (0074,1000) изменяется на CANCELED, а данный атрибут не имеет значения, SCP должен заполнить его текущими датой и временем.

>Reason For Cancellation

(0074,1238)

-/-

3/1

O

-/1

-

-

>Procedure Step Discontinuation Reason Code Sequence

(0074,100e)

-/-

3/1

X

-/1

>>Include Table CC.2.5-2a “UPS Code Sequence Macro”

Unified Procedure Step Performed Procedure Information Module

Unified Procedure Step Performed Procedure Sequence

(0074,1216)

2/2

Должно быть создано пустым

3/2

P

3/2

-

-

См. CC.2.5.1.3.2.

>Actual Human Performers Sequence

(0040,4035)

-/-

3/1

RC

-/1

O

1C

Должно быть указано, если известно.

Ключ возврата обязателен, если задан.

Атрибуты Actual Human Performers Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching).

>>Human Performer Code Sequence

(0040,4009)

-/-

3/1

RC

-/1

-

-

Должно быть указано, если известно.

>>>Include Table CC.2.5-2a “UPS Code Sequence Macro”

>>Human Performer's Name

(0040,4037)

-/-

3/1

RC

-/1

-

-

Должно быть указано, если известно

>>Human Performer's Organization

(0040,4036)

-/-

3/1

O

-/1

-

-

>Performed Station Name Code Sequence

(0040,4028)

-/-

3/2

P

-/2

O

3

>>Include Table CC.2.5-2a “UPS Code Sequence Macro”

>Performed Station Class Code Sequence

(0040,4029)

-/-

3/2

O

-/2

-

-

>>Include Table CC.2.5-2a “UPS Code Sequence Macro”

>Performed Station Geographic Location Code Sequence

(0040,4030)

-/-

3/2

O

-/2

-

-

>>Include Table CC.2.5-2a “UPS Code Sequence Macro”

>Performed Procedure Step Start DateTime

(0040,4050)

-/-

3/1

P

-/1

-

-

>Performed Procedure Step Description

(0040,0254)

-/-

3/1

O

-/1

-

-

>Comments on the Performed Procedure Step

(0040,0280)

-/-

3/1

O

-/1

-

-

>Performed Workitem Code Sequence

(0040,4019)

-/-

3/1

P

-/1

-

-

>>Include Table CC.2.5-2a “UPS Code Sequence Macro”

>Performed Processing Parameters Sequence

(0074,1212)

-/-

3/1

O

-/1

-

-

>>Include Table CC.2.5-2b “UPS Content Item Macro”

>Performed Procedure Step End DateTime

(0040,4051)

-/-

3/1

P

-/1

O

1C

Обязательно, если задано.

>Output Information Sequence

(0040,4033)

-/-

2/2

P

-/2

-

-

Если соответствующие выходные объекты отсутствуют, данная последовательность может не содержать элементов.

>Include Table CC.2.5-2c “Referenced Instances and Access Macro”


CC.2.5.1.3.1 UPS SOP Class UID

SOP Class UID должен быть установлен SCP в значение 1.2.840.10008.5.1.4.34.6.1.

CC.2.5.1.3.2 Unified Procedure Step Performed Procedure Sequence

Атрибуты Unified Procedure Step Performed Procedure Sequence (0074,1216) должны получаться только с помощью сопоставления последовательности (Sequence Matching).

CC.2.5.2 Поведение пользователя сервисного класса (SCU)

SCU использует N-CREATE, чтобы запросить у SCP планирование нового UPS.

SCU должен указать в примитиве запроса N-CREATE UPS Push SOP Class UID и SOP Instance UID создаваемого UPS, для которого предоставляются значения атрибутов. См.Section CC.3.1 for further discussion of UPS SOP Class UIDs.

SCU должен предоставить в примитиве запроса N-CREATE значения атрибутов для всех обязательных атрибутов UPS, указанных в Таблица CC.2.5-3. Кроме того, могут предоставляться значения для необязательных атрибутов, указанных в Таблица CC.2.5-3.

SCU должен указать в примитиве запроса N-CREATE значение «SCHEDULED» для атрибута Procedure Step State (0074,1000).

CC.2.5.3 Поведение поставщика сервисного класса (SCP)

SCP должен создавать и вести экземпляры UPS в соответствии с запросами на создание и как указано в Таблица CC.2.5-3.

SCP должен вернуть, посредством примитива ответа N-CREATE, применимый к данному запросу код состояния ответа N-CREATE.

SCP должен принимать запросы на создание только в том случае, если значение атрибута Procedure Step State (0074,1000) равно «SCHEDULED». Если атрибут Procedure Step State имеет иное значение, SCP должен отклонить запрос.

SCP может изменять атрибуты экземпляра UPS, например, чтобы исправить недопустимые значения атрибутов. Описание изменений, которые может вносить SCP, должно быть задокументировано в заявлении о соответствии SCP.

SCP также может создавать и вести экземпляры UPS без получения запроса N-CREATE для экземпляра UPS, например, на основе внутренней логики, ввода оператора или сообщений HL7. Содержимое экземпляра, созданного SCP, всё равно должно соответствовать требованиям N-CREATE вTable CC.2.5-3.

При создании нового экземпляра UPS SCP должен обновить состояние подписки UPS данного экземпляра для каждой AE с глобальной подпиской, как описано вSection CC.2.3. Optionally, the SCP may create a UPS Subscription for the N-CREATE SCU AE; such behavior shall be documented in the Conformance Statement.

При создании нового экземпляра UPS SCP должен отправить UPS State Report (если он поддерживает класс SOP UPS Event), как описано вSection CC.2.4.3 regardless of whether the creation was based on an N-CREATE or on internal logic.

Двусторонняя аутентификация машин/пользователей/приложений возможна на этапе установления ассоциации (см. PS3.7 и PS3.15). PS3.7 предоставляет код состояния Failure 0124H «Refused: Not authorized». Особых требований к выполнению авторизации не установлено.

CC.2.5.4 Коды состояния

Таблица CC.2.5-4 определяет значения кодов состояния, которые могут возвращаться в ответе N-CREATE. Общие значения кодов состояния и поля, связанные со значениями кодов состояния, определены для сервиса DIMSE N-CREATE в PS3.7.

Table CC.2.5-4. N-CREATE Response Status Values [for Create a Unified Procedure Step]

Статус службы

Дополнительное значение

Status Code

Успех

UPS создан согласно запросу

0000

Предупреждение

UPS создан с изменениями

B300

Отказ

Отказано: предоставленное значение UPS State не равно «SCHEDULED».

C309


CC.2.6 Задание информации унифицированного этапа процедуры (N-SET)

Данная операция позволяет SCU установить значения атрибутов экземпляра UPS и предоставить сведения о конкретном реальном UPS, находящемся под контролем данного SCU. Данная операция вызывается SCU посредством DIMSE-сервиса N-SET.

CC.2.6.1 Спецификация подмножества IOD унифицированного этапа процедуры

Прикладная сущность, заявляющая соответствие классу SOP UPS Pull в роли SCU, может по своему выбору изменять подмножество атрибутов, поддерживаемых SCP. Прикладная сущность, заявляющая соответствие в роли SCP классу SOP UPS Pull, должна поддерживать атрибуты, указанные вTable CC.2.5-3

CC.2.6.2 Поведение пользователя сервисного класса (SCU)

SCU должен указать в примитиве запроса N-SET UID экземпляра UPS, для которого требуется установить значения атрибутов. Поскольку все UPS создаются как экземпляры класса SOP UPS Push, Requested SOP Class UID в запросе N-SET должен быть UID класса SOP UPS Push. См.Section CC.3.1 for further details.

При выполнении N-SET для экземпляра UPS, находящегося в состоянии SCHEDULED, атрибут Transaction UID не должен присутствовать в запросе. Для экземпляра UPS в состоянии IN PROGRESS SCU должен предоставить текущий Transaction UID (0008,1195) в качестве атрибута.

SCU разрешается устанавливать значения атрибутов, указанные в Таблица CC.2.5-3. SCU должен указать список атрибутов, для которых он хочет установить значения. SCU должен предоставить, в одном или нескольких примитивах запроса N-SET, значения атрибутов, указанные в Таблица CC.2.5-3.

При изменении последовательности SCU должен включить в запрос N-SET все элементы последовательности, а не только изменяемые элементы.

Запросы N-SET должны быть атомарными (неделимыми) и идемпотентными (повторное выполнение не даёт дополнительного эффекта). Поскольку N-GET может произойти между двумя запросами N-SET, любой отдельный N-SET должен оставлять экземпляр UPS во внутренне непротиворечивом состоянии (то есть когда несколько атрибутов нужно обновить как группу, это следует делать как несколько атрибутов в одном запросе N-SET, а не как несколько запросов N-SET)

SCU не должен устанавливать значение атрибута Procedure Step State (0074,1000) с помощью N-SET. Procedure Step State управляется с помощью N-ACTION, как описано вSection CC.2.1

SCU должен создать или установить все атрибуты, необходимые для соответствия требованиям конечного состояния, прежде чем использовать N-ACTION для установки значения Procedure Step State (0074,1000) в «COMPLETED» или «CANCELED». См.Section CC.2.5.1.1 for further details.

После того как Procedure Step State (0074,1000) был установлен в «COMPLETED» или «CANCELED», SCU больше не должен изменять данный экземпляр SOP UPS.

Примечание

SCU может устанавливать только те значения атрибутов, которые уже были созданы запросом N-CREATE.

CC.2.6.3 Поведение поставщика сервисного класса (SCP)

SOP Class UID указанного экземпляра UPS всегда будет UID класса SOP UPS Push, который может не совпадать с классом SOP UPS, согласованным с SCU. См.Section CC.3.1 for further details.

SCP должен поддерживать изменения атрибутов экземпляра UPS, указанные SCU в запросе установки, как указано в Таблица CC.2.5-3.

SCP должен отклонить запросы на установку для UPS в состоянии IN PROGRESS и не изменять UPS, если запрос на установку не включает атрибут Transaction UID (0008,1195) с тем же значением, что в данный момент записано в экземпляре UPS.

SCP должен отклонить запросы на установку для UPS в состоянии COMPLETED или CANCELED.

SCP должен использовать значение атрибута Specific Character Set (0008,0005), чтобы должным образом изменить своё внутреннее представление таким образом, чтобы последующие операции отражали сочетание наборов символов, используемых атрибутами в данном запросе, и наборов символов, используемых атрибутами, которые не были изменены.

SCP должен вернуть, посредством примитива ответа N-SET, применимый к данному запросу код состояния ответа N-SET, как указано вSection CC.2.6.4.

SCP может самостоятельно изменять любые атрибуты экземпляра UPS независимо от запроса N-SET, например, если SCP сам выполняет данный этап процедуры, если установлено, что выполняющий SCU вышел из строя, либо если необходимо исправить значения атрибутов после завершения процедуры для проведения сверки данных. Описание изменений (coercions), которые может вносить SCP, должно быть задокументировано в заявлении о соответствии SCP.

Двусторонняя аутентификация машин/пользователей/приложений возможна на этапе установления ассоциации (см. PS3.7 и PS3.15). PS3.7 предоставляет код состояния Failure 0124H «Refused: Not authorized». Особых требований к выполнению авторизации не установлено.

CC.2.6.4 Коды состояния

Таблица CC.2.6-1 определяет значения кодов состояния, которые могут возвращаться в ответе N-SET. Общие значения кодов состояния и поля, связанные со значениями кодов состояния, определены для сервиса DIMSE N-SET в PS3.7.

Table CC.2.6-1. N-SET Response Status Values [for Set Unified Procedure Step Information]

Статус службы

Дополнительное значение

Status Code

Успех

Запрошенное изменение значений атрибутов выполнено

0000

Предупреждение

Запрошенные необязательные атрибуты не поддерживаются.

0001

Недопустимые значения приведены к допустимым

B305

Отказ

Отказано: UPS не находится в состоянии «IN PROGRESS»

C310

Отказано: не предоставлен правильный Transaction UID

C301

Отказано: UPS больше не может быть обновлён

C300

Отказано: указанный SOP Instance UID не существует либо не является экземпляром UPS, управляемым данным SCP

C307


CC.2.7 Получение информации унифицированного этапа процедуры (N-GET)

Данная операция позволяет SCU получить от SCP сведения о конкретном реальном этапе процедуры, представленном как экземпляр унифицированного этапа процедуры. Данная операция вызывается SCU посредством DIMSE-сервиса N-GET.

CC.2.7.1 Спецификация подмножества IOD унифицированного этапа процедуры

Прикладная сущность, заявляющая соответствие классам SOP UPS Pull или UPS Watch в роли SCU, может по своему выбору получать подмножество значений атрибутов, поддерживаемых SCP. Прикладная сущность, заявляющая соответствие в роли SCP этим классам SOP, должна поддерживать атрибуты, указанные вTable CC.2.5-3.

CC.2.7.2 Поведение пользователя сервисного класса (SCU)

SCU использует N-GET, чтобы запросить у SCP предоставление атрибутов и значений экземпляра унифицированного этапа процедуры. Поскольку все UPS создаются как экземпляры класса SOP UPS Push, Affected SOP Class UID (0000,0002) в запросе N-GET должен быть UID класса SOP UPS Push. См.Section CC.3.1 for further details.

SCU должен указать в сервисном элементе N-GET UID экземпляра SOP, из которого требуется получить атрибуты.

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

SCU не должен запрашивать значение атрибута Transaction UID (0008,1195).

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

Примечание

Для точной интерпретации набора символов, использованного в возвращаемых значениях атрибутов, рекомендуется запрашивать значение атрибута Specific Character Set (0008,0005) в примитиве запроса N-GET.

SCU разрешается запрашивать и он должен быть способен получать значения для любого атрибута, указанного в Таблица CC.2.5-3. Кроме того, могут запрашиваться значения для необязательных атрибутов.

SCU должен быть способен принять все запрошенные значения атрибутов, предоставленные SCP в ответ на примитив индикации N-GET.

Примечание

Если SCU или пользователю потребуется доступ к атрибутам конечного состояния, SCU обязан подписаться (см. Раздел CC.2.2), чтобы получать события изменения состояния и затем незамедлительно выполнить N-GET необходимых атрибутов по получении уведомления об изменении состояния на COMPLETED или CANCELED. Если SCU устанавливает блокировку удаления при подписке, экземпляр в состоянии COMPLETED или CANCELED продолжит сохраняться на SCP, расходуя ресурсы. Важно, чтобы SCU снял блокировку (например, отменив подписку) после выполнения N-GET для экземпляра в состоянии COMPLETED или CANCELED.

CC.2.7.3 Поведение поставщика сервисного класса (SCP)

SOP Class UID указанного экземпляра UPS всегда будет UID класса SOP UPS Push, который может не совпадать с классами SOP UPS, согласованными с SCU. См.Section CC.3.1 for further details.

SCP должен вернуть SCU, посредством примитива ответа N-GET, выбранные значения атрибутов из указанного экземпляра унифицированного этапа процедуры.

Примечание

Требование к SCP отвечать на запросы N-GET для экземпляров UPS, перешедших в состояние COMPLETED или CANCELED, ограничено. См.Section CC.2.1.3 Service Class Provider Behavior.

SCP не должен возвращать атрибут Transaction UID (0008,1195). Это необходимо для сохранения роли данного атрибута как блокировки доступа.

SCP должен вернуть, посредством примитива ответа N-GET, применимый к данному запросу код состояния ответа N-GET. Статус Failure означает, что SCP не получил данный экземпляр SOP.

Двусторонняя аутентификация машин/пользователей/приложений возможна на этапе установления ассоциации (см. PS3.7 и PS3.15). PS3.7 предоставляет код состояния Failure 0124H «Refused: Not authorized». Дальнейшее требование или документирование функций аутентификации и/или авторизации со стороны SCU или SCP выходит за рамки данного класса SOP.

CC.2.7.4 Коды состояния

Таблица CC.2.7-1 определяет значения кодов состояния, которые могут возвращаться в ответе N-GET. Общие значения кодов состояния и поля, связанные со значениями кодов состояния, определены для сервиса DIMSE N-GET в PS3.7.

Table CC.2.7-1. N-GET Response Status Values [for Get Unified Procedure Step Information]

Статус службы

Дополнительное значение

Status Code

Предупреждение

Запрошенные необязательные атрибуты не поддерживаются

0001

Отказ

Отказано: указанный SOP Instance UID не существует либо не является экземпляром UPS, управляемым данным SCP

C307


CC.2.8 Поиск унифицированного этапа процедуры (C-FIND)

Данная операция позволяет SCU найти и получить сведения об интересующих его экземплярах унифицированного этапа процедуры, которыми управляет SCP. Данная операция вызывается SCU посредством DIMSE-сервиса C-FIND. SCP обрабатывает такие запросы, сопоставляя управляемые им экземпляры UPS с ключами, присутствующими в идентификаторе, и возвращает ответы C-FIND.

SCU может выполнять поиск экземпляра UPS с намерением начать работу над одним из них либо с намерением подписаться на отслеживание хода выполнения данного экземпляра.

CC.2.8.1 Операция

CC.2.8.1.1 Модель «сущность-связь» (E/R)

В ответ на данный запрос C-FIND SCP может отправить несколько ответов C-FIND (то есть по одному ответу C-FIND на каждый подходящий элемент рабочего списка). Каждый элемент рабочего списка описывает одну задачу и связанную с ней информацию.

Информационная модель унифицированного этапа процедуры представлена диаграммой «сущность-связь», показанной на Рисунок CC.2.8-1.

Unified Procedure Step E-R Diagram

Figure CC.2.8-1. Unified Procedure Step E-R Diagram


В модели присутствует только одна информационная сущность — унифицированный этап процедуры. Атрибуты унифицированного этапа процедуры можно найти вTable CC.2.5-3.

CC.2.8.1.2 Параметры сервиса C-FIND
CC.2.8.1.2.1 SOP Class UID

Affected SOP Class UID DIMSE-запроса C-FIND всегда должен быть классом SOP UPS, согласованным для контекста презентации, в рамках которого запрашивается сервис. Это всегда будет класс SOP UPS Pull, класс SOP UPS Watch или класс SOP UPS Query. См.Section CC.3.1 for further details.

C-FIND выполняется применительно к информационной модели унифицированного этапа процедуры, показанной на Рисунок CC.2.8-1.

CC.2.8.1.2.2 Priority

Атрибут Priority определяет запрошенный приоритет операции C-FIND по отношению к другим операциям DIMSE, выполняемым тем же SCP.

Обработка запросов приоритета не является обязательной для SCP. Поддерживает ли SCP обработку приоритета и значение различных уровней приоритета должны быть указаны в заявлении о соответствии SCP.

CC.2.8.1.3 Идентификатор

Both the C-FIND request and response contain an Identifier encoded as a Data Set (see PS3.5).

CC.2.8.1.3.1 Структура идентификатора запроса

Идентификатор в запросе C-FIND должен содержать:

  • Значения ключевых атрибутов, подлежащие сопоставлению со значениями атрибутов, указанных в классе SOP, идентифицированном Affected SOP Class UID.

  • Условно — атрибут Specific Character Set (0008,0005). Данный атрибут должен быть включён, если в каком-либо из атрибутов идентификатора запроса могут использоваться расширенные или заменяющие наборы символов. В противном случае он не должен включаться.

  • Условно — атрибут Timezone Offset From UTC (0008,0201). Данный атрибут должен быть включён, если значения ключевых атрибутов времени подлежат явной интерпретации в указанном местном часовом поясе. В противном случае он не должен присутствовать, то есть не должен передаваться со значением нулевой длины.

Примечание

Это означает, что Specific Character Set (0008,0005) включается, если SCU поддерживает расширенные или заменяющие наборы символов в контексте данного сервиса. Он не будет включён, если расширенные или заменяющие наборы символов не поддерживаются SCU.

Ключевые атрибуты и допустимые для запроса значения должны быть определены в определении класса SOP, соответствующем Affected SOP Class UID для соответствующей информационной модели унифицированного этапа процедуры.

CC.2.8.1.3.2 Структура идентификатора ответа

Ответ C-FIND не должен содержать атрибуты, которые отсутствовали в запросе или не указаны в настоящем разделе.

Идентификатор в ответе C-FIND должен содержать:

  • Key Attributes with values corresponding to Key Attributes contained in the Identifier of the request (Key Attributes as defined in Table CC.2.5-3.)

  • Условно — атрибут Specific Character Set (0008,0005). Данный атрибут должен быть включён, если в каком-либо из атрибутов идентификатора ответа могут использоваться расширенные или заменяющие наборы символов. В противном случае он не должен включаться. SCP сервиса C-FIND не обязан возвращать ответы в наборе символов, запрошенном SCU, если этот набор символов не поддерживается SCP. SCP может возвращать ответы с иным набором символов Specific Character Set.

  • Условно — атрибут Timezone Offset From UTC (0008,0201). Данный атрибут должен быть включён, если какие-либо атрибуты времени в идентификаторе ответа подлежат явной интерпретации в указанном местном часовом поясе. В противном случае он не должен присутствовать, то есть не должен передаваться со значением нулевой длины.

Примечание

Это означает, что Specific Character Set (0008,0005) включается, если SCP поддерживает расширенные или заменяющие наборы символов в контексте данного сервиса. Он не будет включён, если расширенные или заменяющие наборы символов не поддерживаются SCP.

CC.2.8.2 Поведение пользователя сервисного класса (SCU)

Все SCU сервиса C-FIND должны быть способны формировать запросы, удовлетворяющие требованиям метода поиска «Worklist» (см. Раздел CC.2.8.3.1).

Обязательные ключи (Required Keys) и необязательные ключи (Optional Keys), указанные вTable CC.2.5-3, associated with the Query may be contained in the Identifier.

SCU передаёт следующую семантику посредством запросов и ответов C-FIND:

  • SCU запрашивает у SCP выполнение сопоставления всех ключей, указанных в идентификаторе запроса, с имеющейся у него информацией о запросе, указанном в запросе.

  • SCU должен интерпретировать ответы со статусом Pending как передающие атрибуты одного совпадения (элемента).

  • SCU должен интерпретировать ответ со статусом Success, Failure или Cancel как обозначающий окончание ответов со статусом Pending.

  • SCU должен интерпретировать ответ со статусом Failure на запрос C-FIND как указание на то, что SCP не может обработать данный запрос.

  • SCU может отменить сервис C-FIND, выдав запрос C-CANCEL-FIND в любой момент во время обработки C-FIND. SCU должен распознавать статус Cancel как признак того, что C-CANCEL-FIND был выполнен успешно.

    Примечание

    SCU должен быть готов получать ответы C-FIND, отправляемые SCP, до тех пор, пока SCP окончательно не обработает запрос C-CANCEL-FIND.

CC.2.8.3 Поведение поставщика сервисного класса (SCP)

Все SCP сервиса C-FIND должны быть способны обрабатывать запросы, удовлетворяющие требованиям поиска «Worklist» (см. Раздел CC.2.8.3.1). Это не означает, что SCP, поддерживающий класс SOP UPS Watch или класс SOP UPS Query, должен также быть SCP класса SOP UPS Pull.

SCP должен поддерживать сопоставление атрибутов, как описано в Раздел C.2.2.2.

SCP передаёт следующую семантику посредством запросов и ответов C-FIND:

  • У SCP запрашивается выполнение сопоставления всех ключей, указанных в идентификаторе запроса, с имеющейся у него информацией. Сопоставление атрибутов выполняется с использованием значений ключей, указанных в идентификаторе запроса C-FIND, как определено вTable CC.2.5-3.

  • SCP формирует ответ C-FIND для каждого совпадения методом поиска «Worklist». Все такие ответы должны содержать идентификатор, атрибуты которого содержат значения одного совпадения. Все такие ответы должны иметь статус Pending.

  • Когда все совпадения отправлены, SCP формирует ответ C-FIND со статусом Success. Статус Success означает, что ответ был отправлен для каждого совпадения, известного SCP.

Примечание

  1. Ответ со статусом Success не содержит идентификатора. Полное определение см. вPS3.7.

  2. Если совпадений нет, ответы со статусом Pending не отправляются — отправляется только один ответ со статусом Success.

  • SCP должен сформировать ответ со статусом Failure, если он не может обработать запрос. Ответ со статусом Failure не должен содержать идентификатора.

  • Если SCP получает индикацию C-CANCEL-FIND до завершения обработки совпадений, он должен прервать процесс сопоставления и вернуть статус Cancel.

Двусторонняя аутентификация машин/пользователей/приложений возможна на этапе установления ассоциации (см. PS3.7 и PS3.15). PS3.7 предоставляет код состояния Failure 0124H «Refused: Not authorized». Дальнейшее требование или документирование функций аутентификации и/или авторизации со стороны SCU или SCP выходит за рамки данного класса SOP.

CC.2.8.3.1 Метод поиска в рабочем списке

Для формирования ответов о совпадениях используются следующие шаги.

  • Сопоставить ключевые атрибуты сопоставления (Matching Key Attributes), содержащиеся в идентификаторе запроса C-FIND, со значениями ключевых атрибутов каждого элемента рабочего списка.

  • Если ключи сопоставления отсутствуют, то совпадений нет — вернуть ответ со статусом Success и без идентификатора.

  • Otherwise,

    • Для каждой сущности, атрибуты которой соответствуют всем указанным ключевым атрибутам сопоставления, сформировать идентификатор. Данный идентификатор должен содержать все значения атрибутов данной сущности, соответствующие ключевым атрибутам сопоставления и возврата (Matching Key и Return Key Attributes), указанным в запросе C-FIND.

    • Вернуть ответ для каждого оставшегося идентификатора.

Table CC.2.5-3 defines the Attributes of the Unified Procedure Step Information Model, the requirements for Matching Keys and Return Keys.

CC.2.8.4 Коды состояния

Таблица CC.2.8-2 определяет значения кодов состояния, которые могут возвращаться в ответе C-FIND. Общие значения кодов состояния и поля, связанные со значениями кодов состояния, определены для сервиса DIMSE C-FIND в PS3.7.

Table CC.2.8-2. C-FIND Response Status Values [for Search for Unified Procedure Step]

Статус службы

Дополнительное значение

Status Codes

Related Fields

Отказ

Отказано: нехватка ресурсов

A700

(0000,0902)

Ошибка: набор данных не соответствует SOP классу

A900

(0000,0901)

(0000,0902)

Отказано: класс SOP не поддерживается

0122

Отказано: невозможно обработать

Cxxx

(0000,0901)

(0000,0902)

Отмена

Сопоставление прекращено из-за запроса Cancel

FE00

None

Успех

Сопоставление завершено — заключительный идентификатор не предоставляется.

0000

None

Ожидание

Сопоставление продолжается — предоставлено текущее совпадение, и любые необязательные ключи обрабатывались так же, как обязательные ключи.

FF00

Identifier

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

FF01

Identifier


Примечание

Коды состояния возвращаются в сообщениях ответа DIMSE (см. PS3.7). Значения кодов, указанные в столбце «Status Codes», возвращаются в элементе Status Command Element (0000,0900).

Некоторые коды состояния Failure зависят от конкретной реализации.

Реализация SCP должна назначать конкретные коды состояния Failure, заменяя каждый символ 'x' шестнадцатеричной цифрой в диапазоне от 0 до F. Реализация SCP, желающая различать причины значения Failure «Отказано: невозможно обработать», должна назначать этим причинам конкретные значения кодов состояния в допустимом диапазоне, указанном вTable CC.2.8-2.

Реализация SCU должна распознавать любой код состояния Failure в диапазоне значений, указанном в Таблица CC.2.8-2, как индикатор значения Failure Meaning, указанного в таблице. Требования к тому, чтобы реализация SCU различала конкретные коды состояния внутри допустимого диапазона, отсутствуют.

CC.3 SOP-классы UPS

С IOD унифицированного этапа процедуры связано пять классов SOP UPS. Каждый класс SOP поддерживает различные виды взаимодействия с экземпляром UPS (также называемым элементом рабочего списка).

Класс SOP UPS Push позволяет системам-SCU:

  • create (push) a new worklist item (i.e., instance) onto a worklist

  • submit a cancellation request for a worklist item

Класс SOP UPS Pull позволяет системам-SCU:

  • query a worklist for matching items

  • take responsibility for performing a worklist item

  • add/modify progress/status/result details for the worklist item

  • finalize a controlled worklist item as Completed or Canceled.

Класс SOP UPS Watch позволяет системам-SCU:

  • query for worklist items of interest

  • subscribe/unsubscribe for event notifications of changes to a given worklist item

  • subscribe/unsubscribe for event notifications of all worklist items

  • get details for a given worklist item

  • submit a cancellation request for a given worklist item

Класс SOP UPS Event позволяет системам-SCU:

  • receive event notifications of changes to a worklist item

Класс SOP UPS Query позволяет системам-SCU:

  • query a worklist for matching items

DICOM AE, заявляющие соответствие одному или нескольким из этих классов SOP, должны поддерживать все сервисы, отмеченные «M», в соответствующих Таблица CC.2-1, Таблица CC.2-2, Таблица CC.2-3, Таблица CC.2-4 и Таблица CC.2-5.

CC.3.1 UID сервисного класса и классов SOP

Все экземпляры UPS должны создаваться со значением SOP Class UID, равным «1.2.840.10008.5.1.4.34.6.1» (то есть UID класса SOP UPS Push).

Примечание

Все экземпляры UPS основаны на IOD унифицированного этапа процедуры и создаются либо внутренним образом самим SCP, либо в ответ на запрос N-CREATE, отправленный в рамках класса SOP UPS Push.

После создания над экземплярами UPS могут выполняться операции сервисов DIMSE любого из классов SOP UPS, определённых в сервисном классе унифицированного этапа процедуры.

Во время согласования ассоциации Abstract Syntax UID должен быть UID реализуемого класса SOP, как показано в следующем списке:

  • 1.2.840.10008.5.1.4.34.6.1 (UPS Push SOP Class)

  • 1.2.840.10008.5.1.4.34.6.2 (UPS Watch SOP Class)

  • 1.2.840.10008.5.1.4.34.6.3 (UPS Pull SOP Class)

  • 1.2.840.10008.5.1.4.34.6.4 (UPS Event SOP Class)

  • 1.2.840.10008.5.1.4.34.6.5 (UPS Query SOP Class)

CC.3.1.1 Особенности DIMSE для UPS (информативно)

Экземпляр SOP может быть создан с одним SOP Class UID (UPS Push), а последующие сервисы DIMSE могут ссылаться на него через ассоциацию, согласованную для другого SOP Class UID. Подробнее об этом см. вSection 10 “DIMSE-N” in PS3.7.

Для сервисов DIMSE-N значением Affected SOP Class UID (0000,0002) или Requested SOP Class UID (0000,0003), если они присутствуют, всегда будет UID класса SOP UPS Push, независимо от согласованного Abstract Syntax UID. SCU и SCP не будут отклонять сообщения DIMSE-N на том основании, что Affected/Requested SOP Class UID является UID класса SOP UPS Push, а не одним из остальных четырёх SOP Class UID, перечисленных в качестве Abstract Syntax UID при согласовании ассоциации. SCU и SCP могут отклонить сообщения DIMSE-N, если данный экземпляр не является экземпляром класса SOP UPS Push.

Для сервисов DIMSE-C (C-FIND) Affected SOP Class UID всегда будет совпадать с согласованным Abstract Syntax UID для контекста презентации, в рамках которого делается запрос. Это будет UPS Watch, UPS Pull или UPS Query. Все эти классы SOP представляют информационную модель унифицированного этапа процедуры, описанную вSection CC.2.8.1.

Например, в типичном обмене сообщениями по схеме «Pull Workflow» запрос C-FIND от «выполняющего SCU» будет использовать UID класса SOP UPS Pull как для согласованного Abstract Syntax UID, так и для Affected SOP Class UID (0000,0002), однако SOP Class UID (0008,0016) самих ответов C-FIND будет установлен SCP в значение UID класса SOP UPS Push. Все последующие сообщения N-ACTION, N-SET и N-GET будут затем использовать UID класса SOP UPS Pull для согласованного Abstract Syntax UID и UID класса SOP UPS Push для Affected SOP Class UID (0000,0002).

CC.3.1.2 Global Instance Subscription UID

Общеизвестный UID для подписки/отмены подписки на события для всех экземпляров UPS, которыми управляет SCP, должен иметь значение «1.2.840.10008.5.1.4.34.5».

CC.3.2 Согласование ассоциации

Установление ассоциации — это первая фаза любого сеанса связи между равноправными DICOM AE. Процедура согласования ассоциации, указанная вPS3.7 shall be used to negotiate the supported SOP Classes.

See the Association Negotiation definition for the Basic Worklist Management Service Class (Section K.5).

CC.4 Требования соответствия

Реализации, заявляющие соответствие любому из классов SOP UPS (UPS Pull, UPS Push, UPS Watch, UPS Event и UPS Query), должны соответствовать требованиям, описанным в следующих разделах, и должны включать в своё заявление о соответствии информацию, описанную ниже.

Реализация может соответствовать любому из классов SOP UPS в роли SCU или SCP. Заявление о соответствии должно быть составлено в формате, определённом вPS3.2.

CC.4.1 Соответствие SCU

Реализация, соответствующая любому из классов SOP UPS в роли SCU, должна удовлетворять требованиям соответствия для выполняемых ею операций.

CC.4.1.1 Операции

Заявление о соответствии SCU должно быть составлено в формате, определённом в PS3.2.

Реализация, соответствующая любому из классов SOP UPS Push, UPS Pull или UPS Watch в роли SCU, должна указать, при каких условиях она будет запрашивать изменение значения атрибута Procedure Step State (0074,1000) на «IN PROGRESS», «COMPLETED» и «CANCELED».

Реализация, соответствующая классам SOP UPS Pull, UPS Watch или UPS Query в роли SCU, должна указать в своём заявлении о соответствии

  • Запрашивает ли она сопоставление по необязательным ключевым атрибутам сопоставления (Optional Matching Key Attributes) для C-FIND.

  • Запрашивает ли она атрибуты возврата типа 3 (Type 3 Return Key Attributes). Если она запрашивает такие атрибуты, она должна перечислить эти необязательные атрибуты возврата.

  • Поддерживает ли она расширенное согласование нечёткого семантического сопоставления имён лиц для C-FIND.

  • Каким образом она использует Specific Character Set (0008,0005) и Timezone Offset From UTC (0008,0201) при кодировании запросов и интерпретации ответов для C-FIND.

  • Какие механизмы доступа SCP способен использовать для получения входных данных и/или предоставления выходных данных. (см.Table 10-3b “Referenced Instances and Access Macro Attributes” in PS3.3 for details on the different Retrieval Sequences).

CC.4.2 Соответствие SCP

Реализация, соответствующая любому из классов SOP UPS в роли SCP, должна удовлетворять требованиям соответствия для выполняемых ею операций.

CC.4.2.1 Операции

Заявление о соответствии SCP должно быть составлено в формате, определённом в PS3.2.

Заявление о соответствии SCP должно содержать сведения о поведении SCP в следующих случаях:

  • Создание нового экземпляра класса SOP UPS Push со статусом «SCHEDULED». Должен быть указан результат данного процесса для сведений о планировании и значений атрибутов унифицированного этапа процедуры. Должна быть указана любая автоматически создаваемая подписка UPS в ответ на создание экземпляра.

  • Условия обновления атрибута «Procedure Step State» (0074,1000), то есть изменения состояния на «IN PROGRESS», либо на «CANCELED», либо на «COMPLETED».

  • Какие атрибуты SCP может обновлять после того, как состояние было установлено в «IN PROGRESS», либо «CANCELED», либо «COMPLETED».

  • Как долго экземпляр UPS будет сохраняться на SCP и как долго он будет доступен для N-GET после того, как его состояние было установлено в «COMPLETED» или «CANCELED».

  • Поддерживает ли SCP приоритет для C-FIND. Если SCP поддерживает приоритет для C-FIND, должно быть указано значение различных уровней приоритета.

  • Поддерживает ли SCP сопоставление без учёта регистра для атрибутов с VR PN при C-FIND. Если SCP поддерживает такое сопоставление, должны быть указаны атрибуты, к которым это применяется.

  • Поддерживает ли SCP расширенное согласование нечёткого семантического сопоставления имён лиц для C-FIND. Если SCP поддерживает такое расширенное согласование, должен быть указан механизм нечёткого семантического сопоставления.

  • Каким образом SCP использует Specific Character Set (0008,0005) и Timezone Offset From UTC (0008,0201) при интерпретации запросов C-FIND, выполнении сопоставления и кодировании ответов.

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

  • Может ли SCP отказывать в запросах на подписку и/или блокировках удаления и по каким причинам.

  • Какие механизмы доступа SCP способен использовать для получения входных данных и/или предоставления выходных данных. (см.Table 10-3b “Referenced Instances and Access Macro Attributes” in PS3.3 for details on the different Retrieval Sequences).

DD Классы служб верификации RT-аппарата

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

Классы сервисов верификации аппарата лучевой терапии (RT Machine Verification Service Classes) определяют класс сервиса прикладного уровня, обеспечивающий независимую верификацию геометрических и дозиметрических параметров системы доставки излучения перед проведением лучевой терапии. Классы сервисов предназначены для использования как при обычной (например, фотонной, электронной), так и при терапии частицами (например, протонной, ионной).

DD.2 Модель верификации RT-аппарата

DD.2.1 Поток данных верификации RT-аппарата

В модели верификации аппарата лучевой терапии пользователем сервиса (Service Class User, SCU) соответствующего класса сервиса верификации аппарата является система доставки излучения, используемая для проведения лечения. Верификатор параметров аппарата (Machine Parameter Verifier, MPV) выступает в роли поставщика сервиса (Service Class Provider, SCP).

Состояния обмена между SCU и SCP можно описать на двух уровнях, показанных на Рисунке DD.2-1: A) уровень плана (Plan Level) и B) уровень пучка (Beam Level).

Первый уровень (A на диаграмме) — уровень плана. SCU инициализирует внешнюю верификацию нового плана с помощью команды N-CREATE. Затем MPV получает данные, необходимые для проведения верификации, посредством DICOM или иными способами. Как правило, между MPV и системой управления лечением (Treatment Management System, TMS) или архивом существует тесная связь. Если для получения этих данных используется протокол DICOM, это может выполняться с помощью одной или нескольких операций C-MOVE на архиве.

Второй уровень (B на диаграмме) — уровень пучка. SCU с помощью команды N-SET указывает SCP атрибуты, подлежащие верификации. Затем SCU запрашивает начало верификации с помощью команды N-ACTION. SCP сравнивает значения указанных атрибутов со значениями атрибутов из референсного плана и сообщает о статусе верификации с помощью команды N-EVENT-REPORT, где атрибут Treatment Verification Status (3008,002C) указывает результат верификации. Использование MPV значений допусков (tolerance values) в процессе верификации должно быть описано в заявлении о соответствии (Conformance Statement). После этого SCU может опционально запросить параметры верификации пучка с помощью N-GET.

Наконец, когда все пучки доставлены или отменены, SCU завершает сеанс верификации на уровне плана с помощью N-DELETE.

RT Verification Data Flow

Рисунок DD.2-1. Поток данных RT-верификации


DD.3 Определения SOP-классов верификации аппарата

DD.3.1 Описание IOD

IOD верификации аппарата являются абстракциями информации, необходимой для проверки правильности настройки системы доставки лечения перед проведением лучевой терапии.

DD.3.2 Группа служб DIMSE

Таблица DD.3.2-1 показывает службы DIMSE, применимые к данным IOD.

Table DD.3.2-1. DIMSE Service Group Applicable to Machine Verification

Элемент службы сообщений DICOM

Использование (SCU/SCP)

N-CREATE

M/M

N-SET

M/M

N-GET

M/M

N-ACTION

M/M

N-DELETE

M/M

N-EVENT-REPORT

M/M


Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.

В этом разделе описывается поведение служб DIMSE, специфичное для данного IOD. Общее поведение служб DIMSE специфицировано в PS3.7.

DD.3.2.1 N-CREATE и N-SET

N-CREATE используется для создания экземпляра соответствующего класса SOP верификации аппарата.

N-SET используется для передачи параметров верификации в MPV путём установки атрибутов экземпляра соответствующего класса SOP верификации аппарата.

Все атрибуты таблицы, относящиеся к количеству определённых элементов (например, Number of Wedges, Number of Control Points), задают это количество в команде N-SET. Нумерация в запросе верификации пучков (Beams Verification Request) не обязательно совпадает с нумерацией в референсном RT-плане.

DD.3.2.1.1 Атрибуты

Перечень атрибутов N-CREATE и N-SET для класса SOP RT Conventional Machine Verification показан в Таблице DD.3.2.1-1. См. Раздел 5.4 для обозначений использования.

Table DD.3.2.1-1. N-CREATE and N-SET Attribute List - RT Conventional Machine Verification SOP Class

Имя атрибута

Tag

N-CREATE Использование (SCU/SCP)

N-SET Использование (SCU/SCP)

RT General Machine Verification Module

Referenced RT Plan Sequence

(300C,0002)

1/1

(допускается только один элемент)

Не допускается

>Referenced SOP Class UID

(0008,1150)

1/1

Не допускается

>Referenced SOP Instance UID

(0008,1155)

1/1

Не допускается

Referenced Fraction Group Number

(300C,0022)

1C/1

(обязательно, если план содержит более одной группы фракций)

Не допускается

Patient ID

(0010,0020)

1/1

Не допускается

Issuer of Patient ID

(0010,0021)

2/2

Не допускается

Issuer of Patient ID Qualifiers Sequence

(0010,0024)

2/2

Не допускается

>Include Table CC.2.5-2h “Issuer of Patient ID Qualifiers Macro”

Treatment Verification Status

(3008,002C)

Не допускается

Не допускается

Failed Parameters Sequence

(0074,1048)

Не допускается

Не допускается

Overridden Parameters Sequence

(0074,104A)

Не допускается

Не допускается

General Machine Verification Sequence

(0074,1042)

2/2

(последовательность должна содержать ноль элементов)

1/1

(допускается только один элемент)

>Specified Primary Meterset

(3008,0032)

-/-

3/3

>Specified Secondary Meterset

(3008,0033)

-/-

3/3

>Specified Treatment Time

(3008,003A)

-/-

3/3

>Beam Limiting Device Leaf Pairs Sequence

(3008,00A0)

-/-

3/3

>>RT Beam Limiting Device Type

(300A,00B8)

-/-

1/1

>>Number of Leaf/Jaw Pairs

(300A,00BC)

-/-

1/1

>Recorded Wedge Sequence

(3008,00B0)

-/-

2C/2C

(обязательно, если MPV способен верифицировать клинья). См. Раздел DD.3.2.1.1.1.

>>Wedge Number

(300A,00D2)

-/-

1/1

>>Wedge ID

(300A,00D4)

-/-

3/3

>>Wedge Angle

(300A,00D5)

-/-

3/3

>>Wedge Orientation

(300A,00D8)

-/-

3/3

>>Accessory Code

(300A,00F9)

-/-

3/3

>Recorded Compensator Sequence

(3008,00C0)

-/-

2C/2C

(обязательно, если MPV способен верифицировать компенсаторы). См. Раздел DD.3.2.1.1.1.

>>Compensator ID

(300A,00E5)

-/-

3/3

>>Accessory Code

(300A,00F9)

-/-

3/3

>>Referenced Compensator Number

(300C,00D0)

-/-

1/1

>Recorded Block Sequence

(3008,00D0)

-/-

2C/2C

(обязательно, если MPV способен верифицировать блоки). См. Раздел DD.3.2.1.1.1.

>>Block Tray ID

(300A,00F5)

-/-

3/3

>>Accessory Code

(300A,00F9)

-/-

3/3

>>Referenced Block Number

(300C,00E0)

-/-

1/1

>Treatment Machine Name

(300A,00B2)

-/-

1/1

>Beam Name

(300A,00C2)

-/-

3/3

>Radiation Type

(300A,00C6)

-/-

1/1

>Number of Wedges

(300A,00D0)

-/-

1/1

>Number of Compensators

(300A,00E0)

-/-

1/1

>Number of Boli

(300A,00ED)

-/-

1/1

>Number of Blocks

(300A,00F0)

-/-

1/1

>Applicator Sequence

(300A,0107)

-/-

2C/2C

(обязательно, если MPV способен верифицировать аппликаторы). См. Раздел DD.3.2.1.1.1.

>>Accessory Code

(300A,00F9)

-/-

3/3

>>Applicator ID

(300A,0108)

-/-

3/3

>>Applicator Type

(300A,0109)

-/-

1/1

>Number of Control Points

(300A,0110)

-/-

1/1

(значение должно быть 1)

>Patient Setup Sequence

(300A,0180)

-/-

3/3

(может быть включён один или несколько элементов)

>>Patient Setup Number

(300A,0182)

-/-

1/1

>>Fixation Device Sequence

(300A,0190)

-/-

2C/2C

(обязательно, если MPV способен верифицировать фиксирующие устройства). См. Раздел DD.3.2.1.1.1.

>>>Accessory Code

(300A,00F9)

-/-

3/3

>>>Fixation Device Type

(300A,0192)

-/-

1/1

>Referenced Beam Number

(300C,0006)

-/-

1/1

>Referenced Bolus Sequence

(300C,00B0)

-/-

2C/2C

(обязательно, если MPV способен верифицировать болюс). См. Раздел DD.3.2.1.1.1.

>>Referenced ROI Number

(3006,0084)

-/-

1/1

>>Accessory Code

(300A,00F9)

-/-

3/3

All other Attributes of the RT General Machine Verification Module

-

-/-

3/3

RT Conventional Machine Verification Module

Conventional Machine Verification Sequence

(0074,1044)

2/2

(последовательность должна содержать ноль элементов)

1/1

(допускается только один элемент)

>Conventional Control Point Verification Sequence

(0074,104C)

-/-

1/1

(допускается только один элемент)

>>Nominal Beam Energy

(300A,0114)

-/-

3/3

>>Dose Rate Set

(300A,0115)

-/-

3/3

>>Wedge Position Sequence

(300A,0116)

-/-

1C/1C

(обязательно, если Number of Wedges (300A,00D0) не равно нулю; может быть включён один или несколько элементов)

>>>Wedge Position

(300A,0118)

-/-

1/1

>>>Referenced Wedge Number

(300C,00C0)

-/-

1/1

>>Beam Limiting Device Position Sequence

(300A,011A)

-/-

1C/1C

(обязательно, если отправлена Beam Limiting Device Leaf Pairs Sequence (3008,00A0); может быть включён один или несколько элементов)

>>>RT Beam Limiting Device Type

(300A,00B8)

-/-

1/1

>>>Leaf/Jaw Positions

(300A,011C)

-/-

1/1

>>Gantry Angle

(300A,011E)

-/-

3/3

>>Gantry Rotation Direction

(300A,011F)

-/-

2/2

>>Beam Limiting Device Angle

(300A,0120)

-/-

3/3

>>Beam Limiting Device Rotation Direction

(300A,0121)

-/-

3/3

>>Patient Support Angle

(300A,0122)

-/-

3/3

>>Patient Support Rotation Direction

(300A,0123)

-/-

3/3

>>Table Top Eccentric Axis Distance

(300A,0124)

-/-

3/3

>>Table Top Eccentric Angle

(300A,0125)

-/-

3/3

>>Table Top Eccentric Rotation Direction

(300A,0126)

-/-

3/3

>>Table Top Vertical Position

(300A,0128)

-/-

3/3

>>Table Top Longitudinal Position

(300A,0129)

-/-

3/3

>>Table Top Lateral Position

(300A,012A)

-/-

3/3

>>Table Top Pitch Angle

(300A,0140)

-/-

3/3

>>Table Top Pitch Rotation Direction

(300A,0142)

-/-

3/3

>>Table Top Roll Angle

(300A,0144)

-/-

3/3

>>Table Top Roll Rotation Direction

(300A,0146)

-/-

3/3

>>Referenced Control Point Index

(300C,00F0)

-/-

1/1

All other Attributes of the RT Conventional Machine Verification Module

-

-/-

3/3


Перечень атрибутов N-CREATE и N-SET для класса SOP RT Ion Machine Verification показан в Таблице DD.3.2.1-2.

Table DD.3.2.1-2. N-CREATE and N-SET Attribute List - RT Ion Machine Verification SOP Class

Имя атрибута

Tag

N-CREATE Использование (SCU/SCP)

N-SET Использование (SCU/SCP)

RT General Machine Verification Module

Referenced RT Plan Sequence

(300C,0002)

1/1

(допускается только один элемент)

Не допускается

>Referenced SOP Class UID

(0008,1150)

1/1

Не допускается

>Referenced SOP Instance UID

(0008,1155)

1/1

Не допускается

Referenced Fraction Group Number

(300C,0022)

1C/1

(обязательно, если план содержит более одной группы фракций)

Не допускается

Patient ID

(0010,0020)

1/1

Не допускается

Issuer of Patient ID

(0010,0021)

2/2

Не допускается

Issuer of Patient ID Qualifiers Sequence

(0010,0024)

2/2

Не допускается

>Include Table CC.2.5-2h “Issuer of Patient ID Qualifiers Macro”

Treatment Verification Status

(3008,002C)

Не допускается

Не допускается

Failed Parameters Sequence

(0074,1048)

Не допускается

Не допускается

Overridden Parameters Sequence

(0074,104A)

Не допускается

Не допускается

General Machine Verification Sequence

(0074,1042)

2/2

(последовательность должна содержать ноль элементов)

1/1

(допускается только один элемент)

>Specified Primary Meterset

(3008,0032)

-/-

3/3

>Specified Secondary Meterset

(3008,0033)

-/-

3/3

>Specified Treatment Time

(3008,003A)

-/-

3/3

>Beam Limiting Device Leaf Pairs Sequence

(3008,00A0)

-/-

3/3

См. Section DD.3.2.1.1.1.

>>RT Beam Limiting Device Type

(300A,00B8)

-/-

1/1

>>Number of Leaf/Jaw Pairs

(300A,00BC)

-/-

1/1

>Recorded Wedge Sequence

(3008,00B0)

-/-

2C/2C

(обязательно, если MPV способен верифицировать клинья). См. Раздел DD.3.2.1.1.1.

>>Wedge Number

(300A,00D2)

-/-

1/1

>>Wedge ID

(300A,00D4)

-/-

3/3

>>Wedge Angle

(300A,00D5)

-/-

3/3

>>Wedge Orientation

(300A,00D8)

-/-

3/3

>>Accessory Code

(300A,00F9)

-/-

3/3

>Recorded Compensator Sequence

(3008,00C0)

-/-

2C/2C

(обязательно, если MPV способен верифицировать компенсаторы). См. Раздел DD.3.2.1.1.1.

>>Compensator ID

(300A,00E5)

-/-

3/3

>>Accessory Code

(300A,00F9)

-/-

3/3

>>Referenced Compensator Number

(300C,00D0)

-/-

1/1

>Recorded Block Sequence

(3008,00D0)

-/-

2C/2C

(обязательно, если MPV способен верифицировать блоки). См. Раздел DD.3.2.1.1.1.

>>Block Tray ID

(300A,00F5)

-/-

3/3

>>Accessory Code

(300A,00F9)

-/-

3/3

>>Referenced Block Number

(300C,00E0)

-/-

1/1

>Treatment Machine Name

(300A,00B2)

-/-

1/1

>Beam Name

(300A,00C2)

-/-

3/3

>Radiation Type

(300A,00C6)

-/-

1/1

>Number of Wedges

(300A,00D0)

-/-

1/1

>Number of Compensators

(300A,00E0)

-/-

1/1

>Number of Boli

(300A,00ED)

-/-

1/1

>Number of Blocks

(300A,00F0)

-/-

1/1

>Applicator Sequence

(300A,0107)

-/-

2C/2C

(обязательно, если MPV способен верифицировать аппликаторы). См. Раздел DD.3.2.1.1.1.

>>Accessory Code

(300A,00F9)

-/-

3/3

>>Applicator ID

(300A,0108)

-/-

3/3

>>Applicator Type

(300A,0109)

-/-

1/1

>Number of Control Points

(300A,0110)

-/-

1/1

(значение должно быть 1)

>Patient Setup Sequence

(300A,0180)

-/-

3/3

См. Section DD.3.2.1.1.1.

>>Patient Setup Number

(300A,0182)

-/-

1/1

>>Fixation Device Sequence

(300A,0190)

-/-

2C/2C

(обязательно, если MPV способен верифицировать фиксирующие устройства). См. Раздел DD.3.2.1.1.1.

>>>Accessory Code

(300A,00F9)

-/-

3/3

>>>Fixation Device Type

(300A,0192)

-/-

1/1

>Referenced Beam Number

(300C,0006)

-/-

1/1

>Referenced Bolus Sequence

(300C,00B0)

-/-

2C/2C

(обязательно, если MPV способен верифицировать болюс). См. Раздел DD.3.2.1.1.1.

>>Referenced ROI Number

(3006,0084)

-/-

1/1

>>Accessory Code

(300A,00F9)

-/-

3/3

All other Attributes of the RT General Machine Verification Module

-

-/-

3/3

RT Ion Machine Verification Module

Ion Machine Verification Sequence

(0074,1046)

2/2

(последовательность должна содержать ноль элементов)

1/1

(допускается только один элемент)

>Ion Control Point Verification Sequence

(0074,104E)

-/-

1/1

(допускается только один элемент)

>>Meterset Rate Set

(3008,0045)

-/-

3/3

>>Nominal Beam Energy

(300A,0114)

-/-

3/3

>>Beam Limiting Device Position Sequence

(300A,011A)

-/-

1C/1C

(обязательно, если отправлена Beam Limiting Device Leaf Pairs Sequence (3008,00A0); может быть включён один или несколько элементов)

>>>RT Beam Limiting Device Type

(300A,00B8)

-/-

1/1

>>>Leaf/Jaw Positions

(300A,011C)

-/-

1/1

>>Gantry Angle

(300A,011E)

-/-

3/3

>>Gantry Rotation Direction

(300A,011F)

-/-

2/2

>>Beam Limiting Device Angle

(300A,0120)

-/-

3/3

>>Beam Limiting Device Rotation Direction

(300A,0121)

-/-

3/3

>>Patient Support Angle

(300A,0122)

-/-

3/3

>>Patient Support Rotation Direction

(300A,0123)

-/-

3/3

>>Table Top Vertical Position

(300A,0128)

-/-

3/3

>>Table Top Longitudinal Position

(300A,0129)

-/-

3/3

>>Table Top Lateral Position

(300A,012A)

-/-

3/3

>>Table Top Pitch Angle

(300A,0140)

-/-

3/3

>>Table Top Pitch Rotation Direction

(300A,0142)

-/-

3/3

>>Table Top Roll Angle

(300A,0144)

-/-

3/3

>>Table Top Roll Rotation Direction

(300A,0146)

-/-

3/3

>>Head Fixation Angle

(300A,0148)

-/-

3/3

>>Gantry Pitch Angle

(300A,014A)

-/-

3/3

>>Gantry Pitch Rotation Direction

(300A,014C)

-/-

3/3

>>Snout Position

(300A,030D)

-/-

3/3

>>Range Shifter Settings Sequence

(300A,0360)

-/-

1C/1C

(обязательно, если Number of Range Shifters (300A,0312) не равно нулю; может быть включён один или несколько элементов)

>>>Range Shifter Setting

(300A,0362)

-/-

1/1

>>>Referenced Range Shifter Number

(300C,0100)

-/-

1/1

>>Lateral Spreading Device Settings Sequence

(300A,0370)

-/-

1C/1C

(обязательно, если Number of Lateral Spreading Devices (300A,0330) не равно нулю; может быть включён один или несколько элементов)

>>>Lateral Spreading Device Setting

(300A,0372)

-/-

1/1

>>>Referenced Lateral Spreading Device Number

(300C,0102)

-/-

1/1

>>Range Modulator Settings Sequence

(300A,0380)

-/-

1C/1C

(обязательно, если Number of Range Modulators (300A,0340) не равно нулю; может быть включён один или несколько элементов)

>>>Range Modulator Gating Start Value

(300A,0382)

-/-

1/1

>>>Range Modulator Gating Stop Value

(300A,0384)

-/-

1/1

>>>Referenced Range Modulator Number

(300C,0104)

-/-

1/1

>>Ion Wedge Position Sequence

(300A,03AC)

-/-

1C/1C

(обязательно, если Number of Wedges (300A,00D0) не равно нулю; может быть включён один или несколько элементов)

>>>Wedge Thin Edge Position

(300A,00DB)

-/-

1C/1C

(обязательно, если Wedge Type (300A,00D3) клина, указанного в Referenced Wedge Number (300C,00C0), равен PARTIAL_STANDARD или PARTIAL_MOTORIZ)

>>>Wedge Position

(300A,0118)

-/-

1/1

>>Referenced Control Point Index

(300C,00F0)

-/-

1/1

>Recorded Snout Sequence

(3008,00F0)

-/-

1C/1C

(обязательно, если Snout Sequence включена в RT-план, указанный в Referenced RT Plan Sequence (300C,0002); в данной последовательности допускается только один элемент)

>>Accessory Code

(300A,00F9)

-/-

3/3

>>Snout ID

(300A,030F)

-/-

3/3

>Recorded Range Shifter Sequence

(3008,00F2)

-/-

2C/2C

(обязательно, если MPV способен верифицировать компенсаторы диапазона (range shifters)). См. Раздел DD.3.2.1.1.1.

>>Accessory Code

(300A,00F9)

-/-

3/3

>>Range Shifter ID

(300A,0318)

-/-

3/3

>>Referenced Range Shifter Number

(300C,0100)

-/-

1/1

>Recorded Lateral Spreading Device Sequence

(3008,00F4)

-/-

2C/2C

(обязательно, если MPV способен верифицировать устройства бокового рассеивания (lateral spreading devices)). См. Раздел DD.3.2.1.1.1.

>>Accessory Code

(300A,00F9)

-/-

3/3

>>Lateral Spreading Device ID

(300A,0336)

-/-

3/3

>>Referenced Lateral Spreading Device Number

(300C,0102)

-/-

1/1

>Recorded Range Modulator Sequence

(3008,00F6)

-/-

2C/2C

(обязательно, если MPV способен верифицировать модуляторы диапазона (range modulators)). См. Раздел DD.3.2.1.1.1.

>>Accessory Code

(300A,00F9)

-/-

3/3

>>Range Modulator ID

(300A,0346)

-/-

3/3

>>Range Modulator Type

(300A,0348)

-/-

1/1

>>Beam Current Modulation ID

(300A,034C)

-/-

1C/1C

(обязательно, если Range Modulator Type (300A,0348) равен WHL_MODWEIGHTS)

>>Referenced Range Modulator Number

(300C,0104)

-/-

1/1

>Radiation Mass Number

(300A,0302)

-/-

1C/1C

(обязательно, если Radiation Type (300A,00C6) имеет значение ION)

>Radiation Atomic Number

(300A,0304)

-/-

1C/1C

(обязательно, если Radiation Type (300A,00C6) имеет значение ION)

>Radiation Charge State

(300A,0306)

-/-

1C/1C

(обязательно, если Radiation Type (300A,00C6) имеет значение ION)

>Scan Mode

(300A,0308)

-/-

1/1

>Number of Range Shifters

(300A,0312)

-/-

1/1

>Number of Lateral Spreading Devices

(300A,0330)

-/-

1/1

>Number of Range Modulators

(300A,0340)

-/-

1/1

>Patient Support Type

(300A,0350)

-/-

3/3

>Patient Support ID

(300A,0352)

-/-

3/3

>Patient Support Accessory Code

(300A,0354)

-/-

3/3

>Fixation Light Azimuthal Angle

(300A,0356)

-/-

3/3

>Fixation Light Polar Angle

(300A,0358)

-/-

3/3

All other Attributes of the RT Ion Machine Verification Module

-

-/-

3/3


DD.3.2.1.1.1 Модификаторы пучка

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

DD.3.2.1.2 Состояние

Таблица DD.3.2.1.2-1 определяет значения кодов статуса, которые могут быть возвращены в ответе N-CREATE. Общие значения кодов статуса и связанные с ними поля определены для сервиса DIMSE N-CREATE в PS3.7.

Table DD.3.2.1.2-1. RT Ion Machine Verification SOP Class N-CREATE Status Values

Статус службы

Дополнительное значение

Status Code

Success

Верификация аппарата успешно создана

0000

Failure

Ошибка: объект не найден — референсный RT-план не найден

C227

Ошибка: указанный номер группы фракций (Referenced Fraction Group Number) отсутствует в референсном плане

C221

Ошибка: в референсной группе фракций отсутствуют пучки

C222

Ошибка: SCU уже выполняет верификацию и не может обработать данный запрос в настоящий момент.

C223


Значения статуса для N-SET, специфичные для данных классов SOP, определены следующим образом:

Table DD.3.2.1.2-2. RT Ion Machine Verification SOP Class N-SET Status Values

Статус

Значение

Код

Success

Верификация аппарата успешно обновлена

0000

Failure

Ошибка: указанный номер пучка (Referenced Beam Number) не найден в референсной группе фракций

C224

Ошибка: референсное устройство или принадлежность не поддерживается

C225

Ошибка: референсное устройство или принадлежность не найдены в референсном пучке

C226


DD.3.2.1.3 Поведение
DD.3.2.1.3.1 N-CREATE

SCU использует N-CREATE, чтобы запросить у SCP создание соответствующего экземпляра SOP верификации аппарата. SCP должен создать экземпляр SOP и инициализировать атрибуты класса SOP.

General Machine Verification Sequence, Conventional Machine Verification Sequence и Ion Machine Verification Sequence создаются с пустым значением, а указание содержащихся в них атрибутов откладывается до операции N-SET.

SCP должен вернуть код статуса создания запрошенного экземпляра SOP. Значения кодов статуса Success, Warning и Failure определены в Разделе DD.3.2.1.2.

DD.3.2.1.3.2 N-SET

SCU использует N-SET, чтобы запросить у SCP обновление соответствующего экземпляра верификации аппарата. SCU должен указать обновляемый экземпляр SOP и перечень атрибутов, значения которых требуется установить. Атрибуты в Conventional/Ion Control Point Verification Sequence представляют фактические геометрические значения системы доставки лечения на момент выдачи запроса N-SET, поэтому Conventional/Ion Control Point Verification Sequence всегда должна содержать один элемент последовательности. Referenced Control Point Index должен быть равен нулю для лечения NORMAL и может быть больше нуля для лечения CONTINUATION.

В атрибутной последовательности, такой как General Machine Verification Sequence, Conventional Machine Verification Sequence и Ion Machine Verification Sequence, значения всех обязательных атрибутов должны предоставляться при каждом N-SET, иначе ранее установленные значения отсутствующих атрибутов будут удалены из экземпляра SOP. Существующие параметры можно очистить, отправив пустую последовательность или атрибут. Заявление о соответствии MPV должно определять набор атрибутов, необходимых ему для верификации.

SCU должен установить новые значения указанных атрибутов заданного экземпляра SOP. Затем SCP должен сравнить значения атрибутов заданного экземпляра SOP со значениями тех же атрибутов, найденных в RT-плане, указанном в N-CREATE. Сравнение значений должно выполняться с использованием значений допусков (tolerance values), также найденных в референсном RT-плане. Результат этого сравнения должен быть доступен для использования при запросе SCU статуса верификации лечения (Treatment Verification Status) с помощью N-GET.

DD.3.2.2 N-GET

N-GET используется для получения статуса и результатов верификации соответствующего класса SOP верификации аппарата.

DD.3.2.2.1Verification Макрос атрибута селектора параметров

Таблица DD.3.2.2.1-1 описывает требования поддержки N-GET для макроса атрибута селектора (Selector Attribute Macro). См. Раздел 5.4 для значения кода типа требования.

Table DD.3.2.2.1-1. Verification Parameters Selector Attribute Macro

Имя атрибута

Tag

Использование N-GET (SCU/SCP)

Selector Attribute

(0072,0026)

-/1

Selector Value Number

(0072,0028)

-/1

Selector Sequence Pointer

(0072,0052)

-/1

Selector Sequence Pointer Private Creator

(0072,0054)

-/1

Selector Sequence Pointer Items

(0074,1057)

-/1

Selector Attribute Private Creator

(0072,0056)

-/1


DD.3.2.2.2 Атрибуты

Перечень атрибутов N-GET для классов SOP RT Conventional Machine Verification и RT Ion Machine Verification показан в Таблице DD.3.2.2.2-1. См. Раздел 5.4 для обозначений использования.

Table DD.3.2.2.2-1. N-GET Attribute List- RT Conventional Machine Verification SOP Class and RT Ion Machine Verification SOP Class

Имя атрибута

Tag

Использование (SCU/SCP)

Referenced RT Plan Sequence

(300C,0002)

-/1

>Referenced SOP Class UID

(0008,1150)

-/1

>Referenced SOP Instance UID

(0008,1155)

-/1

Referenced Fraction Group Number

(300C,0022)

-/1

Patient ID

(0010,0020)

-/1

Issuer of Patient ID

(0010,0021)

-/2

Issuer of Patient ID Qualifiers Sequence

(0010,0024)

-/2

>Include Table CC.2.5-2h “Issuer of Patient ID Qualifiers Macro”

Treatment Verification Status

(3008,002C)

-/1

Failed Parameters Sequence

(0074,1048)

-/2

(в данную последовательность должно быть включено ноль или более элементов)

>Include Table DD.3.2.2.1-1 “Verification Parameters Selector Attribute Macro”

Overridden Parameters Sequence

(0074,104A)

-/2

(в данную последовательность должно быть включено ноль или более элементов)

>Include Table DD.3.2.2.1-1 “Verification Parameters Selector Attribute Macro”

>Operators' Name

(0008,1070)

-/2

>Override Reason

(3008,0066)

-/2

All other Attributes of the RT General Machine Verification Module

-

3/2

All other Attributes of the RT Conventional Machine Verification Module if RT Conventional Machine Verification SOP Class is applicable

-

3/2

All other Attributes of the RT Ion Machine Verification Module if RT Ion Machine Verification SOP Class is applicable

-

3/2


DD.3.2.2.3 Состояние

Таблица DD.3.2.2.3-1 определяет значения кодов статуса, которые могут быть возвращены в ответе N-GET. Общие значения кодов статуса и связанные с ними поля определены для сервиса DIMSE N-GET в PS3.7.

Table DD.3.2.2.3-1. RT Conventional Machine and RT Ion Machine Verification SOP Class N-GET Status Values

Статус службы

Дополнительное значение

Код статуса

Success

Статус верификации лечения соответствующего экземпляра верификации аппарата успешно возвращён.

0000

Failure

Ошибка: соответствующий экземпляр верификации аппарата не найден

C112


DD.3.2.2.4 Поведение

SCU использует N-GET для получения от SCP статуса верификации и результатов соответствующего экземпляра SOP верификации аппарата.

SCP должен вернуть атрибут Treatment Verification Status (3008,002C), а также код статуса запрошенного обновления экземпляра SOP. Treatment Verification Status должен иметь одно из следующих значений:

VERIFIED = лечение верифицировано

VERIFIED_OVR = лечение верифицировано с переопределением как минимум одного значения, выходящего за пределы допуска

NOT_VERIFIED = верификация лечения не выполнена успешно

Состояние VERIFIED указывает, что все требуемые параметры проверены и значений, выходящих за пределы допуска, не обнаружено. Состояние VERIFIED_OVR указывает, что верификация лечения не была пройдена из-за одного или нескольких значений, выходящих за пределы допуска, которые затем были переопределены. NOT_VERIFIED указывает, что одно или несколько значений, выходящих за пределы допуска, ещё не были переопределены и лечение не может быть продолжено. Это может быть связано с тем, что было обнаружено как минимум одно значение, выходящее за пределы допуска, либо не были предоставлены одно или несколько значений, необходимых для верификации. Специфичная для площадки и производителя конфигурация MPV определяет атрибуты и диапазоны, необходимые для успешной верификации.

Если Treatment Verification Status имеет значение VERIFIED_OVR, в Overridden Parameters Sequence (0074,104A) должно быть возвращено одно или несколько вхождений параметров, в противном случае последовательность должна быть пустой.

Если Treatment Verification Status имеет значение NOT_VERIFIED, в Failed Parameters Sequence (0074,1048) должно быть возвращено одно или несколько вхождений параметров, в противном случае последовательность должна быть пустой.

См. Раздел C.31.1.1 «Failed Parameters and Overridden Parameters» в PS3.3 для описания кодирования тегов атрибутов и позиции внутри последовательности.

SCP должен вернуть код статуса запрошенного действия. Значения кодов статуса Success, Warning и Failure определены в Разделе DD.3.2.2.3.

DD.3.2.3 N-ACTION

N-ACTION используется для инициации верификации параметров экземпляра соответствующего класса SOP верификации аппарата.

DD.3.2.3.1 Атрибуты

Типы действий N-ACTION определены, как показано в Таблице DD.3.2.3-1.

Table DD.3.2.3-1. Action Event Information

Имя типа действия

Идентификатор типа действия

Имя атрибута

Tag

Использование (SCU/SCP)

Request Beam Verification

1

None

-

-


DD.3.2.3.2 Состояние

Таблица DD.3.2.3-2 определяет значения кодов статуса, которые могут быть возвращены в ответе N-ACTION. Общие значения кодов статуса и связанные с ними поля определены для сервиса DIMSE N-ACTION в PS3.7.

Table DD.3.2.3-2. RT Conventional Machine and RT Ion Machine Verification SOP Class N-ACTION Status Values

Статус службы

Дополнительное значение

Код статуса

Success

Верификация параметров аппарата соответствующего экземпляра верификации аппарата успешно инициирована.

0000

Failure

Ошибка: запрошенный экземпляр верификации аппарата не найден.

C112


DD.3.2.3.3 Поведение

SCU использует N-ACTION, чтобы указать SCP инициировать верификацию параметров аппарата соответствующего экземпляра SOP верификации аппарата.

DD.3.2.4 N-DELETE

N-DELETE используется для удаления экземпляра соответствующего класса SOP верификации аппарата.

DD.3.2.4.1 Атрибуты

Специфических атрибутов нет.

DD.3.2.4.2 Состояние

Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.

DD.3.2.4.3 Поведение

SCU использует N-DELETE, чтобы запросить у SCP удаление соответствующего экземпляра SOP верификации аппарата. SCU должен указать в примитиве запроса N-DELETE UID экземпляра SOP соответствующего экземпляра верификации аппарата.

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

SCP должен вернуть код статуса запрошенного удаления экземпляра SOP. Значения классов статуса success, warning и failure определены в Annex C «Status Type Encoding (Normative)» в PS3.7.

Если N-DELETE не выдаётся, экземпляр SOP может быть удалён на SCP вручную или автоматически. Такое поведение выходит за рамки Стандарта.

DD.3.2.5 N-EVENT-REPORT

N-EVENT-REPORT используется MPV для уведомления TDS о статусе задачи верификации (успешной или нет) либо для уведомления TDS о том, что верификация ожидает выполнения (выполняется). Кодирование информации о событии уведомления определено в PS3.7.

DD.3.2.5.1 Атрибуты

Аргументы N-EVENT-REPORT определены, как показано в Таблице DD.3.2.5-1.

Table DD.3.2.5-1. Notification Event Information

Имя типа события

Идентификатор типа события

Имя атрибута

Tag

Использование (SCP)

Pending

1

None

-

-

Done

2

Treatment Verification Status

(3008,002C)

1


DD.3.2.5.2 Состояние

Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.

DD.3.2.5.3 Поведение

SCP использует N-EVENT-REPORT для информирования SCU о статусе верификации. См. Раздел BBB.3 «Use Cases» в PS3.17 .

Если Event Type ID = 1, верификация всё ещё выполняется, и SCU должен дождаться следующего события. См. Раздел BBB.3.2.2 «Transactions and Message Flow» в PS3.17 .

Если Event Type ID = 2, процесс верификации завершён. SCU может использовать возвращённое значение Treatment Verification Status (3008,002C), чтобы определить, готов ли пучок к доставке, или требуется ли настройка аппарата либо переопределение значений. См. Раздел BBB.3.2.2 «Transactions and Message Flow» в PS3.17 .

EE Display System Management Service Class

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

Сервисный класс системы отображения (Display System Service Class) позволяет пользователям сервиса получать параметры, относящиеся к подсистеме(ам) отображения.

Display System Management Data Flow

Figure EE.1-1. Display System Management Data Flow


EE.2 Display System SOP Class

EE.2.1 IOD Description

IOD системы отображения (Display System IOD) представляет собой абстракцию системы мягкого копирования (soft-copy) и является базовой информационной сущностью для контроля состояния системы отображения. Экземпляр SOP системы отображения создаётся SCP при запуске системы отображения и имеет общеизвестный (well-known) UID экземпляра SOP.

EE.2.2 DIMSE Service Group

Служба DIMSE, показанная в Таблице EE.2.2-1, применима к IOD системы отображения в рамках SOP-класса системы отображения.

Table EE.2.2-1. DIMSE Service Group Applicable to Display System

Элемент службы сообщений DICOM

Использование (SCU/SCP)

N-GET

M/M


В этом разделе описывается поведение служб DIMSE, специфичное для данного IOD. Общее поведение служб DIMSE определено в PS3.7.

EE.2.2.1 N-GET

N-GET используется для получения информации от экземпляра SOP-класса системы отображения.

EE.2.2.1.1 Атрибуты
EE.2.2.1.1.1 Display Subsystem Macros

Для уменьшения размера и сложности EE.2.2.1-2 используется макро-нотация.

Table EE.2.2.1-1. Table Result Context Macro

Имя атрибута

Tag

Использование (SCU/SCP)

Performed Procedure Step Start DateTime

(0040,4050)

-/1

Performed Procedure Step End DateTime

(0040,4051)

-/1

Actual Human Performer Sequence

(0040,4035)

3/2

>Human Performer Code Sequence

(0040,4009)

-/1C

(Обязательно, если Human Performer's Name (0040,4037) не присутствует.)

>>Include Table CC.2.5-2a “UPS Code Sequence Macro”

>Human Performer's Name

(0040,4037)

-/1C

(Обязательно, если Human Performer Code Sequence (0040,4009) не присутствует.)

>Human Performer's Organization

(0040,4036)

-/2

Measurement Equipment Sequence

(0028,7012)

3/2

>Measurement Functions

(0028,7013)

-/1

>Measured Characteristics

(0028,7026)

-/1

>Measurement Equipment Type

(0028,7014)

-/1

>Manufacturer

(0008,0070)

-/1

>Manufacturer's Model Name

(0008,1090)

-/1

>Device Serial Number

(0018,1000)

-/2

>DateTime of Last Calibration

(0018,1202)

-/2


EE.2.2.1.1.2 Требования к атрибутам N-GET системы отображения

Атрибуты, которые могут быть получены, показаны в Таблице EE.2.2.1-2.

Table EE.2.2.1-2. Display System N-GET Attributes

Имя атрибута

Tag

Использование (SCU/SCP)

Specific Character Set

(0008,0005)

-/1C

(Обязательно, если используется расширенный или заменяющий набор символов)

Display System Module

Manufacturer

(0008,0070)

3/1

Institution Name

(0008,0080)

3/1

Institution Address

(0008,0081)

3/1

Device Serial Number

(0018,1000)

3/1

Station Name

(0008,1010)

3/2

Institutional Department Name

(0008,1040)

3/2

Institutional Department Type Code Sequence

(0008,1041)

3/3

Manufacturer's Model Name

(0008,1090)

3/1

Equipment Administrator Sequence

(0028,7000)

3/2

>Person Name

(0040,A123)

-/2

>Person Identification Code Sequence

(0040,1101)

-/1

>>Include Table CC.2.5-2a “UPS Code Sequence Macro”

>Person's Address

(0040,1102)

-/3

>Person's Telephone Numbers

(0040,1103)

-/3

>Institution Name

(0008,0080)

-/1C

(Обязательно, если Institution Code Sequence (0008,0082) не присутствует. Может присутствовать в остальных случаях.)

>Institution Address

(0008,0081)

-/3

>Institution Code Sequence

(0008,0082)

-/1C

(Обязательно, если Institution Name (0008,0080) не присутствует. Может присутствовать в остальных случаях.)

>>Include Table CC.2.5-2a “UPS Code Sequence Macro”

Number of Display Subsystems

(0028,7001)

3/1

Display Subsystem Sequence

(0028,7023)

3/1

>Display Subsystem ID

(0028,7003)

-/1

>Display Subsystem Name

(0028,7004)

-/2

>Display Subsystem Description

(0028,7005)

-/2

>Display Device Type Code Sequence

(0028,7022)

-/2

>>Include Table CC.2.5-2a “UPS Code Sequence Macro”

>Manufacturer

(0008,0070)

-/2

>Device Serial Number

(0018,1000)

-/2

>Manufacturer's Model Name

(0008,1090)

-/2

>System Status

(0028,7006)

-/1

>System Status Comment

(0028,7007)

-/2

>Display Subsystem Configuration Sequence

(0028,700A)

-/2

>>Configuration ID

(0028,700B)

-/1

>>Configuration Name

(0028,700C)

-/2

>>Configuration Description

(0028,700D)

-/2

>>Referenced Target Luminance Characteristics ID

(0028,700E)

-/2

>Current Configuration ID

(0028,7002)

-/2

>Measurement Equipment Sequence

(0028,7012)

-/2

>>Measurement Functions

(0028,7013)

-/1

>>Measured Characteristics

(0028,7026)

-/1

>>Measurement Equipment Type

(0028,7014)

-/1

>>Manufacturer

(0008,0070)

-/1

>>Manufacturer's Model Name

(0008,1090)

-/1

>>Device Serial Number

(0018,1000)

-/1

>>DateTime of Last Calibration

(0018,1202)

-/2

Target Luminance Characteristics Module

Target Luminance Characteristics Sequence

(0028,7008)

2/1

>Luminance Characteristics ID

(0028,7009)

-/1

>Display Function Type

(0028,7019)

-/1

>Target Minimum Luminance

(0028,701D)

-/1

>Target Maximum Luminance

(0028,701E)

-/1

>Gamma Value

(0028,701A)

-/1C

(Обязательно, если значение Display Function Type (0028,7019) равно GAMMA)

>Number of Luminance Points

(0028,701B)

-/1C

(Обязательно, если значение Display Function Type (0028,7019) равно USER_DEFINED)

>Luminance Response Sequence

(0028,701C)

-/1C

(Обязательно, если значение Display Function Type (0028,7019) равно USER_DEFINED)

>>DDL Value

(0028,7017)

-/1

>>Luminance Value

(0028,701F)

-/1

>Luminance Response Description

(0028,7020)

-/1C

(Обязательно, если значение Display Function Type (0028,7019) равно USER_DEFINED. Может присутствовать в остальных случаях.)

>CIExy White Point

(0028,7018)

-/3

>Reflected Ambient Light

(2010,0160)

-/3

>Ambient Light Value Source

(0028,7025)

-/1C

(Обязательно, если присутствует Reflected Ambient Light (2010,0160).)

QA Results Module

QA Results Sequence

(0028,700F)

3/1

>Display Subsystem ID

(0028,7003)

-/1

>Display Subsystem QA Results Sequence

(0028,7010)

-/2

>>Configuration ID

(0028,700B)

-/1

>>Configuration QA Results Sequence

(0028,7011)

-/2

>>>Display Calibration Result Sequence

(0028,7016)

-/2

>>>>Include Table EE.2.2.1-1 “Table Result Context Macro”

>>>>Luminance Characteristics ID

(0028,7009)

-/1

>>>Visual Evaluation Result Sequence

(0028,7015)

-/2

>>>>Include Table EE.2.2.1-1 “Table Result Context Macro”

>>>>Visual Evaluation Test Sequence

(0028,7028)

-/1

>>>>>Test Result

(0028,7029)

-/1

>>>>>Test Result Comment

(0028,702A)

-/3

>>>>>Test Pattern Code Sequence

(0028,702C)

-/3

>>>>>>Include Table CC.2.5-2a “UPS Code Sequence Macro”

>>>>>Referenced Image Sequence

(0008,1140)

-/1C

(Обязательно, если Test Pattern Code Sequence (0028,702C) отсутствует в данном элементе. Может присутствовать в остальных случаях.)

>>>>>>Referenced SOP Class UID

(0008,1150)

-/1

>>>>>>Referenced SOP Instance UID

(0008,1151)

-/1

>>>>>>Referenced Frame Number

(0008,1160)

-/1C

(Обязательно, если Referenced SOP Instance является многокадровым изображением, ссылка относится не ко всем кадрам, и Referenced Segment Number (0062,000B) не присутствует.)

>>>>>>Referenced Segment Number

(0062,000B)

-/1C

(Обязательно, если Referenced SOP Instance является Segmentation или Surface Segmentation, ссылка относится не ко всем сегментам, и Referenced Frame Number (0008,1160) не присутствует.)

>>>>>>Test Image Validation

(0028,702B)

-/3

>>>>Visual Evaluation Method Code Sequence

(0028,702E)

-/1

>>>>>Include Table CC.2.5-2a “UPS Code Sequence Macro”

>>>Luminance Uniformity Result Sequence

(0028,7027)

-/2

>>>>Include Table EE.2.2.1-1 “Table Result Context Macro”

>>>>Number of Luminance Points

(0028,701B)

-/1

>>>>Measurement Pattern Code Sequence

(0028,702D)

-/1

>>>>>Include Table CC.2.5-2a “UPS Code Sequence Macro”

>>>>DDL Value

(0028,7017)

-/1

>>>>White Point Flag

(0028,7021)

-/1

>>>>Luminance Response Sequence

(0028,701C)

-/1

>>>>>Luminance Value

(0028,701F)

-/1

>>>>>CIExy White Point

(0028,7018)

-/1C

(Обязательно, если значение White Point Flag (0028,7021) равно YES.)

>>>>Reflected Ambient Light

(2010,0160)

-/3

>>>>>Ambient Light Value Source

(0028,7025)

-/1C

(Обязательно, если присутствует Reflected Ambient Light (2010,0160).)

>>>Luminance Result Sequence

(0028,7024)

-/2

>>>>Include Table EE.2.2.1-1 “Table Result Context Macro”

>>>>Number of Luminance Points

(0028,701B)

-/1

>>>>Luminance Response Sequence

(0028,701C)

-/1

>>>>>DDL Value

(0028,7017)

-/1

>>>>>Luminance Value

(0028,701F)

-/1

>>>>>CIExy White Point

(0028,7018)

-/3

>>>>Reflected Ambient Light

(2010,0160)

-/3

>>>>Ambient Light Value Source

(0028,7025)

-/1C

(Обязательно, если присутствует Reflected Ambient Light (2010,0160).)


EE.2.2.1.2 SCU Behavior

SCU использует N-GET, чтобы запросить у SCP предоставление содержимого экземпляра SOP системы отображения. SCU должен указать в примитиве запроса N-GET UID экземпляра SOP, для которого должны быть возвращены атрибуты.

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

SCU должен указать в примитиве запроса N-GET общеизвестный UID экземпляра SOP.

EE.2.2.1.3 SCP Behavior

SCP должен вернуть значения указанных атрибутов экземпляра SOP системы отображения.

SCP должен вернуть код состояния для запрошенного извлечения экземпляра SOP. Значение кодов состояния Success, Warning и Failure определено в PS3.7.

EE.2.3 Определения SOP-классов и UID

UID SOP-класса системы отображения должен иметь значение "1.2.840.10008.5.1.1.40".

EE.2.4 Зарезервированные идентификаторы

Общеизвестный UID экземпляра SOP системы отображения должен иметь значение "1.2.840.10008.5.1.1.40.1".

EE.3 Conformance

EE.3.1 Conformance Statement

Заявление о соответствии реализации данного SOP-класса должно следовать PS3.2.

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

  • Максимальное число ассоциаций, поддерживаемых одновременно

  • Список поддерживаемых SOP-классов

  • Для каждого из поддерживаемых SOP-классов:

    • Список поддерживаемых атрибутов SOP-класса и элементов службы сообщений DICOM (DIMSE)

    • Для каждого поддерживаемого атрибута (обязательного и опционального) — допустимый диапазон значений

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

  • Максимальное число ассоциаций, поддерживаемых одновременно

  • Список поддерживаемых SOP-классов

  • Для каждого из поддерживаемых SOP-классов:

    • Список поддерживаемых атрибутов SOP-класса и элементов службы сообщений DICOM (DIMSE)

    • Для каждого поддерживаемого атрибута (обязательного и опционального)

      • Допустимый диапазон значений

      • Значение по умолчанию, если SCU не предоставляет значение

      • Код состояния (Failure или Warning), если SCU предоставляет значение вне допустимого диапазона

  • Для каждой поддерживаемой службы DIMSE

    • Поведение SCP для всех конкретных кодов состояния

FF Классы SOP хранения состояний объёмного представления

FF.1 Обзор

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

Классы SOP хранения состояний объёмного представления расширяют функциональность сервисного класса хранения (Storage Service Class, определён в Приложении B), добавляя возможность передавать предполагаемое состояние объёмного представления (Volumetric Presentation State) или фиксировать существующее состояние объёмного представления. Эти классы SOP определяют информацию и поведение, которые могут использоваться для представления (отображения) изображений, на которые имеются ссылки внутри этих классов SOP.

Они включают возможность задания:

  • пространственной регистрации входных наборов данных

  • кадрирования наборов объёмных данных ограничивающим параллелепипедом, наклонными плоскостями и объектами сегментации

  • геометрии построения объёмных видов

  • моделей затенения (shading)

  • преобразований скалярных значений в P-Value или RGB-значения

  • композитинга нескольких рендерингов MPR

  • композитинга нескольких потоков объёма и одного потока объёма с сегментацией

  • клинического описания заданного вида

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

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

  • позиции в наборе последовательно связанных состояний объёмного представления

  • анимации вида

  • ссылки на изображение, отображающее вид, описываемый состоянием объёмного представления

Каждое состояние объёмного представления соответствует одному виду (эквивалентно окну изображения (Image Box) в протоколе развески (Hanging Protocol) или структурированном дисплее (Structured Display)). Если несколько состояний объёмного представления предполагается отображать вместе (например, набор ортогональных видов MPR), эти состояния представления можно сгруппировать, присвоив им коллекцию отображения (Display Collection). Однако любая детальная информация о том, как должен быть представлен набор видов, может быть описана только экземпляром структурированного дисплея или протокола развески.

Состояние объёмного представления Planar MPR определяет мультипланарную геометрию и преобразования полутонового или цветного изображения, которые должны применяться в явно заданном порядке для преобразования хранимых значений пиксельных данных изображения в композитном экземпляре изображения в значения представления (P-Value) или значения пространства подключения профиля (Profile Connection Space, PCS-Value) при отображении изображения на устройстве мягкой копии.

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

Объёмный рендеринг обычно состоит из ряда шагов, многие из которых параметрически заданы в классах SOP объёмного рендеринга. Этапы обработки:

  • Сегментация, то есть разделение объёмных данных на группы, которые будут использовать общую цветовую палитру. Объекты сегментации задаются как входные данные кадрирования для состояния объёмного представления.

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

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

  • Классификация выборок для присвоения каждой выборке цвета и непрозрачности.

  • Затенение, то есть применение модели освещения к выборкам, показывающей влияние фонового, диффузного и зеркального освещения на выборку.

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

  • Преобразование в значения пространства подключения профиля представления (PCS-Value) при отображении изображения на устройстве мягкой копии.

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

Значения P-Value заданы в независимом от устройства перцептивно линейном пространстве, формально определённом в PS3.14 Grayscale Standard Display Function. Значения PCS-Value заданы в независимом от устройства пространстве, формально определённом в профилях ICC как значения CIEXYZ или CIELab.

Каким образом SCP этих классов SOP выбирает между несколькими экземплярами состояний представления, которые могут применяться к изображению, выходит за рамки настоящего стандарта.

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

Каким образом SCP этих классов SOP выбирает отображение нескольких состояний, входящих в коллекцию отображения, выходит за рамки настоящего стандарта.

Примечание

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

FF.2 Процессы преобразования объёма

FF.2.1 Объёмные преобразования

Преобразования, заданные в классах SOP хранения состояний объёмного представления, заменяют собой преобразования, которые могут быть заданы в экземплярах SOP изображений, на которые есть ссылка. Если конкретное преобразование отсутствует в экземпляре SOP хранения состояния объёмного представления Volume Rendering, оно считается тождественным преобразованием, и любое эквивалентное преобразование, если оно присутствует в экземплярах SOP изображений, на которые есть ссылка, использоваться не должно.

Атрибуты классов SOP хранения состояний объёмного представления Volume Rendering, относящиеся к представлению, неизменяемы. Они никогда не должны модифицироваться или обновляться; для представления другого варианта представления может быть создан только производный экземпляр SOP с новым UID экземпляра SOP.

FF.2.1.1 Объёмные преобразования планарного MPR

Классы SOP хранения состояний объёмного представления Planar MPR поддерживают набор преобразований для построения производных объёмных видов из входных объёмных данных.

Класс SOP хранения состояния объёмного представления Grayscale Planar MPR задаёт полутоновый объёмный вид из одного входного объёма. Последовательность преобразований от объёмных входных данных к значениям P-Value явно определена в эталонном конвейере, описанном на Рисунке FF.2-1.

Grayscale Planar MPR Volumetric Pipeline

Рисунок FF.2-1. Конвейер планарного MPR полутонового объёма


Класс SOP хранения состояния объёмного представления Compositing Planar MPR задаёт вид с истинными цветами из одного или нескольких входных объёмов. Последовательность преобразований от объёмных входных данных к значениям PCS-Value явно определена в эталонном конвейере, описанном на Рисунке FF.2-2. Фактически реализуемая последовательность может отличаться (например, классификация и композитинг могут выполняться до построения вида MPR), но должна давать сходный внешний вид.

Compositing Planar MPR Volumetric Pipeline

Рисунок FF.2-2. Конвейер композиции планарного MPR объёма


Преобразование planar MPR требует, чтобы объём находился в системе координат отсчёта состояния объёмного представления (Volumetric Presentation State Reference Coordinate System, VPS-RCS).

Построение MPR основано на атрибутах модуля Multi-Planar Reconstruction Geometry (см. Раздел C.11.26.1.1 “Planar Style” в PS3.3). Если MPR Thickness Type (0070,1502) имеет значение SLAB, также используется Rendering Method (0070,120D).

Если Pixel Presentation (0008,9205) имеет значение MONOCHROME, преобразование к выходным значениям P-Value задаётся атрибутом Presentation LUT Shape (2050,0020).

Если Pixel Presentation (0008,9205) имеет значение TRUE_COLOR, Presentation State Classification Component Sequence (0070,1801) описывает преобразование каждого обработанного входа в поток данных RGB, а Presentation State Compositor Component Sequence (0070,1805) описывает композитинг этих отдельных потоков данных RGBA в единый поток данных RGB. Этот единый поток данных RGB затем обрабатывается в соответствии с ICC Profile (0028,2000) для получения выходных значений PCS-Value.

FF.2.1.2 Объёмные преобразования объёмного рендеринга

FF.2.1.2.1 Конвейеры объёмного рендеринга

Классы SOP хранения состояний объёмного представления Volume Rendering поддерживают набор преобразований для построения производных объёмных видов из входных объёмных данных. Атрибуты, составляющие состояния объёмного представления Volume Rendering, определены в контексте эталонных конвейеров, описанных в настоящем разделе. Хотя эталонные конвейеры подразумевают определённый порядок выполнения операций объёмного рендеринга — классификации, передискретизации, затенения и композитинга, — конкретный порядок применения этих операций любым устройством, заявляющим соответствие настоящему стандарту, зависит от реализации и выходит за рамки настоящего стандарта. Ответственность за преобразование стандартных атрибутов в параметры, соответствующие конкретному порядку операций, реализованному в приложении просмотра, лежит на этом приложении.

Класс SOP хранения состояния объёмного представления Volume Rendering задаёт объёмный вид из одного входного объёма для построения вида, полученного объёмным рендерингом. Последовательность преобразований от объёмных входных данных к значениям PCS-Value явно определена в эталонном конвейере, описанном на Рисунке FF.2.1.2.1-1.

Volume Rendering Volumetric Pipeline

Рисунок FF.2.1.2.1-1. Конвейер объёмного рендеринга


Класс SOP хранения состояния объёмного представления Segmented Volume Rendering задаёт объёмный вид из одного набора объёмных данных с опциональными сегментационными кадрированиями, каждое из которых окрашено отдельно и смешано в рендерируемый объём. Последовательность преобразований от объёмных входных данных к значениям PCS-Value явно определена в эталонном конвейере, описанном на Рисунке FF.2.1.2.1-2.

Для экземпляров этого класса SOP в Volume Stream Sequence (0070,1A08) присутствует единственный элемент.

Классифицированные сегментированные объёмы должны смешиваться в порядке от низшего к высшему приоритету с использованием смешивания «B поверх A» (B-over-A) данных RGB и соответствующих данных непрозрачности (альфа). Первый элемент в Presentation State Classification Component Sequence (0070,1801) является базой, на которую кадрируются и смешиваются методом B-over-A последующие элементы.

Segmented Volume Rendering Volumetric Pipeline

Рисунок FF.2.1.2.1-2. Сегментированный конвейер объёмного рендеринга


Класс SOP хранения состояния объёмного представления Multiple Volume Rendering задаёт объёмный вид из более чем одного входного объёма. Последовательность преобразований от объёмных входных данных к значениям PCS-Value явно определена в эталонном конвейере, описанном на Рисунке FF.2.1.2.1-3. Конкретные алгоритмы объёмного рендеринга могут отличаться, но должны давать сходный внешний вид.

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

Каждый элемент в Volume Stream Sequence (0070,1A08) формирует один вход для компоновщика RGBA (RGBA Compositor).

Multiple Volume Rendering Volumetric Pipeline

Рисунок FF.2.1.2.1-3. Многократный конвейер объёмного рендеринга


Преобразование в значения PCS-Value выполняется после объёмного рендеринга.

FF.2.1.2.2 Компонент объёмного рендеринга

Этот компонент преобразует объём RGBA в вид, полученный объёмным рендерингом, в соответствии с параметрами модуля Render Geometry. Реализация этого компонента зависит от конкретного устройства, но обычно включает такие этапы обработки, как вычисление градиента для нахождения нормалей, используемых в операции затенения, передискретизацию объёмных данных, затенение в соответствии с параметрами модуля Render Shading и композитинг передискретизированных данных для построения итогового вида, полученного объёмным рендерингом.

FF.2.1.2.3 Компонент графической проекции

Этот компонент преобразует объёмную аннотацию, заданную в модуле Volumetric Graphic Annotation, в графический оверлей для двумерного вида, полученного объёмным рендерингом. Роль этого компонента — оценить объёмные графические аннотации, определить, какие графические элементы видны в виде, полученном объёмным рендерингом, и предоставить графику, накладываемую слоями на вид.

Входными данными для компонента графической проекции являются:

  • Модуль Volumetric Graphic Annotation

  • Объём RGBA, поступающий на вход компонента объёмного рендеринга

  • Модуль Volume Render Geometry

  • Значения Input-specific Cropping Specification Index (0070,1205)

  • Атрибуты модуля Volume Cropping

Алгоритм преобразования графической проекции определяет, видна ли каждая объёмная графическая аннотация в текущем виде, полученном объёмным рендерингом, с учётом объёмных данных, геометрии объёмного рендеринга (Volume Render Geometry) и значения Annotation Clipping (0070,1907).

Если Annotation Clipping (0070,1907) имеет значение YES, аннотация должна быть видна только в том случае, если она находится в поле зрения и не закрыта непрозрачными структурами, которые могут находиться между аннотацией и точкой обзора. В случае Volumetric Presentation Input Annotation Sequence (0070,1905) текст аннотации должен быть видимым, только если видна хотя бы часть заданной сегментации.

Если Annotation Clipping (0070,1907) имеет значение NO, аннотация должна быть видна всегда. Конкретная реализация может отображать аннотации, находящиеся за непрозрачными структурами, в другом стиле (например, более тусклым серым цветом), однако решение о предоставлении такого стиля отображения выходит за рамки настоящего стандарта.

Результат работы компонента графической проекции отображается на двумерном виде представления в графических слоях, заданных соответствующими значениями Graphic Layer (0070,0002).

FF.2.2 Объёмные входные данные, регистрация и кадрирование

Состояние объёмного представления может принимать несколько объёмов в качестве входных данных. Объём определён в Разделе C.11.23.1 “Presentation Input Type Volume Input Requirements” в PS3.3. Одни и те же исходные данные могут быть указаны более чем в одном входе.

Для каждого входного объёма сначала к пиксельным данным применяется преобразование Modality LUT либо Rescale Slope и Rescale Intercept, заданное в исходном изображении(ях); в противном случае предполагается тождественное преобразование.

Примечание

В расширенных многокадровых IOD это задаётся в функциональной группе Pixel Value Transformation.

Далее к входным данным применяется VOI LUT, закодированный в состоянии объёмного представления, если он есть; в противном случае предполагается тождественное преобразование.

Входные объёмы могут находиться или не находиться в системе координат отсчёта состояния объёмного представления (VPS-RCS). Если они не находятся в этой системе, они должны быть зарегистрированы в VPS-RCS.

Предусмотрено два метода кадрирования входных объёмов:

  • Все входы состояния объёмного представления могут быть кадрированы с использованием общих методов кадрирования, заданных Global Crop (0070,120B) и элементами Volume Cropping Sequence (0070,1301).

  • Кроме того, кадрирование может быть задано независимо для каждого входа состояния объёмного представления значением Crop (0070,1204) и элементами Volume Cropping Sequence (0070,1301).

Примечание

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

FF.2.3 Отображение состояния объёмного представления

FF.2.3.1 Обзор отображения состояния объёмного представления

Модуль MPR Volumetric Presentation State Display определяет алгоритмы, используемые для преобразования результата объёмной обработки мультипланарной реконструкции входных данных в выходные значения P-Value или PCS-Value для отображения.

Модуль Render Display определяет алгоритмы, используемые для преобразования результата обработки объёмным рендерингом входных данных в выходные значения RGBA. Presentation State Classification Component Sequence (0070,1801) описывает преобразование каждого кадрированного входа в объёмный поток данных RGBA. Volume Stream Sequence (0070,1209) описывает объёмные потоки данных RGBA, которые накладываются с использованием упорядоченного смешивания «B поверх A» в единый объёмный поток данных. Presentation State Compositor Component Sequence (0070,1805) описывает, как объёмные потоки данных, смешанные методом «B поверх A», объединяются (композитятся) в единый объёмный поток данных RGBA. Этот единый поток данных RGBA является входом для компонента объёмного рендеринга.

FF.2.3.2 Описание компонентов отображения

FF.2.3.2.1 Компоненты классификации

В настоящее время определено два типа компонентов классификации для преобразования скалярных входных данных в RGBA. Определены следующие компоненты:

  • One Input -> RGBA: этот компонент принимает реконструированные данные от одного входа в Volumetric Presentation State Input Sequence (0070,1201) и формирует выходные значения RGB и Alpha. Этот компонент классификации задаётся в элементе Presentation State Classification Component Sequence (0070,1801):

    One Input -> RGBA Component

    Рисунок FF.2-3. Один вход -> RGBA-компонент


  • Two Inputs -> RGBA: этот компонент принимает реконструированные данные от двух входов в Volumetric Presentation State Input Sequence (0070,1201) и формирует выходные значения RGB и Alpha. Этот компонент используется в случае, когда требуется выполнить двумерное цветовое отображение. Этот компонент классификации задаётся в элементе Presentation State Classification Component Sequence (0070,1801):

    Two Inputs ->RGBA Component

    Рисунок FF.2-4. Два входа ->RGBA-компонент


    Примечание

    Примером использования этого компонента является объединение Ultrasound Flow Velocity и Ultrasound Flow Variance для получения цветового диапазона от красного к синему на основе скорости потока с добавлением желто-зелёного оттенка на основе дисперсии потока)

FF.2.3.2.2 Компоненты композиции

Определено два типа компонентов композитинга для смешивания двух входных источников данных RGBA (либо одного RGBA и одного RGB). Определены следующие компоненты:

  • RGB Compositor: этот компонент принимает два входа RGBA (при этом один вход Alpha является опциональным) и объединяет данные в единый выход RGB. Каждый элемент Presentation State Compositor Component Sequence (0070,1805) задаёт один компонент RGB Compositor:

    RGB Compositor Component

    Рисунок FF.2-5. RGB-компонент композиции


  • RGBA Compositor: этот компонент принимает два входа RGBA и объединяет данные в единый выход RGB и единый выход Alpha.

    RGBA Compositor Component

    Рисунок FF.2.3.2.2-2. RGBA-компонент композиции


FF.2.3.3 Внутренняя структура компонентов

FF.2.3.3.1 Внутренняя структура компонентов классификации

Component Type (0070,1802) задаёт компонент, определённый в каждом элементе Presentation State Classification Component Sequence (0070,1801), который, в свою очередь, по условиям управляет остальным содержимым элемента, обеспечивая необходимую спецификацию компонента. Внутренняя структура каждого компонента в виде блок-схемы приведена ниже:

  • One Input -> RGBA: задаётся значением Component Type (0070,1802) = ONE_TO_RGBA:

    Internal Structure of One Input -> RGBA Component

    Рисунок FF.2-6. Внутренняя структура компонента «Один вход -> RGBA»


  • Two Inputs -> RGBA: если Component Type (0070,1802) = TWO_TO_RGBA:

    Internal Structure of Two Input -> RGBA Component

    Рисунок FF.2-7. Внутренняя структура компонента «Два входа -> RGBA»


Количество старших битов, извлекаемых из каждого входа, задаётся значением Bits Mapped to Color Lookup Table (0028,1403) в элементе Component Input Sequence (0070,1803) для этого входа.

Если Component Type (0070,1802) = TWO_TO_RGBA, в Component Input Sequence (0070,1803) должно быть два элемента: первый элемент задаёт источник старших битов входа таблицы Palette Color Lookup Table, а второй — источник младших битов входа таблицы Palette Color Lookup Table

FF.2.3.3.2 Внутренняя структура RGB- и RGBA-компонентов композиции

Весовые передаточные функции, вычисляющие весовые коэффициенты, используемые функцией композитинга (Compositor Function) в зависимости от значений Alpha1 и Alpha2, задаются в виде весовых таблиц соответствия (LUT) в компонентах RGB Compositor и RGBA Compositor. Компоненты RGB Compositor и RGBA Compositor идентичны, за исключением композитинга дополнительной компоненты Alpha в RGBA Compositor:

Internal Structure of RGB Compositor Component

Рисунок FF.2-8. Внутренняя структура RGB-компонента композиции


Internal Structure of RGB and Opacity Compositor Component

Рисунок FF.2.3.3.2-1. Внутренняя структура RGB-компонента композиции с непрозрачностью


Поскольку каждая весовая таблица LUT использует оба значения Alpha при определении весового коэффициента, они позволяют реализовать функции композитинга, невозможные, если бы каждый весовой коэффициент зависел только от значения Alpha соответствующего входа. Типичные примеры использования весовых таблиц LUT см. в Разделе XXX.5 “Compositing and the Use of Weighting Transfer Functions” в PS3.17.

Входные биты для весовых таблиц LUT получаются путём объединения двух входов Alpha, при этом половина входных битов берётся от каждого входа Alpha:

  • В случае первого компонента композитинга, соответствующего первому элементу в Presentation State Compositor Component Sequence (0070,1805), значение Alpha от компонента классификации, соответствующего первому элементу в Presentation State Classification Component Sequence (0070,1805), задаёт старшие биты входов весовой таблицы LUT, а значение Alpha от компонента классификации, соответствующего второму элементу в Presentation State Classification Component Sequence (0070,1805), задаёт младшие биты входов весовой таблицы LUT.

  • В случае последующих компонентов композитинга значение Alpha от компонента классификации, соответствующего следующему элементу в Presentation State Classification Component Sequence (0070,1805), задаёт младшие биты входов весовой таблицы LUT, а старшие биты входов весовой таблицы LUT вычисляются как единица минус значение Alpha от компонента классификации, соответствующего следующему элементу в Presentation State Classification Component Sequence (0070,1805).

Целочисленные выходные значения весовых таблиц LUT нормализуются к диапазону от 0,0 до 1,0, и функция композитинга объединяет нормализованные входные значения R, G, B и Alpha (каждый компонент называется «Color» = Cx) следующим образом:

Cout = (C1*Weight1) + (C2*Weight2)

Сумма нормализованных Weight1 и Weight2 не должна превышать 1,0.

Входные значения цвета нормализуются, поскольку количество выходных битов таблиц RGB Palette Color Lookup Table и Alpha Palette Color Lookup Table может отличаться в каждом компоненте классификации.

Выход компонента композитинга должен быть ограничен по диапазону («отсечён»), чтобы гарантировать, что выходные значения находятся в допустимом диапазоне значений цвета независимо от корректности весовых передаточных функций. Это изолирует последующие компоненты композитинга и преобразование пространства подключения профиля (Profile Connection Space Transform) от ошибок переполнения.

FF.2.4 Дополнительные объёмные аспекты

FF.2.4.1 Аннотации в состояниях объёмного представления

Состояния объёмного представления предоставляют два способа аннотирования видов:

  • Аннотации на виде объёмного представления

  • Аннотации, описанные координатами в системе координат отсчёта состояния объёмного представления (VPS-RCS), с опциональными ссылками на структурированные отчёты, задающие контекст.

Аннотации на виде обеспечивают применение свободного неформатированного текста или векторной графики, как описано в Разделе C.10.5 “Graphic Annotation Module” в PS3.3. Поскольку модуль Graphic Annotation позволяет только добавлять графику к двумерному виду, заданному состоянием представления, без привязанного клинического смысла, объёмные графические аннотации предоставляют механизм для создания аннотаций в VPS-RCS с опциональными ссылками на другие объекты, к которым может быть привязан структурированный контекст.

Объёмные графические аннотации могут задаваться в двух вариантах: либо через графические типы (Graphic Types) с 3D-координатами, как определено в Разделе C.18.9.1.2 “Graphic Type” в PS3.3, либо через ссылку на входные данные состояния представления. Второй вариант предназначен для отображения меток аннотаций для сегментаций объёмных данных; например, когда поражение было отмечено с помощью IOD сегментации, и эта сегментация рендерится вместе с анатомическими данными.

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

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

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

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

Примеры объёмных графических аннотаций см. в Разделе XXX.3.4 “Replacing Set of Derived Images With Single VPS Using Crosscurve Animation” в PS3.17 и Разделе XXX.3.5 “Volumetric Annotations (example: Trajectory Planning)” в PS3.17.

FF.2.4.2 Объёмная анимация

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

FF.2.4.2.1 Анимация входной последовательности

Значение Presentation Animation Style (0070,1A01), равное INPUT_SEQ, указывает, что задаётся анимация входной последовательности (Input Sequence Animation). В этом стиле анимации определяется единое состояние объёмного представления, которое включает входные элементы в Volumetric Presentation State Input Sequence (0070,1201) с разными значениями Input Sequence Position Index (0070,1203). Анимированный вид представления формируется путём последовательного перебора значений Input Sequence Position Index (0070,1203) с частотой, заданной Recommended Animation Rate (0070,1A03), где каждое значение индекса даёт один «кадр» анимированного вида на основе входов с этим значением Input Sequence Position Index (0070,1203). См. Рисунок FF.3.2-1.

Примечание

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

В Volumetric Presentation State Input Sequence (0070,1201) может быть более одного входного элемента с одинаковым значением Input Sequence Position Index (0070,1203); в этом случае входы обрабатываются совместно для формирования кадра анимированного вида.

Примечание

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

Input Sequence Animation

Рисунок FF.3.2-1. Анимация входной последовательности


FF.2.4.2.2 Анимация последовательности представления

Значение Presentation Animation Style (0070,1A01), равное PRESENTATION_SEQ, указывает, что задаётся анимация последовательности представления (Presentation Sequence Animation). В этом стиле анимации последовательно применяется набор состояний объёмного представления. См. Рисунок FF.3.2-2.

Примечание

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

Каждое состояние объёмного представления из набора определяется одинаковым значением Presentation Sequence Collection UID (0070,1102). Порядок применения этих состояний представления определяется значением Presentation Sequence Position Index (0070,1103), заданным в состоянии представления. Анимированный вид представления формируется путём последовательного перебора значений индекса позиции последовательности представления с частотой, заданной Recommended Animation Rate (0070,1A03), где каждое значение индекса даёт один «кадр» анимированного вида, формируемый этим состоянием объёмного представления.

Presentation Sequence Animation

Рисунок FF.3.2-2. Анимация последовательности представления


FF.2.4.2.3 Анимация Crosscurve

Значение Presentation Animation Style (0070,1A01), равное CROSSCURVE, указывает, что задаётся анимация Crosscurve. В этом стиле анимации состояние представления задаёт вид Planar MPR в начале кривой, определённой в Animation Curve Sequence (0070,1A04). Вид Planar MPR перемещается на расстояние Animation Step Size (0070,1A05) вдоль кривой, заданной в Animation Curve Sequence (0070,1A04), с частотой, заданной Recommended Animation Rate (0070,1A03), в шагах в секунду. См. Рисунок FF.3.2-3.

Примечание

Типичным применением этого стиля анимации является перемещение вдоль кривой, проходящей по центру толстой кишки или кровеносного сосуда.

Crosscurve Animation

Рисунок FF.3.2-3. Анимация Crosscurve


FF.2.4.2.4 Анимация пролёта

Значение Presentation Animation Style (0070,1A01), равное FLYTHROUGH, указывает, что задаётся анимация пролёта (Flythrough Animation). В этом стиле анимации состояние объёмного представления задаёт исходный вид, полученный объёмным рендерингом, и заданное перемещение вида вдоль пути через объём. См. Рисунок FF.2.4.2.4-1.

Flythrough Animation

Рисунок FF.2.4.2.4-1. Анимация пролёта


FF.2.4.2.5 Анимация вращения

Значение Presentation Animation Style (0070,1A01), равное SWIVEL, указывает, что задаётся анимация вращения (Swivel Animation). В этом стиле анимации состояние представления задаёт исходный вид, полученный объёмным рендерингом, с использованием Viewpoint Position (0070,1603), Viewpoint LookAt Point (0070,1604) и Viewpoint Up Direction (0070,1605). При запуске анимации вид начинает вращаться туда-сюда вокруг оси, параллельной Viewpoint Up Direction (0070,1605) и проходящей через Viewpoint LookAt Point (0070,1604). Величина дуги вращения задаётся Swivel Range (0070,1A06), а максимальная скорость вращения задаётся Recommended Animation Rate (0070,1A03) в градусах в секунду, хотя рекомендуется, чтобы изменения направления на концах диапазона вращения были плавными, что подразумевает замедление вращения по мере приближения к конечным точкам.

FF.2.5 Макет отображения

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

Например:

  • Anatomic Region Sequence (0008,2218) задаёт анатомическую область, охватываемую состоянием объёмного представления

  • View Code Sequence (0054,0220) описывает вид интересующей анатомической области (например, корональный, косой поперечный и т. д.)

  • Presentation Display Collection UID (0070,1101) идентифицирует состояние представления как одно из набора видов, предназначенных для совместного отображения

  • SOP Class UID (0008,0016) идентифицирует, что состояние представления описывает объёмный вид

Использование этих атрибутов позволяет приложению отображения создавать надлежащее представление нескольких состояний объёмного представления — будь то с помощью экземпляра протокола развески (Hanging Protocol), экземпляра структурированного дисплея (Structured Display) или с помощью специфичного для приложения алгоритма.

Пример их использования см. в Приложении XXX “Volumetric Rendering (Informative)” в PS3.17.

FF.3 Поведение SCP

В дополнение к поведению для сервисного класса хранения, заданному в Разделе B.2.2 «Поведение SCP», для классов SOP хранения состояний объёмного представления заданы следующие дополнительные требования:

  • устройство отображения, действующее как SCP этих классов SOP, должно предоставлять все обязательные атрибуты представления для применения к объёмным данным, на которые есть ссылка, по усмотрению пользователя устройства отображения, для всех классов SOP хранения изображений, заданных в заявлении о соответствии, для которых поддерживается класс SOP хранения состояния объёмного представления.

  • устройство отображения, действующее как SCP классов SOP хранения состояний объёмного представления, должно поддерживать класс SOP Segmentation для кадрирования и класс SOP Spatial Registration для регистрации.

  • устройство отображения, действующее как SCP класса SOP хранения состояния объёмного представления Volume Rendering, должно выполнять незатенённый объёмный рендеринг, если модуль Render Shading отсутствует в экземпляре SOP.

  • устройство отображения, действующее как SCP классов SOP хранения состояний объёмного представления, не обязано поддерживать модуль Presentation Animation.

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

FF.4 Соответствие

В дополнение к требованиям к заявлению о соответствии для сервисного класса хранения, заданным в Разделе B.4.3 «Требования к заявлению о соответствии», для классов SOP хранения состояний объёмного представления заданы следующие дополнительные требования:

FF.4.1 Заявление о соответствии для SCU

В заявлении о соответствии любой реализации, заявляющей соответствие классу SOP хранения состояния объёмного представления в качестве SCU, должно быть документировано следующее поведение:

  • Для SCU класса SOP хранения состояния объёмного представления, создающего экземпляр SOP данного класса SOP, — способ получения атрибутов, относящихся к представлению, из отображаемого изображения, вмешательства оператора или значений по умолчанию, а также способ их включения в IOD.

  • Для SCU класса SOP хранения состояния объёмного представления — классы SOP хранения изображений, также поддерживаемые данным SCU, на которые могут ссылаться экземпляры класса SOP хранения состояния объёмного представления.

FF.4.2 Заявление о соответствии для SCP

В заявлении о соответствии любой реализации, заявляющей соответствие классу SOP хранения состояния объёмного представления в качестве SCP, должно быть документировано следующее поведение:

  • Для SCP класса SOP хранения состояния объёмного представления, отображающего изображение, на которое ссылается экземпляр SOP данного класса SOP, — способ, которым атрибуты, относящиеся к представлению, используются для влияния на отображение изображения.

  • Для SCP класса SOP хранения состояния объёмного представления — классы SOP хранения изображений, также поддерживаемые данным SCP, на которые могут ссылаться экземпляры класса SOP хранения состояния объёмного представления.

  • Для SCP класса SOP хранения состояния объёмного представления — поддерживается ли модуль Presentation Animation, и если не поддерживается, — какие уведомления (или их отсутствие) предоставляются пользователю о том, что контекстная информация не отображается.

  • Для SCP класса SOP хранения состояния объёмного представления — поддерживаются ли ссылки на экземпляры структурированных отчётов, и если не поддерживаются, — какие уведомления (или их отсутствие) предоставляются пользователю о том, что контекстная информация не отображается.

GG Класс службы хранения непациентных объектов

GG.1 Обзор

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

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

SOP-экземпляр непациентского объекта соответствует информационной модели IOD составного экземпляра, заданной в PS3.3, у которой в корне не находится информационная сущность Patient. SOP-экземпляры непациентских объектов всё же могут содержать идентифицируемую информацию, связанную с пациентом, например SOP-экземпляры Inventory.

GG.1.2 Определение службы

Класс службы хранения непациентных объектов включает несколько SOP-классов, каждый из которых использует IOD, определённый в PS3.3 (см. Раздел GG.3). Класс службы хранения непациентных объектов использует службу DIMSE C-STORE, определённую в PS3.7. Успешное завершение C-STORE имеет следующую семантику:

  • И SCU, и SCP поддерживают данный тип хранимой информации.

  • Переданная информация сохраняется на некотором носителе.

  • В течение некоторого промежутка времени сохранённая информация может быть доступна.

Примечание

  1. Поддержка класса службы хранения непациентных объектов не подразумевает поддержку каких-либо связанных классов службы запроса/получения.

  2. Продолжительность хранения также зависит от реализации, но описывается в заявлении о соответствии SCP.

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

GG.2 Согласование ассоциации

Правила согласования ассоциации, определённые в PS3.7, применяются к SOP-классам данного класса службы. Специфичная для SOP-класса прикладная информация (расширенное согласование) не используется.

GG.3 SOP-классы

Услуги прикладного уровня, охватываемые определением класса службы хранения непациентных объектов, задаются SOP-классами, указанными в Таблице GG.3-1.

Table GG.3-1. Standard SOP Classes

SOP Class Name

SOP Class UID

Спецификация IOD (определена в PS3.3)

Hanging Protocol Storage

1.2.840.10008.5.1.4.38.1

Hanging Protocol IOD

Color Palette Storage

1.2.840.10008.5.1.4.39.1

Color Palette IOD

Generic Implant Template Storage

1.2.840.10008.5.1.4.43.1

Generic Implant Template IOD

Implant Assembly Template Storage

1.2.840.10008.5.1.4.44.1

Implant Assembly Template IOD

Implant Template Group Storage

1.2.840.10008.5.1.4.45.1

Implant Template Group IOD

CT Defined Procedure Protocol Storage

1.2.840.10008.5.1.4.1.1.200.1

CT Defined Procedure Protocol IOD

Protocol Approval Storage

1.2.840.10008.5.1.4.1.1.200.3

Protocol Approval IOD

XA Defined Procedure Protocol Storage

1.2.840.10008.5.1.4.1.1.200.7

XA Defined Procedure Protocol IOD

Inventory Storage

1.2.840.10008.5.1.4.1.1.201.1

Inventory IOD


GG.4 Поведение

Этот раздел определяет поведение SCU и SCP для службы хранения непациентных объектов. Механизмом передачи SOP-экземпляров между равноправными DICOM AE служит DIMSE-C служба C-STORE, как описано в PS3.7.

Помимо поведения, определённого в этом разделе, могут существовать требования к поведению, специфичные для конкретного SOP-класса, как описано в Разделе GG.6.

GG.4.1 Пользователь класса службы

DICOM AE, заявляющая соответствие любому из SOP-классов хранения непациентных объектов в роли SCU, должна быть способна отправить SOP-экземпляр, удовлетворяющий требованиям соответствующего IOD. Служба вызывается SCU посредством использования запроса DIMSE C-STORE, применяемого совместно с SOP-классом.

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

GG.4.2 Поставщик класса службы

DICOM AE, заявляющая соответствие любому из SOP-классов хранения непациентных объектов в роли SCP, должна принимать и сохранять SOP-экземпляр посредством использования службы DIMSE C-STORE, применяемой совместно с конкретным SOP-классом.

SCP должен сохранять и предоставлять доступ ко всем атрибутам Type 1, Type 2 и Type 3, определённым в IOD, а также к любым стандартным расширенным атрибутам (включая частные атрибуты), включённым в SOP-экземпляр. SCP может, но не обязан проверять, что атрибуты SOP-экземпляра удовлетворяют требованиям соответствующего IOD.

SCP не должен изменять значения каких-либо атрибутов SOP-экземпляра без присвоения нового SOP Instance UID, за исключением того, что SCP может изменять значения или добавлять атрибуты Type 3 и частные атрибуты, не меняющие семантику или интерпретацию SOP-экземпляра.

Примечание

Например, SCP может добавлять значения в Alternate Content Description Sequence (0070,0087), чтобы предоставить дополнительное описание на другом языке.

SCP должен вернуть, посредством примитива ответа C-STORE, код статуса ответа, применимый к соответствующему запросу. Успешным выполнением этой службы SCP указывает, что SOP-экземпляр был успешно сохранён. Таблица GG.4-1 определяет конкретные значения кода статуса ответа, которые могут быть возвращены в ответе C-STORE. Общие значения кода статуса и поля, связанные со значениями кода статуса, определены для службы DIMSE C-STORE в PS3.7.

Table GG.4-1. C-STORE Response Status Values

Статус службы

Дополнительное значение

Status Codes

Related Fields

Failure

Отказано: нехватка ресурсов

A700

(0000,0902)

Ошибка: набор данных не соответствует SOP-классу

A900

(0000,0901)

(0000,0902)

Ошибка: невозможно распознать

C000

(0000,0901)

(0000,0902)

Success

0000

None


Примечание

Коды статуса возвращаются в сообщениях-ответах DIMSE (см. PS3.7). Значения кода, указанные в столбце «Status Codes», возвращаются в элементе команды Status (0000,0900).

GG.5 Требования к заявлению о соответствии

Реализация может соответствовать любому из SOP-классов хранения непациентных объектов в роли SCU, SCP или обоих. Заявление о соответствии должно иметь формат, определённый в PS3.2.

GG.5.1 Требования к соответствию SCU

Реализация, соответствующая SOP-классу службы хранения непациентных объектов в роли SCU, должна указать в своём заявлении о соответствии:

  • Является ли реализация создателем SOP-экземпляров для данного SOP-класса.

    Примечание

    Могут существовать специфичные для SOP-класса требования к заявлению о соответствии для создателей SOP-экземпляров. См. Раздел GG.6.

  • Поведение SCU в случае успешного статуса ответа C-STORE.

  • Поведение SCU в каждом случае неуспешного статуса ответа C-STORE.

GG.5.2 Требования к соответствию SCP

Реализация, соответствующая SOP-классу службы хранения непациентных объектов в роли SCP, должна указать в своём заявлении о соответствии:

  • Поведение SCP в случае успешной операции C-STORE, включая метод доступа к сохранённому SOP-экземпляру и продолжительность хранения.

  • Значение каждого случая неуспешного статуса ответа C-STORE, а также соответствующее действие по восстановлению.

Примечание

Могут существовать специфичные для SOP-класса требования к заявлению о соответствии для приложений, интерпретирующих SOP-экземпляры для отображения или дальнейшей обработки. См. Раздел GG.6.

GG.6 Поведение приложения для стандартных SOP-классов

Этот раздел определяет специфичное для SOP-класса поведение соответствующих приложений.

GG.6.1 SOP-класс хранения протокола размещения

GG.6.1.1 Создатель экземпляра

Реализация, соответствующая SOP-классу хранения протокола размещения в роли SCU и являющаяся создателем SOP-экземпляров, должна указать в своём заявлении о соответствии:

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

  • Любые частные атрибуты, используемые в качестве значения Selector Attribute (0072,0026) в Image Set Selector Sequence, Filter Operations Sequence или Sorting Operations Sequence.

  • Необязательные атрибуты, которые могут быть включены в SOP-экземпляр протокола размещения.

GG.6.1.2 Приложение отображения

Реализация, соответствующая SOP-классу хранения протокола размещения в роли SCP и интерпретирующая содержимое экземпляров этого SOP-класса для управления отображением изображений, должна применять все обязательные атрибуты протокола размещения и предполагаемого представления к наборам отображаемых изображений. Такая реализация должна указать в своём заявлении о соответствии:

  • Диапазон сред отображения, которые поддерживает приложение (например, количество экранов, размер экранов, перекрывающиеся области изображения).

  • Необязательные атрибуты IOD протокола размещения, которые приложение способно интерпретировать, и те, которые не поддерживаются.

  • Описание поведения приложения, когда значение Partial Data Display Handling (0072,0208) равно ADAPT_LAYOUT или имеет нулевую длину.

  • Описание поведения приложения, когда среда отображения экземпляра протокола размещения отличается от среды отображения приложения, применительно к сохранению макета в сравнении с пространственным разрешением.

  • SOP-классы хранения изображений, для которых поддерживается SOP-класс хранения протокола размещения для управления отображением.

GG.6.2 SOP-класс хранения цветовой палитры

GG.6.2.1 Создатель экземпляра

Реализация, соответствующая SOP-классу хранения цветовой палитры в роли SCU и являющаяся создателем SOP-экземпляров, должна указать в своём заявлении о соответствии:

  • Необязательные атрибуты, которые могут быть включены в SOP-экземпляр цветовой палитры.

GG.6.2.2 Приложение отображения

Реализация, соответствующая SOP-классу хранения цветовой палитры в роли SCP и интерпретирующая содержимое экземпляров этого SOP-класса для воздействия на отображение изображений, должна применять все обязательные атрибуты цветовой палитры и предполагаемого представления к соответствующим отображаемым изображениям.

Реализация, соответствующая SOP-классу хранения цветовой палитры в роли SCP и интерпретирующая содержимое экземпляров этого SOP-класса для воздействия на отображение изображений, должна указать в своём заявлении о соответствии:

  • Необязательные атрибуты IOD цветовой палитры, которые приложение способно интерпретировать, и те, которые не поддерживаются.

  • SOP-классы хранения изображений, для которых поддерживается применение SOP-класса хранения цветовой палитры.

GG.6.3 SOP-классы хранения шаблонов

Реализация, являющаяся SCU SOP-класса Generic Implant Template Storage, Implant Assembly Template Storage или Implant Template Group Storage, может изменять информацию в SOP-экземпляре, который она ранее отправила или получила. Когда такой SOP-экземпляр изменён и отправлен SCP, ему должен быть присвоен новый SOP Instance UID, если происходит добавление, удаление или изменение любого атрибута в составе:

  • Generic Implant Template Description Module

  • Generic Implant Template 2D Drawings Module

  • Generic Implant Template 3D Models Module

  • Generic Implant Template Mating Features Module

  • Generic Implant Template Planning Landmarks Module

  • Implant Assembly Template Module

  • Implant Template Group Module

  • Surface Mesh Module

Ссылочная целостность между наборами связанных SOP-экземпляров должна поддерживаться.

GG.6.4 SOP-класс хранения протокола определённой процедуры CT и XA

Реализация, соответствующая SOP-классам хранения протокола определённой процедуры CT и/или XA в роли SCP, не должна изменять ограничения, для которых значение Modifiable Constraint Flag (0082,0038) равно NO.

Изменение ограничений протокола меняет семантику SOP-экземпляра хранения протокола определённой процедуры CT или XA.

GG.6.5 SOP-класс хранения утверждения протокола

Утверждения основаны на подтверждениях (assertions). Получение или формирование подтверждения будет взаимодействовать с организационными политиками аутентификации и авторизации. Например, утверждение может быть получено по ошибке в составе передачи записи о пациенте.

GG.6.6 SOP-класс хранения инвентаризации

GG.6.6.1 Создатель экземпляра

Реализация, соответствующая SOP-классу хранения инвентаризации в роли SCU и являющаяся создателем SOP-экземпляров, должна указать в своём заявлении о соответствии:

  • Механизмы, посредством которых инициируется создание SOP-экземпляров Inventory.

  • Политики/параметры разбиения логической инвентаризации на несколько SOP-экземпляров Inventory.

  • Любые ограничения на Inventory Level (0008,0403) SOP-экземпляров Inventory.

  • Любые не относящиеся к DICOM механизмы доступа к инвентаризированным SOP-экземплярам, которые могут быть заданы Stored Instance URI, включая протоколы (такие как NFS, SMB или HTTP), а также использование папок и/или файлов-контейнеров (ZIP, TAR, GZIP, TARGZIP, BLOB) для SOP-экземпляров.

  • Политики/параметры продолжительности хранения или удаления созданных SOP-экземпляров Inventory.

  • Предоставляет ли реализация записи для сущностей в нескольких репозиториях (федерация), и как она обрабатывает различия в поддержке сопоставления атрибутов между этими репозиториями при построении SOP-экземпляров Inventory.

HH Классы служб запроса/извлечения протоколов определённых процедур

HH.1 Обзор

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

Классы служб запроса/извлечения протоколов определённых процедур определяют классы сервисов прикладного уровня, обеспечивающие доступ к композитным объектам Defined Procedure Protocol.

HH.1.2 Условные обозначения

Ключевые атрибуты служат двум целям: они могут использоваться как ключевые атрибуты сопоставления или как возвращаемые ключевые атрибуты. Ключевые атрибуты сопоставления используются для сопоставления (критерии, применяемые в запросе C-FIND для определения того, соответствует ли сущность запросу). Возвращаемые ключевые атрибуты используются для указания желаемых возвращаемых атрибутов (какие элементы, помимо ключевых атрибутов сопоставления, должны быть возвращены в ответе C-FIND).

Примечание

Ключи сопоставления обычно используются в предложении SQL «where». Возвращаемые ключи обычно используются в предложении SQL «select» для передачи значений атрибутов.

Ключевые атрибуты сопоставления могут иметь Тип «обязательный» (R) или «необязательный» (O). Возвращаемые ключевые атрибуты могут иметь Тип 1, 1C, 2, 2C, 3, как определено в PS3.5 Data Structure and Semantics.

HH.1.3 Информационная модель запроса/извлечения

Для того чтобы служить SCP класса сервиса запроса/извлечения протоколов определённых процедур, DICOM AE обладает информацией об атрибутах ряда композитных экземпляров SOP Defined Procedure Protocol. Эта информация организована в информационную модель. Информационные модели для различных классов SOP, указанных в настоящем Приложении, определены в Section HH.6.

HH.1.4 Определение службы

Два равноправных DICOM AE реализуют класс SOP класса сервиса запроса/извлечения протоколов определённых процедур, причём один выступает в роли SCU, а другой — в роли SCP. Классы SOP классов сервисов запроса/извлечения протоколов определённых процедур реализуются с использованием сервисов DIMSE-C C-FIND, C-MOVE и C-GET, как определено в PS3.7 Message Exchange Protocol.

SCP этого класса SOP должен поддерживать уровень хранения 2 (полный), определённый в Section B.4.1.

Семантика сервиса C-FIND совпадает с семантикой, определённой в разделе «Определение сервиса» класса сервиса базового управления рабочим списком.

Семантика сервиса C-MOVE совпадает с семантикой, определённой в разделе «Определение сервиса» сервисного класса запроса/получения, за исключением того, что имеется только один уровень получения.

Семантика сервиса C-GET совпадает с семантикой, определённой в разделе «Определение сервиса» сервисного класса запроса/получения, за исключением того, что имеется только один уровень получения.

HH.2 Определения информационных моделей протоколов определённых процедур

Информационные модели протоколов определённых процедур определяются классом SOP, согласованным во время установления ассоциации. Каждый класс SOP состоит из информационной модели и группы сервисов DIMSE-C.

Информационные модели протоколов определённых процедур определены в Section HH.6, with the Entity-Relationship Model Definition and Key Attributes Definition analogous to those defined in the Worklist Information Model Definition of the Basic Worklist Management Service.

HH.3 Информационные модели протоколов определённых процедур

Информационные модели протоколов определённых процедур основаны на одноуровневой сущности:

  • Экземпляр объекта Defined Procedure Protocol.

Экземпляр объекта Defined Procedure Protocol содержит атрибуты, связанные с информационной сущностью (IE) объекта Procedure Protocol композитных IOD, как определено в PS3.3 Information Object Definitions.

HH.4 Группы служб DIMSE-C

HH.4.1 Операция C-FIND

См. определение операции C-FIND для Section K.4.1.3.1 “"Worklist" Search Method”, заменив «Worklist» на «Defined Procedure Protocol». Должен использоваться метод поиска «Worklist».

UID класса SOP определяет информационную модель протоколов определённых процедур, относительно которой выполняется C-FIND. Ключевые атрибуты и допустимые для запроса значения определены в определениях классов SOP для информационной модели протоколов определённых процедур.

HH.4.1.1 Поведение пользователя класса службы

Специфичное для класса SOP поведение SCU не определено.

HH.4.1.2 Поведение поставщика класса службы

Специфичное для класса SOP поведение SCP не определено.

HH.4.2 Операция C-MOVE

См. определение операции C-MOVE для Section C.4.2 “C-MOVE Operation”. Для классов сервисов запроса/извлечения протоколов определённых процедур не определены ни расширенное поведение, ни реляционное получение.

Query/Retrieve Level (0008,0052) не имеет отношения к классам сервисов запроса/извлечения протоколов определённых процедур и поэтому не должен присутствовать в идентификаторе. Единственным уникальным ключевым атрибутом идентификатора должен быть SOP Instance UID (0008,0018). SCU должен предоставить один UID или список UID.

Примечание

Может быть получена более чем одна сущность с использованием сопоставления по списку UID.

HH.4.3 Операция C-GET

См. определение операции C-GET для Section C.4.2 “C-MOVE Operation”. Для классов сервисов запроса/извлечения протоколов определённых процедур не определены ни расширенное поведение, ни реляционное получение.

Примечание

Может быть получена более чем одна сущность с использованием сопоставления по списку UID.

HH.5 Согласование ассоциации

См. определение согласования ассоциации для Section K.5 “Association Negotiation”.

HH.6 Определения SOP-классов

HH.6.1 Информационная модель протоколов определённых процедур

HH.6.1.1 Модели E/R

Информационная модель протоколов определённых процедур состоит из одной сущности. В ответ на заданный запрос C-FIND SCP должен отправить один ответ C-FIND на каждый подходящий экземпляр Defined Procedure Protocol.

Defined Procedure Protocol Information Model E-R Diagram

Рисунок HH.6-1. E-R-диаграмма информационной модели протоколов определённых процедур


HH.6.1.2 Атрибуты протоколов определённых процедур

Таблица HH.6-1 определяет атрибуты информационной модели протоколов определённых процедур.

Таблица HH.6-1. Атрибуты для информационной модели протоколов определённых процедур

Описание / Модуль

Tag

Тип ключа сопоставления

Тип возвращаемого ключа

Примечание / Тип сопоставления

SOP Common

Specific Character Set

(0008,0005)

-

1C

Этот атрибут является обязательным, если используются расширенные или заменяющие наборы символов. См. Section C.2.2.2 и Section C.4.1.1.

SOP Class UID

(0008,0016)

R

1

SOP Instance UID

(0008,0018)

U

1

Protocol Context

Custodial Organization Sequence

(0040,A07C)

R

2

>Institution Name

(0008,0080)

R

2

>Institution Code Sequence

(0008,0082)

R

2

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

>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

Responsible Group Code Sequence

(0008,0220)

R

2

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

>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

Protocol Name

(0018,1030)

R

1

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

Potential Scheduled Protocol Code Sequence

(0018,9906)

R

1

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

>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

Potential Requested Procedure Code Sequence

(0018,9907)

R

1

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

>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

Potential Reasons for Procedure

(0018,9908)

-

2

Potential Reasons for Procedure Code Sequence

(0018,9909)

R

2

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

>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

Potential Diagnostic Tasks

(0018,990A)

-

2

Predecessor Protocol Sequence

(0018,990E)

R

2

>Referenced SOP Class UID

(0008,1150)

R

1

Должен быть получен с использованием сопоставления по списку UID.

>Referenced SOP Instance UID

(0008,1155)

R

1

Должен быть получен с использованием сопоставления по списку UID.

Content Creator's Name

(0070,0084)

R

1

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

Instance Creation Date

(0008,0012)

R

1

Должен быть получен с использованием сопоставления по единственному значению или сопоставления по диапазону.

См. дополнительные сведения в описании атрибута Instance Creation Time.

Instance Creation Time

(0008,0013)

R

1

Должен быть получен с использованием сопоставления по единственному значению или сопоставления по диапазону.

Если и Instance Creation Date, и Instance Creation Time указаны для сопоставления по диапазону, они должны рассматриваться как единый атрибут DateTime, например, диапазон дат с 5 по 7 июля и диапазон времени с 10:00 до 18:00 задают период времени, начинающийся 5 июля в 10:00 и заканчивающийся 7 июля в 18:00.

Clinical Trial Context

Clinical Trial Sponsor Name

(0012,0010)

R

1

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

Clinical Trial Protocol ID

(0012,0020)

R

1

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

Equipment Specification

Equipment Modality

(0008,0221)

R

1

Model Specification Sequence

(0018,9912)

R

2

>Manufacturer

(0008,0070)

R

1

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

>Manufacturer's Related Model Group

(0008,0222)

R

2

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

>Manufacturer's Model Name

(0008,1090)

R

2

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

>Software Versions

(0018,1020)

R

2

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

>Device Serial Number

(0018,1000)

-

2

Patient Positioning

Anatomic Region Sequence

(0008,2218)

R

2

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

>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

Primary Anatomic Structure Sequence

(0008,2228)

R

2

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

>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”


HH.6.1.3 Требования к соответствию

Реализация может соответствовать одному или нескольким SOP-классам запроса/извлечения протоколов определённых процедур в роли SCU или SCP. Заявление о соответствии должно быть представлено в формате, определённом в PS3.2.

HH.6.1.3.1 Соответствие SCU
HH.6.1.3.1.1 Соответствие SCU C-FIND

Реализация, соответствующая классу SOP Defined Procedure Protocol Information Model - FIND, должна поддерживать запросы к информационной модели протоколов определённых процедур с использованием поведения SCU C-FIND, описанного для класса сервиса базового управления рабочим списком (см. Section K.4.1.2 и Section HH.4.1).

Реализация, соответствующая классу SOP Defined Procedure Protocol Information Model - FIND в роли SCU, должна указать в своём заявлении о соответствии, запрашивает ли она возвращаемые ключевые атрибуты Типа 3, и должна перечислить эти необязательные возвращаемые ключевые атрибуты.

Реализация, соответствующая классу SOP Defined Procedure Protocol Information Model - FIND в роли SCU, должна указать в своём заявлении о соответствии, каким образом она использует Specific Character Set (0008,0005) при кодировании запросов и интерпретации ответов.

HH.6.1.3.1.2 Соответствие SCU C-MOVE

Реализация, соответствующая классу SOP Defined Procedure Protocol Information Model - MOVE в роли SCU, должна поддерживать передачи в отношении информационной модели протоколов определённых процедур с использованием базового поведения SCU C-MOVE, описанного для сервисного класса запроса/получения (см. Section C.4.2.2.1 и Section HH.4.2).

HH.6.1.3.1.3 Соответствие SCU C-GET

Реализация, соответствующая классу SOP Defined Procedure Protocol Information Model - GET в роли SCU, должна поддерживать передачи в отношении информационной модели протоколов определённых процедур с использованием базового поведения SCU C-GET, описанного для сервисного класса запроса/получения (см. Section C.4.3.2).

HH.6.1.3.2 Соответствие SCP
HH.6.1.3.2.1 Соответствие SCP C-FIND

Реализация, соответствующая классу SOP Defined Procedure Protocol Information Model - FIND в роли SCP, должна поддерживать запросы к информационной модели протоколов определённых процедур с использованием поведения SCP C-FIND, описанного для класса сервиса базового управления рабочим списком (см. Section K.4.1.3).

Примечание

Содержимое Model Specification Sequence (0018,9912) было бы полезно индексировать для систем, поддерживающих запрос или выбор подходящих протоколов для конкретных систем.

Реализация, соответствующая классу SOP Defined Procedure Protocol Information Model - FIND в роли SCP, должна указать в своём заявлении о соответствии, поддерживает ли она возвращаемые ключевые атрибуты Типа 3, и должна перечислить эти необязательные возвращаемые ключевые атрибуты.

Реализация, соответствующая классу SOP Defined Procedure Protocol Information Model - FIND в роли SCP, должна указать в своём заявлении о соответствии, каким образом она использует Specific Character Set (0008,0005) при интерпретации запросов, выполнении сопоставления и кодировании ответов.

HH.6.1.3.2.2 Соответствие SCP C-MOVE

Реализация, соответствующая классу SOP Defined Procedure Protocol Information Model - MOVE в роли SCP, должна поддерживать передачи в отношении информационной модели протоколов определённых процедур с использованием базового поведения SCP C-MOVE, описанного для сервисного класса запроса/получения (см. Section C.4.2.3.1).

Примечание

Ожидается, что устройство, не соответствующее содержимому Model Specification Sequence (0018,9912), не будет выполнять протокол.

Реализация, соответствующая классу SOP Defined Procedure Protocol Information Model - MOVE в роли SCP и генерирующая передачи с помощью операции C-MOVE, должна указать в своём заявлении о соответствии соответствующий сервисный класс хранения, в рамках которого она будет поддерживать подоперации C-STORE, генерируемые C-MOVE.

HH.6.1.3.2.3 Соответствие SCP C-GET

Реализация, соответствующая классу SOP Defined Procedure Protocol Information Model - GET в роли SCP, должна поддерживать извлечения в отношении информационной модели протоколов определённых процедур с использованием базового поведения SCP C-GET, описанного для сервисного класса запроса/получения в Section C.4.3.3.

HH.6.1.4 SOP-классы

Классы SOP класса сервиса запроса/извлечения протоколов определённых процедур определяют информационные модели и поддерживаемые операции DIMSE-C.

Таблица HH.6.1.4-1. SOP-классы протоколов определённых процедур

SOP Class Name

SOP Class UID

Defined Procedure Protocol Information Model - FIND

1.2.840.10008.5.1.4.20.1

Defined Procedure Protocol Information Model - MOVE

1.2.840.10008.5.1.4.20.2

Defined Procedure Protocol Information Model - GET

1.2.840.10008.5.1.4.20.3


II Protocol Approval Query/Retrieve Service Classes

II.1 Обзор

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

Классы служб запроса/извлечения утверждений протоколов определяют классы сервисов прикладного уровня, обеспечивающие доступ к композитным объектам Protocol Approval.

II.1.2 Условные обозначения

Ключевые атрибуты служат двум целям: они могут использоваться как ключевые атрибуты сопоставления или как возвращаемые ключевые атрибуты. Ключевые атрибуты сопоставления используются для сопоставления (критерии, применяемые в запросе C-FIND для определения того, соответствует ли сущность запросу). Возвращаемые ключевые атрибуты используются для указания желаемых возвращаемых атрибутов (какие элементы, помимо ключевых атрибутов сопоставления, должны быть возвращены в ответе C-FIND).

Примечание

Ключи сопоставления обычно используются в предложении SQL «where». Возвращаемые ключи обычно используются в предложении SQL «select» для передачи значений атрибутов.

Ключевые атрибуты сопоставления могут иметь Тип «обязательный» (R) или «необязательный» (O). Возвращаемые ключевые атрибуты могут иметь Тип 1, 1C, 2, 2C, 3, как определено в PS3.5 Data Structure and Semantics.

II.1.3 Информационная модель запроса/извлечения

Для того чтобы служить SCP класса сервиса запроса/извлечения утверждений протоколов, DICOM AE обладает информацией об атрибутах ряда композитных экземпляров SOP Protocol Approval. Эта информация организована в информационную модель. Информационные модели для различных классов SOP, указанных в настоящем Приложении, определены в Section II.6.

II.1.4 Определение службы

Два равноправных DICOM AE реализуют класс SOP класса сервиса запроса/извлечения утверждений протоколов, причём один выступает в роли SCU, а другой — в роли SCP. Классы SOP классов сервисов запроса/извлечения утверждений протоколов реализуются с использованием сервисов DIMSE-C C-FIND, C-MOVE и C-GET, как определено в PS3.7 Message Exchange Protocol.

SCP этого класса SOP должен поддерживать уровень хранения 2 (полный), определённый в Section B.4.1.

Семантика сервиса C-FIND совпадает с семантикой, определённой в разделе «Определение сервиса» класса сервиса базового управления рабочим списком.

Семантика сервиса C-MOVE совпадает с семантикой, определённой в разделе «Определение сервиса» сервисного класса запроса/получения, за исключением того, что имеется только один уровень получения.

Семантика сервиса C-GET совпадает с семантикой, определённой в разделе «Определение сервиса» сервисного класса запроса/получения, за исключением того, что имеется только один уровень получения.

II.2 Определения информационных моделей утверждений протоколов

Информационные модели утверждений протоколов определяются классом SOP, согласованным во время установления ассоциации. Каждый класс SOP состоит из информационной модели и группы сервисов DIMSE-C.

Информационные модели утверждений протоколов определены в Section II.6, при этом определение модели «сущность-связь» и определение ключевых атрибутов аналогичны определённым для информационной модели рабочего списка класса сервиса базового управления рабочим списком.

II.3 Информационные модели утверждений протоколов

Информационные модели утверждений протоколов основаны на одноуровневой сущности:

  • Экземпляр объекта Protocol Approval.

Экземпляр объекта Protocol Approval содержит атрибуты, связанные с информационной сущностью (IE) Approval композитных IOD, как определено в PS3.3 Information Object Definitions.

II.4 Группы служб DIMSE-C

II.4.1 Операция C-FIND

См. определение операции C-FIND для класса сервиса базового управления рабочим списком (Section K.4.1), заменив «Worklist» на «Approval». Должен использоваться метод поиска «Worklist».

UID класса SOP определяет информационную модель утверждений протоколов, относительно которой выполняется C-FIND. Ключевые атрибуты и допустимые для запроса значения определены в определениях классов SOP для информационной модели утверждений протоколов.

II.4.1.1 Поведение пользователя класса службы

Специфичное для класса SOP поведение SCU не определено.

II.4.1.2 Поведение поставщика класса службы

Специфичное для класса SOP поведение SCP не определено.

II.4.2 Операция C-MOVE

См. определение операции C-MOVE для сервисного класса запроса/получения (Section C.4.2). Для классов сервисов запроса/извлечения утверждений протоколов не определены ни расширенное поведение, ни реляционное получение.

Query/Retrieve Level (0008,0052) не имеет отношения к классам сервисов запроса/извлечения утверждений протоколов и поэтому не должен присутствовать в идентификаторе. Единственным уникальным ключевым атрибутом идентификатора должен быть SOP Instance UID (0008,0018). SCU должен предоставить один UID или список UID.

Примечание

Может быть получена более чем одна сущность с использованием сопоставления по списку UID.

II.4.3 Операция C-GET

См. определение операции C-GET для сервисного класса запроса/получения (Section C.4.2). Для классов сервисов запроса/извлечения утверждений протоколов не определены ни расширенное поведение, ни реляционное получение.

Примечание

Может быть получена более чем одна сущность с использованием сопоставления по списку UID.

II.5 Согласование ассоциации

См. определение согласования ассоциации для класса сервиса базового управления рабочим списком (Section K.5).

II.6 Определения SOP-классов

II.6.1 Информационная модель утверждений протоколов

II.6.1.1 Модели E/R

Информационная модель утверждений протоколов состоит из одной сущности. В ответ на заданный запрос C-FIND SCP должен отправить один ответ C-FIND на каждый подходящий экземпляр Protocol Approval.

Protocol Approval Information Model E-R Diagram

Figure II.6-1. Protocol Approval Information Model E-R Diagram


II.6.1.2 Атрибуты утверждений протоколов

Таблица II.6-1 определяет атрибуты информационной модели утверждений протоколов.

Примечание

Поскольку утверждения протоколов, как правило, имеют значение только в контексте утверждаемого экземпляра протокола, многие запросы будут искать утверждения, содержащие конкретный экземпляр протокола в Approval Subject Sequence (0044,0109).

Table II.6-1. Attributes for the Protocol Approval Information Model

Описание / Модуль

Tag

Тип ключа сопоставления

Тип возвращаемого ключа

Примечание / Тип сопоставления

SOP Common

Specific Character Set

(0008,0005)

-

1C

Этот атрибут является обязательным, если используются расширенные или заменяющие наборы символов. См. Section C.2.2.2 и Section C.4.1.1.

SOP Class UID

(0008,0016)

R

1

SOP Instance UID

(0008,0018)

U

1

Instance Creation Date

(0008,0012)

R

1

Должен быть получен с использованием сопоставления по единственному значению или сопоставления диапазона.

См. Instance Creation Time для дополнительных сведений.

Instance Creation Time

(0008,0013)

R

1

Должен быть получен с использованием сопоставления по единственному значению или сопоставления диапазона.

Если и Instance Creation Date, и Instance Creation Time указаны для сопоставления диапазона, они рассматриваются как единый атрибут DateTime, например, диапазон дат с 5 по 7 июля и диапазон времени с 10:00 до 18:00 задаёт период времени, начинающийся 5 июля в 10:00 и заканчивающийся 7 июля в 18:00.

Protocol Approval

Approval Subject Sequence

(0044,0109)

R

1

>Referenced SOP Class UID

(0008,1150)

R

1

Должен быть получен с использованием сопоставления по списку UID.

>Referenced SOP Instance UID

(0008,1155)

R

1

Должен быть получен с использованием сопоставления по списку UID.

Approval Sequence

(0044,0100)

R

1

>Assertion Code Sequence

(0044,0101)

R

1

>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

>Assertion UID

(0044,0102)

-

1

>Asserter Identification Sequence

(0044,0103)

R

1

>>Observer Type

(0040,A084)

-

1

>>Person Name

(0040,A123)

R

1

>>Person Identification Code Sequence

(0040,1101)

R

1

>>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

>>Organizational Role Code Sequence

(0044,010A)

R

2

>>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

>>Station Name

(0008,1010)

-

3

>>Device UID

(0018,1002)

-

3

>>Manufacturer

(0008,0070)

-

3

>>Manufacturer's Model Name

(0008,1090)

-

3

>>Station AE Title

(0008,0055)

-

3

>>Institution Name

(0008,0080)

R

1

>>Institution Code Sequence

(0008,0082)

R

1

>>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

>>Institutional Department Name

(0008,1040)

U

2

>>Institutional Department Type Code Sequence

(0008,1041)

U

3

>>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением”

>Assertion DateTime

(0044,0104)

R

1

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

>Assertion Expiration DateTime

(0044,0105)

R

2

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

>Assertion Comments

(0044,0106)

-

2

>Related Assertion Sequence

(0044,0107)

U

1

>>Referenced Assertion UID

(0044,0108)

U

1

Enhanced General Equipment

Manufacturer

(0008,0070)

-

1

Manufacturer's Model Name

(0008,1090)

-

2

Software Versions

(0018,1020)

-

2


Примечание

Модуль Enhanced General Equipment описывает оборудование, создавшее экземпляр Protocol Approval, а не оборудование, на котором будет выполняться протокол, на который ссылается утверждение.

II.6.1.3 Требования к соответствию

Реализация может соответствовать одному или нескольким классам SOP запроса/извлечения утверждений протоколов в роли SCU или SCP. Заявление о соответствии должно быть оформлено в формате, определённом в PS3.2.

II.6.1.3.1 Соответствие SCU
II.6.1.3.1.1 Соответствие SCU C-FIND

Реализация, соответствующая классу SOP Protocol Approval Information Model - FIND, должна поддерживать запросы к информационной модели утверждений протоколов с использованием поведения SCU C-FIND, описанного для класса сервиса базового управления рабочим списком (см. Section K.4.1.2 и Section II.4.1).

Реализация, соответствующая классу SOP Protocol Approval Information Model - FIND в роли SCU, должна указать в своём заявлении о соответствии, запрашивает ли она возвращаемые ключевые атрибуты Типа 3, и должна перечислить эти необязательные возвращаемые ключевые атрибуты.

Реализация, соответствующая классу SOP Protocol Approval Information Model - FIND в роли SCU, должна указать в своём заявлении о соответствии, как она использует Specific Character Set (0008,0005) при кодировании запросов и интерпретации ответов.

II.6.1.3.1.2 Соответствие SCU C-MOVE

Реализация, соответствующая классу SOP Protocol Approval Information Model - MOVE в роли SCU, должна поддерживать передачи данных для информационной модели утверждений протоколов с использованием базового поведения SCU C-MOVE, описанного для сервисного класса запроса/получения (см. Section C.4.2.2.1 и Section II.4.2).

II.6.1.3.1.3 Соответствие SCU C-GET

Реализация, соответствующая классу SOP Protocol Approval Information Model - GET в роли SCU, должна поддерживать передачи данных для информационной модели утверждений протоколов с использованием базового поведения SCU C-GET, описанного для сервисного класса запроса/получения (см. Section C.4.3.2).

II.6.1.3.2 Соответствие SCP
II.6.1.3.2.1 Соответствие SCP C-FIND

Реализация, соответствующая классу SOP Protocol Approval Information Model - FIND в роли SCP, должна поддерживать запросы к информационной модели утверждений протоколов с использованием поведения SCP C-FIND, описанного для класса сервиса базового управления рабочим списком (см. Section K.4.1.3).

Примечание

Было бы полезно индексировать содержимое Referenced SOP Instance UID (0008,1155) в Approval Subject Sequence (0044,0109), поскольку запросы утверждений для конкретного экземпляра протокола будут очень распространены.

Реализация, соответствующая классу SOP Protocol Approval Information Model - FIND в роли SCP, должна указать в своём заявлении о соответствии:

  • поддерживает ли она возвращаемые ключевые атрибуты Типа 3, и должна перечислить эти необязательные возвращаемые ключевые атрибуты.

  • как она использует Specific Character Set (0008,0005) при интерпретации запросов, выполнении сопоставления и кодировании ответов.

  • любое поведение, связанное с невозвратом подходящих экземпляров (например, невозврат более старого экземпляра утверждения, который был заменён/перекрыт более новым экземпляром утверждения).

II.6.1.3.2.2 Соответствие SCP C-MOVE

Реализация, соответствующая классу SOP Protocol Approval Information Model - MOVE в роли SCP, должна поддерживать передачи данных для информационной модели утверждений протоколов с использованием базового поведения SCP C-MOVE, описанного для сервисного класса запроса/получения (см. Section C.4.2.3.1).

Реализация, соответствующая классу SOP Protocol Approval Information Model - MOVE в роли SCP, которая генерирует передачи данных с использованием операции C-MOVE, должна указать в своём заявлении о соответствии подходящий сервисный класс хранения, в рамках которого она должна поддерживать субоперации C-STORE, порождаемые C-MOVE.

II.6.1.3.2.3 Соответствие SCP C-GET

Реализация, соответствующая классу SOP Protocol Approval Information Model - GET в роли SCP, должна поддерживать извлечение данных для информационной модели утверждений протоколов с использованием базового поведения SCP C-GET, описанного для сервисного класса запроса/получения в Section C.4.3.3.

II.6.1.4 SOP-классы

Классы SOP класса сервиса запроса/извлечения утверждений протоколов определяют информационные модели и поддерживаемые операции DIMSE-C.

Table II.6.1.4-1. Protocol Approval SOP Classes

SOP Class Name

SOP Class UID

Protocol Approval Information Model - FIND

1.2.840.10008.5.1.4.1.1.200.4

Protocol Approval Information Model - MOVE

1.2.840.10008.5.1.4.1.1.200.5

Protocol Approval Information Model - GET

1.2.840.10008.5.1.4.1.1.200.6


JJ Класс службы запроса/извлечения инвентаризации

JJ.1 Обзор

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

Класс службы запроса/извлечения инвентаризации определяет прикладной класс сервиса, обеспечивающий обнаружение композитных объектов Inventory и доступ к ним.

JJ.1.2 Условные обозначения

См. Класс базовой службы управления рабочим списком, раздел K.1.2 «Условные обозначения».

JJ.1.3 Определение службы

Каждый SOP-класс службы запроса/извлечения инвентаризации состоит из информационной модели и группы служб DIMSE-C.

Для того чтобы выступать в роли SCP службы запроса/извлечения инвентаризации, прикладной объект DICOM (AE) обладает сведениями об атрибутах ряда композитных SOP-экземпляров Inventory. Эта информация организована в виде информационной модели запроса/извлечения инвентаризации.

Два равноправных прикладных объекта DICOM (AE) реализуют SOP-класс службы запроса/извлечения инвентаризации, причём один выступает в роли SCU, а другой — в роли SCP. SOP-классы службы запроса/извлечения инвентаризации реализуются с использованием служб DIMSE-C C-FIND, C-MOVE и C-GET, определённых в PS3.7.

Семантика службы C-FIND совпадает с определённой в разделе «Определение службы» Класса базовой службы управления рабочим списком (см. раздел C.1.4).

Семантика служб C-MOVE и C-GET совпадает с определённой в разделе «Определение службы» сервисного класса запроса/извлечения (см. раздел C.1.4), за исключением того, что имеется только один уровень извлечения.

JJ.2 Информационная модель Q/R инвентаризации

Информационная модель запроса/извлечения (Q/R) инвентаризации основана на определении модели «сущность-связь» и определении ключевых атрибутов, аналогичных определённым в Классе базовой службы управления рабочим списком, раздел K.2 «Определение информационной модели рабочего списка».

JJ.2.1 Модель E-R

Информационная модель Q/R инвентаризации представляет собой одноуровневую сущность:

  • Информационная сущность Inventory

Inventory Q/R Information Model E-R Diagram

Figure JJ.2-1. Inventory Q/R Information Model E-R Diagram


Хотя композитные SOP-экземпляры Inventory, являющиеся предметом данного сервисного класса, содержат атрибуты, связанные с несколькими информационными сущностями (см. раздел 7.13.6 «Inventory» в PS3.3), информационная модель Q/R инвентаризации оперирует только атрибутами информационной сущности Inventory IOD Inventory.

JJ.2.2 Атрибуты информационной модели Q/R инвентаризации

Таблица JJ.2-1 определяет атрибуты информационной модели Q/R инвентаризации.

Table JJ.2-1. Attributes for the Inventory Q/R Information Model

Name

Tag

Тип ключа сопоставления

Тип возвращаемого ключа

Remark

SOP Class UID

(0008,0016)

R

1

SOP Instance UID

(0008,0018)

U

1

Transaction UID

(0008,1195)

R

1C

Обязателен, если SOP-экземпляр Inventory был создан транзакцией SOP-класса Inventory Creation, в противном случае может присутствовать.

Content Date

(0008,0023)

R

1

Content Time

(0008,0033)

O

1

Scope of Inventory Sequence

(0008,0400)

O

2

Может быть запрошен только при универсальном сопоставлении (Universal Matching).

Inventory Purpose

(0008,0401)

O

1

Inventory Instance Description

(0008,0402)

O

2

Inventory Level

(0008,0403)

O

1

Inventory Completion Status

(0008,0426)

O

1

Total Number of Study Records

(0008,0428)

O

1


Примечание

  1. См. также дополнительные возвращаемые атрибуты в идентификаторе ответа, указанные в разделе JJ.4.2.2.1.

  2. Более подробное определение этих атрибутов приведено в разделе C.38.1 «Inventory Module» в PS3.3

JJ.3 Группы служб DIMSE-C

JJ.3.1 Операция C-FIND

См. определение операции C-FIND для Класса базовой службы управления рабочим списком (раздел K.4.1), заменив «Worklist» на «Inventory». Должен использоваться метод поиска «Worklist».

C-FIND выполняется относительно информационной модели Q/R инвентаризации (раздел JJ.2). Ключевые атрибуты и допустимые для запроса значения определены в информационной модели Q/R инвентаризации.

JJ.3.2 Операция C-MOVE

См. определение операции C-MOVE для сервисного класса запроса/извлечения (раздел C.4.2). Для службы запроса/извлечения инвентаризации не определены ни расширенное поведение (Extended Behavior), ни реляционное извлечение (Relational-Retrieve).

Уровень запроса/извлечения (Query/Retrieve Level) (0008,0052) не имеет значения для службы запроса/извлечения инвентаризации и поэтому не должен присутствовать в идентификаторе. Уникальным ключевым атрибутом идентификатора является SOP Instance UID (0008,0018). SCU должен указать один UID или список UID.

Примечание

С помощью сопоставления по списку UID (List of UID Matching) может быть извлечено более одного SOP-экземпляра Inventory.

JJ.3.3 Операция C-GET

См. определение операции C-GET для сервисного класса запроса/извлечения (раздел C.4.3). Для службы запроса/извлечения инвентаризации не определены ни расширенное поведение (Extended Behavior), ни реляционное извлечение (Relational-Retrieve).

Уровень запроса/извлечения (Query/Retrieve Level) (0008,0052) не имеет значения для службы запроса/извлечения инвентаризации и поэтому не должен присутствовать в идентификаторе. Уникальным ключевым атрибутом идентификатора является SOP Instance UID (0008,0018). SCU должен указать один UID или список UID.

Примечание

С помощью сопоставления по списку UID (List of UID Matching) может быть извлечено более одного SOP-экземпляра Inventory.

JJ.4 Определения SOP-классов

JJ.4.1 SOP-классы

SOP-классы службы запроса/извлечения инвентаризации идентифицируют информационную модель Q/R инвентаризации и поддерживаемые операции DIMSE-C. Определены стандартные SOP-классы, приведённые в таблице JJ.4-1.

Table JJ.4-1. Inventory Q/R Service SOP Classes

SOP Class Name

SOP Class UID

Inventory FIND

1.2.840.10008.5.1.4.1.1.201.2

Inventory MOVE

1.2.840.10008.5.1.4.1.1.201.3

Inventory GET

1.2.840.10008.5.1.4.1.1.201.4


JJ.4.2 Требования к соответствию

Реализация может соответствовать одному из SOP-классов службы запроса/извлечения инвентаризации в роли SCU, SCP или обеих ролях. Заявление о соответствии должно иметь формат, определённый в PS3.2.

JJ.4.2.1 Соответствие SCU

JJ.4.2.1.1 Соответствие SCU C-FIND

Реализация, соответствующая SOP-классу Inventory FIND в роли SCU, должна поддерживать запросы к информационной модели Q/R инвентаризации, используя поведение SCU C-FIND, описанное для Класса базовой службы управления рабочим списком (см. раздел K.4.1.2 и раздел JJ.3.1).

JJ.4.2.1.2 Соответствие SCU C-MOVE

Реализация, соответствующая SOP-классу Inventory MOVE в роли SCU, должна поддерживать передачи по информационной модели Q/R инвентаризации, используя базовое поведение SCU C-MOVE, описанное для сервисного класса запроса/извлечения (см. раздел C.4.2.2.1 и раздел JJ.3.2).

JJ.4.2.1.3 Соответствие SCU C-GET

Реализация, соответствующая SOP-классу Inventory GET в роли SCU, должна поддерживать передачи по информационной модели Q/R инвентаризации, используя базовое поведение SCU C-GET, описанное для сервисного класса запроса/извлечения (см. раздел C.4.3.2.1 и раздел JJ.3.3).

JJ.4.2.2 Соответствие SCP

JJ.4.2.2.1 Соответствие SCP C-FIND

Реализация, соответствующая SOP-классу Inventory FIND в роли SCP, должна поддерживать запросы к информационной модели Q/R инвентаризации, используя поведение SCP C-FIND, описанное для Класса базовой службы управления рабочим списком (см. раздел K.4.1.3 и раздел JJ.3.1).

Реализация должна поддерживать дополнительные атрибуты в идентификаторе ответа, указанные в таблице JJ.4-2, для обеспечения указания набора символов и доступа к SOP-экземплярам Inventory.

Примечание

Сравните с разделом C.4.1.1.3.2, где аналогичным образом определены неключевые атрибуты, возвращаемые в SOP-классах C-FIND сервисного класса запроса/извлечения для обеспечения указания набора символов и доступа к соответствующим SOP-экземплярам.

Table JJ.4-2. Inventory FIND Additional Returned Attributes

Attribute

Tag

Type

Remark

Specific Character Set

(0008,0005)

1C

Обязателен, если в каких-либо атрибутах ответа на запрос используются расширенные или заменяющие наборы символов.

Retrieve AE Title

(0008,0054)

1C

Обязателен, если SOP-экземпляр Inventory доступен через SOP-классы Inventory MOVE или Inventory GET.

Retrieve URL

(0008,1190)

1C

Обязателен, если SOP-экземпляр Inventory доступен через службу Non-Patient Instance (см. раздел 12 «Non-Patient Instance Service and Resources» в PS3.18).

File Access Sequence

(0008,041A)

1C

Обязателен, если SOP-экземпляр Inventory находится в формате файла DICOM и доступен через протокол, отличный от DICOM (см. приложение P «Stored File Access Through Non-DICOM Protocols (Normative)» в PS3.3).

>Stored Instance Base URI

(0008,0407)

1C

Обязателен, если File Access URI (0008,0409) является относительной ссылкой на путь.

>File Access URI

(0008,0409)

1

>Container File Type

(0008,040A)

1

>Filename in Container

(0008,040B)

1C

Обязателен, если Container File Type (0008,040A) — ZIP, TAR или TARGZIP.

>Stored Instance Transfer Syntax UID

(0008,040E)

1

>MAC Algorithm

(0400,0015)

3

>MAC

(0400,0404)

3


Примечание

Более подробное определение этих атрибутов, включая определённые термины и перечислимые значения, приведено в разделе C.38.3 «Inventory Creation Module» в PS3.3. В этом разделе атрибуты применяются к сохранённым, относящимся к пациенту композитным SOP-экземплярам, таким как изображения, тогда как здесь они применяются к SOP-экземплярам Inventory.

JJ.4.2.2.2 Соответствие SCP C-MOVE

Реализация, соответствующая классу Inventory MOVE в роли SCP, должна поддерживать передачи по информационной модели Q/R инвентаризации, используя базовое поведение SCP C-MOVE, описанное для сервисного класса запроса/извлечения (см. раздел C.4.2.3.1). Реализация должна поддерживать SOP-класс Inventory Storage (см. приложение GG) для субопераций C-STORE, порождаемых операцией C-MOVE.

JJ.4.2.2.3 Соответствие SCP C-GET

Реализация, соответствующая SOP-классу Inventory GET в роли SCP, должна поддерживать передачи по информационной модели Q/R инвентаризации, используя базовое поведение SCP C-GET, описанное для сервисного класса запроса/извлечения (см. раздел C.4.3.3.1). Реализация должна поддерживать SOP-класс Inventory Storage (см. приложение GG) для субопераций C-STORE, порождаемых операцией C-GET.

KK Класс службы управления хранилищем

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

KK.1 Обзор

KK.1.1 Сценарии использования

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

KK.1.2 SOP-классы

Каждый SOP-класс класса службы управления хранилищем образуется сочетанием общей группы служб DIMSE и конкретной информационной объектной дефиниции.

KK.1.2.1 Группа служб DIMSE

Службы DIMSE-N, применимые ко всем SOP-классам класса службы управления хранилищем, показаны в Таблице KK.1-1.

Table KK.1-1. DIMSE Service Group Applicable to Storage Management

Элемент службы сообщений DICOM

Использование (SCU/SCP)

N-ACTION

M/M

N-EVENT-REPORT

M/M


Службы и протокол DIMSE-N определены в Разделе 10 “DIMSE-N” в PS3.7. Дополнительные ограничения на эти службы, такие как конкретные типы действий и событий, определены для каждого SOP-класса.

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

SOP-классы класса службы управления хранилищем определены с использованием IOD, указанных в Таблице KK.1-2.

Table KK.1-2. Storage Management Service SOP Classes

SOP Class Name

SOP Class UID

Спецификация IOD (определена в PS3.3)

Inventory Creation

1.2.840.10008.5.1.4.1.1.201.5

Inventory Creation IOD


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

KK.1.3 Протокол службы

KK.1.3.1 Согласование ассоциации

Установление ассоциации — это первая фаза любого случая взаимодействия между одноранговыми DICOM AE. Правила согласования ассоциации, определённые в Приложении D “Согласование ассоциации (нормативное)” в PS3.7, используются для согласования поддерживаемых SOP-классов и ролей одноранговых AE.

Примечание

Реализации могут ограничивать установление ассоциации условием обмена информацией, связанной с безопасностью, такой как идентификация и авторизация приложения, либо в рамках согласования ассоциации DICOM, либо вне области действия протокола DICOM. См. Раздел YYYY.6 “Соображения безопасности” в PS3.17.

Поддержка согласования выбора ролей SCP/SCU обязательна. Расширенное согласование SOP-класса для данного класса службы не определено.

SCU открывает ассоциацию, когда желает запросить у SCP выполнение операции управления хранилищем.

SCP обычно открывает ассоциацию, когда сообщает о состоянии, либо завершил запрошенную операцию, либо достиг иного условия завершения, например сбоя. Установление такой ассоциации включает согласование роли SCP/SCU.

Примечание

  1. SCP может попытаться выдать N-EVENT-REPORT в той же ассоциации, что и инициирующий N-ACTION, но эта операция может завершиться неудачей, поскольку SCU вправе в любой момент освободить ассоциацию, по которой был отправлен запрос N-ACTION.

  2. Поскольку DICOM по умолчанию отводит инициатору ассоциации роль SCU, SCP (то есть инициатор ассоциации) согласовывает роль SCP посредством согласования выбора ролей SCP/SCU (см. Раздел D.3.3.4 “Согласование выбора ролей SCP/SCU” в PS3.7).

  3. При ответе по другой ассоциации SCP использует то же имя AE (AE Title), что и в исходной ассоциации, поскольку стандарт DICOM определяет службу между двумя одноранговыми приложениями, каждое из которых идентифицируется именем AE. Таким образом, SCP должен последовательно идентифицироваться во всех транзакциях с конкретным одноранговым узлом в рамках SOP-класса.

KK.1.3.2 Операции и уведомления

После установления ассоциации одноранговое взаимодействие между SCU и SCP использует DIMSE N-ACTION и N-EVENT-REPORT (см. Раздел 10.1 “Службы” в PS3.7).

Примитивы N-ACTION и N-EVENT-REPORT должны содержать общеизвестный экземпляр SOP управления хранилищем, указанный в Таблице KK.1-3, в своих параметрах Requested SOP Instance UID и Affected SOP Instance UID.

Примечание

В описанном здесь варианте использования явное создание экземпляра SOP (с помощью N-CREATE), над которым мог бы выполняться N-ACTION, отсутствует. Вместо этого N-ACTION оперирует общеизвестным экземпляром SOP. Этот экземпляр SOP концептуально создаётся при запуске каждого SCP-приложения класса службы управления хранилищем.

Table KK.1-3. Storage Management SOP Instance UID

SOP Instance UID

UID Name

1.2.840.10008.5.1.4.1.1.201.1.1

Storage Management SOP Instance


SCU запрашивает операцию управления хранилищем с помощью примитива запроса N-ACTION одного из SOP-классов службы управления хранилищем. Запрос включает Transaction UID для целей отслеживания.

Если SCP принимает запрос N-ACTION к обработке, он отправляет статус ответа N-ACTION Success. Если не принимает — отправляет статус ответа N-ACTION Failure. Действия, предпринимаемые SCU при получении статуса, выходят за рамки настоящего стандарта.

В любой момент после получения ответа N-ACTION SCU может освободить ассоциацию, по которой был отправлен запрос N-ACTION.

SCP уведомляет SCU с помощью примитива N-EVENT-REPORT о завершении запрошенной операции либо о достижении иного условия завершения, например сбоя или тайм-аута. Уведомление включает Transaction UID запроса. После завершения или прекращения Transaction UID более не активен и не должен использоваться повторно.

KK.2 SOP-класс создания инвентаризации

KK.2.1 Обзор

SOP-класс создания инвентаризации позволяет прикладной сущности SCU запрашивать у одноранговой прикладной сущности SCP формирование инвентаризации исследований (Studies), серий (Series) и экземпляров (Instances), которыми она управляет. Запрос на инвентаризацию может включать набор ключей сопоставления, ограничивающих область инвентаризации исследованиями с соответствующими значениями атрибутов. Сформированная инвентаризация кодируется в одном или нескольких экземплярах SOP класса SOP инвентаризации (см. Приложение GG). Об успехе или неудаче формирования инвентаризации SCP сообщает SCU посредством уведомления. После этого SCU может обращаться к экземплярам SOP инвентаризации с помощью механизма, поддерживаемого SCP, включая Query/Retrieve (см. Приложение JJ), службы объектов без привязки к пациенту (Non-Patient Instance Services, см. Раздел C.6.2.1 в PS3.4) либо протокол доступа к файлам, отличный от DICOM. Дополнительные пояснения см. в Приложении YYYY “Inventories (информативное)” в PS3.17.

KK.2.1.1 Состояния производства инвентаризации

SOP-класс определяет пять состояний формирования инвентаризации со связанными переходами между состояниями (см. Рисунок KK.2-1). Некоторые переходы связаны с получением и обработкой запросов N-ACTION (обозначены стрелками с подписями на рисунке).

Inventory Production States and State Transitions

Figure KK.2-1. Inventory Production States and State Transitions


После запроса Initiate формирование переходит в состояние PROCESSING. Формирование продолжается и без дальнейших операций N-ACTION достигает одного из двух конечных состояний — COMPLETE или FAILURE.

Формирование может быть приостановлено (PAUSED) либо по запросу N-ACTION, либо из-за внутренних условий SCP, например временной нехватки ресурсов. Формирование может быть возвращено в состояние PROCESSING запросом Resume либо внутренними действиями SCP.

Из состояния PROCESSING или PAUSED формирование может быть переведено в конечное состояние CANCELED запросом Cancel либо внутренними действиями SCP.

KK.2.2 Операции

KK.2.2.1 Информация о действии

DICOM AE, заявляющие о соответствии данному SOP-классу в роли SCU и/или SCP, должны поддерживать типы действий и информацию о действии, указанные в Таблице KK.2-1. Описания атрибутов информации о действии приведены в Разделе B.30 “Inventory Creation IOD” в PS3.3.

Table KK.2-1. Inventory Creation Requests - Action Information

Имя типа действия

Идентификатор типа действия

Имя атрибута

Tag

Использование (SCU/SCP)

Initiate

11

Transaction UID

(0008,1195)

1/1

Scope of Inventory Sequence

(0008,0400)

2/2

>Extended Matching Mechanisms

(0008,040F)

1C/1C

>Specific Character Set

(0008,0005)

1C/1C

>Timezone Offset from UTC

(0008,0201)

1C/1C

>Range Matching Sequence

(0008,0410)

1C/1C

>>Any DA, DT, or TM Attribute

2/2

>List of UID Matching Sequence

(0008,0411)

1C/1C

>>Any UI Attribute

1/1

>Empty Value Matching Sequence

(0008,0412)

1C/1C

>>Any Attribute

2/2

>General Matching Sequence

(0008,0413)

1C/1C

>>Any Attribute

1/1

Inventory Purpose

(0008,0401)

3/1

Inventory Level

(0008,0403)

1/1

Requested Status Interval

(0008,0414)

3/1

Request Status

12

Transaction UID

(0008,1195)

1/1

Requested Status Interval

(0008,0414)

3/1

Cancel

13

Transaction UID

(0008,1195)

1/1

Retain Instances

(0008,0415)

1/1

Pause

14

Transaction UID

(0008,1195)

1/1

Resume

15

Transaction UID

(0008,1195)

1/1


KK.2.2.1.1 Область последовательности инвентаризации

Scope of Inventory Sequence (0008,0400) определяет ограничения на исследования, подлежащие включению в инвентаризацию. Описания атрибутов Scope of Inventory Sequence (0008,0400) см. в Разделе C.38.2.1 “Scope of Inventory Macro” в PS3.3.

Эти атрибуты аналогичны ключевым атрибутам, используемым для сопоставления атрибутов в классе службы Query/Retrieve (см. Раздел C.2.2.2). Значения атрибутов, предоставленные в N-ACTION, должны сопоставляться со значениями атрибутов исследований, которыми управляет SCP, в соответствии с требованиями данного раздела, при этом совпавшие исследования включаются в сформированную инвентаризацию. Исследования, совпавшие по всем указанным ключам, должны быть включены в сформированную инвентаризацию.

Scope of Inventory Sequence (0008,0400) может иметь нулевую длину, что означает универсальное совпадение со всеми исследованиями в хранилище (то есть исчерпывающую инвентаризацию).

KK.2.2.1.2 Уровень инвентаризации

Inventory Level (0008,0403) определяет типы записей, запрошенных для включения в сформированные экземпляры SOP инвентаризации. Инвентаризация может быть запрошена с записями уровня Study, с записями уровней Study и Series, либо с записями уровней Study, Series и Instance.

KK.2.2.2 Поведение пользователя класса службы

SCU должен использовать примитив N-ACTION, содержащий общеизвестный Storage Management SOP Instance UID (определённый в Разделе KK.1.3.2), в своём параметре Requested SOP Instance UID.

SCU должен предоставлять Transaction UID (0008,1195) для однозначной идентификации каждого запроса управления хранилищем. Значение Transaction UID (0008,1195) будет включаться SCP в примитивы N-EVENT-REPORT (см. Раздел KK.2.3.1). Использование атрибута Transaction UID (0008,1195) позволяет SCU сопоставлять запросы и результаты, которые могут возникать в одной и той же или разных ассоциациях.

SCU должен использовать примитив N-ACTION с типом действия "Initiate" (Идентификатор типа действия = 11), чтобы запросить у SCP формирование инвентаризации экземпляров, которыми управляет SCP. SCU должен предоставить Inventory Level (0008,0403), указывающий, должна ли сформированная инвентаризация включать записи для серий и экземпляров. SCU должен предоставить Scope of Inventory Sequence (0008,0400) для указания ключевых атрибутов исследований, подлежащих включению в инвентаризацию. SCU должен указать в Extended Matching Mechanisms (0008,040F) любые запрашиваемые механизмы или семантику сопоставления сверх базового уровня, определённого для Query в Разделе C.2.2.2. SCU может запросить у SCP регулярную отчётность о ходе формирования инвентаризации, связанной с Transaction UID (0008,1195), с интервалом, заданным Requested Status Interval (0008,0414).

SCU должен использовать примитив N-ACTION с типом действия "Request Status" (Идентификатор типа действия = 12), чтобы запросить у SCP отчёт о ходе формирования инвентаризации, связанной с Transaction UID (0008,1195). SCU может запросить у SCP изменение интервала отчётов о ходе выполнения, заданного Requested Status Interval (0008,0414).

Примечание

О состоянии формирования инвентаризации, включая сбой, SCP сообщает посредством примитива N-EVENT-REPORT.

SCU должен использовать примитив N-ACTION с типом действия "Cancel" (Идентификатор типа действия = 13), чтобы запросить у SCP прекращение формирования инвентаризации, связанной с Transaction UID (0008,1195).

SCU должен использовать примитив N-ACTION с типом действия "Pause" (Идентификатор типа действия = 14), чтобы запросить у SCP приостановку формирования инвентаризации, связанной с Transaction UID (0008,1195). Он должен использовать примитив N-ACTION с типом действия "Resume" (Идентификатор типа действия = 15), чтобы запросить у SCP возобновление формирования инвентаризации из состояния PAUSED.

KK.2.2.3 Поведение поставщика класса службы

По получении запроса N-ACTION SCP должен вернуть посредством примитива ответа N-ACTION код статуса ответа N-ACTION, применимый к соответствующему запросу (см. Таблицу KK.2.2.3-1). Статус Success означает, что SCP успешно получил запрос. Статус Warning означает, что SCP успешно получил запрос, но может не обработать некоторые из запрошенных параметров. Статус Failure означает, что SCP не обрабатывает запрос.

Для типа действия "Initiate" (Идентификатор типа действия = 11) SCP должен вернуть код статуса сбоя 0212H "Ошибочно указанный аргумент" (Mistyped argument), если SCP не поддерживает все наборы символов, указанные в Specific Character Set (0008,0005), или все механизмы сопоставления, указанные в Extended Matching Mechanisms (0008,040F), или указанный Inventory Level (0008,0403); дополнительное пояснение может быть возвращено в Error Comment (0000,0902). SCP должен вернуть код статуса предупреждения B010H "Предупреждение о списке атрибутов — один или несколько ключевых атрибутов не поддерживаются для сопоставления" (Attribute List warning), если один или несколько ключевых атрибутов, указанных в Scope of Inventory Sequence (0008,0400), не поддерживаются для сопоставления, и должен вернуть список неподдерживаемых атрибутов в Attribute Identifier List (0000,1005).

Table KK.2.2.3-1. N-ACTION Response Status Values

Статус службы

Дополнительное значение

Коды состояния

Связанные поля

Успех

Success (Успех)

0000

Предупреждение

Attribute List warning (предупреждение о списке атрибутов) — один или несколько ключевых атрибутов не поддерживаются для сопоставления

B010

(0000,1005)

Отказ

Сбой обработки

0110

(0000,0902)

Отказано: не авторизовано

0124

(0000,0902)

Ошибочно указанный аргумент — один из предоставленных параметров не согласован для использования

0212

(0000,0902)

Ограничение ресурсов

0213

(0000,0902)

Прочие статусы Failure, определённые в Разделе 10.1.4.1.10 “Status” в PS3.7


Примечание

Определения связанных полей (Related Fields) см. в Разделе E.1 “Реестр элементов команд DICOM” в PS3.7.

Если SCP передаёт статус Success или Warning для типа действия "Initiate" (Идентификатор типа действия = 11), он должен инициировать формирование инвентаризации и периодическую отчётность о состоянии в соответствии с параметрами Scope of Inventory Sequence (0008,0400) и Inventory Level (0008,0403), предоставленными в запросе N-ACTION. Экземпляр(ы) SOP инвентаризации, сформированные для удовлетворения запроса N-ACTION, должны включать Transaction UID (0008,1195). Область инвентаризации (Scope of Inventory) в сформированных экземплярах SOP инвентаризации должна включать только те ключевые атрибуты, которые поддерживались для сопоставления. Любое значение, предоставленное SCU для Inventory Purpose (0008,0401), должно быть включено в сформированные экземпляры SOP инвентаризации.

Сформированные экземпляры SOP инвентаризации могут включать существующие экземпляры SOP инвентаризации по ссылке в Incorporated Inventory Instance Sequence (0008,0422). Существующие экземпляры SOP инвентаризации, способствующие удовлетворению запроса N-ACTION, могут быть включены по ссылке, но, поскольку они не были сформированы в ответ на данный запрос, они не будут содержать его Transaction UID (0008,1195) и могут иметь иную область инвентаризации (Scope of Inventory) или Inventory Purpose (0008,0401).

Примечание

  1. См. Раздел YYYY.3.3 “Inventory Instance Tree” в PS3.17.

  2. Существующий экземпляр SOP инвентаризации, включённый по ссылке, может не иметь Transaction UID (0008,1195), если его создание не было инициировано транзакцией SOP-класса создания инвентаризации.

  3. Может быть сформирован экземпляр SOP инвентаризации, являющийся исключительно «оболочкой» для существующего экземпляра SOP инвентаризации, включённого по ссылке. Такой сформированный экземпляр SOP инвентаризации устанавливает Content Date (0008,0023), Content Time (0008,0033) и Inventory Purpose (0008,0401) для инвентаризации и связывает её с Transaction UID (0008,1195).

SCP должен сформировать не менее одного экземпляра SOP инвентаризации (в корне дерева ссылающихся экземпляров SOP) по достижении состояния COMPLETE.

Если при формировании инвентаризации SCP сталкивается со сбоем, он может попытаться завершить кодирование уже полученных записей исследований в экземпляр SOP инвентаризации и установить в этом экземпляре SOP Inventory Completion Status (0008,0426) в значение "FAILURE".

Если SCP передаёт статус Success для типа действия "Request Status" (Идентификатор типа действия = 12), он должен инициировать отправку N-EVENT-REPORT с типом события "Inventory Status" (Event Type ID = 12).

Примечание

N-EVENT-REPORT может быть отправлен в той же или другой ассоциации, что и запрос N-ACTION (см. Раздел KK.1.3.1).

Если SCP передаёт статус Success для типа действия "Cancel" (Идентификатор типа действия = 13), он должен прекратить формирование инвентаризации, связанной с Transaction UID (0008,1195). Если запрос Cancel включает Retain Instances (0008,0415) со значением "N", SCP может удалить любые экземпляры SOP инвентаризации, связанные с Transaction UID (0008,1195). Если запрос Cancel включает Retain Instances (0008,0415) со значением "Y", SCP должен завершить кодирование уже полученных записей исследований в экземпляр SOP инвентаризации и установить Inventory Completion Status (0008,0426) в значение "CANCELED". Некоторые записи исследований на момент запроса Cancel могут быть завершены лишь частично, например не все дочерние записи серий и экземпляров были составлены. Завершаются ли такие частичные записи исследований и включаются ли в экземпляр SOP инвентаризации — определяется реализацией. Частичные записи исследований не должны включаться в инвентаризацию.

Если SCP передаёт статус Success для типа действия "Pause" (Идентификатор типа действия = 14), он должен приостановить формирование инвентаризации, связанной с Transaction UID (0008,1195). SCP может завершить обработку, необходимую для достижения устойчивого состояния при приостановке формирования инвентаризации, чтобы обеспечить эффективное возобновление.

Если SCP передаёт статус Success для типа действия "Resume" (Идентификатор типа действия = 15), он должен возобновить формирование инвентаризации, связанной с Transaction UID (0008,1195).

Примечание

SCP может вернуть код статуса сбоя 0124H "Отказано: не авторизовано" (Refused: Not authorized) или 0213H "Ограничение ресурсов" (Resource limitation), если условия, вызвавшие приостановку, не были устранены и формирование не возобновлено.

KK.2.3 Уведомления

KK.2.3.1 Информация о событии

DICOM AE, заявляющие о соответствии данному SOP-классу в роли SCU и/или SCP, должны поддерживать типы событий и информацию о событии, указанные в Таблице KK.2-2. Описания атрибутов информации о событии приведены в Разделе B.30 “Inventory Creation IOD” в PS3.3.

Table KK.2-2. Inventory Creation Responses - Event Information

Имя типа события

Идентификатор типа события

Имя атрибута

Tag

Использование (SCP)

Inventory Terminated with Instances

11

Transaction UID

(0008,1195)

1

Transaction Status

(0008,0417)

1

Transaction Status Comment

(0008,0418)

3

Referenced SOP Class UID

(0008,1150)

1

Referenced SOP Instance UID

(0008,1155)

1

Retrieve AE Title

(0008,0054)

1C

See KK.2.3.1.1

Retrieve URL

(0008,1190)

1C

See KK.2.3.1.1

File Access URI

(0008,0409)

3

Stored Instance Base URI

(0008,0407)

1C

See KK.2.3.1.1

Container File Type

(0008,040A)

1C

See KK.2.3.1.1

Filename in Container

(0008,040B)

1C

See KK.2.3.1.1

File Offset in Container

(0008,040C)

1C

See KK.2.3.1.1

File Length in Container

(0008,040D)

1C

See KK.2.3.1.1

Stored Instance Transfer Syntax UID

(0008,040E)

1C

See KK.2.3.1.1

MAC Algorithm

(0400,0015)

3

MAC

(0400,0404)

3

Expiration DateTime

(0008,0416)

3

Total Number of Study Records

(0008,0428)

1

Inventory Status

12

Transaction UID

(0008,1195)

1

Transaction Status

(0008,0417)

1

Transaction Status Comment

(0008,0418)

3

Total Number of Study Records

(0008,0428)

1

Inventory Terminated without Instances

13

Transaction UID

(0008,1195)

1

Transaction Status

(0008,0417)

1

Transaction Status Comment

(0008,0418)

3


KK.2.3.1.1 Инвентаризация завершена с экземплярами

В информации о событии Inventory Terminated with Instances должен присутствовать Retrieve AE Title (0008,0054) или Retrieve URL (0008,1190), либо оба атрибута.

File Access URI (0008,0409) предоставляет метод доступа по протоколу, отличному от DICOM (см. Приложение P “Stored File Access Through Non-DICOM Protocols (нормативное)” в PS3.3), к сформированному экземпляру SOP инвентаризации, закодированному в соответствии с форматом файла DICOM (см. Раздел 7 “Формат файла DICOM” в PS3.10). Stored Instance Base URI (0008,0407) должен присутствовать, если File Access URI (0008,0409) является URI относительной ссылки на путь. Stored Instance Transfer Syntax UID (0008,040E) и Container File Type (0008,040A) должны присутствовать, если присутствует File Access URI (0008,0409). Filename in Container (0008,040B) должен присутствовать, если Container File Type (0008,040A) равен ZIP, TAR или TARGZIP. File Offset in Container (0008,040C) и File Length in Container (0008,040D) должны присутствовать, если Container File Type (0008,040A) равен BLOB.

KK.2.3.2 Поведение поставщика класса службы

SCP должен использовать примитив N-EVENT-REPORT, содержащий общеизвестный Storage Management SOP Instance UID (определённый в Разделе KK.1.3.2), в своём параметре Affected SOP Instance UID. SCP должен предоставить Transaction UID (0008,1195), соответствующий запросу N-ACTION Initiate создания инвентаризации.

В любой момент в ходе формирования инвентаризации SCP может отправить примитив N-EVENT-REPORT с типом события "Inventory Status" (Event Type ID = 12) с указанием состояния процесса в атрибуте Transaction Status (0008,0417). SCP должен отправить N-EVENT-REPORT "Inventory Status", если состояние формирования инвентаризации изменилось. SCP должен отправить N-EVENT-REPORT "Inventory Status" в ответ на N-ACTION "Request Status".

Когда формирование инвентаризации достигает конечного состояния (COMPLETE, FAILURE или CANCELED) и экземпляры SOP инвентаризации доступны, SCP должен отправить примитив N-EVENT-REPORT с типом события "Inventory Terminated with Instances" (Event Type ID = 11). Информация о событии должна включать атрибуты, указывающие хотя бы один способ доступа к корневому экземпляру SOP инвентаризации, то есть должна включать хотя бы один из атрибутов Retrieve AE Title (0008,0054) или Retrieve URL (0008,1190), и может дополнительно включать File Access URI (0008,0409). Условно обязательные атрибуты см. в Разделе KK.2.3.1.1. Информация о событии может также включать атрибут Expiration DateTime (0008,0416), указывающий ожидаемую дату/время, до которой экземпляр SOP инвентаризации доступен для доступа со стороны SCU.

Если формирование инвентаризации достигает конечного состояния и экземпляры SOP инвентаризации недоступны (то есть FAILURE или CANCELED), SCP должен отправить примитив N-EVENT-REPORT с типом события "Inventory Terminated without Instances" (Event Type ID = 13).

KK.2.3.3 Поведение пользователя класса службы

По получении уведомления N-EVENT-REPORT SCU должен вернуть посредством примитива ответа N-EVENT-REPORT код статуса ответа N-EVENT-REPORT, применимый к обработке им соответствующего уведомления. Статус Success означает, что SCU успешно получил уведомление. Статус Failure означает, что SCU не обрабатывает уведомление.

Примечание

Действие SCP при получении статуса Failure для N-EVENT-REPORT выходит за рамки настоящего стандарта.

KK.2.4 Соответствие

Реализация может заявлять соответствие данному SOP-классу в роли SCU, SCP или обеих. Заявление о соответствии должно быть в формате, определённом в PS3.2.

KK.2.4.1 Соответствие SCU

Реализация, соответствующая SOP-классу создания инвентаризации в роли SCU, должна удовлетворять требованиям соответствия в отношении:

  • операций и действий, которые она вызывает,

  • уведомлений, которые она получает.

KK.2.4.1.1 Операции

SCU должен задокументировать в заявлении о соответствии:

  • поведение и действия, которые вызывают генерацию SCU примитива N-ACTION (Initiate, Request Status, Cancel, Pause или Resume),

  • поведение и действия, предпринимаемые SCU при получении статуса N-ACTION Failure.

KK.2.4.1.2 Уведомления

SCU должен задокументировать в заявлении о соответствии:

  • поведение и действия, предпринимаемые SCU при получении примитива N-EVENT-REPORT (Inventory Terminated with Instances, Inventory Status или Inventory Terminated without Instances).

KK.2.4.2 Соответствие SCP

Реализация, соответствующая SOP-классу создания инвентаризации в роли SCP, должна удовлетворять требованиям соответствия в отношении:

  • операций и действий, которые она выполняет,

  • уведомлений, которые она генерирует.

KK.2.4.2.1 Операции

SCP должен задокументировать в заявлении о соответствии:

  • поведение и действия SCP при получении примитива N-ACTION (Initiate, Request Status, Cancel, Pause или Resume).

  • диапазон значений, поддерживаемых для Requested Status Interval (0008,0414), и значение по умолчанию для периодической отчётности о состоянии, если этот атрибут не предоставлен SCU

  • наборы символов, поддерживаемые в Specific Character Set (0008,0005) в составе Scope of Inventory Sequence (0008,0400)

  • поддержку Extended Matching Mechanisms (0008,040F) в составе Scope of Inventory Sequence (0008,0400)

  • значения, поддерживаемые для Inventory Level (0008,0403)

  • ключевые атрибуты, поддерживаемые для сопоставления в составе Scope of Inventory Sequence (0008,0400)

Примечание

Требования соответствия для SCP в отношении созданных экземпляров SOP инвентаризации подробно изложены в Разделе GG.6.6.1.

KK.2.4.2.2 Уведомления

SCP должен задокументировать в заявлении о соответствии:

  • поведение и действия, которые вызывают генерацию SCP примитива N-EVENT-REPORT (Inventory Terminated with Instances, Inventory Status или Inventory Terminated without Instances), и в частности условия, вызывающие переход в статус обработки PAUSED или FAILURE и генерацию соответствующего N-EVENT-REPORT.

  • поддерживаемые механизмы доступа к экземплярам SOP инвентаризации, на которые указывает уведомление Inventory Terminated with Instances, включая конкретные протоколы, отличные от DICOM (если таковые есть), на которые указывает File Access URI (0008,0409).