Содержание
Список рисунков
Список таблиц
Информация в данной публикации была признана технически обоснованной по 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, все права защищены.
Данная часть стандарта DICOM определяет набор определений классов служб, которые обеспечивают абстрактное определение реальных действий, применимых к передаче цифровой медицинской информации. Для каждого определения класса службы данная часть определяет:
семантическое описание действий из определения класса сервиса
группу операций и уведомлений сервиса DIMSE, применимых к описанию класса сервиса
один или более функционально связанных классов Service-Object Pair (SOP), которые поддерживаются определением класса сервиса и могут выполняться между равноправными прикладными сущностями DICOM
связь каждого класса Service-Object Pair (SOP) с применимыми Определениями информационных объектов, указанными в PS3.3.
Для каждого определения класса сервиса в данной Части не указывается:
Данная Часть связана с другими частями стандарта 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, определённым в данной Части.
Следующие стандарты содержат положения, которые посредством ссылки в данном тексте составляют положения настоящего Стандарта. На момент публикации были действительны указанные редакции. Все стандарты подлежат пересмотру, и сторонам соглашений, основанных на настоящем Стандарте, рекомендуется изучить возможности применения самых последних редакций указанных ниже стандартов.
[ISO/IEC Directives, Part 2] 2021. 9.0. Rules for the structure and drafting of International Standards. http://www.iso.org/sites/directives/current/part2/index.xhtml .
[ISO 7498-1] 1994. Information Processing Systems - Open Systems Interconnection - Basic Reference Model.
[RFC3986] Uniform Resource Identifiers (URI): Generic Syntax. http://tools.ietf.org/html/rfc3986 .
[ISO/TR 8509] 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] June 2014. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. http://tools.ietf.org/html/rfc7230 .
[Porter and Duff 1984] Computer Graphics. 1984. 3. 253-259. “Compositing Digital Images”. doi:10.1145/800031.808606 http://keithp.com/~keithp/porterduff/p253-porter.pdf .
[IHE RAD TF-1] Integrating the Healthcare Enterprise Radiology Technical Framework Volume 1 Integration Profiles. http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol1.pdf .
[IHE RAD TF-2] Integrating the Healthcare Enterprise Radiology Technical Framework Volume 2 Transactions. http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf .
Для целей настоящего Стандарта применяются следующие определения.
В данной Части Стандарта используются следующие термины, определённые в [ISO 7498-1]:
См. [ISO 7498-1].
См. [ISO 7498-1].
См. [ISO 7498-1].
В данной Части Стандарта используются следующие термины, определённые в [ISO/TR 8509]:
См. [ISO/TR 8509].
В данной Части Стандарта используются следующие термины, определённые в PS3.1:
В данной Части Стандарта используются следующие термины, определённые в PS3.8:
В данной Части Стандарта используются следующие термины, определённые в PS3.7:
В данной Части Стандарта используются следующие термины, определённые в PS3.3:
В данной Части Стандарта используются следующие термины, определённые в PS3.2:
В данной Части Стандарта используются следующие термины, определённые в PS3.5:
Следующие определения часто используются в данной Части стандарта DICOM:
Класс SOP хранения изображений, который определяется IOD, сохраняющим одиночный кадр и определяющим большинство Атрибутов в Data Set верхнего уровня.
Пиксельная матрица, созданная путём наложения изображения и оверлея, размер которой определяется наименьшим прямоугольником, охватывающим наложенные изображение и оверлей.
Класс SOP хранения изображений, который определяется IOD, сохраняющим множество кадров и определяющим большинство Атрибутов в Functional Group Sequences.
Специализированный для модальности класс SOP хранения изображений Enhanced, который определяется IOD, определяющим только типовые Functional Group Sequences, не требующим информации, отсутствующей в экземплярах класса Classic Image Storage SOP Class, и предназначенным для хранения преобразованных экземпляров класса Classic Image Storage SOP Class, когда недостаточно информации для использования класса True Enhanced Image Storage SOP Class.
Заранее определённый набор классов SOP, который может быть ассоциирован под единым SOP с целью согласования использования набора с помощью одного элемента.
Экземпляр SOP, который соответствует информационной модели Composite Instance IOD, указанной в PS3.3, но не имеет сущности Patient Information в качестве корня. Экземпляры SOP Non-Patient Object могут по-прежнему содержать связанную с пациентом идентифицируемую информацию, например, экземпляры SOP Inventory
Любой класс SOP, кодирующий сведения о выполнении этапа процедуры.
Экземпляр класса Performed Procedure Step SOP Class. Следует отметить, что все экземпляры UPS являются экземплярами класса UPS Push SOP Class, который способен кодировать сведения о выполнении этапа процедуры (в дополнение к сведениям о запланированном этапе процедуры) и, таким образом, квалифицируется как экземпляр класса Performed Procedure Step SOP Class.
Изображение, в котором все аннотации, графика и преобразования оттенков серого (включая VOI LUT), ожидаемые в печатаемом изображении, были вшиты или применены до отправки на SCP. Это отображаемое изображение, в котором полярность предполагаемого отображения задаётся атрибутом Photometric Interpretation (0028,0004).
Изображение, в котором все аннотации, графика и преобразования цвета, ожидаемые в печатаемом изображении, были вшиты или применены до отправки на SCP.
То, что существует в реальном мире и относится к конкретной области обработки информации в рамках области интересов стандарта DICOM. Такая Real-World Activity может быть представлена одной или несколькими компьютерными информационными метафорами, называемыми классами SOP.
То, что существует в реальном мире и над чем могут выполняться операции, относящиеся к области интересов стандарта DICOM. Такой Real-World Object может быть представлен через компьютерную информационную метафору, называемую экземпляром SOP.
Класс SOP, который связан с другим классом SOP как более обобщённый с точки зрения поведения, определённого в Стандарте, и который может использоваться для идентичного кодирования экземпляра с теми же Атрибутами и значениями, за исключением SOP Class UID. В частности, это может быть класс SOP, из которого выведен Specialized SOP Class (см. PS3.2).
Роль, которую играет прикладная сущность DICOM (DIMSE-Service-User), инициирующая операции и выполняющая уведомления в конкретной Ассоциации.
Роль, которую играет прикладная сущность DICOM (DIMSE-Service-User), выполняющая операции и инициирующая уведомления в конкретной Ассоциации.
Совокупность классов SOP и/или Meta SOP Classes, связанных тем, что они описываются совместно для выполнения единого приложения.
Конкретное воплощение информационного объекта, которым управляет прикладная сущность DICOM и над которым могут выполняться операции в контексте связи, определённом конкретным набором сервисов DIMSE (по сети или на носителях обмена). Экземпляр SOP сохраняется за пределами контекста своего обмена.
Специализированный для модальности класс SOP хранения изображений Enhanced, который определяется IOD, определяющим специализированные для модальности Functional Group Sequences, Атрибуты и наборы значений, и предназначен для создания устройствами съёма.
В данной Части Стандарта используются следующие термины, определённые в PS3.3:
В данной Части Стандарта используются следующие термины, определённые в [RFC7230]:
В данной Части Стандарта используются следующие термины, определённые в PS3.3:
В данной Части Стандарта используются следующие термины, определённые в PS3.16:
В данной Части Стандарта используются следующие условные обозначения и сокращения.
Comité Européen de Normalisation - Технический комитет 251 - Медицинская информатика
Компьютерное вспомогательное обнаружение и/или компьютерное вспомогательное диагностирование для рентгенографии органов грудной клетки
Японская ассоциация производителей медицинского визуализационного и радиологического оборудования
Сущность используется в модели «сущность-связь» (E-R) для представления объекта реального мира, класса объектов реального мира или представления данных DICOM (таких как IOD или Module). Сущность изображается в виде прямоугольника в данной Части стандарта DICOM, как показано на Рисунке 5-1.
Связь, определяющая отношение между сущностями, изображается в данном Стандарте в виде ромба, как показано на Рисунке 5-2.
Связь читается от исходной сущности к целевой, как указано стрелками. Буквы a и b обозначают соответственно исходную и целевую мощность связи. Допускаются следующие мощности:
(a = 1, b = 1) — одна исходная сущность связана с одной целевой сущностью
(a = 1, b = 0-n) — одна исходная сущность связана с нулём или более целевыми сущностями
(a = 1, b = 1-n) — одна исходная сущность связана с одной или более целевыми сущностями
(a = 1-n, b = 1) — одна или более исходных сущностей связаны с одной целевой сущностью
(a = 1-n, b = 0-n) — одна или более исходных сущностей связаны с нулём или более целевыми сущностями
(a = 1-n, b = 1-n) — одна или более исходных сущностей связаны с одной или более целевыми сущностями
В связи, где (a = 1-n, b = 1-n), значения исходной и целевой мощностей могут различаться. Значение "n" просто обозначает одну или более.
DICOM добавил использование стрелок к соглашениям по диаграммам E-R, часто применяемым в другой литературе. Это было сделано во избежание возможности вывода неверной связи, которая может возникнуть при чтении связи в обратном порядке по сравнению с предполагаемым. Например, связь «Кошка ловит мышь» может быть прочитана как «Мышь ловит кошку», если стрелки отсутствуют.
Связь может быть двунаправленной (т.е. связь истинна в обоих направлениях). В таком случае используется соглашение со стрелками, направленными как к исходной, так и к целевой сущности.
Некоторые таблицы в данной Части стандарта DICOM обозначают последовательность элементов (Sequence of Items) с использованием символа: '>'.
В Приложении A '>' используется для обозначения «последовательности модулей» (Sequence of Modules). Вложенные последовательности модулей обозначаются '>>'. В Приложении B и Приложении C '>' используется для обозначения «последовательности атрибутов» (Sequence of Attributes). См. PS3.5 для полной спецификации того, как должны кодироваться последовательности элементов.
Некоторые таблицы в данной Части стандарта DICOM обозначают зависящий от реализации код состояния ответа с использованием символа 'xx' или 'xxx' как части кода.
Базовыми блоками классов SOP являются модули и сервисы DIMSE. Сервисы DIMSE, связанные с классом SOP, могут быть обязательными (M) или необязательными (U). Использование может различаться для SCU и SCP. Использование задаётся парой букв: первая указывает использование для SCU, вторая — использование для SCP.
Значение и поведение спецификации использования для сервисов DIMSE:
SCU должен поддерживать сервис DIMSE, но не обязан использовать его в Ассоциации. SCP должен поддерживать сервис DIMSE.
SCU может поддерживать и использовать сервис DIMSE. SCP должен поддерживать сервис DIMSE.
SCU может поддерживать и использовать сервис DIMSE. SCP может поддерживать сервис DIMSE. Если SCP не поддерживает сервис DIMSE, используемый SCU, он должен вернуть статус Failure.
Модули и их использование в композитных IOD определены в PS3.3. Нормализованные IOD также строятся из модулей, но использование указывается на уровне атрибутов в данной Части стандарта DICOM. Следующая спецификация использования применяется ко всем атрибутам нормализованных IOD, если она не заменена спецификацией использования в конкретной спецификации класса SOP.
Термин «получать» означает следующее: значение должно быть сохранено; при определённых обстоятельствах (например, при принудительном преобразовании) возвращаемое значение могло измениться.
Следующие требования применяются при указании использования сервисов DIMSE N-CREATE, N-SET, N-ACTION.
Используемые в таблице ниже условные обозначения:
Требования к атрибутам SCU
Содержимое атрибутов SCU
Поведение SCP
SCP должен поддерживать получение атрибута с командой. При получении значений нулевой длины SCP должен назначить значения, как определено спецификацией класса сервиса.
SCP может как поддерживать, так и не поддерживать получение атрибута с командой.
SCP не должен поддерживать получение данного атрибута с командой.
Если SCU не передаёт атрибут, обязательный для SCU, SCP должен ответить кодом состояния Failure 0120H «Missing Attribute».
Если SCU передаёт значение нулевой длины для обязательного атрибута, когда нулевая длина не допускается, SCP должен ответить кодом состояния Failure 0121H «Missing Attribute Value».
Следующие требования применяются при указании использования сервисов DIMSE N-GET, N-EVENT-REPORT.
Используемые в таблице ниже условные обозначения:
Поведение SCU
«Не допускается» часто используется для атрибутов, являющихся частью атрибута-последовательности (Sequence Attribute). В этих случаях зачастую можно запросить содержимое всей последовательности целиком, но не отдельные атрибуты внутри последовательности.
Поведение SCP
Содержимое атрибутов SCP
Если поддержка атрибута со стороны SCP является необязательной и SCP не поддерживает атрибут, и атрибут запрашивается SCU, SCP должен ответить кодом состояния Failure 0106H «Invalid Attribute Value» или 0116H «Attribute Value out of range».
Если тип использования 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.
Информационная модель DICOM определяет структуру и организацию информации, относящейся к передаче медицинских изображений. На Рисунке 6-1 показаны связи между основными структурами информационной модели DICOM.
Определение информационного объекта (IOD) — это объектно-ориентированная абстрактная модель данных, используемая для спецификации информации об объектах реального мира. IOD предоставляет взаимодействующим прикладным сущностям общее представление обмениваемой информации.
IOD не представляет конкретный экземпляр объекта реального мира, а скорее класс объектов реального мира, обладающих одинаковыми свойствами. IOD, используемый для представления единственного класса объектов реального мира, называется нормализованным информационным объектом (Normalized Information Object). IOD, содержащий информацию о связанных объектах реального мира, называется композитным информационным объектом (Composite Information Object).
Композитный IOD — это определение информационного объекта, представляющее части нескольких сущностей в модели реального мира DICOM (см. PS3.3). Такой IOD включает атрибуты, которые не являются внутренне присущими объекту реального мира, представляемому IOD, а скорее внутренне присущи связанным объектам реального мира.
Эти связанные объекты реального мира обеспечивают полный контекст для обмениваемой информации. При передаче экземпляра композитного IOD весь этот контекст обменивается между прикладными сущностями. Связи между экземплярами композитных IOD должны передаваться в этой контекстной информации.
Композитные IOD определены в PS3.3.
Нормализованный IOD — это определение информационного объекта, которое обычно представляет единственную сущность в модели реального мира DICOM.
При передаче экземпляра нормализованного IOD контекст для этого экземпляра фактически не обменивается. Вместо этого контекст предоставляется через использование указателей на связанные экземпляры нормализованных IOD.
Нормализованные IOD определены в PS3.3.
Атрибуты IOD описывают свойства экземпляра объекта реального мира. Связанные атрибуты группируются в модули, которые представляют более высокий уровень семантики, задокументированный в спецификациях модулей, содержащихся в PS3.3.
Атрибуты кодируются как элементы данных (Data Elements) с использованием правил, концепций представления значения (Value Representation) и кратности значения (Value Multiplicity), указанных в PS3.5. Для конкретных элементов данных представление значения и кратность значения элементов данных указаны в словаре данных в PS3.6.
При сетевой передаче сервисы DIMSE и веб-сервисы позволяют прикладной сущности DICOM инициировать операцию или уведомление через сеть или интерфейс точка-точка. Сервисы DIMSE определены в PS3.7, а веб-сервисы определены в PS3.18.
При обмене данными через носители сервисы хранения на носителях (Media Storage Services) позволяют прикладной сущности DICOM инициировать операции, связанные с хранением на носителях.
Сервисы хранения на носителях рассматриваются в PS3.10.
Группа сервисов DIMSE (DIMSE Service Group) указывает одну или более операций/уведомлений, определённых в PS3.7, применимых к IOD.
Группы сервисов DIMSE определены в данной Части стандарта DICOM, в спецификации класса Service-Object Pair Class.
Определения классов SOP в PS3.4 содержат правила и семантику, которые могут ограничивать использование сервисов в группе сервисов DIMSE или атрибутов IOD. PS3.10 и PS3.18 содержат правила и семантику, которые могут ограничивать атрибуты IOD или использование сервисов в сервисах хранения на носителях и веб-сервисах соответственно.
Выбор классов SOP используется прикладными сущностями для установления согласованного набора возможностей для поддержки их взаимодействия с классами SOP на основе сервисов DIMSE. Это согласование выполняется во время установления Ассоциации, как описано в PS3.7. Расширенное согласование (Extended Negotiation) позволяет прикладным сущностям дополнительно договориться о конкретных параметрах в рамках класса SOP.
Класс SOP, как он определён в информационной модели DICOM, эквивалентен в терминологии ISO/OSI классу управляемого объекта (Managed Object Class). Читатели, знакомые с объектно-ориентированной терминологией, узнают в операциях (и уведомлениях) класса SOP методы класса объекта.
Спецификации классов SOP играют центральную роль в определении соответствия DICOM. Они позволяют прикладным сущностям DICOM выбрать чётко определённое подмножество прикладного уровня настоящего Стандарта, на соответствие которому они могут заявить претензии. См. PS3.2.
DICOM определяет два типа классов SOP — нормализованные и композитные. Для сервисов DIMSE нормализованные классы SOP определяются как объединение нормализованного IOD и набора сервисов DIMSE-N, тогда как композитные классы SOP определяются как объединение композитного IOD и набора сервисов DIMSE-C. Сервисы хранения на носителях поддерживают только композитные IOD, а веб-сервисы поддерживают как нормализованные, так и композитные классы SOP.
Установление Ассоциации — это первая фаза взаимодействия между равноправными DICOM-совместимыми прикладными сущностями. Прикладные сущности должны использовать установление Ассоциации для согласования того, какие классы SOP могут быть обменены и как эти данные будут кодироваться.
Согласование Ассоциации определено в PS3.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 определяются во время установления Ассоциации.
Представление DICOM о реальном мире, определяющее соответствующие объекты реального мира и их связи в рамках области стандарта DICOM, описано в разделе «Модель реального мира DICOM» в PS3.3.
В этом разделе также описывается информационная модель DICOM, определяющая различные IOD, заданные стандартом DICOM, и их связи.
Макросы в данном разделе определяют использование атрибутов, соответствующих кодированным записям (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, поддержкой ключей сопоставления и обязательным значением
Таблица 8-2a. Расширенный макрос кодированной записи с необязательной поддержкой ключа сопоставления и необязательным значением
|
Включает Таблица 8-2b «Базовый макрос кодированной записи с необязательной поддержкой ключа сопоставления и необязательным значением» |
|||
|
>Include |
|||
Таблица 8-2b. Базовый макрос кодированной записи с необязательной поддержкой ключа сопоставления и необязательным значением
Таблица 8-3a. Расширенный макрос кодированной записи SCU/SCP без поддержки SCU и без поддержки ключа сопоставления
|
Включает Таблица 8-3b «Базовый макрос кодированной записи SCU/SCP без поддержки SCU и без поддержки ключа сопоставления» |
||||
|
>Include |
||||
Таблица 8-3b. Базовый макрос кодированной записи SCU/SCP без поддержки SCU и без поддержки ключа сопоставления
Таблица 8-4a. Расширенный макрос кодированной записи с необязательной поддержкой ключа сопоставления и обязательным значением
|
Включает Таблица 8-4b «Базовый макрос кодированной записи с необязательной поддержкой ключа сопоставления и обязательным значением» |
|||
|
>Include |
|||
Таблица 8-4b. Базовый макрос кодированной записи с необязательной поддержкой ключа сопоставления и обязательным значением
Таблица 8-5a. Расширенный макрос кодированной записи SCU/SCP без поддержки SCU и с необязательным значением для SCP
|
Включает Таблица 8-5b «Базовый макрос кодированной записи SCU/SCP без поддержки SCU и с необязательным значением для SCP» |
||
|
>Include |
||
Таблица 8-5b. Базовый макрос кодированной записи SCU/SCP без поддержки SCU и с необязательным значением для SCP
DICOM AE, поддерживающий роль SCU SOP класса верификации, запрашивает верификацию связи с удалённым DICOM AE. Этот запрос выполняется с использованием примитива запроса C-ECHO. Удалённый DICOM AE, поддерживающий роль SCP SOP класса верификации, выдаёт примитив ответа C-ECHO. При получении подтверждения C-ECHO, SCU определяет, что верификация завершена. См. PS3.7 для спецификации примитивов C-ECHO.
Сервис C-ECHO DIMSE-C должен быть механизмом, используемым для проверки связи между равноправными DICOM AE. Сервис C-ECHO и параметры протокола должны быть обязательными, как определено в PS3.7.
SOP класс верификации состоит из сервиса C-ECHO DIMSE-C. Связанное определение информационного объекта не определяется. UID SOP класса должен быть "1.2.840.10008.1.1".
Специализированные SOP классы и/или мета-SOP классы не должны определяться для SOP класса верификации.
Установление ассоциации является первой фазой любого сеанса связи между равноправными DICOM AE. Следующие правила согласования применяются к DICOM AE, которые поддерживают SOP класс верификации:
Инициатор ассоциации (роль SCU верификации) в запросе A-ASSOCIATE должен передавать абстрактный синтаксис в контексте представления для SOP класса верификации. Имя абстрактного синтаксиса должно быть эквивалентно UID SOP класса верификации.
Акцептор ассоциации (роль SCP верификации) в ответе A-ASSOCIATE должен принять абстрактный синтаксис в контексте представления для поддерживаемого SOP класса верификации.
Информация об ассоциации приложений, специфичная для SOP класса верификации, не должна использоваться.
Реализации, соответствующие роли SCU SOP класса верификации, должны отвечать следующим требованиям:
Требования к сервису C-ECHO, как определено группой сервисов DIMSE, Раздел A.3
Правила согласования ассоциации, как определено в Раздел A.5
Реализации, соответствующие роли SCP SOP класса верификации, должны отвечать следующим требованиям:
Правила операции C-ECHO, как определено группой сервисов DIMSE, Раздел A.3
Правила согласования ассоциации, как определено в Раздел A.5
Реализация может соответствовать SOP классу верификации как SCU, SCP или обоим. Заявление о соответствии должно быть в формате, определённом в PS3.2.
Класс сервиса хранения определяет класс сервиса прикладного уровня, который облегчает простой перенос информационных экземпляров (объектов). Он позволяет одной DICOM AE отправлять изображения, сигналы, отчёты и т.д. другой.
Определения информационных объектов для экземпляров, передаваемых в рамках класса сервиса хранения, должны соответствовать информационной модели Composite Instance IOD, описанной в PS3.3, и включать как минимум информационные сущности Patient, Study и Series.
Две равноправные DICOM AE реализуют SOP класс класса сервиса хранения, одна из которых выступает в роли SCU, а другая — в роли SCP. SOP классы класса сервиса хранения реализуются с использованием сервиса C-STORE DIMSE-C. Сервис C-STORE описан в PS3.7. Успешное завершение C-STORE имеет следующую семантику:
Поддержка SOP классов хранения не обязательно включает поддержку SOP классов класса сервиса Query/Retrieve. То, каким образом может осуществляться доступ к информации, зависит от реализации. Требуется лишь, чтобы существовал некоторый метод доступа. Этот метод может требовать выполнения зависящей от реализации операции на SCP класса сервиса хранения. Длительность хранения также зависит от реализации и описывается в заявлении о соответствии SCP. SOP классы хранения предназначены для использования в различных условиях: например, для передачи изображений от модальностей на рабочие станции или в архивы, для передачи изображений из архивов на рабочие станции или обратно на модальности, для передачи обработанных изображений с рабочих станций в архивы и т.д.
Для синтаксисов передачи JPIP Referenced Pixel Data передача может привести к сохранению неполной информации, поскольку данные пикселей могут быть частично или полностью переданы посредством иного механизма по усмотрению SCP.
В данном разделе рассматривается поведение SCU и SCP для SOP классов класса сервиса хранения. C-STORE DIMSE-C сервис должен быть механизмом, используемым для передачи SOP экземпляров между равноправными DICOM AE, как описано в PS3.7.
SCU инициирует сервис C-STORE DIMSE с SOP экземпляром, который удовлетворяет требованиям соответствующего IOD. SCU должен распознавать статус сервиса C-STORE и предпринимать соответствующие действия при успехе или неудаче сервиса.
SCP SOP класса хранения выступает в роли выполняющего DIMSE-сервис-пользователя для сервиса C-STORE. Путём успешного выполнения этого сервиса SCP указывает, что SOP экземпляр был успешно сохранён.
Таблица B.2-1 определяет конкретные значения кодов статуса, которые могут быть возвращены в ответе C-STORE. Общие значения кодов статуса и поля, связанные со значениями кодов статуса, для сервиса C-STORE DIMSE определены в PS3.7.
Некоторые коды статуса отказа зависят от реализации.
Реализация SCP должна назначать конкретные коды статуса отказа, заменяя каждый символ 'x' шестнадцатеричной цифрой в диапазоне от 0 до F. Реализация SCP, желающая различать причины в пределах одного значения отказа, должна назначать этим причинам конкретные значения кодов статуса в допустимом диапазоне, указанном в Таблице B.2-1.
Реализация SCU должна распознавать любой код статуса отказа в диапазоне значений, указанном в Таблице B.2-1, как индикатор значения отказа, указанного в таблице. Не требуется, чтобы реализация SCU различала конкретные коды статуса в пределах допустимого диапазона.
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 должен принять:
Во время установления ассоциации реализации могут обмениваться информацией о своих соответствующих возможностях, как описано в 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 не поддерживает расширенное согласование, применяются значения по умолчанию.
Подэлемент 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)
Подэлемент 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)
Подэлемент SOP Class Common Extended Negotiation Sub-Item позволяет SCU передать UID класса сервиса для каждого предложенного SOP класса.
UID класса сервиса хранения должен быть "1.2.840.10008.4.2".
Ограниченный набор стандартных 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 класс.
Реализация, соответствующая SOP классам хранения, должна удовлетворять следующим требованиям:
требованиям сервиса C-STORE, как определено в Разделе B.2
требованиям к ассоциации, как определено в Разделе B.3
Не определено никаких требований к поведению SCU или SCP, помимо указанных в данном разделе. В частности, SCP SOP классов хранения может не придавать никакого значения конкретной ассоциации или ассоциациям, по которым запрашиваются операции C-STORE, а также порядку выполнения операций C-STORE в рамках ассоциации. На операции, которые SCU может выполнять во время любой конкретной ассоциации, не накладывается никаких ограничений, кроме определённых во время согласования ассоциации. SCP не должен ожидать, что SCU будет выполнять операции C-STORE в определённом порядке.
Аналогично, закрытию ассоциации не придаётся никакой семантики, такой как завершение исследования (Study) или выполненного этапа процедуры (Performed Procedure Step).
Для 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.
SCP, заявляющий о соответствии уровню поддержки Storage Level 2 (Full) класса сервиса хранения, может принять любое согласование контекста представления для SOP класса, указывающего класс сервиса хранения во время SOP Class Common Extended Negotiation (см. Раздел B.3.1.3), без указания соответствия этому SOP классу в своём заявлении о соответствии.
SCP может поддерживать хранение всех SOP классов класса сервиса хранения, сохраняя все атрибуты как SCP уровня хранения 2.
Это расширенное согласование позволяет SCP определить, что приватный SOP класс в предложенном контексте представления следует семантике класса сервиса хранения, и может быть обработан соответствующим образом.
SCP, заявляющий о соответствии уровню поддержки Storage Level 2 (Full) связанного общего SOP класса, может принять любое согласование контекста представления для SOP класса, указывающего этот связанный общий SOP класс во время SOP Class Common Extended Negotiation, без указания соответствия этому специализированному SOP классу в своём заявлении о соответствии.
Термин "специализированный" в этом разделе используется в общем смысле и включает как специализированные SOP классы, определённые реализацией, так и стандартные SOP классы, указанные в Таблице B.3-3.
SCP может обрабатывать экземпляры таких специализированных SOP классов с использованием семантики связанного общего SOP класса, но сохраняя все дополнительные (потенциально Type 1 или 2) атрибуты как SCP уровня хранения 2.
SCP, имеющий доступ к текущему содержимому Таблицы B.5-1, может использовать его для определения принятия предложенных контекстов представления SOP классов. Это позволяет SCP, даже без расширенного согласования, идентифицировать все стандартные SOP классы класса сервиса хранения. Доступ к Таблице B.5-1 может осуществляться приватным образом или через публикацию PS3 на веб-сайте Комитета по стандартам DICOM. Это обеспечивает автоматизированную альтернативу ручному редактированию таблицы поддерживаемых SOP классов хранения.
При любом уровне поддержки хранения SCP класса сервиса хранения может изменять значения определённых атрибутов для принудительного приведения SOP экземпляра к модели запроса SCP. Атрибуты, которые могут быть изменены, показаны в Таблице B.4-1.
SCP класса сервиса хранения может изменять значения атрибутов последовательности кодов (Code Sequence Attributes) для преобразования из одной схемы кодирования (Coding Scheme) в другую. Это включает замену устаревших значений Coding Scheme Designator (0008,0102) или Code Value (0008,0100) на действующие в настоящее время значения.
Если SCP выполняет такое изменение, он должен вернуть ответ C-STORE со статусом Warning (предупреждение).
Изменение этих атрибутов может потребоваться, если SCP также является SCP SOP классов Query/Retrieve. Эти SOP классы описаны в настоящем стандарте. Например, МР-сканер может быть реализован для генерации Study Instance UID для изображений, полученных на МР. При отправке этих изображений в архив, поддерживающий HIS/RIS, архив может изменить UID исследования, назначенный исследованию PACS. Механизм, с помощью которого выполняется это принудительное изменение, зависит от реализации.
SCP может, например, преобразовать устаревшие Code Values со значением Coding Scheme Designator "99SDM", "SNM3" или "SRT" в соответствующие значения SCT Code Values и использовать обозначение схемы кодирования "SCT" в соответствии с соглашениями DICOM для SNOMED (см. PS3.16).
Изменение атрибутов, которые могут использоваться для ссылки на SOP экземпляр другим SOP экземпляром (таких как атрибуты Study Instance UID и Series Instance UID), сделает эту ссылку недействительной. Изменение этих атрибутов настоятельно не рекомендуется.
Другие атрибуты могут быть изменены/исправлены SCP SOP класса хранения.
Изменение атрибутов может повлиять на цифровые подписи, ссылающиеся на содержимое SOP экземпляра.
Для SCP, заявляющего о соответствии уровню Storage Level 2 (Full), определены три уровня поддержки цифровой подписи:
На уровне подписи 1 SCP может не сохранять цифровые подписи и не заменять их.
На уровне подписи 2 SCP не сохраняет целостность входящих цифровых подписей, но проверяет цифровые подписи сохраняемых SOP экземпляров, принимает зависящие от реализации меры для обеспечения целостности сохраняемых данных и добавляет заменяющие цифровые подписи перед отправкой SOP экземпляров в другое место.
На уровне подписи 3 SCP сохраняет целостность входящих цифровых подписей (т.е. является битово-сохраняющим и сохраняет и извлекает все атрибуты независимо от того, определены ли они в IOD).
SCU должен генерировать только запросы C-STORE с SOP экземплярами, которые соответствуют требованиям IOD, связанного с SOP классом.
Во время согласования ассоциации приложение может предложить специализированный 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 класса. Однако такое преобразование не гарантируется.
Реализация может соответствовать SOP классу класса сервиса хранения в роли SCU, SCP или обеих. Заявление о соответствии должно быть в формате, определённом в PS3.2.
Следующие вопросы должны быть документированы в заявлении о соответствии любой реализации, заявляющей о соответствии 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. Это включает длительность действия ссылки
Следующие вопросы должны быть документированы в заявлении о соответствии любой реализации, заявляющей о соответствии классу сервиса хранения в роли SCP:
Должен быть указан уровень поддержки хранения, как определено в Разделе B.4.1.
Должен быть указан уровень поддержки цифровой подписи, как определено в Разделе B.4.1.
Должны быть перечислены необязательные атрибуты, которые будут отброшены (если таковые имеются), для каждого поддерживаемого IOD.
Должны быть указаны механизмы, с помощью которых динамически поддерживаются дополнительные SOP классы, как определено в Разделе B.4.1.2.
Заявление о соответствии должно документировать политику в отношении атрибута Lossy Image Compression (0028,2110).
Должно быть описано поведение SCP в случае успешной операции C-STORE. Это включает следующее:
Должно быть описано значение каждого случая неуспешного статуса ответа C-STORE, а также соответствующее действие по восстановлению.
Должно быть описано значение каждого случая предупреждающего статуса ответа C-STORE, а также соответствующее действие.
Если SCP выполняет принудительное изменение каких-либо атрибутов, это должно быть указано, а условия, при которых это может произойти, должны быть описаны.
Реализации могут обеспечивать соответствие специализированному SOP классу путём предоставления надлежащего надмножества сохраняемых SOP экземпляров. Реализации, обеспечивающие соответствие специализированному SOP классу одному из SOP классов, определённых в данном приложении, должны соответствовать требованиям, описанным в следующих разделах, и должны включать в своё заявление о соответствии информацию, описанную в следующих разделах.
Реализации разрешается соответствовать как специализации стандартного SOP класса в роли SCU, SCP или обеих. Заявление о соответствии должно быть в формате, определённом в PS3.2.
Любая реализация, которая специализирует стандартный 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.
Стандартный SOP класс может быть специализирован путём поддержки дополнительных приватных атрибутов. Заявление о соответствии должно описывать эти специализации и должно быть оформлено, как определено в PS3.2.
SOP классы в классе сервиса хранения идентифицируют Composite IOD, подлежащие хранению. Таблица B.5-1 определяет стандартные SOP классы.
Таблица B.5-1. Стандартные SOP классы
|
Спецификация IOD (определена в PS3.3) |
|||
|---|---|---|---|
|
Compositing Planar MPR Volumetric Presentation State Storage |
|||
|
Segmented Volume Rendering Volumetric Presentation State Storage |
|||
|
Multiple Volume Rendering Volumetric Presentation State Storage |
|||
|
Intravascular Optical Coherence Tomography Image Storage - For Presentation |
|||
|
Intravascular Optical Coherence Tomography Image Storage - For Processing |
|||
|
Wide Field Ophthalmic Photography Stereographic Projection Image Storage |
Wide Field Ophthalmic Photography Stereographic Projection Image IOD |
||
|
Wide Field Ophthalmic Photography 3D Coordinates Image Storage |
|||
|
Ophthalmic Optical Coherence Tomography En Face Image Storage |
|||
|
Ophthalmic Optical Coherence Tomography B-scan Volume Analysis Storage |
Ophthalmic Optical Coherence Tomography B-scan Volume Analysis IOD |
||
|
Ophthalmic Visual Field Static Perimetry Measurements Storage |
|||
| Content Assessment Results IOD | |||
| Microscopy Bulk Simple Annotations 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).
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 в той же роли.
Цель данного требования — обеспечить полезный уровень совместимости, избегая ситуации, когда 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 в качестве "базового".
Термин "поддержка" используется в данном разделе в том смысле, что 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 гарантированно сможет его отправить.
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 в той же роли.
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 в той же роли.
См. Annex N.
Требования Приложения O применяются к следующим SOP классам:
Приложение O требования не применяются к SOP классу Key Object Selection Document.
SCP класса Enhanced MR Image Storage или Legacy Converted Enhanced MR Image Storage также должен поддерживать SOP класс Grayscale Softcopy Presentation State Storage в качестве SCP.
SCP класса Enhanced CT Image Storage или Legacy Converted Enhanced CT Image Storage также должен поддерживать SOP класс Grayscale Softcopy Presentation State Storage в качестве SCP.
SCP класса Enhanced MR Color Image Storage также должен поддерживать SOP класс Color Softcopy Presentation State Storage в качестве SCP.
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), без обрезки.
SCP не обязан отображать изображение, используя точное количество вертикальных и горизонтальных пикселей. SCP может использовать столько экранного пространства, сколько считает нужным, сохраняя соотношение сторон Structured Display.
Если экран имеет другое соотношение сторон, позиционирование изображения на экране не определено (по центру, выравнивание по левому или правому краю, по верхнему или нижнему краю).
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; такое поведение должно как минимум включать отображение пользователю характера несовместимости.
См. Annex GG.
Требования данного раздела были объединены в класс сервиса Non-Patient Object Storage Service Class (см. Раздел GG.6.3).
Устройства для офтальмологических осевых измерений используются при предоперационном обследовании каждого пациента перед операцией по удалению катаракты. SOP классы офтальмологических осевых измерений поддерживают устройства для офтальмологических осевых измерений.
Для устройства, которое является как SCU, так и SCP класса Ophthalmic Axial Measurements Storage, в дополнение к поведению для класса сервиса хранения, определённому в Разделе B.2.2, указаны следующие дополнительные требования для SOP классов Ophthalmic Axial Measurements Storage:
SCP данного SOP класса должен поддерживать уровень хранения 2 (Full), как определено в Разделе B.4.1.
Расчёт IOL (интраокулярной линзы) используется при предоперационном обследовании каждого пациента перед операцией по удалению катаракты. SOP классы расчёта IOL поддерживают программное обеспечение для расчёта IOL, которое может располагаться либо на устройствах для офтальмологических осевых измерений, либо на отдельном компьютере.
Для устройства, которое является как SCU, так и SCP класса IOL Calculation Storage, в дополнение к поведению для класса сервиса хранения, определённому в Разделе B.2.2, указаны следующие дополнительные требования для SOP классов IOL Calculation Storage:
SCP данного SOP класса должен поддерживать уровень хранения 2 (Full), как определено в Разделе B.4.1.
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 в той же роли.
Цель данного требования — обеспечить полезный уровень совместимости, избегая ситуации, когда SCU может поддерживать только SOP класс Intravascular OCT Image Storage - For Processing, а SCP — только SOP класс Intravascular OCT Image Storage - For Presentation, или наоборот. Таким образом, бременем является поддержка SOP класса Intravascular OCT Image Storage - For Presentation в качестве "базового".
Термин "поддержка" используется в данном разделе в том смысле, что 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 гарантированно сможет его отправить.
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.
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.
SCP класса Enhanced PET Image Storage также должен поддерживать SOP класс Grayscale Softcopy Presentation State Storage и, по выбору, SOP класс Variable Modality LUT Softcopy Presentation State Storage в качестве SCP.
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.
Размер карты топографии роговицы обычно совпадает с размером нижележащего изображения, на которое она наложена, т.е. атрибуты Rows (0028,0010) и Columns (0028,0011) имеют те же значения, а ориентация и начало координат те же. В этом случае нет необходимости задавать Spatial Registration.
Состояние презентации Blending Presentation State предоставляет дополнительные возможности наложения изображений, однако они обычно не требуются для данного варианта использования, т.е. для визуализации карты топографии роговицы поверх исходного изображения.
Примеры визуализации наложенных изображений и аннотированной цветовой шкалы можно найти в Разделе 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.
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 в той же роли.
Требования Раздела FF.2.1.1 применяются к следующим SOP классам:
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).
SCU класса Content Assessment Results Storage, который создаёт SOP экземпляры данного SOP класса, должен указать в своём заявлении о соответствии критерии для установки атрибута Observation Significance (0082,0008).
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.
Для устройства, которое является как SCU, так и SCP класса Raw Data Storage, в дополнение к поведению для класса сервиса хранения, определённому в Разделе B.2.2, указаны следующие дополнительные требования для SOP класса Raw Data Storage:
SCP данного SOP класса должен поддерживать уровень хранения 2 (Full), как определено в Разделе B.4.1.
SCP любого из SOP классов Enhanced Multi-Frame Image, который делает SOP экземпляры доступными через расширенное согласование Enhanced Multi-Frame Image Conversion класса сервиса Query/Retrieve (см. Раздел C.3.5), должен поддерживать уровень хранения 2 (Full).
Требования Раздела FF.2.1.2 применяются к следующим SOP классам:
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).
SOP класс Segmentation Storage должен использовать Segmentation IOD с перечисляемым значением BINARY или FRACTIONAL для атрибута Segmentation Type (0062,0001).
SOP класс Label Map Segmentation Storage должен использовать Segmentation IOD с перечисляемым значением LABELMAP для атрибута Segmentation Type (0062,0001).
SOP классы из Таблицы B.6-1 были определены в предыдущих версиях стандарта DICOM. Они были сняты с поддержки и заменены новыми стандартными SOP классами, показанными в Таблице B.5-1.
Использование снятых с поддержки SOP классов разрешено DICOM. Однако новые реализации настоятельно рекомендуется разрабатывать на основе более новых SOP классов.
Сервисный класс Query/Retrieve (запрос/получение) определяет класс обслуживания прикладного уровня, обеспечивающий простое управление экземплярами составных объектов (Composite Object Instances) способом, функционально аналогичным ACR-NEMA 300-1988. Допускаемые типы запросов не являются сложными. Данный сервисный класс не предназначен для предоставления полнофункционального механиз запросов к базе данных общего назначения, такого как SQL. Вместо этого, сервисный класс Query/Retrieve ориентирован на базовые информационные запросы к экземплярам составных объектов с использованием небольшого набора общих ключевых атрибутов (Key Attributes).
Кроме того, сервисный класс Query/Retrieve предоставляет возможность извлекать/передавать чётко идентифицированный набор экземпляров составных объектов. Возможность извлечения/передачи позволяет DICOM AE извлекать экземпляры составных объектов из удалённой DICOM AE или запрашивать удалённую DICOM AE инициировать передачу экземпляров составных объектов другой DICOM AE.
Опция расширенного согласования преобразования многоформатных изображений 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 будут преобразованы во всех экземплярах, а не только в преобразованных изображениях.
Классическое одноформатное представление не предназначено в качестве альтернативы SOP классам извлечения на уровне кадров (Frame Level Retrieve SOP Classes), определённым в Приложении Y. SOP классы хранения Enhanced-изображений (Enhanced Image Storage SOP Classes) и SOP классы извлечения на уровне кадров (Frame Level Retrieve SOP Classes) следует использовать совместно, поскольку они поддерживают единое представление связей между экземплярами через общий набор UID.
В представлении Enhanced экземпляры, не имеющие Enhanced-эквивалента, будут возвращены в исходной форме, но с изменениями, связанными с обеспечением ссылочной целостности.
Следующие соглашения используются для определения типов ключей, применяемых в информационных моделях 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.
Две равноправные 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:
Сервис 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 (отмена).
Сервис 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.
Сервис 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.
Информационная модель Query/Retrieve идентифицируется SOP классом, согласованным при установлении ассоциации. SOP класс состоит как из информационной модели, так и из группы сервисов DIMSE-C.
Данный SOP класс идентифицирует класс информационной модели Query/Retrieve (т.е. не SOP класс хранимых экземпляров SOP, информацию о которых имеет SCP).
Определения информационных моделей для стандартных SOP классов сервисного класса Query/Retrieve определены в данном Приложении. Определение информационной модели Query/Retrieve содержит:
Для любой информационной модели Query/Retrieve модель «сущность-связь» (Entity-Relationship Model) определяет иерархию сущностей с атрибутами, определёнными для каждого уровня иерархии (например, Patient, Study, Series, Composite Object Instance).
Атрибуты должны быть определены на каждом уровне в модели «сущность-связь». Идентификатор в команде C-FIND, C-MOVE или C-GET должен содержать значения для сопоставления с атрибутами сущностей в информационной модели Query/Retrieve. Для любого запроса набор сущностей, для которых возвращаются атрибуты, должен определяться набором ключевых атрибутов (Key Attributes), указанных в идентификаторе и имеющих соответствующие совпадения у сущностей, управляемых SCP, связанным с запросом.
Все атрибуты сущностей в информационной модели Query/Retrieve должны быть либо уникальными ключами (Unique Key), либо обязательными ключами (Required Key), либо необязательными ключами (Optional Key). Термин «ключевые атрибуты» (Key Attributes) относится к уникальным, обязательным и необязательным ключевым атрибутам.
На каждом уровне в модели «сущность-связь» один атрибут должен быть определён как уникальный ключ. Одно значение в атрибуте уникального ключа должно однозначно идентифицировать одну сущность на заданном уровне. То есть две сущности на одном уровне не могут иметь одинаковое значение уникального ключа.
SCP C-FIND, C-MOVE и C-GET должны поддерживать существование и сопоставление всех уникальных ключей, определённых информационной моделью Query/Retrieve. Все сущности, управляемые SCP C-FIND, C-MOVE и C-GET, должны иметь конкретное ненулевое значение уникального ключа.
Уникальные ключи могут содержаться в идентификаторе запроса C-FIND. Уникальные ключи должны содержаться в идентификаторе запросов C-MOVE и C-GET.
На каждом уровне в модели «сущность-связь» набор атрибутов должен быть определён как обязательные ключи. Обязательные ключи означают, что SCP сервиса C-FIND должен поддерживать сопоставление на основе значения, содержащегося в обязательном ключе запроса C-FIND. Несколько сущностей могут иметь одинаковое значение обязательных ключей. То есть отдельное значение обязательного ключа не обязательно идентифицирует одну сущность на уровне ключа.
SCP C-FIND должны поддерживать существование и сопоставление всех обязательных ключей, определённых информационной моделью Query/Retrieve. Если SCP C-FIND управляет сущностью с обязательным ключом нулевой длины, значение считается неизвестным, и любое сопоставление с обязательным ключом нулевой длины должно считаться успешным совпадением (т.е. любое значение, предоставленное SCU, включая значение нулевой длины, будет соответствовать значению нулевой длины SCP).
Обязательные ключи могут содержаться в идентификаторе запроса C-FIND. Обязательные ключи не должны содержаться в идентификаторе запросов C-MOVE и C-GET.
На каждом уровне в модели «сущность-связь» набор атрибутов должен быть определён как необязательные ключи.
Необязательные ключи, содержащиеся в идентификаторе запроса C-FIND, могут иметь три различных типа поведения в зависимости от поддержки существования и/или сопоставления SCP C-FIND. Если SCP C-FIND:
не поддерживает существование необязательного ключа, то атрибут не должен возвращаться в ответах C-FIND
поддерживает существование необязательного ключа, но не поддерживает сопоставление по необязательному ключу, то необязательный ключ должен обрабатываться так же, как обязательный ключ нулевой длины. То есть значение, указанное для сопоставления по необязательному ключу, игнорируется, но SCP может возвратить значение для этого необязательного ключа.
поддерживает существование и сопоставление необязательного ключа, то необязательный ключ должен обрабатываться так же, как обязательный ключ.
SCU C-FIND не может предполагать, что необязательный ключ с ненулевой длиной будет обрабатываться так же, как обязательный ключ. Заявление о соответствии (Conformance Statement) SCP C-FIND должно перечислять поддерживаемые необязательные ключи.
Необязательные ключи отличаются от обязательных ключей тем, что для необязательных ключей может поддерживаться или не поддерживаться существование и/или сопоставление SCP C-FIND. Обязательные ключи, напротив, всегда должны поддерживаться SCP C-FIND.
Необязательные ключи могут содержаться в идентификаторе запроса C-FIND. Необязательные ключи не должны содержаться в идентификаторе запросов C-MOVE и C-GET.
В сервисном классе Query/Retrieve для ключевых атрибутов могут выполняться следующие типы сопоставления:
Сопоставление требует специальных символов (т.е. «*», «?», «-», «=», «\» и кавычки QUOTATION MARK из стандартного набора символов Default Character Repertoire), которые не обязательно должны быть частью набора символов для VR ключевых атрибутов.
Например, символ «-» недопустим для VR DA, DT и TM, но используется для сопоставления по диапазону. Символы шаблона «*» и «?» недопустимы для VR CS, но используются для сопоставления по шаблону.
При использовании наборов символов, отличных от стандартного (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).
Если SCU отправляет идентификатор запроса с однобайтовым набором символов, не поддерживаемым SCP, то вероятно (но не обязательно), что SCP будет трактовать нераспознанные символы как шаблоны и сопоставлять только символы из стандартного набора, возвращая ответ в стандартном наборе символов.
Некоторые значения Specific Character Set используются с многокомпонентными именами персон (например, однобайтовыми, идеографическими и фонетическими группами компонентов, разделёнными символом «=» (3DH)), что может также влиять на поведение сопоставления строк буквально.
Атрибут Timezone Offset From UTC (0008,0201) может присутствовать в идентификаторе, но не сопоставляется, если согласована корректировка часового пояса запроса (Timezone query adjustment). Если корректировка часового пояса запроса согласована, он определяет, как значения атрибутов VR DT и TM (включая связанные значения атрибутов VR DA, если они присутствуют) интерпретируются в идентификаторах запроса и ответа, если эти значения не содержат явного указания смещения часового пояса.
Если значение, указанное для ключевого атрибута в запросе, имеет ненулевую длину и не имеет VR SQ и:
имеет VR AE, CS, LO, LT, PN, SH, ST, UC, UR или UT и содержит одно значение без символов шаблона, и если расширенное согласование сопоставления пустого значения (Empty Value Matching) прошло успешно и значение не состоит ровно из двух символов QUOTATION MARK, или
имеет VR DA, TM или DT и содержит одно значение без «-» и без символов QUOTATION MARK, или
то выполняется сопоставление по одному значению. За исключением атрибутов с VR PN, совпадают только сущности, значения которых точно соответствуют значению, указанному в запросе. Это сопоставление чувствительно к регистру, т.е. чувствительно к точному кодированию значения ключевого атрибута в наборах символов, где буква может иметь несколько кодировок (например, в зависимости от регистра, позиции в слове или наличия диакритических знаков).
Следующие подразделы определяют особенности для определённых VR.
Для атрибутов с VR PN (например, Patient Name (0010,0010)) приложение может выполнять буквальное сопоставление, чувствительное к регистру, или нечувствительное к некоторым или ко всем аспектам регистра, позиции, акцента или другим вариантам кодирования символов.
Для многокомпонентных имён разделитель групп компонентов «=» (3DH) может присутствовать в значении ключевого атрибута, но может давать неожиданные результаты, если SCP не поддерживает сопоставление по отдельным компонентам, а интерпретирует всё значение буквально как одну строку. Например, «Wang^XiaoDong=王^小東» может как соответствовать, так и не соответствовать «Wang^XiaoDong» или «王^小東»; может потребоваться сопоставление по шаблону без разделителя групп компонентов, такое как «*Wang^XiaoDong*» или «*王^小東*».
Если расширенное согласование нечёткого семантического сопоставления (fuzzy semantic matching) атрибутов VR PN прошло успешно вместо буквального сопоставления, сопоставление может быть нечувствительным не только к регистру, позиции, акценту и кодированию символов (включая комбинируемые символы), но и применять дополнительные методы, такие как фонетическое сопоставление.
Сопоставление атрибутов PN может быть нечувствительным к диакритическим знакам, как указано в заявлении о соответствии. Нечувствительное к диакритическим знакам сопоставление успешно сопоставит, например, символ запроса «SMALL LETTER a» (06/01 в стандартном ISO-IR 6) с
но не будет соответствовать 14/00 в ISO-IR 101, который является «SMALL LETTER r WITH ACUTE ACCENT». Сопоставление с конкретными битовыми комбинациями зависит от каждого поддерживаемого набора символов (обратите внимание на разницу в значении 14/00) и должно быть описано в заявлении о соответствии.
Приложение SCU может применять дополнительную фильтрацию ответов, самостоятельно применяя правила сопоставления. В случае, когда и SCU, и SCP применяют правила сопоставления, этот процесс будет успешным до тех пор, пока оба выполняют буквальное сопоставление, а любая дополнительная фильтрация SCU нечувствительна к регистру, позиции, акценту или другим вариантам кодирования символов.
Однако если было согласовано нечёткое семантическое сопоставление атрибутов PN, сопоставление SCP может привести к ответам, которые не имеют очевидной связи с запросом, поэтому следует проявлять осторожность при выполнении SCU любой дополнительной фильтрации ответов. Например, при фонетическом сопоставлении запрос «Swain» может вернуть «Swayne», а при сопоставлении, нечувствительном к порядку компонентов имени, запрос «Smith^Mary» может вернуть «Mary^Smith» или «Mary Smith» или «Smith, Mary». Нечёткое семантическое сопоставление может также учитывать отдельные группы компонентов имени — однобайтовые, идеографические и фонетические.
VR AE, LO, LT, PN, SH, ST, UC, UR и UT допускают наличие символов шаблона «*» и «?». Сопоставление по шаблону также определено для значений CS. Сопоставление по одному значению для таких символов не поддерживается. См. Раздел C.2.2.2.4.
Если атрибут Timezone Offset From UTC (0008,0201) присутствует в идентификаторе и корректировка часового пояса запроса была согласована, он должен использоваться для корректировки значений атрибутов VR TM (и связанных атрибутов VR DA, если они присутствуют) из местного часового пояса в UTC. Он также должен корректировать значения атрибутов VR DT, не указывающие смещение часового пояса. Кодирование и семантика атрибута Timezone Offset From UTC (0008,0201) должны соответствовать определению в модуле SOP Common в PS3.3.
Способ выполнения сопоставления зависит от реализации и должен быть указан в заявлении о соответствии.
Это определение подразумевает, что значения VR TM, DA и DT сопоставляются по их смыслу, а не как буквальные строки. Например:
Если приложение обеспокоено тем, как выполняется сопоставление по одному значению для дат и времени другим приложением, оно может рассмотреть возможность использования сопоставления по диапазону, которое всегда выполняется по смыслу, с обоими значениями в диапазоне, одинаковыми.
Исключение символа «-» для сопоставления по одному значению означает, что ключевой атрибут с VR DT не может содержать отрицательное смещение от всемирного координированного времени (UTC), если предполагается сопоставление по одному значению. Использование символа «-» в значениях VR TM, DA и DT указывает на сопоставление по диапазону.
Если приложение находится в местном часовом поясе с отрицательным смещением, оно не может выполнить сопоставление по одному значению с использованием местной записи времени. Вместо этого оно может преобразовать значение ключевого атрибута в UTC и использовать явный суффикс «+0000».
Список UID кодируется с использованием оператора кратности значения — обратной косой черты («\») в качестве разделителя между UID. Каждый элемент списка должен содержать одно значение UID. Каждый UID в списке, содержащемся в идентификаторе запроса, может породить совпадение.
Список отдельных значений кодируется точно так же, как VR UI с VM Multiple (см. PS3.5).
Если значение, указанное для ключевого атрибута в запросе, имеет нулевую длину, то все сущности должны соответствовать этому атрибуту. Атрибут, содержащий спецификацию универсального сопоставления в запросе C-FIND, предоставляет механизм для запроса значения выбранного атрибута в соответствующих ответах C-FIND.
Если атрибут имеет VR AE, CS, LO, LT, PN, SH, ST, UC, UR, UT и значение, указанное в запросе, содержит любое вхождение «*» или «?», то «*» должно соответствовать любой последовательности символов (включая значение нулевой длины), а «?» должен соответствовать любому одиночному символу. Это сопоставление чувствительно к регистру, за исключением атрибутов с VR PN (например, Patient Name (0010,0010)).
Для атрибутов с VR PN, включая случай расширенного согласования нечёткого семантического сопоставления, сопоставление по шаблону зависит от реализации и должно быть указано в заявлении о соответствии.
Сопоставление по шаблону для значения «*» эквивалентно универсальному сопоставлению.
Метод сопоставления по шаблону, определённый в DICOM, может не поддерживаться некоторыми не-DICOM текстовыми процессорами многобайтовых символов.
Для многокомпонентных имён разделитель групп компонентов «=» (3DH) может присутствовать в значении ключевого атрибута, но может давать неожиданные результаты, если SCP не поддерживает сопоставление по отдельным компонентам, а интерпретирует всё значение буквально. Например, «*=*» или «*=*=*» может как возвращать, так и не возвращать все строки, и поэтому не эквивалентно «*», ни универсальному сопоставлению.
Атрибуты с VR AE, LO, PN, SH и UC могут содержать символы шаблона «*» и «?». Попытки сопоставить строку, явно содержащую «*» или «?», будут рассматриваться как сопоставление по шаблону и, таким образом, могут вернуть несколько результатов, а не один. Не существует механизма сопоставления по одному значению для значений, содержащих символы «*» и «?» для данных VR — такие запросы всегда будут рассматриваться как запросы с сопоставлением по шаблону.
Атрибуты с VR ST, LT и UT предназначены для передачи текста описаний и могут содержать символы шаблона «*» и «?». Попытки сопоставить строку, явно содержащую «*» или «?», будут рассматриваться как сопоставление по шаблону и, таким образом, могут вернуть несколько результатов, а не один. Не существует механизма сопоставления по одному значению для значений, содержащих символы «*» и «?» для данных VR — такие запросы всегда будут рассматриваться как запросы с сопоставлением по шаблону.
Атрибуты с VR UR могут содержать символы шаблона «*» и «?» в качестве разделителей. Эти символы зарезервированы в соответствии с [RFC3986] Раздел 2. Попытки сопоставить строку, явно содержащую «*» или «?», будут рассматриваться как сопоставление по шаблону и, таким образом, могут вернуть несколько результатов, а не один. Не существует механизма сопоставления по одному значению для значений, содержащих символы «*» и «?» для данных VR — такие запросы всегда будут рассматриваться как запросы с сопоставлением по шаблону.
При отсутствии расширенного согласования:
Строка вида «<дата1> - <дата2>», где <дата1> меньше или равна <дата2>, должна соответствовать всем вхождениям дат, попадающим в диапазон от <дата1> до <дата2> включительно
Строка вида «- <дата1>» должна соответствовать всем вхождениям дат до <дата1> включительно
Строка вида «<дата1> -» должна соответствовать всем вхождениям <дата1> и последующим датам
Все сравнения, указанные ниже, должны основываться на прямом сравнении моментов времени в течение дня. «До» включает все моменты времени от полуночи того же дня до указанного времени. «После» включает все моменты времени от указанного времени до любого момента времени до полуночи следующего дня. Сопоставление по диапазону, пересекающему полночь, не поддерживается.
Смещение от всемирного координированного времени не допускается в значениях VR TM. Если Timezone Offset From UTC (0008,0201) присутствует в идентификаторе запроса, указанные значения времени и определение полуночи соответствуют указанному часовому поясу.
При отсутствии расширенного согласования:
Строка вида «<время1> - <время2>», где <время1> меньше или равно <время2>, должна соответствовать всем вхождениям моментов времени, попадающим в диапазон от <время1> до <время2> включительно
Строка вида «- <время1>» должна соответствовать всем вхождениям моментов времени до <время1> включительно
Строка вида «<время1> -» должна соответствовать всем вхождениям <время1> и последующим моментам времени
Строка вида «<дата-время1> - <дата-время2>», где <дата-время1> меньше или равно <дата-время2>, должна соответствовать всем моментам времени, попадающим в диапазон от <дата-время1> до <дата-время2> включительно
Строка вида «- <дата-время1>» должна соответствовать всем моментам времени до <дата-время1> включительно
Строка вида «<дата-время1> -» должна соответствовать всем моментам времени после <дата-время1> включительно
Смещение от всемирного координированного времени, если оно присутствует в значении атрибута, должно учитываться для целей сопоставления.
Если расширенное согласование комбинированного сопоставления даты-времени (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-FIND должен быть сопоставлен с атрибутом, структурированным как последовательность элементов (Sequence of Items, VR SQ), ключевой атрибут должен быть структурирован как последовательность элементов с одним элементом (Item). Этот элемент может содержать ноль или более ключевых атрибутов элемента (Item Key Attributes). Сопоставление каждого ключевого атрибута элемента должно выполняться на поэлементной основе. Должны использоваться типы сопоставления, определённые в Разделе C.2.2.2: сопоставление по одному значению, сопоставление по списку UID, универсальное сопоставление, сопоставление по шаблону, сопоставление по диапазону и сопоставление последовательностей (рекурсивное сопоставление последовательностей).
Если все ключевые атрибуты элемента совпадают по крайней мере для одного из элементов атрибута, с которым выполняется сопоставление, генерируется успешное совпадение. Последовательность совпавших элементов, содержащая только запрошенные атрибуты, возвращается в соответствующих ответах C-FIND.
Если ключевой атрибут в идентификаторе запроса C-FIND не содержит ни одного ключевого атрибута элемента (тег Item нулевой длины), то все сущности должны соответствовать этому атрибуту. Это обеспечивает механизм, подобный универсальному сопоставлению, для запроса значения выбранного ключевого атрибута (всей последовательности элементов) в соответствующих ответах C-FIND.
Если расширенное согласование сопоставления пустого значения (Empty Value Matching) прошло успешно, и для атрибутов с VR AE, CS, DA, DT, LO, LT, PN, SH, ST, TM, UC, UR или UT, значение ключевого атрибута, состоящее ровно из двух символов QUOTATION MARK (22H в стандартном наборе символов Default Character Repertoire), указанное в запросе, должно означать сопоставление с пустым значением. Такое сопоставление считается успешным для сущностей с значением нулевой длины для соответствующего атрибута или для которых атрибут отсутствует.
Другие символы кавычек, определённые в расширенном или заменяющем наборе символов, такие как двойные угловые кавычки, левые и правые изогнутые кавычки и т.д., недопустимы для указания сопоставления пустого значения.
VR AE, LO, LT, PN, SH, ST, UC и UT допускают символ QUOTATION MARK. Сопоставление строки из двух символов QUOTATION MARK в этих атрибутах может быть выполнено с помощью сопоставления по шаблону с использованием символа ASTERISK (например, ""*).
Многозначное сопоставление (Multiple Value Matching) относится к предоставлению нескольких значений в ключевом атрибуте. В этом разделе описывается, как выполнять сопоставление с такими ключевыми атрибутами. Раздел C.2.2.3 описывает, что возвращать, когда сопоставляемый атрибут сущности содержит несколько значений.
Если расширенное согласование многозначного сопоставления (Multiple Value Matching) прошло успешно, для атрибутов с VR AE, AS, AT, CS, LO, PN, SH или UC и определённой VM больше 1, ключевой атрибут с несколькими значениями, указанный в запросе, должен означать сопоставление с многозначным атрибутом сущности. Такое сопоставление считается успешным только если каждое значение в ключевом атрибуте соответствует значению в соответствующем атрибуте сущности.
Значения ключевого атрибута не должны содержать шаблоны.
Порядок значений атрибутов в запросе не обязан соответствовать порядку в соответствующем атрибуте сущности.
Это логическая функция «И» для всех значений в ключевом атрибуте. Например, значение CT\PT для Modalities in Study (0008,0061) в идентификаторе запроса будет соответствовать только исследованиям, которые включают как серию CT, так и серию PT.
В атрибуте сущности могут быть дополнительные значения, которые не соответствуют значениям в ключевом атрибуте.
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.
При отсутствии успешного расширенного согласования многозначного сопоставления семантика нескольких значений в ключевом атрибуте не определена.
При использовании сопоставления по одному значению, сопоставления по шаблону или сопоставления по диапазону для сопоставления ключевого атрибута с атрибутом сущности, имеющим кратность значения больше одного, если какое-либо из значений совпадает, должны быть возвращены все значения.
При использовании многозначного сопоставления, если сопоставление успешно, должны быть возвращены все значения.
Стандартные информационные модели Query/Retrieve определены в данном Приложении. Каждая информационная модель Query/Retrieve связана с рядом SOP классов. Определены следующие иерархические информационные модели Query/Retrieve:
Информационная модель Query/Retrieve с корнем Patient (Patient Root Query/Retrieve Information Model) основана на четырёхуровневой иерархии:
Уровень пациента является верхним уровнем и содержит атрибуты, связанные с информационной сущностью пациента (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.
Информационная модель Query/Retrieve с корнем Study (Study Root Query/Retrieve Information Model) идентична модели с корнем Patient, за исключением того, что верхним уровнем является уровень исследования. Атрибуты пациентов считаются атрибутами исследований.
Анулировано (Retired). См. PS3.4-2004.
Некоторые необязательные атрибуты, которые могут использоваться в информационных моделях Query/Retrieve и не являются атрибутами информационной объектной дефиниции (IOD), и, следовательно, не определены в PS3.3. Эти атрибуты определены в Таблице C.3-1.
Таблица C.3-1. Дополнительные атрибуты Query/Retrieve
|
Количество исследований, соответствующих критериям поиска Query/Retrieve на уровне Patient |
||
|
Количество серий, соответствующих критериям поиска Query/Retrieve на уровне Patient |
||
|
Количество экземпляров составных объектов, соответствующих критериям поиска Query/Retrieve на уровне Patient |
||
|
Количество серий, соответствующих критериям поиска Query/Retrieve на уровне Study |
||
|
Количество экземпляров составных объектов в серии, соответствующих критериям поиска Query/Retrieve на уровне Series |
||
|
Количество экземпляров составных объектов, соответствующих критериям поиска Query/Retrieve на уровне Study |
||
|
Все уникальные значения, использованные для Modality (0008,0060) в сериях исследования. |
||
|
Анатомические области интереса в данном исследовании (т.е. внешняя анатомия, анатомия поверхности или общая область тела). В этой последовательности допускается один или несколько элементов (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"). |
||
|
Последовательность элементов, каждый из которых идентифицирует альтернативное кодирование изображения, соответствующее критериям поиска Query/Retrieve на уровне Instance (см. Раздел C.6.1.1.5.1) |
||
|
Описывает один или несколько синтаксисов передачи (Transfer Syntaxes), которые SCP гарантирует поддерживать для извлечения SOP Instance (см. Раздел C.6.1.1.5.2). |
||
|
Дата/время последнего обновления метаданных исследования (например, атрибутов Patient, Study или Procedure, Imaging Service Request или Series) или набора SOP Instance в исследовании. ПримечаниеМожет также отражать дату/время обновления места хранения SOP Instance для исследования, если SCP поддерживает атрибуты для доступа к хранимым SOP Instance через протокол, отличный от DICOM (см. Раздел C.6.4.1.3), |
Если SCP управляет изображениями в нескольких альтернативных кодированиях, только одно из альтернативных кодирований изображения включается в количество экземпляров объектов.
Если Query/Retrieve View (0008,0053) присутствует со значением «CLASSIC» или «ENHANCED» в идентификаторе запроса C-FIND, C-MOVE или C-GET, то информационная модель, по которой выполняется запрос или извлечение, и любые извлекаемые SOP Instance должны быть возвращены, сконструированы или преобразованы в соответствии с требованиями данного раздела.
Не существует требований относительно того, когда такие экземпляры фактически создаются или сохраняются, — требуется лишь их доступность по запросу. Т.е. они могут быть созданы заранее (кэшированы) или созданы динамически по мере необходимости, при условии что процесс является детерминированным в том смысле, что одни и те же атрибуты будут заполнены одними и теми же значениями при последовательных запросах и извлечениях (включая UID).
Процесс генерации UID должен быть детерминированным, но важно помнить, что добавление суффикса к существующему UID не является допустимым подходом к генерации нового UID, если только преобразователь не является производителем (владельцем корня) исходного UID и не знает, что это безопасно и результат будет уникальным.
Перекрёстные ссылки между исходными и преобразованными экземплярами содержат достаточно информации для восстановления UID в альтернативной форме.
Все экземпляры для пациента, известные SCP, должны быть преобразованы по мере необходимости для поддержания ссылочной целостности и предотвращения потери информации.
Не допускается исключать подмножество экземпляров из этой области действия, например, состояния отображения (presentation states) или документы выбора ключевых объектов (key object selection documents), из представления «ENHANCED» с целью избежать затрат на создание новых экземпляров с обновлёнными ссылками, необходимыми для поддержания ссылочной целостности. Иными словами, суммарное «информационное содержание» любого представления будет не меньше, чем у представления по умолчанию.
Это не означает, что все экземпляры должны быть преобразованы, поскольку если они не содержат таких ссылок, они могут быть оставлены без изменений и включены в представление. Например, классическое однослойное КТ-изображение-локализатор без ссылок может оставаться неизменным в представлении как SOP класс CT Image Storage с его существующим SOP Instance UID и SOP классом в его существующей серии и ссылаться из преобразованных экземпляров, таких как аксиальные срезы, назначенные на его основе. SCU не может делать никаких предположений о том, что будет или не будет преобразовано, или в каком порядке.
Следует понимать, что требования данного раздела применимы к отдельному 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) всех экземпляров в новой серии должны быть самыми ранними из значений в исходных составных экземплярах, если они присутствуют.
Новые Series Date и Time НЕ должны соответствовать моменту выполнения преобразования, а должны отражать значения в исходных изображениях.
Не существует стандартного требования или механизма для изменения или сохранения других атрибутов уровня серии, таких как Series Number или Series Description. Это оставлено на усмотрение разработчика, особенно в случаях, когда экземпляры из разных серий объединяются.
Новый составной экземпляр должен иметь те же элементы и значения Request Attributes Sequence (0040,0275), что и исходные составные экземпляры, если Request Attributes Sequence (0040,0275) присутствует в любом из исходных составных экземпляров.
Если новый составной экземпляр содержит ссылки на другую сущность для того же пациента (включая, помимо прочего, ссылки на SOP Instance, серии, исследования или системы координат), и цель этих ссылок также преобразована, то ссылки должны быть изменены так, чтобы указывать на преобразованную сущность.
Например, если исходный экземпляр ссылается на экземпляр в серии, и ссылаемый экземпляр также преобразован и, следовательно, помещён в новую серию, то как SOP Instance UID, так и Series Reference UID в иерархической ссылке на экземпляр должны быть обновлены, как и SOP Class UID ссылаемого экземпляра, если он изменился (что, вероятно, произойдёт).
Общая цель состоит в поддержании ссылочной целостности в преобразованном наборе экземпляров в рамках одного пациента. Поскольку, вероятно, большинство (если не все) неизобразительных экземпляров для пациента ссылаются на изображения, которые будут преобразованы, это означает, что большинство (если не все) неизобразительных экземпляров также должны быть «преобразованы» с целью обновления таких ссылок. Эта ссылочная целостность требуется независимо от того, относится ли первоначальный запрос к подмножеству экземпляров пациента или нет.
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.
Например, если исходные изображения для преобразования принадлежат к SOP классу CT Image Storage, то предпочтительным новым SOP классом является Enhanced CT Image Storage SOP Class, но если это невозможно, используется Legacy Converted Enhanced CT Image Storage SOP Class.
Не предполагается, что изображения из разных модальностей будут объединены в одном новом составном экземпляре. Например, не ожидается, что КТ и ПЭТ изображения будут объединены в одном экземпляре, поскольку технические атрибуты и характеристики пиксельных данных совершенно различны.
Ожидается, что столько одноформатных изображений, сколько разумно, будет объединено в одно многоформатное изображение с учётом ограничений на то, какие атрибуты должны быть идентичны, как определено в данном разделе, и в зависимости от типа изображений и размера результирующего объекта. Различные реализации могут делать различный выбор в этом отношении. Например, приложение может объединять только изображения в одной серии, или с одинаковым расстоянием между срезами, или с одинаковыми значениями Image Type, или с одинаковым Image Orientation (Patient).
Новый составной экземпляр (Composite Instance) не должен входить в конкатенацию (Concatenation). Это означает, что он не должен содержать атрибут Concatenation UID (0020,9161) или другие атрибуты конкатенации. Если существующий составной экземпляр содержит такие атрибуты, они не должны включаться в новый составной экземпляр.
Новый составной экземпляр содержит только один набор атрибутов для модуля Image Pixel, поэтому содержимое модуля Image Pixel должно быть либо одинаковым во всех исходных изображениях, либо Pixel Data для каждого кадра должна быть преобразована по мере необходимости для соответствия модулю Image Pixel нового составного экземпляра.
В частности, это означает, что значения 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.
Особое внимание следует уделить Pixel Padding Value и связанным атрибутам, в случае если они варьируются от кадра к кадру в исходных изображениях; в этом случае Pixel Data для некоторых кадров может потребоваться изменить для согласованности со всеми остальными кадрами.
При преобразовании можно изменить атрибуты модуля 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).
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.
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).
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.
Целостность набора частных атрибутов, восстановленных таким образом, не может быть гарантирована для корректного функционирования любых приложений, которые зависят от них, но ожидается, что это будет не лучше и не хуже, чем влияние хранения экземпляров с частными атрибутами на любом 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.
Специальные требования для преобразования других экземпляров:
Три сервиса DIMSE-C используются при конструировании SOP классов сервисного класса Query/Retrieve. Используются следующие операции DIMSE-C:
SCP некоторых SOP классов сервисного класса Query/Retrieve могут обладать способностью обрабатывать запросы с использованием операции C-FIND, как описано в PS3.7. Операция C-FIND — это механизм, с помощью которого выполняются запросы. Совпадения с ключами, присутствующими в идентификаторе, возвращаются в ответах C-FIND.
SOP Class UID идентифицирует информационную модель Query/Retrieve, по которой выполняется C-FIND. Поддержка SOP Class UID подразумевается Abstract Syntax UID контекста представления (Presentation Context), используемого данной операцией C-FIND.
Атрибут Priority определяет запрошенный приоритет операции C-FIND по отношению к другим операциям DIMSE, выполняемым тем же SCP.
Обработка запросов приоритета не требуется от SCP. Поддерживает ли SCP обработку приоритета и значение различных уровней приоритета, должно быть указано в заявлении о соответствии SCP.
Как запрос, так и ответ 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-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-FIND не должен содержать атрибуты, которых не было в запросе или не указано в данном разделе.
Идентификатор в ответе C-FIND должен содержать:
Ключевые атрибуты со значениями, соответствующими ключевым атрибутам, содержащимся в идентификаторе запроса.
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.
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.
Требование о том, что неподдерживаемые необязательные ключи, присутствующие в идентификаторе запроса, не должны включаться в идентификатор ответа, указано в Разделе C.2.2.1.3.
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.
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".
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.
Тот факт, что значение ключевого атрибута неизвестно 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).
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
Некоторые коды статуса 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.
В данном разделе рассматриваются как базовое, так и расширенное поведение SCU C-FIND.
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.
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.
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:
Может быть согласовано более одной опции.
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.
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.
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.
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.
Непреобразованные экземпляры, например, для других модальностей, таких как Ultrasound, будут выглядеть одинаково независимо от представления.
Реализации могут применять оптимизацию производительности, такую как предварительное вычисление или кэширование потенциальной информации, по которой могут выполняться запросы CLASSIC и ENHANCED, чтобы минимизировать значительные задержки между запросом и ответом, вызванные преобразованием «по требованию», но SCU может потребоваться учитывать возможность задержки ответа при настройке тайм-аутов и т.д.
В данном разделе рассматриваются как базовое, так и расширенное поведение SCP C-FIND.
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.
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).
Начиная с верхнего уровня в информационной модели Query/Retrieve и продолжая до достижения уровня, указанного в запросе C-FIND, следующие процедуры используются для генерации совпадений:
Если текущий уровень является уровнем, указанным в запросе C-FIND, то строки сопоставления ключей, содержащиеся в идентификаторе запроса C-FIND, сопоставляются со значениями ключевых атрибутов для каждой сущности на текущем уровне. Для каждой сущности, атрибуты которой соответствуют всем указанным строкам сопоставления, конструируется идентификатор. Этот идентификатор должен содержать все уникальные ключи на более высоких уровнях и все значения атрибутов для этой сущности, соответствующие указанным в запросе C-FIND. Возвращается ответ для каждого такого идентификатора. Если нет совпадающих ключей, то совпадений нет — возвращается ответ со статусом Success и без идентификатора.
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.
В противном случае совпадений нет; возвращается ответ со статусом Success.
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:
Может быть согласовано более одной опции.
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.
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:
Строки сопоставления ключей, содержащиеся в идентификаторе запроса C-FIND, сопоставляются со значениями ключевых атрибутов для каждой сущности на текущем уровне.
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).
Если текущий уровень является уровнем, указанным в запросе C-FIND, то для каждой совпадающей сущности (совпадающая сущность — это та, атрибуты которой соответствуют всем указанным строкам сопоставления в ключевых атрибутах) конструируется идентификатор. Этот идентификатор должен содержать все атрибуты, сгенерированные данной процедурой на более высоких уровнях на этом пути рекурсии, и все значения ключевых атрибутов для этой сущности, соответствующие указанным в запросе C-FIND.
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.
Otherwise, if there are no matches, return a response with status equal to Success and no Identifier.
Описанное выше определяет рекурсивную процедуру. Она может рекурсировать несколько раз при движении вниз по иерархическим уровням, и на каждом уровне она может рекурсировать несколько раз (по одному разу для каждой совпадающей сущности). Это может привести к генерации большого количества идентификаторов.
Не требуется, чтобы описанная выше процедура использовалась для генерации совпадений. Ожидается, что реализации будут использовать различные алгоритмы для выполнения поиска в базах данных. Для заданного запроса набор совпадений должен быть эквивалентен тому, который был бы сгенерирован описанной выше процедурой.
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.
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.
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.
Непреобразованные экземпляры, например, для других модальностей, таких как Ultrasound, будут выглядеть одинаково независимо от представления.
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).
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.
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.
Получатель перемещения (Move Destination) определяет заголовок прикладной сущности (Application Entity Title) получателя подопераций C-STORE.
Запрос C-MOVE должен содержать идентификатор (Identifier). Ответ C-MOVE должен условно содержать идентификатор, как требуется в Разделе C.4.2.1.4.2.
Идентификатор указан как U в определении примитива C-MOVE в PS3.7, но специализирован для использования с данным сервисом.
Идентификатор в запросе 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.
При нереляционном поведении может быть извлечено более одной сущности, если уровень Query/Retrieve равен IMAGE, SERIES или STUDY с использованием сопоставления по списку UID, но для Patient ID (0010,0020) может быть указано только одно значение при сопоставлении по одному значению.
Эмитент Patient ID (0010,0020) подразумевается; не существует возможности передать Issuer of Patient ID (0010,0021). При возможности неоднозначности значения Patient ID (0010,0020) следует использовать извлечение на уровне STUDY вместо извлечения на уровне PATIENT.
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.4-2 определяет конкретные значения кодов состояния, которые могут быть возвращены в ответе C-MOVE. Общие значения кодов состояния и поля, связанные со значениями кодов состояния, для службы C-MOVE DIMSE определены в PS3.7.
Таблица C.4-2. Значения состояния ответа C-MOVE
Некоторые коды состояния сбоя зависят от реализации.
Реализация SCP должна назначать конкретные коды состояния сбоя путём замены каждого символа 'x' шестнадцатеричной цифрой в диапазоне от 0 до F. Реализация SCP, желающая различать причины значения сбоя «Ошибка: невозможно обработать», должна назначить этим причинам конкретные значения кодов состояния в допустимом диапазоне, указанном в Таблице C.4-2.
Реализация SCU должна распознавать любой код состояния сбоя в диапазоне значений, указанном в Таблице C.4-2, как индикатор значения сбоя, указанного в таблице. От реализации SCU не требуется различать конкретные коды состояния в пределах допустимого диапазона.
Включение количества оставшихся подопераций является условным и зависит от состояния в ответе C-MOVE. Количество оставшихся подопераций указывает число оставшихся подопераций C-STORE, необходимых для завершения операции C-MOVE.
Включение количества завершённых подопераций является условным и зависит от состояния в ответе C-MOVE. Количество завершённых подопераций указывает число подопераций C-STORE, созданных запрошенной передачей, которые были успешно завершены.
Включение количества неудачных подопераций является условным и зависит от состояния в ответе C-MOVE. Количество неудачных подопераций указывает число подопераций C-STORE, созданных запрошенной передачей, которые завершились неудачно.
В этом разделе рассматривается как базовое, так и расширенное поведение SCU для C-MOVE.
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.
Расширенное поведение SCU должно быть согласовано во время установления ассоциации. Если параметр в рамках расширенного поведения не согласован в ходе переговоров, то в отношении этого параметра должно выполняться только базовое поведение SCU. Расширенное поведение SCU включает всё базовое поведение со следующими дополнительными параметрами:
Может быть согласовано более одного параметра.
Служба C-MOVE с реляционным получением снимает ограничение, согласно которому SCU должен предоставлять значения уникальных ключей для уровней выше уровня запроса/получения для идентификации сущности на уровне получения. Следовательно, идентификатор запроса C-MOVE может передавать:
все экземпляры составных объектов (Composite Object Instances), относящиеся к исследованию, путём указания только Study Instance UID (0020,000D)
все экземпляры составных объектов, относящиеся к серии, путём указания только Series Instance UID (0020,000E)
отдельные экземпляры составных объектов путём указания только списка SOP Instance UID (0008,0018)
Служба 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 предоставил все расширенные мультикадровые экземпляры (преобразованные из классических однокадровых экземпляров, если требуется), а также любые экземпляры, преобразованные для сохранения ссылочной целостности, и те, которые не требуют преобразования.
SCU может предполагать, что дублирующая информация не будет предоставлена. Например, если целая серия однокадровых экземпляров может быть преобразована в отдельную серию преобразованных экземпляров, C-MOVE на уровне STUDY не предоставит обе серии.
Информационная модель запроса не изменена, и те же уникальные ключи одинаково применимы к обоим представлениям, за исключением того, что значения для запросов на уровне SERIES и IMAGE будут различаться и будут зависеть от содержимого преобразованных экземпляров.
Query/Retrieve View по-прежнему требуется в идентификаторе запроса на уровне IMAGE или SERIES, даже если запрошенные уникальные ключи однозначны, и представление в определённом смысле «избыточно», поскольку преобразование, создавшее запрошенные экземпляры, могло ещё не быть выполнено. Не допускается указывать представление, несовместимое с запрошенными уникальными ключами.
В этом разделе рассматривается как базовое, так и расширенное поведение SCP для C-MOVE.
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.
Расширенное поведение SCP должно быть согласовано во время установления ассоциации. Если параметр в рамках расширенного поведения не согласован в ходе переговоров, то в отношении этого параметра должно выполняться только базовое поведение SCP. Расширенное поведение SCP включает всё базовое поведение со следующими дополнительными параметрами:
Может быть согласовано более одного параметра.
Служба C-MOVE с реляционным получением снимает ограничение, согласно которому SCP должен предоставлять значения уникальных ключей для уровней выше уровня запроса/получения для идентификации сущности на уровне получения. Следовательно, идентификатор запроса C-MOVE может указывать передачу:
всех экземпляров составных объектов, относящихся к исследованию, путём указания только Study Instance UID (0020,000D)
всех экземпляров составных объектов, относящихся к серии, путём указания только Series Instance UID (0020,000E)
отдельных экземпляров составных объектов путём указания только списка SOP Instance UID (0008,0018)
Если 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 хранения.
SCP не будет отправлять дублирующую информацию SCP C-STORE. Например, если целая серия однокадровых экземпляров может быть преобразована в отдельную серию преобразованных экземпляров, C-MOVE на уровне STUDY не отправит обе серии.
SCP C-STORE должен поддерживать необходимые SOP Class для преобразованных экземпляров, в противном случае подоперации C-STORE завершатся неудачно обычным образом, и это будет отражено в ответах C-MOVE.
Информационная модель запроса не изменена, и те же уникальные, обязательные и необязательные ключи одинаково применимы к обоим представлениям, за исключением того, что значения для запросов на уровне SERIES и IMAGE будут различаться и будут зависеть от содержимого преобразованных экземпляров.
Query/Retrieve View по-прежнему требуется в идентификаторе запроса на уровне IMAGE или SERIES, даже если запрошенные уникальные ключи однозначны.
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.
SOP Class UID идентифицирует информационную модель запроса/получения, по которой выполняется C-GET. Поддержка SOP Class UID подразумевается Abstract Syntax UID контекста представления, используемого этой операцией C-GET.
Атрибут приоритета (Priority) определяет запрошенный приоритет операции C-GET и соответствующих подопераций C-STORE по отношению к другим операциям DIMSE, выполняемым тем же SCP.
Обработка запросов с приоритетом не требуется от SCP. Поддерживает ли SCP обработку с приоритетом и значение различных уровней приоритета должны быть указаны в заявлении о соответствии SCP. Один и тот же приоритет должен использоваться для всех подопераций C-STORE.
Запрос C-GET должен содержать идентификатор. Ответ C-GET должен условно содержать идентификатор, как требуется в Разделе C.4.3.1.3.2.
Идентификатор указан как U в определении примитива C-GET в PS3.7, но специализирован для использования с данной службой.
Идентификатор в запросе 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 для информационной модели запроса/получения.
При нереляционном поведении может быть извлечено более одной сущности, если Query/Retrieve Level — IMAGE, SERIES или STUDY, с использованием сопоставления списка UID (List of UID matching), но для Patient ID (0010,0020) может быть указано только одно значение при сопоставлении по одному значению (Single Value Matching).
Эмитент Patient ID (0010,0020) подразумевается; не предусмотрена возможность отправки Issuer of Patient ID (0010,0021). При возможности неоднозначного толкования значения Patient ID (0010,0020) следует использовать получение на уровне STUDY вместо получения на уровне PATIENT.
Список 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.4-3 определяет конкретные значения кодов состояния, которые могут быть возвращены в ответе C-GET. Общие значения кодов состояния и поля, связанные со значениями кодов состояния, для службы C-GET DIMSE определены в PS3.7.
Таблица C.4-3. Значения состояния ответа C-GET
Некоторые коды состояния сбоя зависят от реализации.
Реализация SCP должна назначать конкретные коды состояния сбоя путём замены каждого символа 'x' шестнадцатеричной цифрой в диапазоне от 0 до F. Реализация SCP, желающая различать причины значения сбоя «Ошибка: невозможно обработать», должна назначить этим причинам конкретные значения кодов состояния в допустимом диапазоне, указанном в Таблице C.4-3.
Реализация SCU должна распознавать любой код состояния сбоя в диапазоне значений, указанном в Таблице C.4-3, как индикатор значения сбоя, указанного в таблице. От реализации SCU не требуется различать конкретные коды состояния в пределах допустимого диапазона.
Включение количества оставшихся подопераций является условным и зависит от состояния в ответе C-GET. Количество оставшихся подопераций указывает число оставшихся подопераций C-STORE, необходимых для завершения операции C-GET.
Включение количества завершённых подопераций является условным и зависит от состояния в ответе C-GET. Количество завершённых подопераций указывает число подопераций C-STORE, созданных запрошенной передачей, которые были успешно завершены.
Включение количества неудачных подопераций является условным и зависит от состояния в ответе C-GET. Количество неудачных подопераций указывает число подопераций C-STORE, созданных запрошенной передачей, которые завершились неудачно.
В этом разделе рассматривается как базовое, так и расширенное поведение SCU для C-GET.
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.
Расширенное поведение SCU должно быть согласовано во время установления ассоциации. Если параметр в рамках расширенного поведения не согласован в ходе переговоров, то в отношении этого параметра должно поддерживаться только базовое поведение SCU. Расширенное поведение SCU включает всё базовое поведение со следующими дополнительными параметрами:
Может быть согласовано более одного параметра.
Служба C-GET с реляционным получением снимает ограничение, согласно которому SCU должен предоставлять значения уникальных ключей для уровней выше уровня запроса/получения для идентификации сущности на уровне получения. Следовательно, идентификатор запроса C-GET может получать:
все экземпляры составных объектов, относящиеся к исследованию, путём указания Study Instance UID (0020,000D)
все экземпляры составных объектов, относящиеся к серии, путём указания Series Instance UID (0020,000E)
отдельные экземпляры составных объектов путём указания списка SOP Instance UID (0008,0018)
Служба 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 получил все расширенные мультикадровые экземпляры (преобразованные из классических однокадровых экземпляров, если требуется), а также любые экземпляры, преобразованные для сохранения ссылочной целостности, и те, которые не требуют преобразования.
SCU C-GET, выступающий в роли SCP C-STORE, может предполагать, что дублирующая информация не будет предоставлена. Например, если целая серия однокадровых экземпляров может быть преобразована в отдельную серию преобразованных экземпляров, C-GET на уровне STUDY не вернёт обе серии.
SCU C-GET, выступающий в роли SCP C-STORE, должен поддерживать необходимые SOP Class для преобразованных экземпляров, в противном случае подоперации C-STORE завершатся неудачно обычным образом, и это будет отражено в ответах C-GET.
Информационная модель запроса не изменена, и те же уникальные, обязательные и необязательные ключи одинаково применимы к обоим представлениям, за исключением того, что значения для запросов на уровне SERIES и IMAGE будут различаться и будут зависеть от содержимого преобразованных экземпляров.
Query/Retrieve View по-прежнему требуется в идентификаторе запроса на уровне IMAGE или SERIES, даже если запрошенные уникальные ключи однозначны, и представление в определённом смысле «избыточно», поскольку преобразование, создавшее запрошенные экземпляры, могло ещё не быть выполнено. Не допускается указывать представление, несовместимое с запрошенными уникальными ключами.
В этом разделе рассматривается как базовое, так и расширенное поведение SCP для C-GET.
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, или других факторов.
Расширенное поведение SCP должно быть согласовано во время установления ассоциации. Если параметр в рамках расширенного поведения не согласован в ходе переговоров, то в отношении этого параметра должно выполняться только базовое поведение SCP. Расширенное поведение SCP включает всё базовое поведение со следующими дополнительными параметрами:
Может быть согласовано более одного параметра.
Служба C-GET с реляционным получением снимает ограничение, согласно которому SCU должен предоставлять значения уникальных ключей для уровней выше уровня запроса/получения для идентификации сущности на уровне получения. Следовательно, идентификатор запроса C-GET может получать:
Если 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 хранения.
SCP C-GET, выступающий в роли SCU C-STORE, не будет отправлять дублирующую информацию SCU C-GET, выступающему в роли SCP C-STORE. Например, если целая серия однокадровых экземпляров может быть преобразована в отдельную серию преобразованных экземпляров, C-GET на уровне STUDY не отправит обе серии.
Информационная модель запроса не изменена, и те же уникальные, обязательные и необязательные ключи одинаково применимы к обоим представлениям, за исключением того, что значения для запросов на уровне SERIES и IMAGE будут различаться и будут зависеть от содержимого преобразованных экземпляров.
Query/Retrieve View по-прежнему требуется в идентификаторе запроса на уровне IMAGE или SERIES, даже если запрошенные уникальные ключи однозначны.
Установление ассоциации — первая фаза любого сеанса связи между равноправными прикладными сущностями 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, которые могут использоваться для получения.
Следующие правила согласования применяются к DICOM SOP Class и специализированным DICOM SOP Class сервисного класса запроса/получения, включающим операцию C-FIND.
Инициатор ассоциации (роль SCU запроса) должен передать в запросе A-ASSOCIATE:
Акцептор ассоциации (роль SCP запроса) запроса A-ASSOCIATE должен принять:
Расширенное согласование 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.
Субэлемент расширенного согласования 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
Субэлемент расширенного согласования 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
Следующие правила согласования применяются к DICOM SOP Class и специализированным DICOM SOP Class сервисного класса запроса/получения, включающим операцию C-MOVE.
Инициатор ассоциации (роль SCU получения) должен передать в запросе A-ASSOCIATE:
Акцептор ассоциации (роль SCP получения) запроса A-ASSOCIATE должен принять:
Расширенное согласование 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.
Субэлемент расширенного согласования 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
Субэлемент расширенного согласования 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
Когда 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 должен передать:
Поддержка индуцированной подоперации хранения, где SOP Class (в роли SCU получения) выступает как Storage SOP Class в роли SCP. См. Рисунок C.5-1. Для каждого поддерживаемого Storage SOP Class запрос A-ASSOCIATE содержит:
один субэлемент согласования выбора роли SCP/SCU с полем SCP-role, установленным для указания поддержки роли SCP. Согласование выбора роли SCP/SCU должно использоваться, как определено в PS3.7.
Это согласование не предъявляет никаких требований к флагу SCU в субэлементе согласования выбора роли SCP/SCU. Он может быть установлен, если инициатор ассоциации поддерживает Storage Service Class в роли SCU.
Акцептор ассоциации (роль SCP получения) в ответе A-ASSOCIATE должен передать:
Поддержку индуцированной подоперации хранения, где SOP Class (используя роль SCP получения) выступает как Storage SOP Class в роли SCU. См. Рисунок C.5-1. Для каждого поддерживаемого Storage SOP Class ответ A-ASSOCIATE содержит:
один субэлемент согласования выбора роли SCP/SCU с полем SCP-role, установленным для указания принятия акцептором ассоциации поддержки инициатором роли SCP. Согласование выбора роли SCP/SCU должно использоваться, как определено в PS3.7.
Согласование не предъявляет никаких требований к флагу SCU в субэлементе согласования выбора роли SCP/SCU. Он может быть установлен, если акцептор ассоциации принимает роль Storage SCP. Рисунок C.5-2 иллюстрирует пример согласования получения (C-GET).
Рисунок C.5-2 иллюстрирует пример согласования получения (C-GET).
Расширенное согласование SOP Class позволяет при установлении ассоциации связанным DICOM AE обмениваться прикладной информацией ассоциации, определённой конкретными SOP Class.
Это достигается путём определения поля Service-class-application-information. Поле Service-class-application-information используется для определения поддержки реляционного получения и альтернативных представлений для преобразования расширенных мультикадровых изображений.
Расширенное согласование для SOP Class на основе служб получения, включающих операции C-GET, идентично согласованию, определённому для C-MOVE, которое определено в Разделе C.5.2.1 данного приложения.
Расширенное согласование для SOP Class Storage Service Class (для подоперации C-STORE) определено в Приложении B.
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.
Использование слова «Images» (изображения) вместо «Composite Object Instances» (составные экземпляры объекта) является историческим для обеспечения обратной совместимости с предыдущими редакциями стандарта. Не следует считать, что составные экземпляры объекта, не являющиеся изображениями, не включены на уровень, обозначаемый значением IMAGE.
Информационная модель Query/Retrieve с корнем Patient может быть представлена диаграммой «сущность-связь», показанной на Рисунке C.6-1.
Таблица C.6-1 определяет атрибуты на уровне запроса/получения Patient информационной модели Query/Retrieve с корнем Patient.
Описание атрибутов этой информационной модели содержится в Разделе C.3 данной части.
Хотя Patient ID может не быть глобально уникальным, Study Instance UID является глобально уникальным, что гарантирует отсутствие ошибочной идентификации двух исследований. Область уникальности Patient ID может быть указана с помощью атрибута Issuer of Patient ID (0010,0021).
Ранее атрибут Other Patient IDs (0010,1000) входил в эту таблицу. Этот атрибут был удалён. См. PS3.4 2017a.
Таблица C.6-2 определяет ключи на информационном уровне Study информационной модели Query/Retrieve с корнем Patient.
Описание атрибутов этой информационной модели содержится в Разделе C.3 данной части.
Хотя Patient ID может не быть глобально уникальным, Study Instance UID является глобально уникальным, что гарантирует отсутствие ошибочной идентификации двух исследований. Область уникальности Patient ID может быть указана с помощью атрибута Issuer of Patient ID (0010,0021).
Таблица C.6-2a. Макрос расширенных ключей Code Value с дополнительными ключами
Таблица C.6-2b. Макрос базовых ключей Code Value с дополнительными ключами
Таблица C.6-2. Ключи уровня исследования для информационной модели запроса/получения корня пациента
Таблица C.6-3 определяет ключи на уровне информации о серии информационной модели запроса/получения корня пациента.
Таблица C.6-4 определяет ключи на уровне информации о составном объектном экземпляре информационной модели запроса/получения корня пациента.
Таблица C.6-4. Ключи уровня составного объектного экземпляра для информационной модели запроса/получения корня пациента
|
>>Include Table C.6-2a “Enhanced Code Value Keys Macro with Optional Keys” |
||
|
>Include Table C.6-2a “Enhanced Code Value Keys Macro with Optional Keys” |
||
|
Все остальные атрибуты на уровне составного объектного экземпляра |
||
SOP Class UID (0008,0016) является необязательным ключом, однако настоятельно рекомендуется, чтобы он всегда возвращался всеми SCP, если запрашивается сопоставление.
Concept Name Code Sequence (0040,A043) и Content Template Sequence (0040,A504) — необязательные ключи, полезные для идентификации экземпляров различных SOP-классов хранения структурированных отчётов. Настоятельно рекомендуется, чтобы SCP поддерживал эти ключи для запросов к таким экземплярам.
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.
Available Transfer Syntax UID (0008,3002) описывает один или несколько синтаксисов передачи (Transfer Syntaxes), которые SCP может гарантировать как поддерживаемые для получения SOP Instance. Это может, но не обязано, включать синтаксис передачи, в котором SCP сохранил экземпляр. Для всех перечисленных синтаксисов передачи перекодирование из сохранённой формы не должно сопровождаться потерями.
Этот атрибут является многозначным, и если присутствует более одного значения, SCU может интерпретировать синтаксисы передачи, перечисленные ранее, как предпочтительные для SCP по сравнению с перечисленными позднее. Например, порядок может отражать объём усилий, необходимых для преобразования из сохранённой формы, и первым может быть указана сохранённая форма.
Не существует требования включать каждый синтаксис передачи, в котором экземпляр может быть получен без потерь. Например, синтаксис передачи по умолчанию, как указано в Разделе 10.1 в PS3.5 , если он применим, может быть опущен, если он не является синтаксисом передачи, в котором экземпляр фактически сохранён.
Значение этого атрибута может быть полезно, например, для определения того, сохранён ли экземпляр в синтаксисе передачи с потерями, который не поддерживается SCU, и для которого распаковка или преобразование в другую форму сжатия повлекло бы потери и было бы нецелесообразным, что потребовало бы использования альтернативного представления (Alternate Representation).
Запрос 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).
Реализация может соответствовать одному из SOP-классов группы SOP-классов корня пациента (Patient Root SOP Class Group) в качестве SCU, SCP или обоих. Заявление о соответствии должно быть в формате, определённом в PS3.2.
Реализация, соответствующая одному из 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) при кодировании запросов и интерпретации ответов.
Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCU, должна поддерживать передачи в рамках информационной модели запроса/получения, описанной в Разделе C.6.1.1, с использованием поведения C-MOVE SCU, описанного в Разделе C.4.2.2.
Реализация, соответствующая одному из 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.
Реализация, соответствующая одному из 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 (если поддерживается) и перечислить атрибуты, к которым это применяется.
Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCP, должна поддерживать передачи в рамках информационной модели запроса/получения, описанной в Разделе C.6.1.1, с использованием поведения C-MOVE SCP, описанного в Разделе C.4.2.3.
Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCP и генерирующая передачи с помощью операции C-MOVE, должна указать в своём заявлении о соответствии SOP-классы сервисного класса хранения, для которых она будет поддерживать подоперации C-STORE, генерируемые C-MOVE.
Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCP, должна поддерживать получение данных в рамках информационной модели запроса/получения, описанной в Разделе C.6.1.1, с использованием поведения C-GET SCP, описанного в Разделе C.4.3.3.
Реализация, соответствующая одному из SOP-классов группы SOP-классов корня пациента в качестве SCP и генерирующая получение данных с помощью операции C-GET, должна указать в своём заявлении о соответствии SOP-классы сервисного класса хранения, для которых она будет поддерживать подоперации C-STORE, генерируемые C-GET.
SOP-классы в группе SOP-классов запроса корня пациента (Patient Root Query SOP Class Group) сервисного класса запроса/получения идентифицируют информационную модель запроса/получения корня пациента и поддерживаемые операции DIMSE-C. Стандартные SOP-классы перечислены в Таблице C.6.1.3-1.
В информационной модели запроса/получения корня исследования информация организована на трёх уровнях, соответствующих одному из трёх значений в элементе (0008,0052), показанных в Таблице C.6.2-1.
Использование слова "Images" вместо "Composite Object Instances" является историческим для обеспечения обратной совместимости с предыдущими редакциями стандарта. Это не следует понимать как означающее, что составные объектные экземпляры, не являющиеся изображениями, не включены на уровень, указываемый значением IMAGE.
Информационная модель запроса/получения корня исследования может быть представлена диаграммой «сущность-связь», показанной на Рисунке C.6-2.
Таблица C.6-5 определяет ключи на уровне информации об исследовании информационной модели запроса/получения корня исследования.
Описание атрибутов данной информационной модели содержится в Разделе C.3.
Хотя Patient ID может не быть глобально уникальным, Study Instance UID является глобально уникальным, что гарантирует отсутствие ошибочной идентификации двух исследований. Область уникальности Patient ID может быть указана с помощью Issuer of Patient ID (0010,0021).
Ранее в эту таблицу был включён Other Patient IDs (0010,1000). Этот атрибут был отозван (retired). См. PS3.4 2017a.
Таблица C.6-5. Ключи уровня исследования для информационной модели запроса/получения корня исследования
Атрибуты уровня серии информационной модели запроса/получения корня исследования совпадают с атрибутами уровня серии информационной модели запроса/получения корня пациента, описанными в Разделе C.6.1.1.4.
Атрибуты уровня составного объектного экземпляра информационной модели запроса/получения корня исследования совпадают с атрибутами уровня составного объектного экземпляра информационной модели запроса/получения корня пациента, описанными в Разделе C.6.1.1.5.
Запрос C-MOVE или C-GET может быть выполнен на любой уровень модели запроса/получения. Однако передача сохранённых SOP Instance всегда должна происходить на уровне составного объектного экземпляра. C-MOVE или C-GET, где уровень запроса/получения — это:
уровень STUDY указывает, что все составные объектные экземпляры, относящиеся к исследованию, должны быть переданы
уровень SERIES указывает, что все составные объектные экземпляры, относящиеся к серии, должны быть переданы
уровень IMAGE указывает, что выбранные отдельные составные объектные экземпляры должны быть переданы
Реализация может соответствовать одному из SOP-классов группы SOP-классов корня исследования (Study Root SOP Class Group) в качестве SCU, SCP или обоих. Заявление о соответствии должно быть в формате, определённом в PS3.2.
Реализация, соответствующая одному из 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) при кодировании запросов и интерпретации ответов.
Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования в качестве SCU, должна поддерживать передачи в рамках информационной модели запроса/получения, описанной в Разделе C.6.2.1, с использованием поведения C-MOVE SCU, описанного в Разделе C.4.2.2.
Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования в качестве SCU, должна поддерживать получение данных в рамках информационной модели запроса/получения, описанной в Разделе C.6.2.1, с использованием поведения C-GET SCU, описанного в Разделе C.4.3.2.
Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования в качестве SCU и генерирующая получение данных с помощью операции C-GET, должна указать в своём заявлении о соответствии SOP-классы сервисного класса хранения, для которых она будет поддерживать подоперации C-STORE, генерируемые C-GET.
Реализация, соответствующая одному из 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 (если поддерживается) и перечислить атрибуты, к которым это применяется.
Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования в качестве SCP, должна поддерживать передачи в рамках информационной модели запроса/получения, описанной в Разделе C.6.2.1, с использованием поведения C-MOVE SCP, описанного в Разделе C.4.2.3.
Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования в качестве SCP и генерирующая передачи с помощью операции C-MOVE, должна указать в своём заявлении о соответствии SOP-классы сервисного класса хранения, для которых она будет поддерживать подоперации C-STORE, генерируемые C-MOVE.
Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования в качестве SCP, должна поддерживать получение данных в рамках информационной модели запроса/получения, описанной в Разделе C.6.2.1, с использованием поведения C-GET SCP, описанного в Разделе C.4.3.3.
Реализация, соответствующая одному из SOP-классов группы SOP-классов корня исследования в качестве SCP и генерирующая получение данных с помощью операции C-GET, должна указать в своём заявлении о соответствии SOP-классы сервисного класса хранения, для которых она будет поддерживать подоперации C-STORE, генерируемые C-GET.
SOP-классы в группе SOP-классов корня исследования сервисного класса запроса/получения идентифицируют информационную модель запроса/получения корня исследования и поддерживаемые операции DIMSE-C. Стандартные SOP-классы перечислены в Таблице C.6.2.3-1.
Отозвано (Retired). См. PS3.4-2004.
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.
SOP-класс запроса к репозиторию использует информационную модель запроса/получения корня исследования, указанную в Разделе C.6.2.1, но определяет дополнительные ключевые атрибуты. Эти ключевые атрибуты, как и те, что определены в Разделе C.3.4, не указаны в составных IOD PS3.3, но представляют информацию, которая может использоваться системой репозитория для управления сохранёнными SOP Instance. Таблица C.6.4.1-1 определяет дополнительные ключевые атрибуты.
Таблица C.6.4.1-1. Дополнительные ключи для запроса к репозиторию
|
Специфичный для реализации уникальный идентификатор записи сущности. Этот атрибут поддерживается только с универсальным сопоставлением (Universal Matching). См. Раздел C.6.4.1.1. |
|||
|
Признак того, что сущность на уровне запроса/получения, указанном в идентификаторе C-FIND, и её набор составных объектных экземпляров удалены из оперативного использования, связанного с обслуживанием пациентов. См. Раздел C.6.4.1.2. |
|||
|
Причина, по которой сущность на уровне запроса/получения, указанном в идентификаторе C-FIND, была удалена из оперативного использования. В эту последовательность может быть включено ноль или один элемент. |
|||
|
>Include Table C.6-2b “Basic Code Value Keys Macro with Optional Keys” |
|||
|
Описание доступа к наборам сохранённых SOP Instance по протоколу, не относящемуся к DICOM. Этот атрибут определён только на уровнях исследования и серии. Этот атрибут поддерживается только с универсальным сопоставлением, т.е. если присутствует в идентификаторе запроса, он имеет нулевую длину или содержит только элемент нулевой длины. См. Раздел C.6.4.1.3. См. Раздел C.6.4.5.5 для дополнительных требований к SCP. В этой последовательности в идентификаторе ответа может быть включено ноль или один элемент. |
|||
|
Базовый URI для доступа к SOP Instance через протокол, не относящийся к DICOM. |
|||
|
URI доступа к папке, содержащей все SOP Instance для данного исследования или серии. |
|||
|
URI доступа к файлу-контейнеру, содержащему все SOP Instance для данного исследования или серии. |
|||
|
См. Раздел P.1.2 «Форматы файлов-контейнеров» в PS3.3 для определений терминов. Обязательно в идентификаторе ответа, если присутствует File Access URI (0008,0409). |
|||
|
Описание доступа по протоколу, не относящемуся к DICOM, к сохранённой SOP Instance. Этот атрибут определён только на уровне составного экземпляра (Composite Instance). Этот атрибут поддерживается только с универсальным сопоставлением (Universal Matching), т.е. если присутствует в идентификаторе запроса, он имеет нулевую длину или содержит только элемент нулевой длины. См. Раздел C.6.4.1.3. См. Раздел C.6.4.5.5 для дополнительных требований к SCP. В эту последовательность в идентификаторе ответа может быть включено ноль или более элементов. |
|||
|
URI доступа для файла, содержащего SOP Instance. Обязательно в идентификаторе ответа, если File Access Sequence (0008,041A) содержит элемент. |
|||
|
См. Раздел P.1.2 «Форматы файлов-контейнеров» в PS3.3 для определений терминов, не описанных здесь. Обязательно в идентификаторе ответа, если присутствует File Access URI (0008,0409). |
|||
|
Имя файла внутри файла-контейнера, содержащего файл с SOP Instance. Обязательно в идентификаторе ответа, если Container File Type (0008,040A) имеет значение ZIP, TAR или TARGZIP. |
|||
|
Байтовое смещение (с отсчётом от нуля) внутри файла-контейнера для начала файла SOP Instance. Обязательно в идентификаторе ответа, если Container File Type (0008,040A) имеет значение BLOB, может присутствовать в остальных случаях. |
|||
|
Длина файла SOP Instance внутри файла-контейнера. Обязательно в идентификаторе ответа, если Container File Type (0008,040A) имеет значение BLOB, может присутствовать в остальных случаях. |
|||
|
Transfer Syntax SOP Instance, закодированной в формате DICOM File Format. Равна Transfer Syntax UID (0002,0010) в заголовке File Meta Information. Обязательно в идентификаторе ответа, если File Access Sequence (0008,041A) содержит элемент. |
|||
|
Описывает примерные коэффициенты сжатия с потерями, которые были применены к данному изображению. |
|||
|
Алгоритм, используемый для генерации кода аутентификации сообщения (Message Authentication Code). См. Раздел C.12.1.1.3.1.2 «Подпись» в PS3.3 для определённых терминов. Обязательно в идентификаторе ответа, если присутствует MAC (0400,0404). |
|||
|
Код аутентификации сообщения (Message Authentication Code), вычисленный по файлу сохранённого экземпляра для проверки целостности файла. |
|||
|
Все неблочные (non-bulk) атрибуты данных на уровне запроса/получения, управляемые SCP. См. Раздел C.6.4.1.4. См. Раздел C.6.4.5.5 для дополнительных требований к SCP. Этот атрибут поддерживается только с универсальным сопоставлением (Universal Matching), т.е. если присутствует в идентификаторе запроса, он имеет нулевую длину или содержит только элемент нулевой длины. В эту последовательность в идентификаторе ответа может быть включён ноль или один элемент. |
|||
|
В идентификаторе ответа может присутствовать несколько атрибутов. |
|||
|
Неблочные (non-bulk) атрибуты данных на уровне запроса/получения, управляемые SCP, значения которых отличаются от значений, содержащихся в сохранённых файлах SOP Instance. См. Раздел C.6.4.1.4. См. Раздел C.6.4.5.5 для дополнительных требований к SCP. Этот атрибут поддерживается только с универсальным сопоставлением (Universal Matching), т.е. если присутствует в идентификаторе запроса, он имеет нулевую длину или содержит только элемент нулевой длины. В эту последовательность в идентификаторе ответа может быть включён ноль или один элемент. |
|||
|
В идентификаторе ответа может присутствовать несколько атрибутов. |
|||
Символ "-" в столбце Type используется для обозначения атрибутов, находящихся внутри последовательности (Sequence), которая определена только с универсальным сопоставлением (Universal Matching). Следовательно, эти атрибуты не будут присутствовать в идентификаторе запроса; поэтому они не являются ключевыми атрибутами (Key Attributes) для сопоставления, и столбец Type к ним не применяется. Если SCP поддерживает атрибут последовательности, и он запрошен SCU, SCP возвращает эти атрибуты "-" в соответствии с их описанием атрибута.
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), действительно ли это значение всё ещё пригодно для определения следующей возвращаемой записи.
Структура, содержимое и метод упорядочивания значений Record Key (0008,041B) являются специфичными для реализации SCP и непрозрачны (opaque) для SCU, т.е. SCU не должен пытаться анализировать эти значения на компоненты или семантику. Значения могут быть постоянными или могут конструироваться динамически во время обработки запроса. Только SCP может определить по значению одного Record Key (0008,041B), какая запись должна быть возвращена следующей. Например, SCP может использовать зашифрованные представления внутреннего первичного ключа базы данных в качестве Record Key (0008,041B), и для SCU они могут выглядеть как случайные неупорядоченные значения.
Цель требований к упорядочиванию и использованию Record Key (0008,041B) — позволить SCU получить полный перечень, соответствующий ключевым атрибутам (Key Attributes), в последовательности запросов. См. Раздел YYYY.2.2 «Record Key and Continuation» в PS3.17.
Атрибут Removed from Operational Use (0008,0405) определён на уровнях запроса исследования (Study), серии (Series) и экземпляра (Instance).
Перечислимые значения:
Значение Y указывает, что исследование (Study), серия (Series) или экземпляр (Instance) были удалены из оперативного использования, связанного с обслуживанием пациентов, хотя они могут сохраняться в системе репозитория по другим причинам (например, для аудита лучевой нагрузки пациента). На уровне исследования и серии этот атрибут указывает, было ли всё исследование или вся серия удалена из оперативного использования. Значение Y на уровне исследования имеет приоритет над любым значением, указанным для подчинённых серий и экземпляров, а значение Y на уровне серии имеет приоритет над любым значением, указанным для подчинённых экземпляров.
Хотя атрибут определён на уровнях исследования, серии и экземпляра, SCP может не поддерживать этот атрибут на некоторых или на всех этих уровнях. Например, SCP может управлять этим атрибутом только на уровне экземпляра и не обязан выводить значение для уровня серии или исследования.
Значение «оперативного использования, связанного с обслуживанием пациентов» зависит от реализации или учреждения, но обычно включает диагностическое, клиническое и терапевтическое использование, а также административное использование, необходимое для оказания помощи (например, авторизация страхования).
Исследования, серии или экземпляры могут быть помечены как удалённые из оперативного использования действиями, связанными с обработкой определённых 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.
Семантика атрибута Removed from Operational Use (0008,0405) позволяет SCP включать такие сущности в ответ на запрос к репозиторию без ограничений. SCP может исключать сущности, помеченные как удалённые из оперативного использования, из ответов C-FIND других классов SOP Query/Retrieve (например, см. [IHE RAD TF-2] Раздел 4.66.4.1.3.1 «Доступ к отклонённым экземплярам»).
Атрибут Removed from Operational Use (0008,0405) не зависит от Instance Availability (0008,0056). Составной экземпляр может быть удалён из оперативного использования, но всё ещё быть доступным с оперативностью, указанной Instance Availability (0008,0056). И наоборот, экземпляр может не быть удалённым из оперативного использования, но быть «UNAVAILABLE» (недоступным) для получения.
Если SCP сохраняет записи об удалённых исследованиях, сериях или экземплярах, даже если сами экземпляры физически удалены, он может включать эти сущности в ответ C-FIND с соответствующим значением Reason for Removal Code Sequence (0008,0406). Такие экземпляры могут иметь значение Instance Availability (0008,0056) «UNAVAILABLE» (см. Раздел C.4.1.1.3.2).
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).
См. Раздел YYYY.3.4 «Access Mechanisms For Repository Data» в PS3.17
Понятие «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) на уровне исследования.
SCP может хранить SOP Instance на нескольких устройствах хранения (например, на быстрых носителях краткосрочного хранения и более медленных носителях долгосрочного хранения) или в разных Transfer Syntax. Поэтому SOP Instance может быть доступна через протокол, не относящийся к DICOM, по нескольким URI.
Если File Access URI (0008,0409) для SOP Instance является URI относительной ссылки пути, SCU должен получить Stored Instance Base URI (0008,0407) из запросов на иерархически вышестоящих уровнях STUDY и SERIES. Т.е. запросы на уровне исследования и серии должны были включать запрос File Set Access Sequence (0008,0419).
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.
Ожидается, что SOP Instance, доступ к которым осуществляется через протоколы DICOM, имеют текущие значения во всех атрибутах.
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.4.1.1.3.1, идентификатор запроса к репозиторию может содержать атрибуты, показанные в Таблице C.6.4.2-1, чтобы SCU мог запросить определённое содержимое ответа C-FIND.
Таблица C.6.4.2-1. Дополнительные атрибуты идентификатора запроса Repository Query
|
Идентификатор сущности, который был возвращён как значение Record Key (0008,041B) в предыдущем запросе. Сущности, возвращённые для текущего запроса, будут начинаться с первой соответствующей записи с ключом записи, следующим после данного ключа записи. См. Раздел C.6.4.5.3 для требований к обработке на стороне SCP. |
||
|
Максимальное количество сопоставленных сущностей, возвращаемых для данного запроса. См. Раздел C.6.4.5.2 для требований к обработке на стороне SCP. |
Класс 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.4.1.2, SCU должен интерпретировать ответ со статусом B001 «Warning» (Предупреждение) как указывающий на окончание отложенных (Pending) ответов и как признак того, что доступны дополнительные ответы, но SCP больше не обрабатывает данный запрос в этой операции C-FIND.
Класс SOP Repository Query добавляет следующие поведения как к базовому, так и к расширенному поведению SCP, описанному в Разделе C.4.1.3.
SCP должен возвращать ответы C-FIND в соответствии с упорядочиванием значений Record Key (0008,041B), если этот атрибут включён в идентификатор запроса.
Если Record Key (0008,041B) не запрошен, требования к упорядочиванию отсутствуют, и SCU не сможет issued последующий запрос с Prior Record Key (0008,041C).
Структура, содержимое и метод упорядочивания значений Record Key (0008,041B) являются специфичными для реализации SCP и непрозрачны для SCU (см. Раздел C.6.4.1.1).
SCP должен отправить не более указанного SCU в атрибуте Maximum Number of Records (0008,0429) в идентификаторе запроса к репозиторию количества отложенных ответов (т.е. возвращённых сопоставленных записей). Кроме того, SCP может ограничить количество ответов в транзакции запроса до собственного определяемого реализацией предела ресурсов. Если достигнут любой из этих пределов и имеются дополнительные записи, удовлетворяющие сопоставлению ключевых атрибутов, SCP должен отправить итоговое значение статуса B001 «Warning» (Предупреждение).
Если 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, зависит от реализации.
Например, сущность, добавленная после времени начального запроса, может получить Record Key (0008,041B), предшествующий Record Key (0008,041B), уже отправленному в ответе C-FIND; эта сущность не будет возвращена в наборе транзакций запроса. Однако добавленная сущность, чей Record Key (0008,041B) находится после последнего отправленного Record Key (0008,041B), может как быть включена, так и не быть включена в набор транзакций запроса; поскольку она была добавлена после начальной транзакции запроса, реализация определяет, включать ли такое изменение в ответы.
SCP не должен предполагать, что последний отправленный им Record Key (0008,041B) будет использован как Prior Record Key (0008,041C) в последующей транзакции. Условия ошибки могут потребовать от SCU возобновить работу с более раннего значения.
Не требуется, чтобы ключевые атрибуты в идентификаторе запроса были идентичны атрибутам в предыдущей транзакции запроса к репозиторию, даже несмотря на то, что наличие Prior Record Key (0008,041C) подразумевает продолжение предыдущей транзакции. Каждая транзакция запроса к репозиторию является независимой. SCP не должен сохранять информацию о состоянии между транзакциями запроса к репозиторию, хотя он может включать информацию о состоянии в Record Key (0008,041B).
Если SCP поддерживает Removed from Operational Use (0008,0405) (см. Раздел C.6.4.1.2) как ключевой атрибут, ответы на запрос должны включать все сущности независимо от значения этого атрибута, если только SCU явно не включил сопоставление по этому атрибуту в запрос C-FIND и SCP поддерживает сопоставление по этому атрибуту.
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 для дальнейших разъяснений.
Реализация может соответствовать классу SOP Repository Query как SCU, SCP или оба. Заявление о соответствии (Conformance Statement) должно быть в формате, определённом в PS3.2.
Реализация, соответствующая классу 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).
Реализация, соответствующая классу 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).
Предоставляет ли она ответы, включающие сущности из нескольких репозиториев (федерация), и как она обрабатывает различия в поддержке сопоставления атрибутов между этими репозиториями при формировании ответов.
UID для класса SOP Repository Query приведён в Таблице C.6.4.7-1.
Выведен из употребления. См. PS3.4-2004.
Выведен из употребления. См. PS3.4-2004.
Это приложение определяет классы SOP этапа процедуры (Procedure Step).
Ранее в этом приложении определялся класс службы управления исследованием (Study Management Service Class), который был выведен из употребления. См. PS3.4-2004.
Выведено из употребления. См. PS3.4-2004.
Выведено из употребления. См. PS3.4-2004.
Выведено из употребления. См. PS3.4-2004.
Выведено из употребления. См. PS3.4-2004.
Информация о состоянии, относящаяся к 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-4 определяет допустимые переходы состояний для Performed Procedure Steps. Для каждого из определённых выше состояний указывается допустимое состояние, возникающее в результате наступления событий. Эти переходы состояний управляются классом SOP Modality Performed Procedure Step.
Выведено из употребления. См. PS3.4-2011.
Выведено из употребления. См. PS3.4-2011.
Службы прикладного уровня, рассматриваемые в данном определении класса службы (Service Class Definition), задаются через следующие отдельные классы SOP:
Каждый класс SOP работает с подмножеством IOD Modality Performed Procedure Step и определяет атрибуты, операции, уведомления и поведение, применимые к классу SOP. Соответствие прикладных сущностей (Application Entities) определяется путём выбора одного или нескольких классов SOP. Для каждого класса SOP требования соответствия определяются с точки зрения поставщика класса службы (Service Class Provider, SCP) и пользователя класса службы (Service Class User, SCU).
Установление ассоциации является первой фазой любого сеанса связи между равноправными прикладными сущностями DICOM AE. Процедура согласования ассоциации, указанная в PS3.7, должна использоваться для согласования поддерживаемых классов SOP.
Поддержка согласования выбора роли SCP/SCU (SCP/SCU Role Selection Negotiation) является обязательной. Расширенное согласование класса SOP (SOP Class Extended Negotiation) не должно поддерживаться.
Выведен из употребления. См. PS3.4-2004.
Выведен из употребления. См. PS3.4-2004.
Выведен из употребления. См. PS3.4-2004.
Выведено из употребления. См. PS3.4-2004.
Службы DIMSE, показанные в Таблице F.7.1-1, применимы к IOD Modality Performed Procedure Step в рамках класса SOP Modality Performed Procedure Step.
Службы и протоколы DIMSE специфицированы в PS3.7
Прикладная сущность, заявляющая о соответствии этому классу SOP как SCU, должна иметь право вызывать следующие операции, а прикладная сущность, заявляющая о соответствии как SCP, должна быть способна предоставлять следующие операции.
Эта операция позволяет 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.
Прикладная сущность, заявляющая о соответствии этому классу 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
Таблица F.7.2-1b. Макрос Simple Code Value для Modality Performed Procedure Step без N-SET
Таблица F.7.2-1c. Макрос Enhanced Code Value для Modality Performed Procedure Step с N-SET, обязательное значение (Mandatory Meaning)
Таблица F.7.2-1d. Макрос Simple Code Value для Modality Performed Procedure Step с N-SET, обязательное значение (Mandatory Meaning)
Таблица F.7.2-1e. Макрос Enhanced Code Value для Modality Performed Procedure Step с N-SET, необязательное значение (Optional Meaning)
Таблица F.7.2-1f. Макрос Simple Code Value для Modality Performed Procedure Step с N-SET, необязательное значение (Optional Meaning)
Таблица F.7.2-1. Атрибуты N-CREATE, N-SET и Final State класса SOP Modality Performed Procedure Step
|
(Обязательно, если используется расширенный или заменяющий набор символов) |
(Обязательно, если расширенный или заменяющий набор символов используется в атрибуте, который устанавливается) |
|||
|
Связь выполненного этапа процедуры (Performed Procedure Step Relationship) |
||||
|
Обязательно, если Universal Entity ID (0040,0032) отсутствует; может присутствовать в остальных случаях |
||||
|
Обязательно, если Local Namespace Entity ID (0040,0031) отсутствует; может присутствовать в остальных случаях. |
||||
|
Обязательно, если присутствует Universal Entity ID (0040,0032). |
||||
|
Обязательно, если Universal Entity ID (0040,0032) отсутствует; может присутствовать в остальных случаях |
||||
|
Обязательно, если Local Namespace Entity ID (0040,0031) отсутствует; может присутствовать в остальных случаях. |
||||
|
Обязательно, если присутствует Universal Entity ID (0040,0032). |
||||
|
Обязательно, если Universal Entity ID (0040,0032) отсутствует; может присутствовать в остальных случаях |
||||
|
Обязательно, если Local Namespace Entity ID (0040,0031) отсутствует; может присутствовать в остальных случаях. |
||||
|
Обязательно, если присутствует Universal Entity ID (0040,0032). |
||||
|
>>Include Table F.7.2-1a “Modality Performed Procedure Step Enhanced Code Value Macro with no N-SET” |
||||
|
>>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 |
||||
|
Обязательно, если присутствует Universal Entity ID (0040,0032). |
||||
|
>All other Attributes of the Issuer of Patient ID Qualifiers Sequence |
||||
|
>>All other Attributes of the Issuer of Patient ID Qualifiers Sequence |
||||
|
>>Include Table F.7.2-1a “Modality Performed Procedure Step Enhanced Code Value Macro with no N-SET” |
||||
|
>>Include Table F.7.2-1a “Modality Performed Procedure Step Enhanced Code Value Macro with no N-SET” |
||||
|
Required if Sex Parameters for Clinical Use Category Code Sequence (0010,0046) is (131232, DCM, "Specified"). May be present otherwise. |
||||
|
Required if Sex Parameters for Clinical Use Category Code Sequence (0010,0046) is (131232, DCM, "Specified"). May be present otherwise. |
||||
|
>>Include Table F.7.2-1a “Modality Performed Procedure Step Enhanced Code Value Macro with no N-SET” |
||||
|
Обязательно, если Universal Entity ID (0040,0032) отсутствует; может присутствовать в остальных случаях |
||||
|
Обязательно, если Local Namespace Entity ID (0040,0031) отсутствует; может присутствовать в остальных случаях. |
||||
|
Обязательно, если присутствует Universal Entity ID (0040,0032). |
||||
|
Обязательно, если Universal Entity ID (0040,0032) отсутствует; может присутствовать в остальных случаях |
||||
|
Обязательно, если Local Namespace Entity ID (0040,0031) отсутствует; может присутствовать в остальных случаях. |
||||
|
Обязательно, если присутствует Universal Entity ID (0040,0032). |
||||
|
Информация о выполненном этапе процедуры (Performed Procedure Step Information) |
||||
|
>Include Table F.7.2-1e “Modality Performed Procedure Step Enhanced Code Value Macro with N-SET, Optional Meaning” |
||||
|
>Include Table F.7.2-1c “Modality Performed Procedure Step Enhanced Code Value Macro with N-SET, Mandatory Meaning” |
||||
|
Performed Procedure Step Discontinuation Reason Code Sequence |
||||
|
>Include Table F.7.2-1c “Modality Performed Procedure Step Enhanced Code Value Macro with N-SET, Mandatory Meaning” |
||||
|
>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 |
||||
|
Код учёта и управления материалами (Billing and Material Management Code) |
||||
|
All Attributes of the Billing and Material Management Code Module |
||||
Требование для конечного состояния — это то, которое применяется в момент, когда Performed Procedure Step Status (0040,0252) устанавливается (N-SET) в значение COMPLETED или DISCONTINUED, как описано в Разделе F.7.2.2.2. Оно описывается только в том случае, если оно отличается от требования SCP для N-CREATE.
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.
Атрибуты (0040,1006) Placer Order Number/Procedure и (0040,1007) Filler Order Number/Procedure были ранее определены в DICOM. Они были выведены из употребления (см. PS3.3-1998).
Атрибуты (0040,2006) и (0040,2007) были ранее определены в DICOM. Они были выведены из употребления (см. PS3.3-1998).
Только те атрибуты, которые указаны в SOP Instance при N-CREATE, могут впоследствии быть обновлены посредством N-SET. Если SCU желает использовать PPS Discontinuation Reason Code Sequence (0040,0281), он должен создать этот атрибут (нулевой длины) во время N-CREATE.
Модуль Radiation Dose был ранее определён в DICOM. Он был выведен из употребления (см. PS3.3-2017c).
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».
Предполагается (но не требуется), что SCU (модальность) получил Study Instance UID в рамках Basic Worklist Management SOP Class.
Если 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).
Если у 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).
Операция 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), когда несколько этапов процедуры выполняются на разных устройствах.
Специфические коды статусов отсутствуют. См. PS3.7 для кодов статусов ответа.
Эта операция позволяет SCU устанавливать значения атрибутов экземпляра класса Modality Performed Procedure Step SOP Class и предоставлять информацию о конкретном реальном этапе процедуры модальности (Modality Performed Procedure Step), находящемся под управлением SCU. Эта операция должна вызываться через DIMSE-сервис N-SET.
Прикладной элемент (Application Entity), заявляющий о соответствии данному SOP Class как SCU, может выбрать для изменения подмножество атрибутов, поддерживаемых SCP. Прикладной элемент, заявляющий о соответствии данному SOP Class как SCP, должен поддерживать подмножество атрибутов Modality Performed Procedure Step, указанное в Таблице F.7.2-1.
Набор символов, используемый для значений атрибутов, обновляемых с помощью N-SET, должен совпадать с набором, указанным в примитиве запроса N-CREATE.
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) соответственно.
Предполагается, что завершённый или прекращённый объект Modality Performed Procedure Step будет содержать полный список всех Image и Non-Image Composite SOP Instances, которые были созданы.
Различие между списками изображений (images) и не-изображений (non-images) присутствует только по историческим причинам и не имеет семантического значения.
Modality Performed Procedure Step Status (0040,0252) не должен устанавливаться в «COMPLETED» или «DISCONTINUED», если список не содержит ни ссылок на Image, ни ссылок на Non-Image Composite SOP Instance, за исключением случая, когда ни одного такого экземпляра (Instance) создано не было.
Операция 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».
Такое принудительное изменение атрибутов со стороны SCP может потребоваться для исправления, например, идентификационной информации пациента (patient identification) или неверно выбранной информации о расписании (scheduling information). Такая операция не разрешена для SCU согласно требованиям, описанным в Таблице F.7.2-1; вместо этого SCU может создать новый экземпляр Modality Performed Procedure Step SOP Instance для достижения той же цели.
В исключительных обстоятельствах SCP может потребоваться самостоятельно установить Performed Procedure Step Status (0040,0252) в значение COMPLETED или DISCONTINUED — например, при отказе модальности. Когда модальность восстановит работу, последующие запросы N-SET могут завершиться неудачей.
Специфические коды статусов отсутствуют. Специфические Error Comment и Error ID, которые могут быть возвращены с кодом статуса Processing Failure в N-SET-RSP, определены в Таблице F.7.2-2. См. PS3.7 для дополнительных кодов статусов ответа.
Класс Modality Performed Procedure Step SOP Class должен быть однозначно идентифицирован UID класса Modality Performed Procedure Step SOP Class UID, который должен иметь значение «1.2.840.10008.3.1.2.3.3».
Реализации, заявляющие о соответствии классу Modality Performed Procedure Step SOP Class, должны соответствовать требованиям, описанным в следующих разделах, и должны включать в своё Заявление о соответствии (Conformance Statement) информацию, как описано ниже.
Реализация может соответствовать данному SOP Class как SCU или как SCP. Заявление о соответствии (Conformance Statement) должно быть оформлено в соответствии с форматом, определённым в PS3.2.
Реализация, соответствующая данному SOP Class как SCU, должна удовлетворять требованиям соответствия для операций, которые она вызывает.
Любые атрибуты, для которых 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.
Реализация, соответствующая данному SOP Class как SCP, должна удовлетворять требованиям соответствия для операций, которые она выполняет.
Любые атрибуты, для которых 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.
DIMSE-сервисы, показанные в Таблице F.8.1-1, применимы к Modality Performed Procedure Step IOD в рамках класса Modality Performed Procedure Step Retrieve SOP Class.
DIMSE-сервисы и протоколы специфицированы в PS3.7. Если объект Modality Performed Procedure Step Object больше недоступен, примитив запроса (Request Primitive) будет отвечать кодом статуса сбоя (Failure Status Code) 0112H «No such SOP Instance».
Прикладной элемент (Application Entity), заявляющий о соответствии данному SOP Class как SCU, должен иметь право вызывать следующие операции, а прикладной элемент, заявляющий о соответствии как SCP, должен быть способен предоставлять следующие операции.
Эта операция позволяет 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), созданных другими прикладными элементами.
Прикладной элемент (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
Атрибуты (0040,1006) Placer Order Number/Procedure и (0040,1007) Filler Order Number/Procedure были ранее определены в DICOM. Они были выведены из употребления (см. PS3.3-1998).
Атрибуты (0040,2006) и (0040,2007) были ранее определены в DICOM. Они были выведены из употребления (см. PS3.3-1998).
Модуль Radiation Dose был ранее определён в DICOM. Он был выведен из употребления (см. PS3.3-2017c).
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 должен сделать в результате получения этой информации.
Операция 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-2 определяет конкретные значения кодов состояния, которые могут быть возвращены в ответе N-GET. См. PS3.7 для дополнительных кодов состояния ответа.
SOP-класс получения выполненного этапа процедуры модальности должен быть однозначно идентифицирован UID SOP-класса получения выполненного этапа процедуры модальности, который должен иметь значение "1.2.840.10008.3.1.2.3.4".
Реализации, обеспечивающие соответствие SOP-классу получения выполненного этапа процедуры модальности, должны соответствовать требованиям, описанным в следующих разделах, и должны включить в своё заявление о соответствии информацию, как описано ниже.
Реализация может соответствовать этому SOP-классу как SCU или как SCP. Заявление о соответствии должно быть составлено в формате, определённом в PS3.2.
Реализация, соответствующая этому SOP-классу как SCU, должна удовлетворять требованиям соответствия для операций, которые она инициирует.
Любые атрибуты, для значений которых могут быть запрошены SCU (с использованием службы N-GET), должны быть перечислены в заявлении о соответствии. Заявление о соответствии должно быть составлено в формате, определённом в PS3.2.
Реализация, соответствующая этому SOP-классу как SCP, должна удовлетворять требованиям соответствия для операций, которые она выполняет.
Любые атрибуты, для значений которых могут быть запрошены SCU (с использованием службы N-GET), должны быть перечислены в заявлении о соответствии. Заявление о соответствии должно быть составлено в формате, определённом в PS3.2.
SOP-класс уведомлений о выполненном этапе процедуры модальности предназначен для тех прикладных сущностей, которым требуются уведомления об изменениях состояния выполненного этапа процедуры модальности.
Прикладная сущность может предпринять некоторые действия на основе уведомления или запроса информации, но ни в коей мере не обязана это делать.
Например, в одной конфигурации ИС может отвечать за ведение данных, связанных с выполненными этапами процедуры. Рабочая станция просмотра PACS может потребовать отображения изображений для любого просматриваемого исследования. Чтобы PACS мог связать изображения с исследованием, PACS может получать уведомление при каждом выполнении этапа процедуры. В такой конфигурации ИС является SCP, а PACS — SCU. Когда PACS получает это уведомление, он может связать изображения и выполненный этап процедуры с исследованием в своей внутренней базе данных или может не предпринимать никаких действий.
Термины ИС и PACS, использованные в предыдущем примере, приведены исключительно для пояснения. Настоящий документ не определяет и не ограничивает назначение или роль какого-либо ИС, PACS или прикладной сущности получения, соответствующей настоящей спецификации сервисного класса.
Определение того, как SCP узнаёт о том, каких SCU уведомлять об изменениях, выходит за рамки настоящей спецификации. Предполагаемый способ — сделать это элементом конфигурации SCP.
Таблица F.9.1-1 показывает службы DIMSE-N, применимые к IOD выполненного этапа процедуры модальности в рамках SOP-класса уведомлений о выполненном этапе процедуры модальности.
Службы и протоколы DIMSE-N определены в PS3.7.
Таблица F.9.1-1. Группа служб DIMSE, применимая к уведомлению о выполненном этапе процедуры модальности
Прикладная сущность, заявляющая о соответствии как SCU этому SOP-классу, должна иметь право получать следующее уведомление. Прикладная сущность, заявляющая о соответствии как SCP этому SOP-классу, должна быть способна предоставлять уведомления, определённые в Таблице F.9.2-1.
Таблица F.9.2-1. Информация о событии уведомления выполненного этапа процедуры
Информация о событии уведомления не содержит атрибутов, помимо определённых в PS3.7. SCU, получающий уведомление и нуждающийся в дополнительной информации, может также быть SCU SOP-класса получения выполненного этапа процедуры модальности и может использовать Affected SOP Instance UID (0000,1000) для выполнения N-GET SOP-экземпляра выполненного этапа процедуры модальности.
Это уведомление позволяет 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-класса уведомлений о выполненном этапе процедуры модальности.
Эти уведомления позволяют 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.
Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.
SOP-класс уведомлений о выполненном этапе процедуры модальности должен быть однозначно идентифицирован UID SOP-класса уведомлений о выполненном этапе процедуры модальности, который должен иметь значение "1.2.840.10008.3.1.2.3.5".
Реализации, обеспечивающие соответствие стандартного SOP-класса SOP-классу уведомлений о выполненном этапе процедуры модальности, должны соответствовать требованиям, описанным в следующих разделах, и должны включить в своё заявление о соответствии информацию, как описано в следующих разделах.
Реализация может соответствовать этому SOP-классу как SCU, SCP или обоим. Заявление о соответствии должно быть составлено в формате, определённом в PS3.2.
Реализация, соответствующая этому SOP-классу как SCU, должна удовлетворять требованиям соответствия для:
Реализация, соответствующая этому SOP-классу как SCP, должна удовлетворять требованиям соответствия для:
Любые дополнительные атрибуты, которые могут быть включены в стандартные уведомления для SCU, должны быть перечислены в заявлении о соответствии. Заявление о соответствии должно быть составлено в формате, определённом в PS3.2. За этим заявлением должен следовать список типов событий и дополнительных атрибутов.
Сервисный класс управления печатью определяет прикладной уровень класса обслуживания, который облегчает печать изображений и связанных с ними данных на материале для твёрдых копий.
Сервисный класс управления печатью DICOM охватывает общие случаи печати медицинских изображений в стандартизованных макетах. Приложение может получить более гибкое размещение, аннотирование и форматирование путём непосредственного манипулирования матрицами пикселей, используемыми в управлении печатью DICOM, или путём использования описаний страниц, написанных на языке описания страниц (таком как PostScript или PDF), которые передаются в систему печати с использованием общедоступных протоколов. Эти другие языки описания страниц не передаются с использованием протоколов DICOM, и их применение выходит за рамки стандарта DICOM.
Модель потока данных управления печатью (Рисунок H.2-1) состоит из трёх основных процессов:
В стандарте используется слово «плёнка» как общее наименование для различных типов носителей твёрдых копий (например, фотоплёнка, бумага).
Процесс управления сеансом плёнки отвечает за сбор всей информации, необходимой для печати сеанса плёнки. Сеанс плёнки является неделимым рабочим пакетом приложения управления печатью и содержит одну или несколько плёнок, связанных заданным пользователем образом (например, принадлежащих одному обследованию, пациенту), которые исходят от одного узла (например, рабочей станции, диагностической модальности) и печатаются на одном принтере твёрдых копий.
Каждая плёнка состоит из одного или нескольких изображений и нуля или более аннотаций, связанных с плёнкой. Аннотация состоит из одной или нескольких строк текста.
Каждое изображение состоит из данных пикселей и нуля или более плоскостей наложения (overlay planes). Пользователь управляет видом плёнки, задавая значения параметров печати.
Параметры печати определены на уровнях сеанса плёнки, плёнки, изображения и аннотации. Уровень параметра определяет область действия параметров печати (например, параметры печати уровня изображения действительны для соответствующего изображения).
Входными данными процесса управления сеансом плёнки являются:
Выходными данными процесса управления сеансом плёнки является задание печати (Print Job), которое содержит всю информацию для печати сеанса плёнки.
Процесс печати печатает набор плёнок на основе информации в задании печати. Процесс печати зависит от реализации, и его управление выходит за рамки стандарта DICOM.
Сервисный класс управления печатью поддерживает два преобразования в градациях серого и пространственные преобразования, которые преобразуют исходное изображение в печатное.
Последовательность пространственных преобразований (например, увеличение и объединение аннотаций с изображениями) и их связь с преобразованиями в градациях серого зависят от реализации и выходят за рамки стандарта DICOM.
Последовательность преобразований в градациях серого имеет важное значение для достижения стабильного качества изображений из-за неортогонального характера различных преобразований. Рисунок H.2-2 описывает последовательность преобразований в градациях серого.
Этот раздел ранее содержал более подробное описание преобразований Modality LUT и VOI LUT. Поскольку Referenced Print SOP Classes были выведены из употребления, эти описания больше не применимы к сервисному классу управления печатью. См. PS3.4-1998.
Примерами таких преобразований являются Modality LUT, вычитание маски (Mask Subtraction) и VOI LUT.
Modality LUT преобразует зависящие от производителя значения пикселей в значения пикселей, имеющие смысл для модальности и не зависящие от производителя.
VOI LUT преобразует значения пикселей модальности в значения пикселей, имеющие смысл для пользователя или приложения. Например, он выбирает диапазон значений пикселей для оптимизации отображения, такой как окна мягких тканей или костей в изображении CT.
Полярность (Polarity) определяет, должны ли минимальные входные значения пикселей отображаться как чёрные или белые. Если Polarity (2020,0020) имеет значение NORMAL, пиксели отображаются в соответствии с Photometric Interpretation; если Polarity имеет значение REVERSE, пиксели отображаются с противоположной полярностью, как указано Photometric Interpretation.
Polarity (2020,0020) является атрибутом IOD блока изображения (Image Box).
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, являющуюся тождественной функцией. Тождественная функция сообщает устройству отображения, что дальнейшее преобразование не требуется.
Структура сервисного класса управления печатью показана на Рисунке H.2-3.
SCU управления печатью и SCP управления печатью являются равноправными прикладными сущностями DICOM для управления печатью. Прикладная сущность SCP управления печатью соответствует одному или нескольким принтерам твёрдых копий. Если прикладная сущность SCP соответствует нескольким принтерам, то прикладная сущность SCP выбирает для каждого задания печати принтер, на котором это задание будет напечатано.
SCU управления печатью и SCP управления печатью устанавливают ассоциацию, используя службы ассоциации сервиса OSI Upper Layer. Во время установления ассоциации прикладные сущности DICOM для управления печатью согласовывают поддерживаемые SOP-классы. Процедура согласования определена в Разделе H.5.
Рисунок H.2-4 показывает альтернативные конфигурации для печати изображений и связанных с ними данных с одного узла на несколько принтеров.
Конфигурация 1: одна прикладная сущность SCU соответствует узлу, и одна прикладная сущность SCP соответствует нескольким принтерам. SCU не имеет контроля над параметрами печати каждого принтера и над назначением печати задания печати.
Конфигурация 2: одна прикладная сущность SCU соответствует узлу, и одна прикладная сущность SCP соответствует каждому принтеру. SCU имеет явный контроль над параметрами печати каждого принтера и над назначением печати задания печати. Каждая прикладная сущность SCP имеет одну ассоциацию с прикладной сущностью SCU и идентифицируется по своему титулу прикладной сущности.
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 настоящей части.
Базовыми структурными элементами SOP-классов являются модули и службы DIMSE. Модули содержат связанные атрибуты, которые являются обязательными (M, Mandatory) или необязательными (U, Optional). Использование может различаться для SCU и SCP. Использование указывается как пара букв: первая обозначает использование SCU, последняя — использование SCP.
Группа служб DIMSE (DIMSE Service Group) может быть обязательной (M) или необязательной (U), как указано в Разделе 5.4 настоящей части.
Значение и поведение спецификации использования для атрибутов в сервисном классе управления печатью:
SCU должен предоставить значение для атрибута. Если SCU не предоставляет значение, SCP должен вернуть код состояния ошибки 0120H "Missing Attribute" ("Отсутствует атрибут"). SCP должен поддерживать хотя бы одно значение атрибута. Если SCP не поддерживает значение, указанное SCU, он должен вернуть код состояния ошибки 0106H "Invalid Attribute Value" ("Недопустимое значение атрибута").
Использование атрибута со стороны SCU не определено. SCP должен поддерживать хотя бы одно значение атрибута.
SCU может предоставить значение для атрибута. Если SCP не поддерживает значение, указанное SCU, он должен вернуть либо код состояния ошибки 0106H "Invalid Attribute Value" ("Недопустимое значение атрибута"), либо код состояния предупреждения 0116H "Attribute Value out of range" ("Значение атрибута вне диапазона"). В случае состояния предупреждения SCP применит значение по умолчанию, как определено в заявлении о соответствии SCP.
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), приведённая выше спецификация должна быть изменена, чтобы включить требование о том, что атрибут должен поддерживаться при выполнении указанного условия.
Для каждой операции, запрошенной на SOP-классе сервисного класса управления печатью, будет возвращён код состояния. Эти коды состояния сгруппированы в категории успеха, предупреждения или ошибки.
Эти категории кодов состояния определены в PS3.7:
Успех (Success) — указывает, что SCP выполнил запрошенную операцию, как запрошено.
Предупреждение (Warning) — указывает, что SCP получил запрос и обработает его. Однако немедленная обработка запроса или обработка способом, указанным SCU, может быть невозможна. SCP ожидает, что сможет завершить запрос без дальнейших действий SCU через интерфейс DICOM. Точное поведение SCP описано в заявлении о соответствии.
Ошибка (Failure) — указывает, что SCP не может выполнить запрос. Запрос не будет обработан, если он не будет повторён SCU в более позднее время. Точное поведение SCP описано в заявлении о соответствии.
Соответствие управления печатью определяется в терминах поддерживаемых мета-SOP-классов (Meta SOP Classes), которые соответствуют обязательной функциональности, и поддерживаемых необязательных SOP-классов, которые соответствуют дополнительной функциональности.
Мета-SOP-класс соответствует заранее определённой группе SOP-классов. Определены следующие мета-SOP-классы управления печатью:
Все 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.
Базовые мета-SOP-классы управления печатью соответствуют минимальной функциональности, которую реализация сервисного класса управления печатью должна поддерживать. Базовые мета-SOP-классы управления печатью поддерживают следующие обязательные функции:
предформатированные изображения в градациях серого или предформатированные цветные изображения; предформатированные изображения — это изображения, в которых аннотации, графика, наложения (overlays) вшиты в пиксели
предопределённые макеты плёнки (форматы отображения изображений)
базовые параметры представления на уровнях сеанса плёнки, блока плёнки и блока изображения
Необязательные SOP-классы, описанные в Разделе H.3.3, могут использоваться с базовыми мета-SOP-классами управления печатью.
Мета-SOP-класс определяется следующим набором поддерживаемых SOP-классов.
Значение Использования (SCU/SCP) описано в Разделе H.2.4.
UID мета-SOP-класса Basic Grayscale Print Management имеет значение "1.2.840.10008.5.1.1.9".
Мета-SOP-класс определяется следующим набором поддерживаемых SOP-классов.
Значение Использования (SCU/SCP) описано в Разделе H.2.4.
UID мета-SOP-класса Basic Color Print Management имеет значение "1.2.840.10008.5.1.1.18".
Этот раздел был ранее определён в DICOM. Он выведен из употребления. См. PS3.4-1998.
Этот раздел был ранее определён в DICOM. Он выведен из употребления. См. PS3.4-1998.
Этот раздел был ранее определён в DICOM. Он выведен из употребления. См. PS3.4-2004.
Необязательные SOP-классы обеспечивают функциональность, выходящую за рамки мета-SOP-классов управления печатью. Один или несколько необязательных SOP-классов могут использоваться в дополнение к мета-SOP-классам управления печатью.
Следующая функциональность поддерживается необязательными SOP-классами:
Использование этих необязательных SOP-классов позволяет SCU предоставлять информацию для печати с изображением или на изображении без вшивания информации в пиксельные данные изображения. Если эти необязательные SOP-классы не поддерживаются как SCU, так и SCP, будет напечатана только информация, вшитая в пиксели изображения до их отправки на SCP. Если необязательные SOP-классы не поддерживаются, SCU отвечает за вшивание всего ожидаемого текста или графики в пиксели изображения.
Следующие необязательные SOP-классы могут использоваться совместно с базовыми мета-SOP-классами управления печатью, указанными в Разделе H.3.2.2.
Table H.3.3.2-1. Перечень необязательных SOP-классов для базовых мета-SOP-классов управления печатью
Заявление о соответствии реализации этих SOP-классов должно следовать PS3.2.
Заявление о соответствии SCU должно указывать следующие пункты:
Заявление о соответствии SCP должно указывать следующие пункты:
максимальное количество поддерживаемых одновременно ассоциаций
минимальное и максимальное количество печатаемых пиксельных матриц для каждого поддерживаемого формата плёнки
для каждого поддерживаемого атрибута (обязательного и необязательного):
для каждой поддерживаемой службы DIMSE — поведение SCP для всех специфических кодов состояния
описание каждого поддерживаемого пользовательского формата отображения изображений (Image Display Format) (2010,0010), например, положение и размеры каждого составляющего блока изображения, схема нумерации позиций изображений
описание каждого поддерживаемого идентификатора формата отображения аннотаций (Annotation Display Format ID) (2010,0030), например, положение и размеры блока аннотаций, шрифт, количество символов
описание каждой поддерживаемой таблицы конфигурации (например, идентификация, содержимое)
если SCP поддерживает N-ACTION для SOP-класса сеанса плёнки, то SCP должен указать максимальное количество колированных плёнок
в случае полутоновых принтеров, печатающих цветные изображения, — поведение при печати цветных изображений
если поддерживается кадрирование изображений, — алгоритм удаления строк и столбцов из изображения
IOD базового сеанса плёнки описывает параметры представления, общие для всех плёнок сеанса плёнки (например, количество плёнок, назначение плёнки)
Экземпляр SOP базового сеанса плёнки ссылается на один или несколько экземпляров SOP базового блока плёнки.
Службы DIMSE, применимые к данному IOD, показаны в Таблице H.4-1.
Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.
В этом разделе описывается поведение служб DIMSE, специфичное для данного IOD. Общее поведение служб DIMSE специфицировано в PS3.7.
N-CREATE используется для создания экземпляра SOP-класса базового сеанса плёнки.
Список атрибутов N-CREATE определён, как показано в Таблице H.4-2.
Атрибут распределения памяти позволяет SCU зарезервировать достаточный объём памяти для хранения иерархии «рабочего» сеанса плёнки, а также иерархии «скопированного» сеанса плёнки в задании печати, чтобы предотвратить ситуации взаимной блокировки.
Owner ID (2100,0160) является пользовательской опцией для базового сеанса плёнки.
Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.
В рамках сеанса плёнки выделенная память расходуется по мере создания экземпляров SOP и освобождается для повторного использования по мере удаления экземпляров SOP. Вся выделенная память должна быть освобождена после завершения ассоциации или удаления экземпляра SOP сеанса плёнки.
Таблица H.4.1.2.1.2-1 определяет специфические значения кодов состояния, которые могут быть возвращены в ответе N-CREATE или N-SET для данного SOP-класса. См. PS3.7 для получения дополнительных кодов состояния ответа служб DIMSE N-CREATE и N-SET.
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.
N-SET может использоваться для обновления экземпляра SOP-класса базового сеанса плёнки.
Все атрибуты и их использование в Таблице H.4-2 применимы к N-SET.
Значения статуса, специфичные для данного SOP-класса, определены в Разделе H.4.1.2.1.2.
SCU использует N-SET для запроса SCP на обновление экземпляра SOP базового сеанса плёнки. SCU должен указать UID экземпляра SOP для обновления и указать список атрибутов, значения которых должны быть установлены.
SCP должен установить новые значения для указанных атрибутов указанного экземпляра SOP.
SCP должен вернуть код состояния запрошенного обновления экземпляра SOP. Значение кодов состояния успеха, предупреждения и отказа определено в Разделе H.2.5
N-DELETE используется для удаления полной иерархии экземпляра SOP базового сеанса плёнки. В результате все ссылки на экземпляры SOP изображений в рамках сеанса плёнки удаляются.
Иерархия экземпляра SOP базового сеанса плёнки состоит из одного экземпляра SOP базового сеанса плёнки, одного или нескольких экземпляров SOP базового блока плёнки, одного или нескольких экземпляров SOP блока изображения, нуля или более экземпляров SOP базового блока аннотаций, нуля или более экземпляров SOP LUT представления и нуля или более экземпляров SOP базового блока наложения печатного изображения.
Иерархия экземпляра SOP базового сеанса плёнки может быть представлена в виде перевёрнутого дерева, где экземпляр SOP базового сеанса плёнки является корнем, а экземпляры SOP блока изображения — листьями.
Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.
SCU использует N-DELETE для запроса SCP на удаление иерархии экземпляра SOP базового сеанса плёнки. SCU должен указать в примитиве запроса N-DELETE UID экземпляра SOP базового сеанса плёнки (корень).
SCP должен удалить указанную иерархию экземпляра SOP.
SCP не должен удалять экземпляры SOP в иерархии, пока существуют незавершённые ссылки на эти экземпляры SOP
Определение того, когда SCP фактически удаляет экземпляры SOP с незавершёнными ссылками, выходит за рамки Стандарта.
SCP должен вернуть код состояния запрошенного удаления экземпляра SOP. Значение кодов состояния успеха, предупреждения и отказа определено в Разделе H.2.5.
N-ACTION используется для печати сеанса плёнки; т.е. для печати всех плёнок, принадлежащих сеансу плёнки.
Если было запрошено несколько копий сеанса плёнки, SCP должен колировать копии. Это означает, что если указаны две копии четырёх плёнок, напечатанная последовательность будет 12341234.
Аргументы 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
Таблица H.4-4определяет специфические значения кодов состояния, которые могут быть возвращены в ответе N-ACTION. См. PS3.7 для дополнительных кодов состояния ответа.
Таблица H.4-4. Значения статуса SOP-класса
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 блока плёнки.
IOD базового блока плёнки является абстракцией представления одной плёнки сеанса плёнки. IOD базового блока плёнки описывает параметры представления, общие для всех изображений на данном листе плёнки.
Экземпляр SOP базового блока плёнки ссылается на один или несколько экземпляров SOP блока изображения, нуль или более связанных с плёнкой экземпляров SOP блока аннотаций и нуль или один экземпляр SOP LUT представления.
Таблица H.4-5 показывает службы DIMSE, применимые к данному IOD.
Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.
В этом разделе описывается поведение служб DIMSE, специфичное для данного IOD. Общее поведение служб DIMSE специфицировано в PS3.7.
N-CREATE используется для создания экземпляра SOP-класса базового блока плёнки.
Список атрибутов N-CREATE показан в Таблице H.4-6.
Таблица H.4-6. Список атрибутов N-CREATE
Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.
Если значения Illumination (2010,015E) и Reflected Ambient Light (2010,0160), обозначаемые соответственно L0 и La, не созданы, для полутоновой печати рекомендуются следующие значения по умолчанию:
Атрибут ICC Profile (0028,2000) должен использоваться только для описания цветового пространства изображений для цветной печати, т.е. в сочетании с SOP-классом базового блока цветного изображения. Он не должен использоваться с SOP-классом базового блока полутонового изображения.
Таблица 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-класса базового блока плёнки
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.
N-SET может использоваться для обновления последнего созданного экземпляра SOP-класса базового блока плёнки.
Атрибуты, которые могут быть обновлены, показаны в Таблице H.4-7.
Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.
Значения статуса, специфичные для данного SOP-класса, определены в Разделе H.4.2.2.1.2.
SCU использует N-SET для запроса SCP на обновление экземпляра SOP базового блока плёнки. SCU должен указать только UID экземпляра SOP последнего созданного базового блока плёнки в примитиве запроса N-SET и указать список атрибутов, значения которых должны быть установлены.
SCP должен установить новые значения для указанных атрибутов указанного экземпляра SOP.
SCP должен вернуть код состояния запрошенного обновления экземпляра SOP. Значение кодов состояния успеха, предупреждения и отказа определено в Разделе H.2.5.
N-DELETE используется для удаления иерархии последнего созданного экземпляра SOP базового блока плёнки. В результате удаляется вся информация, описывающая последнюю плёнку.
Иерархия экземпляра SOP базового блока плёнки состоит из одного экземпляра SOP базового блока плёнки, одного или нескольких экземпляров SOP блока изображения, нуля или более экземпляров SOP базового блока аннотаций, нуля или более экземпляров SOP LUT представления и нуля или более экземпляров SOP базового блока наложения печатного изображения.
В Стандарте DICOM не предусмотрена возможность удаления ранее созданных экземпляров SOP блока плёнки.
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
Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.
N-ACTION используется для печати одной или нескольких копий последнего созданного экземпляра блока плёнки.
Аргументы 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
Таблица H.4-9 определяет специфические значения кодов состояния, которые могут быть возвращены в ответе N-ACTION. См. PS3.7 для дополнительных кодов состояния ответа.
Таблица H.4-9. Значения статуса
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.
IOD базового блока изображения является абстракцией представления изображения и связанных с ним данных в области изображения на плёнке. IOD базового блока изображения описывает параметры представления и пиксельные данные изображения, применимые к одному изображению на листе плёнки.
Экземпляр SOP базового полутонового блока изображения создаётся SCP в момент создания экземпляра SOP базового блока плёнки на основе значения атрибута Image Display Format (2010,0010) базового блока плёнки.
Экземпляр SOP базового полутонового блока изображения ссылается на нуль или один экземпляр SOP блока наложения изображения и нуль или один экземпляр SOP LUT представления.
Службы DIMSE, применимые к данному IOD, показаны ниже.
Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.
N-CREATE отсутствует, поскольку экземпляры SOP-класса базового полутонового блока изображения создаются SCP в результате выполнения N-CREATE для экземпляра SOP блока плёнки.
В этом разделе описывается поведение служб DIMSE, специфичное для данного IOD. Общее поведение служб DIMSE специфицировано в PS3.7.
N-SET может использоваться для обновления экземпляра SOP-класса базового полутонового блока изображения.
Атрибуты, которые могут быть обновлены, показаны в Таблице H.4-10.
Значение параметра «Использование (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-1 определяет специфические значения кодов статуса, которые могут быть возвращены в ответе N-SET. См. PS3.7 для дополнительных кодов статуса ответа.
Таблица H.4.3.1.2.1.2-1. Значения статуса для класса SOP базового блока изображения в градациях серого
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.
IOD базового блока изображения является абстракцией представления изображения и связанных с ним данных в области изображения на плёнке. IOD базового блока изображения описывает параметры представления и пиксельные данные изображения, применимые к одному изображению на листе плёнки.
Экземпляр SOP базового цветового блока изображения создаётся SCP в момент создания экземпляра SOP базового блока плёнки на основе значения атрибута базового блока плёнки Image Display Format (2010,0010).
Экземпляр SOP базового цветового блока изображения ссылается на ноль или один экземпляр SOP блока наложения изображения (Image Overlay Box SOP Instance).
Следующие службы DIMSE применимы к данному IOD.
Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.
N-CREATE отсутствует, поскольку экземпляры SOP-класса базового цветного блока изображения создаются SCP в результате N-CREATE экземпляра SOP блока плёнки.
В этом разделе описывается поведение служб DIMSE, специфичное для данного IOD. Общее поведение служб DIMSE специфицировано в PS3.7.
N-SET может использоваться для обновления экземпляра SOP-класса базового цветного блока изображения.
Атрибуты, которые могут быть обновлены, показаны в Таблице H.4-11.
Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.
Значения атрибутов Magnification Type (2010,0060) и Smoothing Type (2010,0080) конкретного блока изображения переопределяют значения Magnification Type и Smoothing Type блока плёнки.
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-класса базового цветного блока изображения
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.
Этот раздел был ранее определён в DICOM. Он был выведен из употребления. См. PS3.4-1998.
IOD базового блока аннотаций является абстракцией представления аннотации (например, текстовой строки) на плёнке. IOD базового блока аннотаций описывает наиболее используемые параметры представления, связанные с текстом.
Экземпляр SOP базового блока аннотаций создаётся SCP во время создания экземпляра SOP базового блока плёнки на основе значения атрибута Annotation Display Format ID (2010,0030) базового блока плёнки.
Службы DIMSE, применимые к данному IOD, показаны ниже.
Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.
N-CREATE отсутствует, поскольку экземпляры SOP-класса базового блока аннотаций создаются экземпляром SOP блока плёнки.
В этом разделе описывается поведение служб DIMSE, специфичное для данного IOD. Общее поведение служб DIMSE специфицировано в PS3.7.
N-SET используется для обновления экземпляра SOP базового блока аннотаций.
Атрибуты, которые могут быть обновлены, показаны в Таблице H.4-13.
Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.
Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.
SCU использует N-SET для запроса SCP на обновление экземпляра SOP базового блока аннотаций. SCU должен указать только SOP Instance UID базового блока аннотаций, принадлежащего последнему созданному экземпляру SOP блока плёнки, в примитиве запроса N-SET, и должен указать список атрибутов, для которых должны быть установлены значения атрибутов. SCU может стереть текстовую строку, установив нулевое значение длины в атрибуте Text String (2030,0020).
SCP должен установить новые значения для указанных атрибутов указанного экземпляра SOP.
SCP должен вернуть код статуса запрошенного обновления экземпляра SOP. Значение кодов статуса успеха, предупреждения и отказа определено в Разделе H.2.5.
IOD задания печати является абстракцией транзакции задания печати и представляет собой базовую информационную сущность для мониторинга выполнения процесса печати. Задание печати содержит одну плёнку или несколько плёнок, все принадлежащие одному сеансу плёнки.
SOP-класс задания печати создаётся операцией N-ACTION SOP-класса сеанса плёнки, SOP-класса блока плёнки или SOP-класса запроса pull-печати. Экземпляр SOP задания печати удаляется после печати плёнок или после возникновения условия отказа.
Службы DIMSE, применимые к данному IOD, показаны ниже.
Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.
В этом разделе описывается поведение служб DIMSE, специфичное для данного IOD. Общее поведение служб DIMSE специфицировано в PS3.7.
N-EVENT-REPORT используется для асинхронного сообщения SCU об изменениях состояния выполнения.
Аргументы N-EVENT-REPORT определены, как показано в Таблице H.4-14.
Кодирование информации о событии уведомления определено в PS3.7.
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.
Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.
N-GET используется для извлечения экземпляра SOP-класса задания печати.
Атрибуты, которые могут быть извлечены, показаны в Таблице H.4-15.
Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.
SCU использует N-GET для запроса SCP на получение экземпляра SOP задания печати. SCU должен указать в примитиве запроса N-GET UID экземпляра SOP, который должен быть извлечён.
SCP должен вернуть значения для указанных атрибутов указанного экземпляра SOP.
SCP должен вернуть код статуса запрошенного извлечения экземпляра SOP. Значение кодов статуса успеха, предупреждения и отказа определено в Разделе H.2.5.
Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.
Информация о состоянии определена в PS3.3. Специфические для реализации коды статуса предупреждения и отказа должны быть определены в Заявлении о соответствии (Conformance Statement).
IOD принтера является абстракцией принтера твёрдых копий и представляет собой базовую информационную сущность для мониторинга состояния принтера.
Экземпляр SOP принтера создаётся SCP во время запуска принтера твёрдых копий и имеет общеизвестный SOP Instance UID.
Службы DIMSE, применимые к данному IOD, показаны ниже.
Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.
В этом разделе описывается поведение служб DIMSE, специфичное для данного IOD. Общее поведение служб DIMSE специфицировано в PS3.7.
N-EVENT-REPORT используется для асинхронного сообщения об изменениях состояния принтера.
Аргументы N-EVENT-REPORT определены, как показано в Таблице H.4-16.
Кодирование информации о событии уведомления определено в PS3.7.
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.
Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.
N-GET используется для извлечения экземпляра SOP-класса принтера.
Атрибуты, которые могут быть извлечены, показаны в Таблице H.4-17.
Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.
SCU использует N-GET для запроса SCP на получение экземпляра SOP принтера. SCU должен указать в примитиве запроса N-GET UID экземпляра SOP, который должен быть извлечён.
SCP должен вернуть значения для указанных атрибутов указанного экземпляра SOP.
SCP должен вернуть код статуса запрошенного извлечения экземпляра SOP. Значение кодов статуса успеха, предупреждения и отказа определено в Разделе H.2.5.
Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.
Информация о состоянии определена в PS3.3. Специфические для реализации коды статуса предупреждения и отказа должны быть определены в Заявлении о соответствии (Conformance Statement).
Этот раздел был ранее определён в DICOM. Он был выведен из употребления. См. PS3.4-1998.
Этот раздел был ранее определён в DICOM. Он был выведен из употребления. См. PS3.4-1998.
Информационный объект 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 представления должны иметь приоритет.
Математическое определение стандартной функции отображения в градациях серого и отображение P-значений в оптическую плотность для рефлексивных и трансмиссивных принтеров содержится в PS3.14 Grayscale Standard Display Function.
Следующие службы DIMSE применимы к информационному объекту LUT представления, связанному с ассоциацией:
Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.
В этом разделе описывается поведение служб DIMSE, специфичное для данного информационного объекта. Общее поведение служб DIMSE специфицировано в PS3.7.
Элемент службы N-CREATE используется для создания экземпляра SOP-класса LUT представления.
Список атрибутов элемента службы N-CREATE определён, как показано в Таблице H.4-23.
Таблица H.4-23. Список атрибутов N-CREATE
Первое значение (количество записей в LUT) должно быть равно:
Второе значение должно быть равно 0.
Третье значение (количество бит для каждой записи LUT) должно быть 10–16.
См. определение в PS3.3 для дополнительного пояснения.
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
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 для предлагаемых значений по умолчанию).
Элемент службы N-DELETE используется для удаления экземпляра SOP LUT представления.
Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.
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.
Этот раздел был ранее определён в DICOM. Он был выведен из употребления. См. PS3.4-2004.
IOD конфигурации принтера является абстракцией принтера твёрдых копий и представляет собой базовую информационную сущность для извлечения ключевых характеристик отображения принтера.
Экземпляр SOP извлечения конфигурации принтера создаётся SCP во время запуска принтера твёрдых копий и имеет общеизвестный SOP Instance UID.
Службы DIMSE, применимые к данному IOD, показаны в Таблице H.4.11.2-1.
Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.
В этом разделе описывается поведение служб DIMSE, специфичное для данного IOD. Общее поведение служб DIMSE специфицировано в PS3.7.
N-GET используется для извлечения экземпляра SOP-класса извлечения конфигурации принтера.
Извлекаемые атрибуты показаны в Таблице H.4-26.
Таблица H.4-26. Атрибуты N-GET
Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.
SCU использует N-GET для запроса SCP на получение экземпляра SOP извлечения конфигурации принтера. SCU должен указать в примитиве запроса N-GET UID экземпляра SOP, подлежащего извлечению.
SCP должен вернуть значения указанных атрибутов указанного экземпляра SOP.
SCP должен вернуть код состояния запрошенного извлечения экземпляра SOP.
Код состояния отказа должен указывать, что SCP не извлёк экземпляр SOP.
Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.
Этот раздел ранее был определён в DICOM. Он устарел. См. PS3.4-2004.
Установление ассоциации — первая фаза любого сеанса связи между равноправными DICOM AE. Процедура согласования ассоциации используется для согласования поддерживаемых классов SOP или мета-классов SOP. PS3.7 определяет процедуры ассоциации.
Процедура согласования используется для согласования поддерживаемых мета-классов SOP и поддерживаемых дополнительных классов SOP. SCU и SCP должны поддерживать как минимум один UID мета-класса SOP (например, мета-класс SOP базового управления печатью в оттенках серого) и могут поддерживать дополнительные необязательные классы SOP.
Класс сервиса управления печатью не поддерживает расширенное согласование.
SCU должен указать в запросе A-ASSOCIATE один абстрактный синтаксис в контексте представления для каждого поддерживаемого класса SOP или мета-класса SOP.
Если ассоциация освобождена или прервана, то все экземпляры SOP, за исключением экземпляра SOP задания печати и экземпляра SOP принтера, удаляются.
Перемещено в PS3.17.
Этот раздел ранее был определён в DICOM. Он устарел. См. PS3.4-1998.
Этот раздел ранее был определён в DICOM. Он устарел. См. PS3.4-2004.
Этот раздел ранее был определён в DICOM. Он устарел. См. PS3.4-2004.
Класс сервиса хранения на носителях определяет прикладной класс сервиса, обеспечивающий простую передачу изображений и связанной с ними информации между DICOM AE посредством носителей хранения. Он поддерживает:
DICOM AE поддерживают класс SOP класса сервиса хранения на носителях, выполняя одну или несколько ролей из трёх: FSC, FSR или FSU. Классы SOP класса сервиса хранения на носителях используют сервисы хранения на носителях (M-WRITE, M-READ, M-DELETE, M-INQUIRE FILE-SET и M-INQUIRE FILE). Эти сервисы определены в PS3.10.
В этом разделе обсуждается поведение FSC, FSR и FSU для классов SOP класса сервиса хранения на носителях.
FSC должен быть способен создавать файл DICOMDIR, содержащий класс SOP каталога хранения на носителях, для созданного набора файлов и создавать ноль или более файлов, принадлежащих набору файлов, вызывая операции M-WRITE с экземплярами SOP, удовлетворяющими требованиям соответствующего IOD. Ответственность FSC — обеспечить, чтобы M-WRITE привёл к созданию корректно сформированного файла DICOM. Способ достижения этого выходит за рамки стандарта DICOM.
FSC должен поддерживать операцию хранения на носителях M-INQUIRE FILE-SET и может дополнительно поддерживать M-INQUIRE FILE.
FSR должен быть способен распознавать набор файлов и соответствующий файл DICOMDIR, содержащий класс SOP каталога хранения на носителях. Допустимый набор файлов может содержать только DICOMDIR и никаких других файлов. Если набор файлов содержит другие файлы с сохранёнными экземплярами SOP, FSR должен быть способен вызывать операции M-READ для доступа к содержимому файлов набора файлов. Способ достижения этого выходит за рамки стандарта DICOM.
FSR должен поддерживать операцию хранения на носителях M-INQUIRE FILE и может дополнительно поддерживать M-INQUIRE FILE-SET.
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.
Реализация, соответствующая одному из классов SOP класса сервиса хранения на носителях:
должна отвечать требованиям, указанным в Разделе I.2.1;
должна отвечать требованиям, указанным в PS3.10;
должна выполнять операции M-WRITE в соответствии со спецификацией класса SOP, определяемой UID класса SOP в метафайле;
должна поддерживать класс SOP каталога хранения на носителях (сохраняемый в файле DICOMDIR).
Реализация, соответствующая одному из классов SOP класса сервиса хранения на носителях:
должна отвечать требованиям, указанным в Разделе I.2.2;
должна отвечать требованиям, указанным в PS3.10;
должна выполнять операции M-READ в соответствии со спецификацией класса SOP, определяемой UID класса SOP в метафайле. M-READ неподдерживаемых классов SOP должен просто приводить к игнорированию таких сохранённых наборов данных;
должна читать файлы DICOMDIR без модуля информации каталога или с модулем информации каталога, включающим записи каталога типа, не поддерживаемого реализацией.
Реализация, соответствующая одному из классов SOP класса сервиса хранения на носителях:
должна отвечать требованиям, указанным в Разделе I.2.3;
должна отвечать требованиям, указанным в PS3.10;
должна выполнять операции M-READ в соответствии со спецификацией класса SOP, определяемой UID класса SOP в метафайле. M-READ неподдерживаемых классов SOP должен просто приводить к игнорированию таких сохранённых наборов данных;
должна выполнять операции M-WRITE в соответствии со спецификацией класса SOP, определяемой UID класса SOP в метафайле;
должна поддерживать класс SOP каталога хранения на носителях (сохраняемый в файле DICOMDIR). Каталоги, содержащие модуль информации каталога, должны обновляться FSU. Каталоги, не содержащие модуля информации каталога, не должны обновляться FSU;
должна читать файлы DICOMDIR без модуля информации каталога или с модулем информации каталога, включающим записи каталога типа, не поддерживаемого реализацией.
Реализация класса сервиса хранения на носителях может поддерживать одну или несколько ролей, как указано в Таблице I.3-1. Кроме того, реализация может соответствовать одному или нескольким классам SOP класса сервиса хранения на носителях, определённым в Разделе I.4. Заявление о соответствии должно быть оформлено в формате, определённом PS3.2.
Следующие аспекты должны быть документированы в заявлении о соответствии любой реализации, заявляющей о соответствии одному из классов SOP хранения на носителях:
поддерживаемое подмножество базовой модели информационного объекта каталога;
при создании или обновлении модуля информации каталога (поддерживаемый модуль информации каталога) дополнительные стандартные ключи, которые могут быть включены в записи каталога, должны быть документированы. Частные ключи и частные записи также могут быть документированы;
В дополнение к стандартным классам SOP хранения на носителях реализации могут поддерживать стандартные расширенные, специализированные и/или частные классы SOP, как определено в PS3.2.
Для всех трёх типов классов SOP реализациям разрешается соответствовать в качестве FSC, FSR, обоих ролей или FSU. Заявление о соответствии должно быть оформлено в формате, определённом в PS3.2.
Классы 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
За исключением класса SOP каталога хранения на носителях, всем классам SOP в классе сервиса хранения на носителях присвоено то же значение UID, что и соответствующим классам SOP сетевого обмена. Это было сделано для упрощения назначения UID. Хотя эти классы SOP основаны на разных сервисах, контекст их использования должен однозначно отличать класс SOP, используемый для хранения на носителях, от класса SOP сетевого обмена.
Хранение нормализованных экземпляров SOP печати на носителях ранее было определено в DICOM. Они устарели. См. PS3.4-1998.
Хранение отсоединённых и автономных экземпляров SOP на носителях ранее было определено в DICOM. Они устарели. См. PS3.4-2004
См. Section B.6.
Механизм, в настоящее время определённый в 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 требуется документировать это поведение в своём заявлении о соответствии.
Запрос фиксации хранения может быть выполнен с использованием push-модели.
Push-модель предполагает, что SCU передаёт экземпляры SOP на SCP с использованием соответствующего механизма, выходящего за рамки данного класса сервиса. Фиксация хранения затем инициируется передачей запроса фиксации хранения, содержащего ссылки на набор из одного или нескольких экземпляров SOP. Успех или неудача фиксации хранения впоследствии указывается через уведомление от SCP к SCU.
Pull-модель была определена в более ранних версиях, но устарела. См. PS3.4-2001.
Как указано, механизмы, используемые для передачи экземпляров SOP от SCU к SCP, выходят за рамки данного класса сервиса. Однако типичные механизмы можно найти в классе сервиса хранения, классе сервиса запроса/получения или обмене через носители.
Прикладные сервисы, охватываемые данным классом сервиса, специфицируются через класс SOP push-модели фиксации хранения.:
Реализация SCP класса сервиса фиксации хранения должна поддерживать класс SOP push-модели фиксации хранения.
Класс SOP определяет атрибуты, операции, уведомления и поведение, применимые к классу SOP. Требования соответствия должны быть определены с точки зрения поставщика класса сервиса (SCP) и пользователя класса сервиса (SCU).
Класс сервиса фиксации хранения использует IOD фиксации хранения, как определено в PS3.3, и сервисы DIMSE N-ACTION и N-EVENT-REPORT, специфицированные в PS3.7.
Установление ассоциации — первая фаза любого сеанса связи между равноправными DICOM AE. Правила согласования ассоциации, указанные в PS3.7, должны использоваться для согласования поддерживаемых классов SOP.
Поддержка согласования выбора ролей SCP/SCU обязательна. Расширенное согласование класса SOP не должно поддерживаться.
Реализация SCP класса сервиса фиксации хранения должна поддерживать класс SOP push-модели фиксации хранения.
Класс SOP push-модели фиксации хранения предназначен для прикладных сущностей, нуждающихся в фиксации хранения, где SCU определяет момент передачи экземпляров SOP. SCU передаёт экземпляры SOP на SCP с использованием соответствующего механизма. Запрос фиксации хранения передаётся на SCP вместе со списком ссылок на один или несколько экземпляров SOP. Успех или неудача фиксации хранения впоследствии указывается через уведомление от SCP к SCU.
Сервисы DIMSE-N, применимые к классу SOP push-модели фиксации хранения, показаны в Таблице J.3.1-1.
Сервисы и протокол DIMSE-N специфицированы в PS3.7.
DICOM AE, заявляющие о соответствии данному классу SOP в роли SCU, должны вызывать операцию N-ACTION. DICOM AE, заявляющие о соответствии данному классу SOP в роли SCP, должны поддерживать операцию N-ACTION.
Операция запроса фиксации хранения позволяет SCU запросить SCP принять обязательство по обеспечению сохранности набора экземпляров SOP. Эта операция должна быть вызвана через примитив N-ACTION.
DICOM AE, заявляющие о соответствии данному классу SOP в роли SCU и/или SCP, должны поддерживать типы действий и информацию о действии, как указано в Таблице J.3-1.
Таблица J.3-1. Запрос фиксации хранения — Информация о действии
|
См. Section J.3.2.1.1.1. |
||||
|
См. Section J.3.2.1.1.1. |
||||
|
См. Section J.3.2.1.1.3. |
||||
|
См. Section J.3.2.1.1.1. |
||||
|
См. Section 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, на который ссылается этот элемент, должен быть доступен для извлечения из указанного набора файлов на носителе хранения.
Referenced Performed Procedure Step Sequence (0008,1111) был включён в более ранние версии, но его использование здесь устарело. См. PS3.4-2001, где этот атрибут ранее назывался Referenced Study Component Sequence.
Этот раздел ранее определял способ ссылки на завершённый компонент исследования (Study Component) и семантику, согласно которой список изображений в запросе фиксации хранения представлял полный набор. Этот раздел устарел, поскольку классы SOP этапа выполненной процедуры модальности (Modality Performed Procedure Step) обеспечивают ту же функциональность в более подходящем сервисе.
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.
Отказ фиксации хранения будет сигнализироваться через примитив N-EVENT-REPORT.
В ситуациях, когда экземпляры SOP передаются через обмен носителями, запрос фиксации хранения может завершиться неудачей, поскольку носитель, содержащий указанные экземпляры SOP, мог ещё не быть прочитан. Атрибуты (0088,0130) File-Set ID и (0088,0140) File-Set UID могут как присутствовать, так и отсутствовать в случае обмена носителями. Они могут быть предоставлены для облегчения идентификации носителя, содержащего переданные экземпляры SOP, со стороны SCP фиксации хранения.
После получения запроса N-ACTION SCP должен вернуть через примитив ответа N-ACTION код состояния ответа N-ACTION, применимый к соответствующему запросу. Код успешного состояния означает, что SCP успешно получил запрос. Код состояния отказа означает, что SCP не обрабатывает запрос.
Отказ фиксации хранения будет сигнализироваться через примитив N-EVENT-REPORT.
Когда запрос фиксации хранения получен SCP, он может немедленно оценить список ссылок, для которых запрашивается фиксация хранения, и вернуть N-EVENT-REPORT. В ситуациях, когда экземпляры SOP передаются через обмен носителями, N-EVENT-REPORT может завершиться неудачей, поскольку носитель, содержащий указанные экземпляры SOP, мог ещё не быть прочитан. Атрибуты (0088,0130) File-Set ID и (0088,0140) File-Set UID могут как присутствовать, так и отсутствовать в случае обмена носителями. Они могут использоваться для облегчения идентификации носителя, содержащего переданные экземпляры SOP, со стороны SCP фиксации хранения.
Для сервиса N-ACTION не определены специфические для класса сервиса значения состояния. См. PS3.7 для общих кодов состояния ответа.
DICOM AE, заявляющие о соответствии данному классу SOP в роли SCP, должны вызывать запрос N-EVENT-REPORT. DICOM AE, заявляющие о соответствии данному классу SOP в роли SCU, должны быть способны принимать запрос N-EVENT-REPORT.
Уведомление о результате фиксации хранения позволяет SCP сообщить SCU, принял ли он ответственность за фиксацию хранения экземпляров SOP, на которые ссылается запрос фиксации хранения. Это уведомление также используется для передачи информации об ошибках (т.е. фиксация хранения не могла быть достигнута для одного или нескольких указанных экземпляров SOP). Это уведомление должно быть вызвано через примитив N-EVENT-REPORT.
DICOM AE, заявляющие о соответствии данному классу SOP в роли SCU и/или SCP, должны поддерживать типы событий и информацию о событии, как указано в Таблице J.3-2.
Таблица J.3-2. Результат фиксации хранения — Информация о событии
|
См. Section J.3.3.1.1.1. |
||||
|
См. Section J.3.3.1.1.2. |
||||
|
См. Section J.3.3.1.1.2. |
||||
|
См. Section J.3.3.1.1.1. |
||||
|
См. Section J.3.3.1.1.2. |
||||
|
См. Section J.3.3.1.1.2. |
||||
|
См. Section J.3.3.1.1.1. |
||||
|
См. Section J.3.3.1.1.2. |
||||
|
См. Section J.3.3.1.1.2. |
||||
|
Этот атрибут должен быть предоставлен, если фиксация хранения для одного или нескольких экземпляров SOP прошла успешно |
||||
|
См. Section J.3.3.1.1.1. |
||||
|
См. Section J.3.3.1.1.2. |
||||
|
См. Section J.3.3.1.1.2. |
||||
Если он присутствует, Retrieve AE Title (0008,0054) должен находиться либо вне Referenced SOP Sequence (0008,1199), либо внутри одного или нескольких элементов этой последовательности, но не одновременно. Если он находится вне последовательности, то все экземпляры SOP в последовательности должны быть доступны для извлечения с указанного Retrieve AE Title. Если он находится внутри элемента этой последовательности, то экземпляр SOP, на который ссылается этот элемент, должен быть доступен для извлечения с указанного Retrieve AE Title.
Если они присутствуют, Storage Media File-Set ID (0088,0130) и Storage Media File-Set UID (0088,0140) должны находиться либо вне Referenced SOP Sequence (0008,1199), либо внутри одного или нескольких элементов этой последовательности, но не одновременно. Если они находятся вне последовательности, то все экземпляры SOP в последовательности должны быть доступны для извлечения из указанного набора файлов на носителе хранения. Если они находятся внутри элемента этой последовательности, то экземпляр SOP, на который ссылается этот элемент, должен быть доступен для извлечения из указанного набора файлов на носителе хранения.
Если 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.
SCP может попытаться выпустить N-EVENT-REPORT по той же ассоциации, но эта операция может завершиться неудачей, поскольку SCU вправе освободить в любое время ассоциацию, по которой он отправил запрос N-ACTION. Поскольку DICOM по умолчанию назначает инициатору ассоциации роль SCU, SCP (т.е. инициатор ассоциации) согласует роль SCP с помощью согласования выбора ролей SCU/SCP (см. PS3.7).
При ответе по другой ассоциации SCP должен использовать тот же AE Title, что и в исходной ассоциации, поскольку стандарт DICOM определяет сервис между двумя равноправными приложениями, каждое из которых идентифицируется AE Title. Таким образом, SCP должен быть единообразно идентифицирован для всех ассоциаций в конкретном сеансе сервиса фиксации хранения.
Необязательные атрибуты 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.
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. Однако это поведение выходит за рамки данного стандарта.
Для сервиса N-EVENT-REPORT не определены специфические для класса сервиса значения состояния. См. PS3.7 для общих кодов состояния ответа.
Этот раздел относится к кодам состояния, возвращаемым примитивом ответа N-EVENT-REPORT. Атрибут Failure Reason, возвращаемый в информации о событии результата фиксации хранения (см. PS3.3), описан в IOD фиксации хранения.
Класс SOP push-модели фиксации хранения должен быть однозначно идентифицирован UID класса SOP push-модели фиксации хранения, который должен иметь значение «1.2.840.10008.1.20.1».
Известный UID экземпляра SOP push-модели фиксации хранения должен иметь значение «1.2.840.10008.1.20.1.1».
Реализации, заявляющие о стандартном соответствии классу SOP push-модели фиксации хранения, должны соответствовать требованиям, описанным в данном разделе, и должны включить в своё заявление о соответствии информацию, описанную в данном разделе и его подразделах.
Реализация может заявить о соответствии данному классу SOP в роли SCU, SCP или обоих. Заявление о соответствии должно быть оформлено в формате, определённом в PS3.2.
Реализация, соответствующая данному классу SOP в роли SCU, должна отвечать требованиям соответствия для
Механизмы, используемые SCU для передачи экземпляров SOP на SCP, должны быть документированы.
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
SCU должен документировать в заявлении о соответствии поведение и действия, предпринимаемые SCU при получении примитива N-EVENT-REPORT (результат фиксации хранения).
SCU должен указать поведение и действия, выполняемые при получении кода успешного состояния (т.е. если и когда локальные копии экземпляров SOP удаляются).
SCU должен указать поведение и действия, выполняемые при получении кода состояния отказа (т.е. механизмы восстановления и т.д.).
Заявление о соответствии должно быть оформлено в формате, определённом в PS3.2
Реализация, соответствующая данному классу SOP в роли SCP, должна отвечать требованиям соответствия для
SCP должен документировать в заявлении о соответствии поведение и действия SCP при получении примитива N-ACTION (запрос фиксации хранения).
SCP должен указать параметры, определяющие уровень фиксации хранения, такие как:
SCP должен указать механизмы и характеристики получения сохранённых экземпляров SOP, такие как:
SCP должен указать, поддерживает ли он необязательные атрибуты Storage Media File-Set ID и UID в N-ACTION. Если эти атрибуты поддерживаются, SCP должен также указать, какие профили приложений хранения на носителях поддерживаются.
Заявление о соответствии должно быть оформлено в формате, определённом в PS3.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.
Модель вытягивания (Pull Model) была определена в более ранних версиях, но признана устаревшей. См. PS3.4-2001.
Перемещено в PS3.17
Сервисный класс базового управления рабочим списком определяет класс службы прикладного уровня, облегчающий доступ к рабочим спискам.
Рабочий список — это структура для представления информации, связанной с определённым набором задач. Он определяет конкретные детали для каждой задачи. Эта информация поддерживает выбор задачи, которая будет выполнена первой, и поддерживает выполнение этой задачи.
Одним из примеров является рабочий список, используемый для представления информации о запланированных процедурах визуализации на модальности визуализации и оператору этой модальности. Другой пример — рабочий список, представляемый на рабочей станции подготовки радиологических заключений, для указания того, какие исследования были выполнены и ожидают оформления заключения.
Настоящее приложение определяет службу для передачи таких рабочих списков. Ниже приведены характеристики данного сервисного класса:
Рабочий список должен запрашиваться прикладной сущностью (Application Entity, AE), связанной с приложением, на котором или посредством которого должны выполняться задачи, включённые в рабочий список. В этом запросе может использоваться ряд ключей поиска, определённых для каждого конкретного класса SOP рабочего списка.
Рабочий список состоит из элементов рабочего списка, каждый из которых связан с одной задачей. Элемент рабочего списка содержит атрибуты из различных объектов, связанных с задачей.
Настоящий сервисный класс не предназначен для предоставления всеобъемлющего обобщённого механизма запросов к базе данных, подобного SQL. Вместо этого сервисный класс базового управления рабочим списком ориентирован на базовые запросы с использованием небольшого набора общих ключевых атрибутов, используемых в качестве ключей сопоставления или возвращаемых атрибутов. Информационные модели базового рабочего списка не являются иерархическими.
Информационные модели базового рабочего списка всегда состоят из одного уровня запроса, который может состоять из одной или нескольких сущностей. В сервисном классе базового управления рабочим списком не проводится различие между иерархическим и реляционным использованием C-FIND.
Ключевые атрибуты служат двум целям: они могут использоваться как атрибуты сопоставления (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.
Для того чтобы выступать в роли поставщика сервисного класса (Service Class Provider, SCP) сервисного класса базового управления рабочим списком, прикладная сущность DICOM (AE) обладает информацией об атрибутах ряда управляемых записей рабочего списка. Эта информация организована в информационные модели рабочего списка.
Рабочие списки реализуются на основе чётко определённых информационных моделей. Конкретный класс SOP сервисного класса базового управления рабочим списком состоит из информативного обзора, определения информационной модели и группы служб DIMSE-C. В этом сервисном классе информационная модель играет роль, аналогичную информационной объектной дефиниции (IOD) большинства других сервисных классов DICOM.
Два равноправных 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.
Информационная модель рабочего списка идентифицируется классом SOP, согласованным при установлении ассоциации. Класс SOP состоит как из информационной модели, так и из группы служб DIMSE-C.
Определения информационных моделей для стандартных классов SOP сервисного класса базового управления рабочим списком определены в настоящем приложении. Определение информационной модели рабочего списка содержит:
Информационные модели базового рабочего списка состоят из одного уровня, включающего все атрибуты сопоставления и все возвращаемые ключевые атрибуты, которые могут быть отправлены от SCU к SCP в запросе и значения которых ожидается получить от SCP к SCU в каждом из ответов (или элементов рабочего списка). Значения атрибутов сопоставления в запросе определяют, какие элементы рабочего списка должны быть возвращены в ответах. Все ключевые атрибуты (атрибуты сопоставления и возвращаемые ключевые атрибуты) в запросе определяют, какие значения атрибутов возвращаются в ответах для данного рабочего списка.
Элемент рабочего списка имеет отношение «один к одному» с объектом реального мира, определяющим корень информационной модели базового рабочего списка. Кроме того, элемент рабочего списка связан с рядом других объектов из модели реального мира. Каждый из этих объектов реального мира представлен иерархией сущностей, организованной во (внутренней) модели «сущность-связь».
Атрибуты определяются для каждой сущности во внутренней модели «сущность-связь». Идентификатор в запросе C-FIND должен содержать значения, сопоставляемые с атрибутами сущностей информационной модели рабочего списка. Для любого запроса рабочего списка набор сущностей, для которых возвращаются атрибуты, должен определяться набором атрибутов сопоставления и возвращаемых ключевых атрибутов, указанных в идентификаторе.
Все атрибуты сущностей в информационной модели рабочего списка должны быть указаны как атрибут сопоставления (обязательный или необязательный), так и как возвращаемый ключевой атрибут.
Атрибуты сопоставления — это ключи, отбирающие элементы рабочего списка для включения в запрашиваемый рабочий список.
SCP одного из классов SOP сервисного класса базового управления рабочим списком должен поддерживать сопоставление на основе значений всех обязательных атрибутов сопоставления запроса C-FIND. Нескольким сущностям может соответствовать заданное значение обязательного ключа.
Если SCP управляет сущностью с неизвестным значением атрибута (то есть нулевой длины), неизвестное значение не должно совпадать ни с одним значением ключа сопоставления.
Несмотря на отсутствие средств выполнения сопоставления по таким сущностям, их можно запрашивать как возвращаемый ключевой атрибут, используя запрос C-FIND со значением нулевой длины (универсальное сопоставление) или с помощью одиночного подстановочного знака (сопоставление по маске).
SCU может по своему усмотрению предоставить любое подмножество обязательных атрибутов сопоставления.
В информационной модели рабочего списка набор атрибутов может быть определён как необязательные атрибуты сопоставления. Необязательные атрибуты сопоставления, содержащиеся в идентификаторе запроса C-FIND, могут вызывать два различных типа поведения в зависимости от поддержки сопоставления со стороны SCP. Если SCP
не поддерживает сопоставление по необязательному атрибуту сопоставления, то необязательный атрибут сопоставления должен игнорироваться при сопоставлении, но должен обрабатываться так же, как возвращаемый ключевой атрибут.
поддерживает сопоставление по необязательному атрибуту сопоставления, то необязательный атрибут сопоставления должен обрабатываться так же, как обязательный ключ сопоставления.
Значения возвращаемых ключевых атрибутов, которые должны быть получены с рабочим списком, указываются со значением нулевой длины (универсальное сопоставление) в запросе C-FIND. SCP должны поддерживать возвращаемые ключевые атрибуты, определённые информационной моделью рабочего списка, в соответствии с типом элемента данных (1, 1C, 2, 2C, 3), как определено в PS3.5.
Каждый атрибут сопоставления также должен рассматриваться как возвращаемый ключевой атрибут. Поэтому ответ C-FIND должен содержать, помимо значений запрошенных возвращаемых ключевых атрибутов, значения запрошенных атрибутов сопоставления.
Заявление о соответствии SCP перечисляет поддерживаемые возвращаемые ключевые атрибуты типа 3.
SCU может по своему усмотрению предоставить любое подмножество возвращаемых ключевых атрибутов.
SCU не может ожидать получения каких-либо возвращаемых ключевых атрибутов типа 3.
Возвращаемые ключевые атрибуты с VR, равным SQ, могут быть указаны либо с нулевой длиной, либо с элементом нулевой длины в последовательности.
Следующие типы сопоставления, определённые сервисным классом запроса/получения в Annex C, могут выполняться над атрибутами сопоставления в сервисном классе базового управления рабочим списком. Различные атрибуты сопоставления могут подпадать под разные типы сопоставления. Информационная модель рабочего списка определяет тип сопоставления для каждого обязательного атрибута сопоставления. Заявление о соответствии SCP должно определять тип сопоставления для каждого необязательного атрибута сопоставления. Типы сопоставления:
Следующий тип сопоставления, определённый сервисным классом запроса/получения в Annex C настоящей части, должен выполняться над возвращаемыми ключевыми атрибутами в сервисном классе базового управления рабочим списком.
См. 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, может влиять расширенное согласование нечёткого семантического сопоставления имён лиц.
Каждая информационная модель рабочего списка связана с одним классом SOP. Определена следующая информационная модель рабочего списка:
Одна служба DIMSE-C используется при построении классов SOP сервисного класса базового управления рабочим списком. Используется следующая операция DIMSE-C.
SCP некоторых классов SOP сервисного класса базового управления рабочим списком способны обрабатывать запросы с использованием операции C-FIND, как описано в PS3.7. Операция C-FIND является механизмом, посредством которого выполняются запросы. Совпадения по ключам, присутствующим в идентификаторе, возвращаются в ответах C-FIND.
SOP Class UID идентифицирует информационную модель рабочего списка, по которой должна выполняться операция C-FIND. Поддержка SOP Class UID подразумевается Abstract Syntax UID контекста представления, используемого данной операцией C-FIND.
Атрибут Priority определяет запрошенный приоритет операции C-FIND по отношению к другим операциям DIMSE, выполняемым тем же SCP.
Обработка запросов приоритета не является обязательной для SCP. Поддерживает ли SCP обработку приоритета и значение различных уровней приоритета должно быть указано в заявлении о соответствии SCP.
Как запрос, так и ответ C-FIND содержат идентификатор, закодированный как набор данных (см. PS3.5).
Идентификатор в запросе C-FIND должен содержать
значения ключевых атрибутов, сопоставляемые со значениями атрибутов, указанных в данном классе SOP.
условно — атрибут Specific Character Set (0008,0005). Этот атрибут должен включаться, если в каких-либо атрибутах идентификатора запроса могут использоваться расширенные или замещающие наборы символов. В противном случае он не должен включаться.
условно — атрибут Timezone Offset From UTC (0008,0201). Этот атрибут должен включаться, если ключевые атрибуты времени должны интерпретироваться явно в указанном локальном часовом поясе. В противном случае он не должен присутствовать, то есть не должен отправляться со значением нулевой длины.
Ключевые атрибуты и значения, допустимые для запроса, должны определяться в определении класса SOP для соответствующей информационной модели рабочего списка.
Ответ 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.
условно — атрибут Timezone Offset From UTC (0008,0201). Этот атрибут должен включаться, если какие-либо атрибуты времени в идентификаторе ответа должны интерпретироваться явно в указанном локальном часовом поясе. В противном случае он не должен присутствовать, то есть не должен отправляться со значением нулевой длины.
условно — атрибут HL7 Structured Document Reference Sequence (0040,A390) и его вложенные элементы последовательности. Этот атрибут должен включаться, если в идентификаторе имеются ссылки на структурированные документы HL7, например, в Pertinent Documents Sequence (0038,0100).
Table K.4-1 определяет значения кодов статуса, которые могут быть возвращены в ответе C-FIND. Общие значения кодов статуса и поля, связанные со значениями кодов статуса, определены для службы DIMSE C-FIND в PS3.7.
Table K.4-1. Значения статуса ответа C-FIND
Коды статуса возвращаются в сообщениях ответа 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 различала конкретные коды статуса в допустимом диапазоне.
Все 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.
Все 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.
Идентификатор не содержится в ответе со статусом Success. Полное определение см. в PS3.7.
Когда совпадений нет, ответы со статусом Pending не отправляются — отправляется только один ответ со статусом Success.
SCP должен генерировать ответ со статусом Failure, если он не может обработать запрос. Ответ Failure не должен содержать идентификатор.
Если SCP получает индикацию C-CANCEL-FIND до завершения обработки совпадений, он должен прервать процесс сопоставления и вернуть статус Cancel.
Для генерации совпадений используется следующая процедура.
Ключевые строки сопоставления, содержащиеся в идентификаторе запроса C-FIND, сопоставляются со значениями ключевых атрибутов для каждой сущности рабочего списка. Для каждой сущности, атрибуты которой соответствуют всем указанным строкам сопоставления, строится идентификатор. Этот идентификатор должен содержать все значения атрибутов данной сущности, соответствующие значениям в запросе C-FIND. Для каждого такого идентификатора возвращается ответ. Если ключи сопоставления отсутствуют, значит совпадений нет — возвращается ответ со статусом Success и без идентификатора.
Установление ассоциации — первая фаза любого экземпляра обмена данными между равноправными AE DICOM. Процедура согласования ассоциации, определённая в PS3.7, должна использоваться для согласования поддерживаемых классов SOP или мета-классов SOP.
Поддержка согласования выбора роли SCP/SCU необязательна. Расширенное согласование класса 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. Это поле определяет три или более подполя:
Значение нечёткого семантического сопоставления имён лиц и корректировки запроса по часовому поясу определено в Section K.2.2.2 и Section C.2.2.2.1.
Получатель ассоциации должен вернуть трёхбайтовое поле (три подполя), если инициатор ассоциации предложил трёхбайтовое поле (три подполя). Получатель ассоциации может вернуть более трёх байтов, если инициатор ассоциации предложил более трёх байтов. Трёхбайтовый ответ на запрос длиннее трёх байтов означает, что отсутствующее подполе должно рассматриваться как значение 0.
Получатель ассоциации для каждого предложенного подполя подэлемента расширенного согласования класса SOP либо принимает предложение инициатора ассоциации, вернув то же значение (1), либо отклоняет предложение, вернув значение (0).
Если подэлемент расширенного согласования класса SOP не возвращается получателем ассоциации, то нечёткое семантическое сопоставление имён лиц не поддерживается, а корректировка запроса по часовому поясу не определена в рамках ассоциации (условие по умолчанию).
Если подэлементы расширенного согласования класса SOP отсутствуют в индикации A-ASSOCIATE, они должны быть опущены в ответе A-ASSOCIATE.
Подэлемент расширенного согласования класса SOP состоит из последовательности обязательных полей, как определено в PS3.7. Длина этого поля должна составлять три или четыре байта.
Table K.5.1-1. Подэлемент расширенного согласования класса SOP (поле Service-Class-Application-Information) — A-ASSOCIATE-RQ
Этот подэлемент идентичен подэлементам расширенного согласования, используемым классами SOP запроса/получения. Однако реляционные запросы (байт 1) неприменимы, поскольку информационные модели рабочего списка являются одноуровневыми, а сопоставление даты-времени (байт 2) уже требуется информационными моделями рабочего списка, а поддержка преобразования Enhanced Multi-Frame Image неприменима (байт 5).
Подэлемент расширенного согласования класса SOP состоит из последовательности обязательных полей, как определено в PS3.7. Длина этого поля должна составлять три или четыре байта.
Table K.5.1-2. Подэлемент расширенного согласования класса SOP (поле Service-Class-Application-Information) — A-ASSOCIATE-AC
Класс SOP рабочего списка модальности, определённый в рамках сервисного класса базового управления рабочим списком, определяет класс службы прикладного уровня, облегчающий передачу модальности визуализации информации о запланированных этапах процедуры и сущностях, связанных с запланированными этапами процедуры. Как будет подробно показано ниже, часть информации, передаваемой механизмом рабочего списка, предназначена для использования самой модальностью визуализации, но большая часть информации предназначена для представления оператору модальности.
Этот рабочий список структурирован в соответствии с запланированными этапами процедуры. Этап процедуры — это единица обслуживания в контексте запрошенной процедуры визуализации.
Класс SOP рабочего списка модальности поддерживает следующие требования:
Проверка пациента (например, загрузка демографической информации о пациенте из информационной системы (IS) на модальность для проверки того, что обследуемое лицо является предполагаемым субъектом).
Выбор запланированного этапа процедуры из IS (например, загрузка информации об этапе процедуры из IS на модальность). Класс SOP рабочего списка модальности поддерживает два альтернативных способа реализации этого требования, поддерживающих различные методы организации работы отделения:
Модальность может получать список запланированных этапов процедуры из IS. Отображение списка и выбор из списка выполняются на модальности.
Список отображается, а выбор выполняется в IS. Это означает, что информация получается модальностью непосредственно перед началом запланированного этапа процедуры.
Однозначная увязка изображений DICOM со связанной информацией из IS (например, демографические данные пациента, описание процедуры, структура данных ID из IS, контекстная информация IS).
Получение из IS всех атрибутов, которые обязательно должны быть вставлены в объект изображения DICOM
Класс SOP рабочего списка модальности не предназначен для предоставления доступа ко всей информации и службам IS, которые могут представлять интерес для оператора модальности или лечащего врача. Его основная цель — эффективная работа оборудования получения изображений. Могут потребоваться классы SOP DICOM, такие как класс SOP запроса релевантной информации о пациенте, и не относящиеся к DICOM службы, выходящие за рамки класса SOP рабочего списка модальности.
Класс SOP рабочего списка модальности не поддерживает передачу информации от модальности к информационной системе.
В ответ на данный запрос C-FIND SCP может потребоваться отправить несколько ответов C-FIND (то есть по одному ответу C-FIND на каждый совпадающий элемент рабочего списка). Каждый элемент рабочего списка сосредоточен на одном запланированном этапе процедуры и связанной с ним информации. Диаграмма E-R, представленная на Figure K.6-1, изображает содержимое одного ответа C-FIND, а именно:
Таким образом, для данного запроса C-FIND конкретный запланированный этап процедуры появится только в одном из результирующих ответов C-FIND. Очевидно, что информация о запрошенной процедуре, запросе на услугу визуализации, посещении и пациенте может упоминаться в нескольких из этих ответов C-FIND.
Информационная модель рабочего списка модальности представлена диаграммой сущность-связь, показанной на рисунке Section K.6 -1.
Сущности, встречающиеся в сообщениях, связанных с классом SOP рабочего списка модальности, обязаны соответствовать модели рабочего списка модальности. Однако DICOM не определяет внутреннюю структуру базы данных.
Точкой входа рабочего списка модальности является сущность запланированного этапа процедуры.
Атрибуты рабочего списка запланированного этапа процедуры можно найти в следующих модулях в PS3.3.
Модуль идентификации пациента (Patient Identification Module)
Модуль демографических данных пациента (Patient Demographic Module)
Модуль медицинской информации пациента (Patient Medical Module)
Модуль идентификации посещения (Visit Identification Module)
Модуль запланированного этапа процедуры (Scheduled Procedure Step Module)
Модуль запроса на услугу визуализации (Imaging Service Request Module)
Table K.6-1 определяет атрибуты информационной модели рабочего списка модальности:
Table K.6-1. Атрибуты информационной модели рабочего списка модальности
|
Атрибуты запланированного этапа процедуры должны получаться только с помощью сопоставления последовательности. Scheduled Procedure Step Sequence должна содержать только один элемент. |
||||
|
Scheduled Station AE Title должно получаться только с помощью сопоставления одиночного значения. |
||||
|
Scheduled Procedure Step Start Date (0040,0002) должно получаться с помощью сопоставления одиночного значения или сопоставления по диапазону. См. примечание к Scheduled Procedure Step Start Time (0040,0003). |
||||
|
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 должно получаться с помощью сопоставления одиночного значения. |
||||
|
Scheduled Performing Physician's Name должно получаться с помощью сопоставления одиночного значения или сопоставления по маске. |
||||
|
SCP должен поддерживать Scheduled Procedure Step Description (0040,0007) и/или Scheduled Protocol Code Sequence (0040,0008). |
||||
|
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 и её элементы не должны использоваться для сопоставления |
||||
|
>>>>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support” |
||||
|
>>>>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support” |
||||
|
>>>>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support” |
||||
|
Требуется, если к данному запланированному этапу процедуры должна применяться премедикация. |
||||
|
Требуется, если к данному запланированному этапу процедуры должно применяться контрастное вещество. |
||||
|
>All other Attributes of the Scheduled Procedure Step Sequence |
||||
|
В этой последовательности может быть возвращён один или несколько элементов. |
||||
|
В этой последовательности должно быть возвращено ноль или один элемент. |
||||
|
>>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support” |
||||
|
В этой последовательности должен быть возвращён один или несколько элементов. |
||||
|
Specimen Preparation Sequence (0040,0610), если присутствует, описывает уже выполненные этапы подготовки, а не запланированные этапы процедуры |
||||
|
Это значение может совпадать с Container Identifier (0040,0512). |
||||
|
SCP должен поддерживать Requested Procedure Description (0032,1060) или Requested Procedure Code Sequence (0032,1064), либо оба атрибута. |
||||
|
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” |
||||
|
В этой последовательности может быть возвращён только один элемент. |
||||
|
>Include Таблица 8-2b «Базовый макрос кодированной записи с необязательной поддержкой ключа сопоставления и необязательным значением» |
||||
|
All other Attributes of the Requested Procedure Module |
||||
|
All other Attributes of the Imaging Service Request Module |
||||
|
All other Attributes of the Visit Identification Module |
||||
|
All other Attributes of the Visit Status Module |
||||
|
All other Attributes of the Visit Relationship Module except those explicitly included in this table (see Note 3) |
||||
|
All Attributes from the Patient Relationship Module except those explicitly included in this table (see Note 3) |
||||
|
Patient Name должно получаться с помощью сопоставления одиночного значения или сопоставления по маске. |
||||
|
Patient ID должно получаться с помощью сопоставления одиночного значения. |
||||
|
All other Attributes of the Patient Identification Module |
||||
|
>>Include Table 8-4a “Enhanced Coded Entry Macro with Optional Matching Key Support and Mandatory Meaning” |
||||
|
>>Include Table 8-4a “Enhanced Coded Entry Macro with Optional Matching Key Support and Mandatory Meaning” |
||||
|
>>Include Table 8-4a “Enhanced Coded Entry Macro with Optional Matching Key Support and Mandatory Meaning” |
||||
|
Языки, которые можно использовать для общения с пациентом. Если возвращается, 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 должна содержать только один элемент. |
||||
|
>>Include Table 8-4a “Enhanced Coded Entry Macro with Optional Matching Key Support and Mandatory Meaning” |
||||
|
All other Attributes of the Patient Demographic Module |
||||
|
Pertinent Documents Sequence должна получаться только с помощью универсального сопоставления |
||||
|
>>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support” |
||||
|
All other Attributes of the Patient Medical Module |
||||
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).
Каждый модуль содержит атрибут Comment. Он может использоваться для передачи неструктурированной информации, которая может отображаться оператору модальности.
Причина такого исключения — обеспечить, чтобы атрибуты, которые могут присутствовать в нескольких модулях, включались только один раз со значением, относящимся только к одному модулю (например, Referenced Study Sequence (0008,1110) должна включаться один раз со значением, определённым в модуле Requested Procedure Module).
The use of Specific Character Set is discussed in Section K.4.1.1.3.1 and Section K.4.1.1.3.2.
Значения 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
|
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 |
||||
|
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. См. Section K.4.1.1.3 |
||||
Реализация может соответствовать классу SOP рабочего списка модальности в роли SCU или SCP. Заявление о соответствии должно быть в формате, определённом в PS3.2.
Реализация, соответствующая классу 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) при кодировании запросов и интерпретации ответов.
Реализация, соответствующая классу 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 (если поддерживается), и перечислить атрибуты, для которых это применимо.
Устарело. См. PS3.4-2011.
Перемещено в PS3.17
Устарело. См. PS3.17-2011.
Устарело. См. PS3.4-2004.
Устарело. См. PS3.17.
Классы SOP хранения состояния мягкокопийного представления расширяют функциональность сервисного класса хранения (определённого в Annex B), добавляя возможность передавать предполагаемое состояние представления или записывать существующее состояние представления. Классы SOP определяют информацию и поведение, которые могут использоваться для представления (отображения) изображений, на которые есть ссылки внутри классов SOP.
Они включают возможности указания:
преобразований контраста серой шкалы, включая LUT модальности, VOI и представления
выбора области изображения для отображения и того, следует ли её поворачивать или отражать
аннотаций, относящихся к изображению и дисплею, включая графику, текст и наложения (overlays)
смешивания (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 должен сделать состояние представления доступным пользователю устройства, и, если оно выбрано пользователем, должен применить все преобразования, сохранённые в состоянии, тем способом, каким они определены в Стандарте.
Например, устройство получения изображений может автоматически сохранять подходящие состояния представления для серий изображений по мере их реконструкции, представляющие адекватные значения по умолчанию. Пользователь или алгоритм может впоследствии определить более подходящее состояние представления, более эффективно отображающее содержимое изображения, либо записать некоторую аннотацию, непосредственно связанную с изображением, и сохранить это как другое состояние представления для изображения. Приложение впоследствии может отображать изображение, автоматически выбирая использование более недавно сохранённого или более специфичного состояния представления, либо может использовать более общее состояние представления по умолчанию для всех изображений, но уведомлять пользователя о доступности альтернативных состояний представления.
Выбор одного и того же состояния представления для отображения изображения серой шкалы на двух устройствах, заявляющих о соответствии этим классам SOP, через определение пространства P-значений подразумевает, что отображаемое изображение на обоих устройствах будет перцептивно схожим в пределах, определённых в PS3.14 Grayscale Standard Display Function, независимо от фактических возможностей систем отображения.
Выбор одного и того же состояния представления для отображения цветного изображения на двух устройствах, заявляющих о соответствии этим классам SOP, через определение пространства PCS-значений подразумевает, что отображаемое изображение на обоих устройствах будет выглядеть схожим по цвету независимо от фактических возможностей систем отображения.
Цветные изображения DICOM без встроенного необязательного профиля ICC не имеют определённого цветового пространства, независимо от их представления. Реализация, создающая состояние мягкокопийного представления цвета с профилем ICC, явно определяет цветовое пространство, в котором следует интерпретировать это изображение, даже если оно не было известно на момент создания изображения. Часто в таких обстоятельствах в состоянии представления используется хорошо известное цветовое пространство, такое как sRGB.
Классы SOP хранения состояния мягкокопийного представления поддерживают последовательность преобразований, полностью определяющую преобразование сохранённого изображения в отображаемое изображение.
Последовательность преобразований от сохранённых значений пикселей в P-значения или PCS-значения явно определена в концептуальной модели. Фактически реализованная последовательность может отличаться, но должна приводить к тому же внешнему виду. Figure N.2-1 описывает эту последовательность преобразований.
Хотя класс SOP хранения составных изображений может не включать некоторые модули, входящие в описанные преобразования, классы SOP хранения состояния мягкокопийного представления их включают. Например, класс SOP хранения изображений CT включает Rescale Slope и Intercept в модуле CT Image Module, но не включает модуль Modality LUT Module, и поэтому ограничен описанием линейных преобразований. Сохранённое состояние представления, ссылающееся на экземпляр SOP хранения изображений CT, может включать Modality LUT и, следовательно, может применять нелинейное преобразование.
Для затвора (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 в экземпляр изображения.
Операция Modality LUT применяется только к значениям серой шкалы.
Преобразование Modality LUT преобразует зависящие от производителя значения пикселей в значения пикселей, значимые для модальности и не зависящие от производителя (например, число Хаунсфилда для модальностей CT, оптическая плотность для дигитайзеров плёнки). Они могут представлять физические единицы или быть безразмерными. Modality LUT в состоянии представления зависит от модальности и аналогичен тому же модулю в изображении.
В некоторых случаях, например, в классе SOP хранения изображений CT, тот же концептуальный этап, что и Modality LUT, указывается в иной форме, например, как атрибуты Rescale Slope и Rescale Intercept в модуле CT Image Module, хотя модуль Modality LUT Module не входит в IOD CT Image.
Значения пикселей изображения со значением 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 или эквивалентные атрибуты в изображении не должны использоваться.
Операция Mask применяется только к значениям серой шкалы.
Преобразование маски может применяться в случае многокадровых изображений, для которых другие кадры с фиксированной позицией кадра или временным интервалом относительно текущего кадра могут вычитаться из текущего кадра. Несколько кадров маски могут быть усреднены и сдвинуты на субпиксельную величину перед вычитанием.
Это преобразование использует модуль Mask Module, применяемый в классе SOP хранения изображений рентгеновской ангиографии, хотя оно может применяться к любому экземпляру SOP хранения изображений, содержащему многокадровое изображение.
В случае рентгеновских изображений вычитание определено происходящим в пространстве, логарифмическом относительно интенсивности рентгеновского излучения. Если сохранённые значения пикселей ещё не находятся в таком пространстве, перед вычитанием должно быть выполнено определённое реализацией преобразование в такое пространство. Если присутствует модуль Modality LUT Module наряду с модулем Mask Module, то Modality LUT должен определять преобразование в такое логарифмическое пространство, иначе он не должен присутствовать (даже если Modality LUT может присутствовать в изображении(-ях), на которое есть ссылка, которое должно игнорироваться).
В случае изображения 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 .
В случае изображения XA или XRF, если Pixel Intensity Relationship (0028,1040) равен LIN, то Modality LUT не присутствовал бы в изображении, но Modality LUT должен был бы присутствовать в состоянии представления, поскольку для вычитания требуются логарифмические значения.
В случае изображения XA или XRF, если Pixel Intensity Relationship (0028,1040) в изображении равен DISP, то, хотя Modality LUT может присутствовать или не присутствовать в изображении (для отображения значений пикселей обратно в линейную зависимость от интенсивности рентгеновского излучения), в состоянии представления присутствовал бы другой Modality LUT, если бы создатель состояния представления мог создать преобразование значений пикселей DISP в логарифмическое пространство для вычитания, либо Modality LUT в состоянии представления был бы тождественным преобразованием, если бы было известно, что значения пикселей DISP уже являются логарифмическими значениями, требуемыми для вычитания.
Результатом будет знаковое значение с битовой длиной на один бит больше, чем у исходных кадров.
Когда разница между соответствующими значениями пикселей отсутствует, пиксель вычтенного изображения будет иметь значение 0.
Если пиксель в текущем кадре имеет большее значение, чем в кадре маски, результирующий кадр должен иметь положительное значение. Если он имеет меньшее значение, результирующий кадр должен иметь отрицательное значение.
Операция 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 или эквивалентные значения в изображении не должны использоваться.
Операция 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 .
Поскольку конвейер преобразования серой шкалы полностью определяет все преобразования, применённые к сохранённым значениям пикселей в объекте изображения, на который есть ссылка, значение 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 для достижения инверсии полярности.
Минимальное P-значение (ноль) всегда предписывает отображение наименьшей интенсивности.
Модуль Softcopy Presentation LUT Module всегда присутствует в состоянии представления. Если Presentation LUT присутствует в изображении, должен использоваться Presentation LUT состояния представления вместо Presentation LUT изображения.
Операция преобразования Profile Connection Space применяется только к цветным изображениям, включая изображения истинного цвета (например, RGB) и псевдоцвета (например, PALETTE COLOR), изображения серой шкалы, для которых в состоянии представления указан Palette Color LUT, и выходные значения RGB операции смешивания.
Профиль ICC является входным профилем (Input Profile). То есть он описывает цветовые характеристики (возможно, гипотетического) устройства, использованного для создания входных цветовых значений.
Замысел состоит в том, что устройство визуализации будет использовать эту информацию для достижения согласованности цвета. Обычно это выполняется путём калибровки выходного устройства для создания профиля ICC Display или Output Profile, преобразования значений пикселей с использованием входного профиля ICC в пространство соединения профилей, с последующим преобразованием с использованием профиля ICC Display или Output Profile в значения, подходящие для визуализации на выходном устройстве. Однако точные используемые механизмы выходят за рамки определения Стандарта.
Способ достижения согласованности цвета в значительной степени зависит от характера материала и назначения приложения. Этот процесс сложнее, чем простое достижение колориметрической точности, которое тривиально, но не даёт удовлетворительных результатов. Преобразования могут учитывать такие вопросы, как
Реализации схем управления цветом обычно предоставляются операционными системами, библиотеками и наборами инструментов, и точные детали обычно находятся вне контроля разработчика приложения DICOM. Соответственно, обычно достаточно определить источник значений пикселей и соответствующий входной профиль ICC для устройства, которое их получило или создало.
Когда цветное изображение визуализируется на дисплее серой шкалы, поведение не определено. Поскольку значение L* представления CIELab пространства PCS не сильно отличается от модели Бартена, используемой в GSDF, разумным подходом было бы интерпретировать его как P-значение.
Профиль ICC всегда присутствует в состоянии представления цвета, псевдоцвета или смешивания. Если профиль ICC присутствует в изображении, должен использоваться профиль ICC состояния представления вместо профиля ICC изображения.
D50 означает излучение абсолютно чёрного тела объекта при температуре 5000 градусов К и включает много красного, что выглядит «естественно». D65 более синий, больше похож на «облачные дни», но человеческий глаз более чувствителен к синему. В то время как мониторы, по-видимому, находятся в диапазоне D50–D100, негатоскопы имеют около D110 (11000K).
PCS ICC всегда использует точку белого D50.
Во входном профиле ICC тег chromaticAdaptationTag кодирует преобразование цвета XYZ от фактического источника освещения к источнику освещения PCS (D50) и может быть полезен, если фактический источник освещения не является D50. Фактический источник освещения может также быть определён в mediaWhitePointTag. Однако при перцептивном намерении визуализации ни один из этих тегов не обязан использоваться системой управления цветом, и они не имеют какого-либо заданного поведения визуализации (в отличие от их использования с абсолютным и относительным колориметрическими намерениями визуализации).
Определение требуемой или рекомендуемой точки белого для визуализации выходит за рамки DICOM, поскольку подходящий выбор зависит от знания характеристик устройства отображения или носителя и среды просмотра.
Общие пространственные преобразования и преобразования аннотаций применяются к любым независимым от устройства значениям — будь то P-значения серой шкалы или PCS-значения цвета — для любого типа состояния представления.
Значения, с которыми визуализируются аннотации, кодируются как независимые от устройства значения — либо как P-значения серой шкалы, либо как PCS-значения цвета. В случае PCS-значений кодируются значения CIELab, определённые со ссылкой на источник света D50.
Состояния представления серой шкалы могут указывать аннотации в цвете для визуализации на цветном выходном устройстве.
Механизм отображения P-значений серой шкалы и PCS-значений цвета на один и тот же дисплей зависит от реализации и не определён Стандартом.
Преобразование Shutter предоставляет возможность исключить периметр за пределами области изображения. Может быть указан уровень серого для замены области под затвором.
Одна форма этого преобразования использует модуль Display Shutter Module, применяемый в классе SOP хранения изображений рентгеновской ангиографии, хотя она может применяться к любому экземпляру SOP хранения изображений, включая однокадровые изображения.
Другая форма использует битовое наложение (overlay) для указания произвольных областей изображения, которые следует исключить из отображения путём замены указанным уровнем серого, как описано в модуле Bitmap Display Shutter Module.
Преобразование аннотации до пространственного преобразования включает применение битовых наложений, как определено в модуле Overlay Plane Module, и свободного неформатированного текста или векторной графики, как описано в модуле Graphic Annotation Module, определённых в пространстве пикселей изображения (в отличие от пространства отображаемой области).
Некоторые модальности могут не доставлять изображение в желаемом повороте и требуют указания поворота в желаемое положение для представления. Это преобразование, указанное в модуле Spatial Transformation Module, включает поворот на 90, 180, 270 градусов по часовой стрелке с последующим горизонтальным отражением (L <--> R). Поворот на произвольный угол не поддерживается.
Кроме того, выбор области пространства пикселей изображения для отображения указывается в модуле Displayed Area Module. Это может иметь эффект увеличения (или уменьшения) этой области в зависимости от того, какому физическому размеру дисплею предписано визуализировать выбранную область. Если это так, метод интерполяции (или субдискретизации) зависит от реализации.
Преобразование аннотации после пространственного преобразования включает применение свободного неформатированного текста или векторной графики, как описано в модуле Graphic Annotation Module, определённых в пространстве отображаемой области (в отличие от пространства пикселей изображения).
Это подразумевает, что пространство отображаемой области определяется как изображение после применения всех пространственных преобразований.
Эти аннотации визуализируются в отображаемом пространстве, хотя они могут быть привязаны к точкам либо в отображаемой области, либо в пространстве пикселей изображения.
Модель преобразования смешивания серой шкалы в цвет применяется только к паре значений серой шкалы, одно из которых сначала отображается в цвет, а затем накладывается на другое. Результирующие значения являются независимыми от устройства цветовыми PCS-значениями. Этот процесс проиллюстрирован на Figure N.2-3.
Для целей настоящего раздела пиксели упоминаются как сохранённые значения пикселей, а преобразования определены как поточечные операции над этими значениями. Однако вероятно, что пиксели из накладываемого и/или базового наборов изображений будут пространственно передискретизированы и, следовательно, интерполированы или продублированы. Такие операции не влияют на концептуальный конвейер.
Преобразования Modality LUT и VOI LUT применяются к сохранённым значениям пикселей базового изображения.
Выходной диапазон преобразования VOI LUT зависит либо от ширины линейного окна, либо от диапазона выходных значений LUT, определённого дескриптором LUT (LUT Descriptor). Концептуально, для целей описания последующей операции смешивания, наименьшее значение пикселя из диапазона отображается в 0.0, наибольшее значение пикселя отображается в 1.0, а все промежуточные значения линейно отображаются в интервал [0.0..1.0].
Преобразования 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 в экземплярах изображений игнорируются.
Входными данными операции смешивания являются значения серой шкалы от 0.0 до 1.0 из базового изображения (Yu) и значения RGB от 0.0 до 1.0 из накладываемого изображения (RGBs), а также значение непрозрачности от 0.0 до 1.0 (A).
Выходом является единое изображение, содержащее значения RGB (RGBo), смешанные следующим образом:
Класс SOP хранения состояния представления в оттенках серого XA/XRF (XA/XRF Grayscale Softcopy Presentation State Storage SOP Class) поддерживает последовательность преобразований, которая полностью определяет преобразование сохранённого изображения в отображаемое изображение.
Последовательность преобразований из сохранённых значений пикселей в P-значения явно определена в концептуальной модели. Фактически реализованная последовательность может отличаться, но должна приводить к тому же самому внешнему виду. Figure N.2.5-1 описывает эту последовательность преобразований.
Преобразование 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 может быть указан покадрово и может отличаться для кадров маски и контрастных кадров.
Для изображений класса SOP X-Ray Angiographic Image Storage или X-Ray RF Image Storage состояние представления в оттенках серого XA/XRF позволяет указывать Pixel Intensity Relationship LUT покадрово. Это расширение Modality LUT изображения, который применим только ко всем кадрам изображения в целом.
В случае изображения 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 .
В случае изображения 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 (для преобразования значений пикселей в логарифмические значения), поскольку для вычитания требуются логарифмические значения.
В случае изображения 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 уже являются логарифмическими значениями, требуемыми для вычитания.
Примечания 2, 3 и 4 обобщены в Table N.2.5.1-1
Таблица N.2.5.1-1. Сводка предоставления функции LUT для вычитания
Модель расширенного преобразования смешивания применяется к нескольким входным данным цвета 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.
Пиксели заполнения (padding) во входных данных получают нулевое значение непрозрачности и должны быть установлены в 0 для красного, зелёного и синего.
Метод переднего плана смешивает два входных набора данных. Первый входной набор использует непрозрачность Relative Opacity (0070,0403), а второй входной набор использует непрозрачность (1 - Relative Opacity (0070,0403)).
Если оба входных значения являются значениями заполнения, результатом является значение заполнения.
Если одно из значений является значением заполнения, результатом является значение, не являющееся заполнением.
Если оба пикселя имеют значения, результат равен Relative Opacity * первое значение + (1 - Relative Opacity) * второе значение.
Режим равного смешивания смешивает два или более входных набора данных, где для каждого местоположения пикселя непрозрачность вычисляется как 1.0, делённое на число пикселей, не являющихся заполнением. Результирующий пиксель смешивает все пиксели, не являющиеся заполнением, используя вычисленную непрозрачность.
Если входное значение пикселя является значением заполнения, то Relative Opacity для этого входного пикселя равна нулю.
Если входное значение пикселя не является значением заполнения, то Relative Opacity для этого пикселя равна 1 / (число входных пикселей, не являющихся заполнением).
Результирующее значение — это сумма по всем входным пикселям произведения входного значения пикселя на Relative Opacity.
Если все входные пиксели являются значениями заполнения, результатом является значение заполнения.
В дополнение к поведению для класса услуг хранения, указанному в 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) в другую или для явного указания взаимосвязи между членами двух наборов изображений и может быть способно передискретизировать базовые и накладываемые наборы изображений, отличающиеся друг от друга ориентацией и пространственным разрешением внутри плоскости и между плоскостями.
В дополнение к требованиям заявления о соответствии для класса услуг хранения, указанным в Section B.4.3, для классов SOP хранения состояния представления в виде мягкой копии указаны следующие дополнительные требования:
В заявлении о соответствии любой реализации, заявляющей о соответствии классу SOP хранения состояния представления в виде мягкой копии в роли SCU, должны быть документированы следующие вопросы:
Для SCU класса SOP хранения состояния представления в виде мягкой копии, создающего экземпляр SOP этого класса SOP, — способ, которым атрибуты, связанные с представлением, получаются из отображаемого изображения, вмешательства оператора или значений по умолчанию, и то, как они включаются в IOD.
Для SCU класса SOP хранения состояния представления в виде мягкой копии — классы SOP хранения изображений, также поддерживаемые SCU и на которые могут ссылаться экземпляры класса SOP хранения состояния представления в виде мягкой копии.
Для SCU класса SOP хранения состояния представления в виде мягкой копии — поддерживает ли он Compound Graphic Sequence (0070,0209), и с указанием того, какие составные типы графики могут быть сгенерированы, включая дополнительные частные определённые типы составной графики.
В заявлении о соответствии любой реализации, заявляющей о соответствии классу SOP хранения состояния представления в виде мягкой копии в роли SCP, должны быть документированы следующие вопросы:
Для SCP класса SOP хранения состояния представления в виде мягкой копии, отображающего изображение, на которое ссылается экземпляр SOP этого класса SOP, — способ, которым атрибуты, связанные с представлением, используются для влияния на отображение изображения.
Для SCP класса SOP хранения состояния представления в виде мягкой копии — классы SOP хранения изображений, также поддерживаемые SCP и на которые могут ссылаться экземпляры класса SOP хранения состояния представления в виде мягкой копии.
Для SCP класса SOP хранения состояния представления в виде мягкой копии — поддерживает ли он Compound Graphic Sequence (0070,0209), и какие составные типы графики могут быть визуализированы, включая дополнительные частные определённые типы составной графики.
Классы SOP хранения структурированных отчётов расширяют функциональность класса услуг хранения (определённого в Annex B) дополнительным поведением и требованиями соответствия.
Модификаторы концепции 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), в элементах содержимого, перефразированных из другого источника.
Концепция расширяемости подразумевает, что получатель может столкнуться с элементами содержимого, типами значений и типами взаимосвязей, которые непредвиденны и неподдерживаемы и, следовательно, потенциально не могут быть визуализированы.
Реализация должна указывать в своём заявлении о соответствии, какие элементы содержимого, типы значений и типы взаимосвязей она создаёт.
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, будут сохранены и доступны.
Объекты 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 .
Концепция расширяемости подразумевает, что получатель может столкнуться с элементами содержимого, типами значений и типами взаимосвязей, которые непредвиденны и неподдерживаемы и, следовательно, потенциально не могут быть визуализированы.
Реализация должна указывать в своём заявлении о соответствии, какие элементы содержимого, типы значений и типы взаимосвязей она поддерживает.
Поскольку из-за нераспознанного содержимого может оказаться невозможным однозначно визуализировать всё содержимое целиком, SCP, намеревающийся отобразить или иным образом визуализировать экземпляр SOP расширяемого SR,
Устройство, являющееся SCU класса SOP хранения SR, может изменять информацию в экземпляре SOP, который оно ранее отправило или получило. Когда этот экземпляр SOP изменяется и отправляется SCP, ему должен быть присвоен новый SOP Instance UID, если выполняется любое из следующих условий:
В дополнение к требованиям заявления о соответствии для класса услуг хранения, указанным в Section B.4.3, для классов SOP хранения структурированных отчётов указаны следующие дополнительные требования:
В заявлении о соответствии любой реализации, заявляющей о соответствии классам SOP хранения структурированных отчётов в роли SCU, должно быть документировано следующее:
Классы SOP хранения изображений или других составных объектов, также поддерживаемые SCU и на которые могут ссылаться экземпляры класса SOP хранения структурированных отчётов.
Диапазон типов значений и типов взаимосвязей, поддерживаемых SCU.
Условия, при которых для существующего документа SR генерируется новый SOP Instance UID.
Если реализация предоставляет функциональность Query/Retrieve экземпляров SOP структурированных отчётов в роли SCU — поддерживает ли она необязательные ключи Concept Name Code Sequence или Content Template Sequence.
Описание типов значений и типов взаимосвязей, поддерживаемых SCU, особенно важно для класса SOP расширяемого SR.
В заявлении о соответствии любой реализации, заявляющей о соответствии классу SOP Mammography CAD SR в роли SCU, должно быть документировано следующее:
В заявлении о соответствии любой реализации, заявляющей о соответствии классу SOP Chest CAD SR в роли SCU, должно быть документировано следующее:
В заявлении о соответствии любой реализации, заявляющей о соответствии классу SOP Colon CAD SR в роли SCU, должно быть документировано следующее:
В заявлении о соответствии любой реализации, заявляющей о соответствии классам 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»
В заявлении о соответствии любой реализации создателя SR, заявляющей о соответствии классу SOP Simplified Adult Echo SR в роли SCU, должно быть документировано следующее:
Список всех кодов измерений из CID 12300 “Core Echo Measurement”, поддерживаемых устройством для использования в TID 5301 “Pre-coordinated Cardiac Measurement”.
Список исходных кодов измерений, поддерживаемых устройством для использования в строке 1 или 2 TID 5302 “Post-coordinated Cardiac Measurement”.
Опционально — таблица постскоординированных значений модификаторов TID 5302, связанных с каждым кодом измерения.
Список любых кодов расширения, добавленных к CID 12301 “Measurement Selection Reason”, CID 12304 “Cardiovascular Measured Property”, CID 12305 “Basic Echo Anatomic Site”, CID 12307 “Cardiac Phase and Time Point”, CID 12227 “Echocardiography Measurement Method”.
В заявлении о соответствии любой реализации, заявляющей о соответствии классу 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.
В заявлении о соответствии любой реализации, заявляющей о соответствии классам SOP Mammography CAD SR, Chest CAD SR или Colon CAD SR в роли SCP, должно быть документировано следующее:
Класс услуг журналирования событий приложения определяет класс услуг на уровне приложения, который облегчает сетевую передачу записей журнала событий для их регистрации или записи в центральном местоположении.
Класс услуг журналирования событий приложения охватывает класс специфичных для приложения журналов (например, журналов процедурных событий), управляемых медицинским приложением. Класс услуг журналирования событий приложения не определяет средства доступа к центральным журналам.
Два равноправных AE DICOM реализуют класс SOP класса услуг журналирования событий приложения, при этом одно выступает в роли SCU, а другое — в роли SCP. Классы SOP класса услуг журналирования событий приложения реализуются с использованием услуги DIMSE-N N-ACTION, как определено в PS3.7.
Услуга N-ACTION передаёт следующую семантику:
Процедура согласования ассоциации используется для согласования поддерживаемых классов SOP. PS3.7 определяет процедуру ассоциации. Класс услуг журналирования событий приложения не поддерживает расширенное согласование.
Освобождение ассоциации не должно оказывать никакого влияния на содержимое журнала, управляемого SCP.
Класс 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 могут использоваться для идентификации устройства как участника конкретной процедуры.
Услуги DIMSE-N, применимые к классу SOP журналирования процедурных событий, показаны в Table P.2-1.
Услуги и протокол DIMSE-N определены в PS3.7.
AE DICOM, заявляющие о соответствии этому классу SOP в роли SCU, должны инициировать запрос N-ACTION. AE DICOM, заявляющие о соответствии этому классу SOP в роли SCP, должны поддерживать запрос N-ACTION.
AE DICOM, заявляющие о соответствии этому классу SOP в роли SCU и/или SCP, должны поддерживать Action Type и Action Information в N-ACTION-RQ, как указано в Table P.2-2.
Таблица P.2-2. Информация о действии журналирования процедурных событий
|
(Обязательно, если используется расширенный или заменяющий набор символов) |
||||
|
All other Attributes of the SR Document Content Module using Procedure Log IOD Content Constraints |
См. Раздел P.2.2.1.3 |
SCU может предоставить атрибуты Patient ID (0010,0020), Study Instance UID (0020,000D), Study ID (0020,0010) и/или Performed Location (0040,0243), чтобы позволить SCP сопоставить N-ACTION с исследованием, для которого создаётся журнал процедуры.
Атрибут Synchronization Frame of Reference UID (0020,0200) определяет временную систему координат (frame of reference) для атрибутов Observation DateTime (0040,A032) в записи Procedural Event. Если значения атрибута Observation DateTime не синхронизированы в идентифицируемой системе координат, атрибут должен иметь нулевую длину.
Запись Procedural Event должна передаваться в (верхнеуровневом) элементе содержимого и подчинённых элементах содержимого, как указано определением модуля SR Document Content Module в PS3.3.
Верхнеуровневый и подчинённые элементы содержимого должны быть построены в соответствии с Procedure Log IOD Content Constraints из PS3.3.
Эти ограничения определяют использование BTID 3001 Procedure Log, определённого в PS3.16, а также конкретное особое использование атрибутов Observation DateTime (0040,A032).
TID 3001 требует явного указания контекста наблюдателя (Observer Context) верхнеуровневого CONTAINER через TID 1002.
В одном сообщении N-ACTION-RQ может быть включено несколько событий (подчинённых элементов содержимого).
SCU должен запрашивать журналирование событий, происходящих во время исследования, используя примитив запроса N-ACTION.
SCU должен получать ответы N-ACTION. Действия, предпринимаемые при коде статуса ответа об ошибке (Failure) или при отсутствии ответа SCP, зависят от реализации.
SCP должен управлять созданием экземпляров SOP услуги хранения журнала процедуры. Он должен получать через примитив запроса N-ACTION запросы на журналирование событий, происходящих во время исследования. SCP должен (в соответствии с ограничениями, зависящими от приложения) включать эти записи событий в экземпляр SOP журнала процедуры для указанного исследования.
SCP должен возвращать через примитив ответа N-ACTION код статуса ответа N-ACTION, применимый к соответствующему запросу действия.
Table P.2-3 определяет конкретные значения кодов статуса, которые могут быть возвращены в ответе N-ACTION. Дополнительные общие коды статуса ответа см. в PS3.7.
Таблица P.2-3. Статус ответа
При любом статусе ответа, указывающем на успех или предупреждение, идентификаторы исследования, в которое было записано событие, должны быть возвращены в Action Reply N-ACTION-RSP, как указано в Table P.2-4.
Класс SOP журналирования процедурных событий должен однозначно идентифицироваться UID класса SOP журналирования процедурных событий, который должен иметь значение «1.2.840.10008.1.40».
Общеизвестный (well-known) UID экземпляра SOP журналирования процедурных событий должен иметь значение «1.2.840.10008.1.40.1».
Заявление о соответствии AE DICOM должно быть оформлено, как определено в PS3.2.
SCU должен документировать в своём заявлении о соответствии поведение и действия, которые заставляют SCU генерировать примитив N-ACTION (уведомление о процедурном событии). Он должен указать шаблон, используемый для построения информации о событии, и схемы кодирования, используемые для кодированных записей в информации о событии.
SCU должен документировать идентификаторы, которые он отправляет для целей сопоставления, и способ получения этих атрибутов (например, через запрос Modality Worklist, ручной ввод и т. д.).
SCU должен документировать поведение и действия, выполняемые при получении статуса успеха, предупреждения или отказа.
SCU должен документировать механизмы, используемые для установления синхронизации времени и указания Synchronization Frame of Reference UID.
SCP должен документировать в своём заявлении о соответствии способ, которым он использует полученные идентификаторы для сопоставления N-ACTION (уведомления о процедурном событии) с конкретной процедурой.
SCP должен документировать поведение и действия, которые заставляют SCP генерировать статус успеха, предупреждения или отказа для полученного N-ACTION.
SCP должен документировать поведение и действия, которые заставляют SCP генерировать экземпляр SOP журнала процедуры, включающий полученную информацию о событии.
SCP должен документировать способ присвоения значения атрибуту Observation Datetime (0040,A032), когда Synchronization Frame of Reference UID, предоставленный SCU, отсутствует или отличается от такового у SCP.
Класс 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.
SCP этого класса услуг не обязательно является системой журнала введения лекарственных препаратов, но может быть шлюзовой системой между этой услугой DICOM и интерфейсом HL7 или частным интерфейсом системы MAR. Такая архитектура реализации выходит за рамки Стандарта DICOM.
Этот класс SOP не ограничивается только указанием лекарственных препаратов, хотя условное название целевого журнала — журнал введения лекарственных препаратов. Класс SOP может также использоваться для записи имплантации терапевтических устройств, включая как стенты с лекарственным покрытием, так и без него, протезные и сердечно-сосудистые устройства, имплантируемые инфузионные насосы и т. д.
Авторизация операторов на уровне приложения для целей записи в MAR отличается от любого механизма контроля доступа на транспортном уровне (см. профили ассоциации идентификации пользователя в PS3.15).
Услуги DIMSE-N, применимые к классу SOP журналирования введения веществ, показаны в Table P.3-1.
Услуги и протокол DIMSE-N определены в PS3.7.
AE DICOM, заявляющие о соответствии этому классу SOP в роли SCU, должны инициировать запрос N-ACTION. AE DICOM, заявляющие о соответствии этому классу SOP в роли SCP, должны поддерживать запрос N-ACTION.
Эта операция позволяет 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 журналирования введения веществ
|
(Обязательно, если используется расширенный или заменяющий набор символов) |
||||
|
SCU должен предоставить Patient ID и/или Admission ID; SCP должен поддерживать атрибут, если он предоставлен |
||||
|
SCU должен предоставить Patient ID и/или Admission ID; SCP должен поддерживать атрибут, если он предоставлен |
||||
|
SCU должен предоставить Product Package Identifier и/или Product Name; SCP должен поддерживать атрибут, если он предоставлен |
||||
|
SCU должен предоставить Product Package Identifier и/или Product Name; SCP должен поддерживать атрибут, если он предоставлен |
||||
|
>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
|
>All Attributes of the Substance Administration Parameter Sequence |
||||
|
>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
SCU должен запрашивать журналирование событий введения веществ для указанного пациента, используя примитив запроса N-ACTION.
SCU должен получать ответы N-ACTION. Действия, предпринимаемые при коде статуса ответа об ошибке или при отсутствии ответа SCP, зависят от реализации.
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, применимый к соответствующему запросу действия.
Table P.3-3 определяет конкретные значения кодов статуса, которые могут быть возвращены в ответе N-ACTION. Дополнительные общие коды статуса ответа см. в PS3.7.
Таблица P.3-3. Статус ответа
Класс SOP журналирования введения веществ должен однозначно идентифицироваться UID класса SOP журналирования введения веществ, который должен иметь значение «1.2.840.10008.1.42».
Общеизвестный UID экземпляра SOP журналирования введения веществ должен иметь значение «1.2.840.10008.1.42.1».
Заявление о соответствии AE DICOM должно быть оформлено, как определено в PS3.2.
SCU должен документировать в своём заявлении о соответствии поведение и действия, которые заставляют SCU генерировать примитив N-ACTION-RQ.
SCU должен документировать способ получения атрибута Patient ID (0010,0020) или Admission ID (0038,0010) (например, через запрос Modality Worklist, сканирование штрихкода, ручной ввод и т. д.).
SCU должен документировать поведение и действия, выполняемые при получении статуса успеха или отказа.
SCP должен документировать в своём заявлении о соответствии способ использования получаемой информации для добавления данных в журнал введения лекарственных препаратов.
SCP должен документировать поведение и действия, которые заставляют SCP генерировать статус успеха или отказа для полученного N-ACTION-RQ.
Класс услуг запроса релевантной информации о пациенте определяет класс услуг на уровне приложения, который облегчает доступ к релевантной информации о пациенте, известной на момент запроса.
Информационная модель запроса состоит из двух сущностей с отношением «один к одному»: пациент (Patient) и информация о пациенте (Patient Information).
Информация о пациенте может быть общей или специфичной для конкретной области визуализации или процедуры. Определён общий класс SOP наряду с несколькими дополнительными специфичными для предметной области классами SOP.
Одна услуга DIMSE-C используется при построении классов SOP класса услуг запроса релевантной информации о пациенте. Используется следующая операция DIMSE-C.
SCP класса услуг запроса релевантной информации о пациенте способны обрабатывать запросы с использованием операции C-FIND, как описано в PS3.7. Операция C-FIND — это механизм, посредством которого выполняются запросы. SCP должен предоставлять релевантную информацию о пациенте не более чем для одного соответствующего пациента в ответе C-FIND.
SOP Class UID определяет модель релевантной информации о пациенте и шаблон, относительно которых должен выполняться C-FIND. Поддержка SOP Class UID подразумевается Abstract Syntax UID контекста представления, используемого этой операцией C-FIND.
Атрибут Priority определяет запрошенный приоритет операции C-FIND относительно других операций DIMSE, выполняемых тем же SCP.
Обработка запросов приоритета не требуется от SCP. Поддерживает ли SCP обработку приоритета и значение различных уровней приоритета должны быть указаны в заявлении о соответствии SCP.
И запрос, и ответ C-FIND содержат идентификатор, закодированный как набор данных (см. PS3.5).
Идентификатор в запросе 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 для модели релевантной информации о пациенте.
Ответ 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.
Шаблоны, используемые в запросе релевантной информации о пациенте, определены в PS3.16.
Шаблон, указанный в идентификаторе запроса, не должен использовать отношения по ссылке (by-reference).
Table Q.2-1 определяет значения кодов статуса, которые могут быть возвращены в ответе C-FIND. Общие значения кодов статуса и поля, связанные со значениями кодов статуса, определены для услуги DIMSE C-FIND в PS3.7.
Таблица Q.2-1. Значения статуса ответа C-FIND
Коды статуса возвращаются в сообщениях ответа DIMSE (см. PS3.7). Значения кодов, указанные в столбце «Коды статуса», возвращаются в элементе команды Status (0000,0900).
Установление ассоциации является первой фазой любого экземпляра связи между равноправными AE DICOM. Для согласования поддерживаемого класса SOP должна использоваться процедура согласования ассоциации, указанная в PS3.7.
Расширенное согласование класса SOP не определено для этого класса услуг.
Услуга DIMSE-C C-FIND — это операция, посредством которой запрашивается и предоставляется релевантная информация о пациенте.
Ключевые атрибуты в идентификаторе запроса служат двум целям. Они могут использоваться как ключевые атрибуты сопоставления (Matching Key Attributes) и ключевые атрибуты возврата (Return Key Attributes). Ключевые атрибуты сопоставления могут использоваться для сопоставления (критерии, используемые в запросе C-FIND для определения того, соответствует ли сущность запросу). Ключевые атрибуты возврата могут использоваться для указания желаемых возвращаемых атрибутов (какие элементы, помимо ключевых атрибутов сопоставления, должны быть возвращены в ответе C-FIND).
Ключевые атрибуты сопоставления могут иметь тип «обязательный» (R) или «необязательный» (O). Ключевые атрибуты возврата могут иметь тип 1, 1C, 2, 2C, 3, как определено в PS3.5.
Два равноправных 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 прервёт всё сопоставление и вернёт статус «Отмена».
Для того чтобы выступать в качестве поставщика класса услуг (SCP) одного или нескольких классов SOP модели релевантной информации о пациенте, прикладной объект (Application Entity, AE) DICOM располагает релевантной информацией о пациентах. Эта информация организована в модель релевантной информации о пациенте.
Классы SOP состоят как из информационной модели, так и из группы услуг DIMSE-C.
Модель E/R состоит из пациента (Patient) и структурированной информации (Structured Information) без отношения к другим информационным сущностям в информационной модели DICOM.
IE Patient включает атрибуты модулей Patient Identification и Patient Demographics.
IE Structured Information включает атрибуты, не связанные по своей природе с сущностью реального мира, а интерпретируемые через их кодированное содержимое. Сюда входят атрибуты модуля Structured Document Content Module, содержимое которого в случае услуги запроса релевантной информации о пациенте ограничено указанными шаблонами для передачи информации, связанной с пациентом. Также в IE Structured Information включены атрибуты модулей SOP Common и Common Instance Reference, поддерживающие интерпретацию кодированных данных или доступ к информационным объектам, на которые есть ссылка, идентифицированным в кодированных данных.
Table Q.4-1 определяет атрибуты модели релевантной информации о пациенте:
Таблица Q.4-1. Атрибуты модели релевантной информации о пациенте
|
Должен присутствовать в идентификаторе запроса. Должен извлекаться с использованием сопоставления единичного значения (Single Value Matching). |
||||
|
Должен извлекаться с использованием сопоставления единичного значения (Single Value Matching). В ситуациях, когда существует несколько эмитентов (issuers), этот ключ ограничивает сопоставление Patient ID (0010,0020) доменом, в котором Patient ID (0010,0020) уникален. |
||||
|
All other Attributes of the Patient Identification Module |
||||
|
All other Attributes of the Patient Demographic Module |
||||
|
См. Раздел Q.4.3.1.2.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” |
||||
|
См. Section Q.4.3.1.2.1. |
||||
|
Элементы содержимого, предоставленные SCP. Требования к типам атрибутов элементов содержимого должны соответствовать определениям в модуле SR Document Content Module. |
||||
|
Требуется, если Content Sequence (0040,A390) включает элементы содержимого, ссылающиеся на экземпляры SOP, использующие информационную модель Patient/Study/Series/Instance. |
||||
Атрибуты в 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
|
Требуется, если используются расширенные или заменяющие наборы символов. См. Section Q.2.1.1.3, |
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 в наборе данных ответа должна содержать элементы содержимого запрошенного шаблона.
Реализация может соответствовать классам SOP модели релевантной информации о пациенте в роли SCU и/или SCP.
Заявление о соответствии должно быть оформлено в формате, определённом в PS3.2.
Реализация, соответствующая одному или нескольким классам SOP модели релевантной информации о пациенте, должна поддерживать запросы к модели релевантной информации о пациенте, описанной в Section Q.4.3.1, используя базовое поведение SCU C-FIND, описанное в Section Q.4.2.
Реализация, соответствующая одному или нескольким классам SOP модели релевантной информации о пациенте в роли SCU, должна указать в своём заявлении о соответствии, какой класс(-ы) SOP она поддерживает, и какой(-ие) корневой(-ые) шаблон(-ы) она может запрашивать, если это не указано классом SOP. Заявление о соответствии должно также указывать определение любых поддерживаемых расширений шаблона.
Реализация, соответствующая одному или нескольким классам SOP модели релевантной информации о пациенте, должна поддерживать запросы к модели релевантной информации о пациенте, описанной в Section Q.4.3.1, используя базовое поведение SCP C-FIND, описанное в Section Q.4.2.
Реализация, соответствующая одному или нескольким классам SOP модели релевантной информации о пациенте в роли SCP, должна указать в своём заявлении о соответствии, какой класс(-ы) SOP она поддерживает, и какой(-ие) корневой(-ые) шаблон(-ы) она будет поддерживать в ответе на запрос, если это не указано классом SOP. Заявление о соответствии должно также указывать определение любых поддерживаемых расширений шаблона.
Реализация, соответствующая одному или нескольким классам SOP модели релевантной информации о пациенте в роли SCP, должна указать в своём заявлении о соответствии, как она использует Specific Character Set (0008,0005) при интерпретации запросов, выполнении сопоставления и кодировании ответов.
Классы SOP модели релевантной информации о пациенте в классе услуг запроса релевантной информации о пациенте идентифицируют модель релевантной информации о пациенте и поддерживаемую операцию DIMSE-C. В некоторых случаях указан корневой шаблон. Стандартные классы SOP определены в Table Q.4-3:
Таблица Q.4-3. Классы SOP модели релевантной информации о пациенте
|
TID 9007 General Relevant Patient Information, or from the list in PS3.16 |
||
Перемещено в PS3.17.
Класс услуг уведомления о доступности экземпляра определяет класс услуг на уровне приложения, который позволяет одному 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 этого класса услуг не обязан гарантировать, что исследование, шаг процедуры или любая сущность, связанная с рабочим процессом, «завершены»; фактически, использование этой услуги не выражает и не подразумевает никакой семантики, кроме концепции «доступности».
Атрибут Performed Workitem Code Sequence (0040,4019) экземпляра шага процедуры, на который есть ссылка, может предоставлять конкретное описание рабочего элемента, вызвавшего уведомление о доступности экземпляра.
Уведомление о доступности экземпляра обычно является услугой SCP хранения составного экземпляра, поскольку это приложение отвечает за обеспечение доступности экземпляров. Уведомление о доступности экземпляра позволяет этому приложению сообщать конкретный Retrieve AE Title, который может отличаться от AE Title услуги хранения и может варьироваться в зависимости от различных классов SOP экземпляров или изменяться со временем.
Класс услуг уведомления о доступности экземпляра состоит из одного класса SOP: класса SOP уведомления о доступности экземпляра.
Класс SOP определяет атрибуты, операции и поведение, применимые к классу SOP. Требования соответствия должны быть указаны в терминах поставщика класса услуг (SCP) и пользователя класса услуг (SCU).
Класс услуг уведомления о доступности экземпляра использует IOD уведомления о доступности экземпляра, определённый в PS3.3, и услугу DIMSE N-CREATE, указанную в PS3.7.
Услуги DIMSE, показанные в Table R.3.1-1, применимы к IOD уведомления о доступности экземпляра в рамках класса SOP уведомления о доступности экземпляра.
Услуги и протоколы DIMSE определены в PS3.7.
Прикладному объекту (Application Entity), заявляющему о соответствии этому классу SOP в роли SCU, должно быть разрешено инициировать следующие операции, а прикладной объект, заявляющий о соответствии в роли SCP, должен быть способен предоставлять следующие операции.
Эта операция позволяет SCU создать экземпляр класса SOP уведомления о доступности экземпляра и предоставить информацию о доступности экземпляров, находящихся под управлением SCU. Эта операция должна инициироваться через услугу DIMSE N-CREATE.
Список атрибутов N-CREATE определён, как показано в Table R.3.2-1.
Таблица R.3.2-1. Атрибуты N-CREATE класса SOP уведомления о доступности экземпляра
|
(Обязательно, если используется расширенный или заменяющий набор символов) |
||
|
All other Attributes of the SOP Common Module |
||
|
>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||
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) или исследования должно предоставляться при его получении, равно как и о том, что уведомление о доступности должно предоставляться, когда доступен весь набор экземпляров, составляющих завершённый шаг процедуры или исследование, хотя это типичные и распространённые сценарии.
SCP должен возвращать через примитив ответа N-CREATE код статуса ответа N-CREATE, применимый к соответствующему запросу.
Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.
Класс SOP уведомления о доступности экземпляра должен однозначно идентифицироваться UID класса SOP уведомления о доступности экземпляра, который должен иметь значение «1.2.840.10008.5.1.4.33».
Реализации должны включать в своё заявление о соответствии информацию, как описано ниже.
Реализация может соответствовать этому классу SOP в роли SCU или SCP. Заявление о соответствии должно быть оформлено в формате, определённом в PS3.2.
Реализация, соответствующая этому классу SOP в роли SCU, должна удовлетворять требованиям соответствия для операций, которые она инициирует.
Любые атрибуты, для которых значения могут быть предоставлены (с использованием N-CREATE) SCU, должны быть перечислены в заявлении о соответствии SCU. Заявление о соответствии SCU должно быть оформлено в формате, определённом в PS3.2.
Реализация, соответствующая этому классу SOP в роли SCU, должна указывать, при каких условиях в ходе выполнения реальных действий она будет создавать экземпляр класса SOP.
Заявление о соответствии SCU должно указывать, что подразумевается под каждым сообщаемым значением Instance Availability (0008,0056).
Заявление о соответствии SCU должно описывать взаимосвязь между уведомлением о доступности экземпляра и классами SOP выполненного шага процедуры (Performed Procedure Step), если последние поддерживаются.
Реализация, соответствующая этому классу SOP в роли SCP, должна удовлетворять требованиям соответствия для операций, которые она выполняет.
Заявление о соответствии SCP должно быть оформлено в формате, определённом в PS3.2.
Заявление о соответствии SCP должно предоставлять информацию о поведении SCP (в терминах реальных действий) для каждого сообщаемого значения Instance Availability (0008,0056).
Заявление о соответствии SCP должно описывать поведенческую взаимосвязь между уведомлением о доступности экземпляра и классами SOP выполненного шага процедуры, если последние поддерживаются.
Класс услуг управления созданием носителя определяет механизм, посредством которого SCU может дать указание устройству создать носитель обмена (Interchange Media), содержащий набор составных экземпляров SOP, которые уже переданы на устройство создания носителя с использованием класса услуг хранения.
Этот класс услуг не рассматривает требования архивного хранения. Он предназначен только для управления устройствами создания носителя. Стандарт не требует, чтобы SCP этого класса услуг брал на себя ответственность за архивирование составных экземпляров, позволяя SCU затем удалить их. Такое поведение полностью выходит за рамки Стандарта. Другими словами, создание носителя не подразумевает подтверждения хранения (Storage Commitment).
Профиль(-и) приложения для набора экземпляров, определяющий(-ие) форму создаваемого носителя (то есть CD, DVD или MOD), может(-гут) быть либо оставлен(ы) на усмотрение SCP, либо явно указан(ы) в запросе на создание носителя. В последнем случае, если устройство не способно создать запрошенные профили, должна быть возвращена ошибка.
Может быть запрошен или использован по умолчанию более чем один профиль, поскольку запрошенный набор экземпляров может быть несовместим с единственным профилем. Носитель DICOM всегда может содержать экземпляры, записанные более чем одним профилем. См. PS3.2.
Ответственность за согласование и сохранение экземпляров с надлежащим синтаксисом передачи, если конкретный синтаксис передачи требуется запрошенным профилем, лежит на SCU. От SCP не требуется поддержка сжатия или распаковки сохраненных экземпляров для преобразования их в форму, пригодную для запрошенного профиля. SCP может это делать по запросу, но степень потери качества при сжатии остается на усмотрение SCP. Если степень сжатия важна для приложения, SCU может сжать изображения перед их отправкой на SCP.
Запрос управляет тем, будет ли сгенерирована этикетка на носителе, будь то из информации, содержащейся в экземплярах (например, демографических данных пациента), или из текста, явно указанного в запросе.
SCP может быть физически не способен наносить этикетку на носитель. Эта возможность выходит за рамки соответствия Стандарту. Невозможность создать этикетку не является ошибкой.
Деидентификация экземпляров (и этикеток), например для учебных файлов или носителей клинических испытаний, является ответственностью SCU и выходит за рамки данной услуги. То есть SCU должен деидентифицировать составные экземпляры перед их отправкой, до запроса на создание носителя.
Класс услуг обладает ограниченной возможностью возврата информации о статусе. Запрос на создание носителя может изначально либо завершиться неудачей, либо быть принят. Впоследствии SCU может опрашивать SCP о статусе запроса (ожидание, выполняется/создается, успешно или неудачно) в рамках той же или отдельной ассоциации. Асинхронное уведомление отсутствует. Нет зависимости от продолжительности или сохранения ассоциации.
Услуги прикладного уровня, рассматриваемые данным классом услуг, определяются через SOP-класс управления созданием носителя.
SOP-класс управления созданием носителя определяет атрибуты, операции и поведение, применимые к данному SOP-классу. Требования соответствия должны определяться в терминах поставщика класса услуг (SCP) и пользователя класса услуг (SCU).
Класс услуг управления созданием носителя использует IOD управления созданием носителя, определенный в PS3.3, и услуги N-CREATE, N-ACTION и N-GET, определенные в PS3.7.
Установление ассоциации является первой фазой любого экземпляра взаимодействия между равноправными DICOM AE. Правила согласования ассоциации, определенные в PS3.7, должны использоваться для согласования поддерживаемых SOP-классов.
Поддержка согласования выбора ролей SCP/SCU не применима. Расширенное согласование SOP-класса для данного класса услуг не определено.
SCU передает SOP-экземпляры на SCP с использованием класса услуг хранения. Запрос на создание носителя передается на SCP и содержит список ссылок на один или несколько SOP-экземпляров. Успех или неудача создания носителя впоследствии указывается SCU путем запроса статуса у SCP в рамках той же или отдельной ассоциации.
Следующие услуги DIMSE-N применимы к SOP-классу управления созданием носителя.
Услуги DIMSE-N и протокол определены в PS3.7.
DICOM AE, заявляющие соответствие данному SOP-классу в роли SCU, должны использовать операции N-CREATE и N-ACTION. DICOM AE, заявляющие соответствие данному SOP-классу в роли SCP, должны поддерживать операции N-CREATE, N-ACTION и N-GET.
Операция создания запроса на создание носителя позволяет SCU создать экземпляр SOP-класса управления созданием носителя и инициализировать атрибуты этого SOP-класса. SCP использует эту операцию для создания нового запроса на создание носителя, содержащего набор SOP-экземпляров, которые должны быть включены в носитель обмена (Interchange Media). Эта операция должна вызываться через примитив N-CREATE.
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
|
1C/1C (требуется, если используется расширенный или заменяющий набор символов) |
||
|
См. Section S.3.2.1.1.1. |
||
|
См. Section S.3.2.1.1.1. |
||
|
См. Section S.3.2.1.1.4. |
||
|
См. Section S.3.2.1.1.4. |
||
|
См. Section S.3.2.1.1.4. |
||
|
См. Section S.3.2.1.1.5. |
||
|
См. Section S.3.2.1.1.2. |
||
|
См. Section S.3.2.1.1.3. |
Если присутствуют, 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).
Requested Media Application Profile (2200,000C), если присутствует, должен использоваться SCP для указанного SOP-экземпляра. Если отсутствует для конкретного экземпляра, выбор профиля хранения на носителе (Media Storage Application Profile) для этого экземпляра остается на усмотрение SCP.
Icon Image Sequence (0088,0200), если присутствует:
должен использоваться SCP для включения в запись каталога DICOM уровня экземпляра для указанного SOP-экземпляра, если профиль хранения на носителе требует его включения и значок, предоставленный SCU, соответствует требованиям профиля
может использоваться SCP для включения в запись каталога DICOM уровня экземпляра для указанного SOP-экземпляра, если профиль хранения на носителе не требует его включения
Если отсутствует для конкретного экземпляра, выбор профиля хранения на носителе для этого экземпляра определяет, обязан ли SCP создавать собственную последовательность значков Icon Image Sequence (0088,0200) из содержимого SOP-экземпляра.
Некоторые профили хранения на носителе требуют включения Icon Image Sequence (0088,0200) в записи каталога.
Некоторые профили хранения на носителе задают ограничения на форму Icon Image Sequence (0088,0200).
SCP может по своему усмотрению расширить профиль хранения на носителе, генерируя и включая значки в любом случае.
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).
Media Disposition (2200,0004), если присутствует, может использоваться SCP для определения того, куда и кому отправить носитель после завершения.
SCP может обладать или не обладать возможностью разделить запрос на несколько частей носителя (например, если он не помещается на одну). Если обладает, применяется следующее поведение SCP, и указанные атрибуты должны поддерживаться SCP.
Атрибут Allow Media Splitting (2200,0007) должен использоваться SCP для определения того, разрешено ли разделять этот запрос на несколько частей носителя.
Если размер набора файлов превышает емкость носителя, а этот флаг установлен в NO, SCP должен отказать в обработке запроса.
Если запрошенный профиль хранения на носителе допускает сжатие без потерь, а изображения еще не сжаты, такое сжатие может быть применено SCP, чтобы уместить все экземпляры на одной части носителя. Это также применимо к сжатию с потерями, если оно разрешено значением Allow Lossy Compression (2200,000F).
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 объекты на носитель.
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 не должен включать приложение просмотра на носитель.
Если Allow Lossy Compression (2200,000F) имеет значение YES, SCP разрешается выполнять сжатие с потерями при следующих обстоятельствах:
Если Allow Lossy Compression (2200,000F) имеет значение YES, но запрошенный профиль не допускает сжатие с потерями, сжатие с потерями выполняться не должно.
Уровень сжатия остается на усмотрение SCP.
SCP не должен распаковывать и повторно сжимать уже сжатые с потерями изображения, но может использовать изображения, уже сжатые с потерями.
От SCP никогда не требуется выполнять сжатие с потерями.
Если Allow Lossy Compression (2200,000F) имеет значение NO, SCP не разрешается выполнять сжатие с потерями. Если Allow Lossy Compression (2200,000F) имеет значение NO, а запрошенный профиль требует сжатия с потерями, должна быть возвращена ошибка.
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-CREATE SCP должен вернуть через примитив ответа N-CREATE код состояния ответа N-CREATE, применимый к соответствующему запросу. Статус успеха означает, что SCP успешно получил запрос N-CREATE.
Статусы предупреждения (Warning) не должны возвращаться.
Любой другой статус (то есть статус неудачи) означает, что SCP не обрабатывает запрос на создание носителя.
Стандарт не определяет, какие проверки SCP должен выполнить после приема примитива запроса N-CREATE и перед возвратом ответа N-CREATE. Реализациям не рекомендуется выполнять расширенную проверку содержимого запроса N-CREATE, такую как доступность ссылочных составных SOP-экземпляров, поддержка запрошенных профилей и т. д. В случае неудачи N-CREATE SCU не сможет выполнить N-GET для определения подробных причин неудачи и позволить операторам применить подходящие корректирующие действия, чтобы сделать запрос обрабатываемым (например, повторно отправить недостающие составные SOP-экземпляры). Такие проверки лучше отложить до получения запроса N-ACTION, после чего может быть выполнен N-GET.
Стандарт не требует от SCP постановки нескольких запросов в очередь, хотя реализациям рекомендуется это делать. Как следствие, новый запрос, поданный до завершения предыдущего, может немедленно завершиться неудачей либо вернуть успешный ответ и быть поставлен в очередь. Размер такой очереди выходит за рамки Стандарта.
Как долго экземпляр SOP-класса управления созданием носителя сохраняется после установки Execution Status (2100,0020) в значение IDLE, выходит за рамки Стандарта.
N-CREATE неявно создает атрибуты Execution Status (2100,0020) и Execution Status Info (2100,0030), которые впоследствии могут быть получены через N-GET.
Table S.3.2.2.4-1 определяет конкретные значения кодов состояния, которые могут быть возвращены в ответе N-CREATE. Общие коды состояния ответа см. в PS3.7.
Операция инициирования создания носителя позволяет SCU запросить у SCP создание носителя обмена в соответствии с уже созданным экземпляром SOP-класса управления созданием носителя. SCP должен использовать эту операцию для планирования создания носителя обмена. Эта операция должна вызываться через примитив N-ACTION.
DICOM AE, заявляющие соответствие данному SOP-классу в роли SCU и/или SCP, должны поддерживать типы действий и информацию о действии, указанные в Table S.3.2.2.1-1.
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.
N-GET соответствующего экземпляра SOP-класса управления созданием носителя может быть выполнен в рамках той же или последующей ассоциации.
Длительность, в течение которой SOP Instance UID экземпляра SOP-класса управления созданием носителя остается активным после завершения или неудачи запроса, зависит от реализации, но должна быть достаточно большой, чтобы позволить SCU определить окончательный результат запроса.
После получения запроса N-ACTION Initiate Media Creation SCP должен вернуть через примитив ответа N-ACTION код состояния ответа N-ACTION, применимый к соответствующему запросу. Статус успеха означает, что SCP успешно запланировал запрос.
Степень проверки содержимого запроса, доступность ссылочных составных SOP-экземпляров, поддержка запрошенных профилей и другие проверки, которые могут определить итоговый успех или неудачу запроса, Стандартом не определяются. В частности, запрос может быть немедленно успешно принят, но впоследствии завершиться неудачей по какой-либо причине, либо примитив ответа N-ACTION может содержать статус, отражающий более тщательную (и продолжительную) проверку.
Как долго сохраняются составные экземпляры, переданные SCP через класс услуг хранения для целей запроса на создание носителя, выходит за рамки Стандарта. Флаг Preserve Composite Instances After Media Creation (2200,000A) предоставляется только как подсказка. Даже если этот флаг установлен, последующий запрос, ссылающийся на некоторые или все те же экземпляры, может завершиться неудачей, если у SCP была причина очистить кэш экземпляров в промежутке, и SCU может потребоваться быть готовым повторно отправить их.
Как долго экземпляр 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.
Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.
Операция отмены создания носителя позволяет SCU запросить у SCP отмену запроса на создание носителя независимо от того, начал ли он обрабатываться. Эта операция должна вызываться через примитив N-ACTION.
DICOM AE, заявляющие соответствие данному SOP-классу в роли SCU и/или SCP, должны поддерживать типы действий и информацию о действии, указанные в Table S.3.2.3.1-1.
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-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.
Table S.3.2.3.4-1 определяет конкретные значения кодов состояния, которые могут быть возвращены в ответе N-ACTION. Общие коды состояния ответа см. в PS3.7.
Операция получения результата создания носителя позволяет SCU запросить у SCP статус запроса на создание носителя. Эта операция должна вызываться через примитив N-GET, используемый совместно с соответствующим экземпляром SOP-класса управления созданием носителя, соответствующим запросу на создание.
Прикладной объект (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
|
(требуется, если используется расширенный или заменяющий набор символов) |
||
|
All other Attributes of the Media Creation Management Module |
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 должен делать в результате получения этой информации.
Эта операция позволяет 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 должен вернуть все содержимое последовательности, если запрошен атрибут последовательности.
Table S.3.2.4.4-1 defines the specific Status Code values that might be returned in a N-GET response.
Общие коды состояния ответа см. в PS3.7.
Реализации, заявляющие стандартное соответствие SOP-классу управления созданием носителя, должны соответствовать описанию в данном разделе и включать в свое заявление о соответствии (Conformance Statement) информацию, описанную в данном разделе и его подразделах.
Реализация может заявлять соответствие данному SOP-классу в роли SCU, SCP или обеих ролей. Заявление о соответствии должно иметь формат, определенный в PS3.2.
Реализация, соответствующая данному SOP-классу в роли SCU, должна удовлетворять требованиям соответствия для
Механизмы, используемые SCU для передачи SOP-экземпляров на SCP с использованием класса услуг хранения перед инициированием операции запроса, также должны быть задокументированы, в частности синтаксисы передачи, которые могут быть предложены.
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
Реализация, соответствующая данному SOP-классу в роли SCP, должна удовлетворять требованиям соответствия для
Механизмы класса услуг хранения, принимаемые SCP перед получением операции запроса, также должны быть задокументированы, в частности синтаксисы передачи, которые могут быть приняты.
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:
SCP должен указать длительность сохранения полученных составных экземпляров после того, как запрос был обработан успешно или неуспешно.
SCP должен указать, как долго он будет сохранять:
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.
См. Annex GG.
Требования данного раздела были объединены с классом услуг хранения объектов, не связанных с пациентом (Non-Patient Object Storage Service Class) (см. Section GG.6.1).
Класс услуг запроса/получения протокола размещения определяет класс услуг прикладного уровня, облегчающий доступ к составным объектам протокола размещения. Он предоставляет возможности запроса и получения/передачи, аналогичные классу услуг управления базовым рабочим списком (Basic Worklist Management Service Class) и классу услуг запроса/получения (Query/Retrieve Service Class).
См. класс услуг управления базовым рабочим списком, раздел K.1.2 «Соглашения».
Чтобы выступать в роли SCP класса услуг запроса/получения протокола размещения, DICOM AE обладает информацией об атрибутах ряда составных SOP-экземпляров протокола размещения. Эта информация организована в информационную модель протокола размещения.
Два равноправных DICOM AE реализуют SOP-класс класса услуг запроса/получения протокола размещения, при этом один выступает в роли SCU, а другой — в роли SCP. SOP-классы класса услуг запроса/получения протокола размещения реализуются с использованием услуг DIMSE-C C-FIND, C-MOVE и C-GET, определенных в PS3.7.
Семантика услуг C-FIND и C-GET совпадает с определенной в разделе «Определение услуги» класса услуг управления базовым рабочим списком.
Семантика услуги C-MOVE совпадает с определенной в разделе «Определение услуги» класса услуг запроса/получения, за исключением того, что существует только один уровень получения.
Информационная модель протокола размещения идентифицируется SOP-классом, согласованным во время установления ассоциации. SOP-класс состоит как из информационной модели, так и из группы услуг DIMSE-C.
Информационная модель протокола размещения определена таким образом, что определение модели «сущность-связь» и определение ключевых атрибутов аналогичны определенным в информационной модели рабочего списка услуги управления базовым рабочим списком.
Информационная модель протокола размещения основана на одноуровневой сущности:
Экземпляр объекта протокола размещения содержит атрибуты, связанные с IE объекта Hanging Protocol составных IOD, определенных в PS3.3.
См. определение операции C-FIND для класса услуг управления базовым рабочим списком (K.4.1), заменив «Worklist» на «Hanging Protocol». Должен использоваться метод поиска «Worklist».
SOP Class UID идентифицирует информационную модель протокола размещения, относительно которой выполняется C-FIND. Ключевые атрибуты и допустимые для запроса значения определены в определении SOP-класса для информационной модели протокола размещения.
См. определение операции C-MOVE для класса услуг запроса/получения (C.4.2). Для класса услуг запроса/получения протокола размещения не определены ни расширенное поведение, ни реляционное получение (Relational-Retrieve).
Query/Retrieve Level (0008,0052) не применим к классу услуг запроса/получения протокола размещения и, следовательно, не должен присутствовать в идентификаторе. Единственным уникальным ключевым атрибутом идентификатора должен быть SOP Instance UID (0008,0018). SCU должен предоставить один UID или список UID.
См. определение операции C-GET для класса услуг запроса/получения (C.4.3). Для класса услуг запроса/получения протокола размещения не определены ни расширенное поведение, ни реляционное получение (Relational-Retrieve).
Query/Retrieve Level (0008,0052) не применим к классу услуг запроса/получения протокола размещения и, следовательно, не должен присутствовать в идентификаторе. Единственным уникальным ключевым атрибутом идентификатора должен быть SOP Instance UID (0008,0018). SCU должен предоставить один UID или список UID.
Информационная модель протокола размещения состоит из единственной сущности. В ответ на данный запрос C-FIND SCP должен отправить один ответ C-FIND на каждый соответствующий экземпляр протокола размещения.
Table U.6-1 определяет атрибуты информационной модели протокола размещения:
Таблица U.6-1. Атрибуты информационной модели протокола размещения
|
Этот атрибут обязателен, если используются расширенные или замещающие наборы символов. См. Раздел C.2.2.2 и Раздел C.4.1.1. |
||||
|
Этот атрибут должен извлекаться с использованием сопоставления единичного значения, сопоставления с подстановочными знаками или универсального сопоставления. |
||||
|
Должен извлекаться с использованием сопоставления единичного значения (Single Value Matching) или универсального сопоставления (Universal Matching). |
||||
|
Должен извлекаться с использованием сопоставления последовательности (Sequence Matching) или универсального сопоставления (Universal Matching). |
||||
|
Должен извлекаться с использованием сопоставления единичного значения (Single Value Matching) или универсального сопоставления (Universal Matching). |
||||
|
Должен извлекаться с использованием сопоставления последовательности (Sequence Matching) или универсального сопоставления (Universal Matching). |
||||
|
>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
|
Должен извлекаться с использованием сопоставления единичного значения (Single Value Matching) или универсального сопоставления (Universal Matching). |
||||
|
Должен извлекаться с использованием сопоставления последовательности (Sequence Matching) или универсального сопоставления (Universal Matching). |
||||
|
>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
|
Должен извлекаться с использованием сопоставления последовательности (Sequence Matching) или универсального сопоставления (Universal Matching). |
||||
|
>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
|
Должен извлекаться с использованием сопоставления единичного значения (Single Value Matching) или универсального сопоставления (Universal Matching). |
||||
|
Должен извлекаться с использованием сопоставления последовательности (Sequence Matching) или универсального сопоставления (Universal Matching). |
||||
|
>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
|
Требуется, если Screen Minimum Color Bit Depth (0072,010C) отсутствует. |
||||
|
Требуется, если Screen Minimum Grayscale Bit Depth (0072,010A) отсутствует. |
||||
Реализация может соответствовать одному из SOP-классов информационной модели протокола размещения в роли SCU, SCP или обоих. Заявление о соответствии должно быть в формате, определенном в PS3.2.
Реализация, соответствующая одному из SOP-классов информационной модели протокола размещения, должна поддерживать запросы к информационной модели протокола размещения с использованием поведения SCU для C-FIND, описанного для класса услуг управления базовым рабочим списком (см. Section K.4.1.2 and Section U.4.1).
Реализация, соответствующая одному из SOP-классов информационной модели протокола размещения в роли SCU, должна указать в своем заявлении о соответствии, запрашивает ли она возвращаемые ключевые атрибуты типа 3, и должна перечислить эти необязательные возвращаемые ключевые атрибуты.
Реализация, соответствующая одному из SOP-классов информационной модели протокола размещения в роли SCU, должна указать в своем заявлении о соответствии, как она использует Specific Character Set (0008,0005) при кодировании запросов и интерпретации ответов.
Реализация, соответствующая одному из SOP-классов информационной модели протокола размещения в роли SCU, должна поддерживать передачу для информационной модели протокола размещения с использованием базового поведения SCU для C-MOVE, описанного для класса услуг запроса/получения (см. Section C.4.2.2.1 and Section U.4.2).
Реализация, соответствующая SOP-классу Hanging Protocol Information Model - GET в роли SCU, должна поддерживать передачу для информационной модели протокола размещения с использованием базового поведения SCU для C-GET, описанного для класса услуг запроса/получения (см. Section C.4.3.2.1 and Section U.4.3).
Реализация, соответствующая одному из SOP-классов информационной модели протокола размещения в роли SCP, должна поддерживать запросы к информационной модели протокола размещения с использованием поведения SCP для C-FIND, описанного для класса услуг управления базовым рабочим списком (см. Section K.4.1.3).
Реализация, соответствующая одному из SOP-классов информационной модели протокола размещения в роли SCP, должна указать в своем заявлении о соответствии, поддерживает ли она возвращаемые ключевые атрибуты типа 3, и должна перечислить эти необязательные возвращаемые ключевые атрибуты.
Реализация, соответствующая одному из SOP-классов информационной модели протокола размещения в роли SCP, должна указать в своем заявлении о соответствии, как она использует Specific Character Set (0008,0005) при интерпретации запросов, выполнении сопоставления и кодировании ответов.
Реализация, соответствующая одному из SOP-классов информационной модели протокола размещения в роли SCP, должна поддерживать передачу для информационной модели протокола размещения с использованием базового поведения SCP для C-MOVE, описанного для класса услуг запроса/получения (см. Section C.4.2.3.1).
Реализация, соответствующая одному из SOP-классов информационной модели протокола размещения в роли SCP, генерирующая передачи с использованием операции C-MOVE, должна указать в своем заявлении о соответствии SOP-класс класса услуг хранения протокола размещения, в рамках которого она будет поддерживать подоперации C-STORE, генерируемые операцией C-MOVE.
Реализация, соответствующая 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.
Класс услуг запроса на введение веществ определяет класс услуг прикладного уровня, облегчающий получение подробной информации о веществах или устройствах, используемых в визуализации, лечении под визуальным контролем и связанных процедурах. Он также облегчает получение разрешения на введение конкретного контрастного вещества или препарата конкретному пациенту.
Этот класс услуг предназначен как часть более широкого рабочего процесса, обеспечивающего безопасность пациента в среде визуализации. Данная услуга затрагивает только протокол обмена данными, позволяющий устройству в месте оказания помощи (модальности визуализации) опрашивать приложение SCP на предмет информации о вводимом веществе или проверки соответствия вещества пациенту. Приложение SCP использует данные, связанные с безопасностью пациента, такие как аллергии, текущие лекарства, соответствующие дозировки, состояние пациента по результатам лабораторных анализов и т.д., для ответа на запросы; однако механизм такого использования выходит за рамки настоящего Стандарта. То, как устройство в месте оказания помощи использует ответы на запросы, например, отображая их пользователю или блокируя определенные функции устройства, также выходит за рамки настоящего Стандарта.
SCP данного класса услуг не обязательно является системой поддержки клинических решений (CDS), но может быть шлюзовой системой между данной услугой DICOM и интерфейсом HL7 или проприетарным интерфейсом системы CDS. Такая архитектура реализации выходит за рамки Стандарта DICOM.
Результатом услуги будет ответ на запрос, содержащий ноль или один элемент. Однако для упрощения реализации услуга использует общий механизм запроса, поддерживающий ответы с несколькими элементами, как это принято в других классах услуг запроса DICOM.
Ключевые атрибуты служат двум целям: они могут использоваться как ключевые атрибуты сопоставления и как возвращаемые ключевые атрибуты. Ключевые атрибуты сопоставления могут использоваться для сопоставления (критерии, используемые в запросе C-FIND для определения соответствия сущности запросу). Возвращаемые ключевые атрибуты могут использоваться для указания желаемых возвращаемых атрибутов (какие элементы, помимо ключевых атрибутов сопоставления, должны быть возвращены в ответе C-FIND).
Ключевые атрибуты сопоставления могут иметь тип «обязательный» (required, R) или «необязательный» (optional, O). Возвращаемые ключевые атрибуты могут иметь тип 1, 1C, 2, 2C, 3, как определено в PS3.5.
Чтобы выступать в роли поставщика класса услуг (SCP) класса услуг запроса на введение веществ, DICOM AE должен быть способен возвращать информацию об атрибутах вещества, устройства или акта введения вещества. Эта информация организована в четко определенные информационные модели запроса на введение веществ.
Конкретный SOP-класс класса услуг запроса на введение веществ состоит из информативного обзора, определения информационной модели и группы услуг DIMSE-C. В данном классе услуг информационная модель играет роль, аналогичную информационной объектной дефиниции (IOD) в других классах услуг DICOM.
Два равноправных DICOM AE реализуют SOP-класс класса услуг запроса на введение веществ, при этом один выступает в роли SCU, а другой — в роли SCP. SOP-классы класса услуг запроса на введение веществ реализуются с использованием услуги DIMSE-C C-FIND, определенной в PS3.7.
В данном классе услуг используется только базовое поведение DIMSE-C C-FIND. Расширенное согласование не используется.
Приведенное ниже описание услуги DIMSE-C C-FIND дает краткий обзор семантики SCU/SCP.
Услуга C-FIND несет следующую семантику:
В данном приложении термин «идентификатор» относится к параметру услуги 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.
Информационная модель запроса на введение веществ идентифицируется SOP-классом, согласованным во время установления ассоциации. SOP-класс состоит как из информационной модели, так и из группы услуг DIMSE-C.
Определения информационных моделей для стандартных SOP-классов класса услуг запроса на введение веществ определены в данном приложении. Определение информационной модели запроса на введение веществ содержит:
Информационные модели запроса на введение веществ состоят из единого уровня, включающего все ключевые атрибуты сопоставления и все возвращаемые ключевые атрибуты, которые могут быть отправлены от SCU к SCP в запросе и значения которых ожидается получить от SCP к SCU в ответе (или элементах запроса). Значения ключевых атрибутов сопоставления в запросе определяют элементы запроса, которые должны быть возвращены в ответе. Все ключевые атрибуты (ключевые атрибуты сопоставления и возвращаемые ключевые атрибуты) в запросе определяют, какие значения атрибутов возвращаются в ответе на данный запрос.
Атрибуты определены для каждой сущности во внутренней модели «сущность-связь». Идентификатор в запросе C-FIND должен содержать значения для сопоставления с атрибутами сущностей в информационной модели запроса на введение веществ. Для любого запроса набор сущностей, для которых возвращаются атрибуты, определяется набором ключевых атрибутов сопоставления и возвращаемых ключевых атрибутов, указанных в идентификаторе.
Все атрибуты сущностей в информационной модели запроса на введение веществ должны быть указаны как ключевой атрибут сопоставления (обязательный или необязательный), так и как возвращаемый ключевой атрибут.
Ключевые атрибуты сопоставления являются ключами, которые выбирают элементы запроса для включения в запрашиваемый запрос.
SCP услуги запроса на введение веществ должен поддерживать сопоставление на основе значений всех обязательных ключевых атрибутов сопоставления запроса C-FIND.
В информационной модели запроса на введение веществ набор атрибутов может быть определен как необязательные ключевые атрибуты сопоставления. Необязательные ключевые атрибуты сопоставления, содержащиеся в идентификаторе запроса C-FIND, могут вызывать два разных типа поведения в зависимости от поддержки сопоставления со стороны SCP. Если SCP
не поддерживает сопоставление по необязательному ключевому атрибуту сопоставления, то этот атрибут должен игнорироваться при сопоставлении, но должен обрабатываться так же, как возвращаемый ключевой атрибут.
поддерживает сопоставление по необязательному ключевому атрибуту сопоставления, то этот атрибут должен обрабатываться так же, как обязательный ключ сопоставления.
Значения возвращаемых ключевых атрибутов, которые должны быть получены с запросом, указываются в запросе C-FIND с нулевой длиной (универсальное сопоставление). SCP должны поддерживать возвращаемые ключевые атрибуты, определенные информационной моделью запроса на введение веществ, в соответствии с типом элемента данных (1, 1C, 2, 2C, 3), как определено в PS3.5.
Каждый ключевой атрибут сопоставления также должен рассматриваться как возвращаемый ключевой атрибут. Поэтому ответ C-FIND должен содержать, помимо значений запрошенных возвращаемых ключевых атрибутов, значения запрошенных ключевых атрибутов сопоставления.
Заявление о соответствии SCP перечисляет поддерживаемые возвращаемые ключевые атрибуты типа 3.
SCU может по своему усмотрению предоставить любое подмножество возвращаемых ключевых атрибутов.
SCU не может рассчитывать на получение каких-либо возвращаемых ключевых атрибутов типа 3.
Возвращаемые ключевые атрибуты с VR типа SQ могут быть указаны либо с нулевой длиной, либо с элементом нулевой длины в последовательности.
Следующие типы сопоставления, определенные классом услуг запроса/получения в Annex C, могут выполняться для ключевых атрибутов сопоставления в классе услуг запроса на введение веществ. Различные ключевые атрибуты сопоставления могут подлежать разным типам сопоставления. Информационная модель запроса на введение веществ определяет тип сопоставления для каждого обязательного ключевого атрибута сопоставления. Заявление о соответствии SCP должно определять тип сопоставления для каждого необязательного ключевого атрибута сопоставления. Типы сопоставления:
Следующий тип сопоставления, определенный классом услуг запроса/получения в Annex C настоящей части, должен выполняться для возвращаемых ключевых атрибутов в классе услуг запроса на введение веществ.
См. Section C.2.2.2 и последующие разделы для получения конкретных правил, регулирующих кодирование ключевых атрибутов сопоставления и выполнение различных типов сопоставления.
Атрибут Specific Character Set (0008,0005) может присутствовать в идентификаторе, но никогда не участвует в сопоставлении, т.е. не считается ключевым атрибутом сопоставления. См. Section C.2.2.2 для получения подробностей.
Каждая информационная модель запроса на введение веществ связана с одним SOP-классом. Определены следующие информационные модели запроса на введение веществ:
Одна услуга DIMSE-C используется при построении SOP-классов класса услуг запроса на введение веществ. Используется следующая операция DIMSE-C.
SCP SOP-классов класса услуг запроса на введение веществ способны обрабатывать запросы с использованием операции C-FIND, как описано в PS3.7. Операция C-FIND является механизмом, посредством которого выполняются запросы. Совпадения по ключам, присутствующим в идентификаторе, возвращаются в ответах C-FIND.
SOP Class UID идентифицирует информационную модель запроса на введение веществ, относительно которой выполняется C-FIND. Поддержка SOP Class UID подразумевается Abstract Syntax UID контекста представления, используемого данной операцией C-FIND.
Атрибут Priority определяет запрошенный приоритет операции C-FIND по отношению к другим операциям DIMSE, выполняемым тем же SCP.
Обработка запросов приоритета не является обязательной для SCP. Поддерживает ли SCP обработку приоритета и значение различных уровней приоритета должно быть указано в заявлении о соответствии SCP.
И запрос, и ответ C-FIND содержат идентификатор, закодированный как набор данных (см. PS3.5).
Идентификатор в запросе C-FIND должен содержать
Значения ключевых атрибутов для сопоставления со значениями атрибутов, указанных в данном SOP-классе.
Условно — атрибут Specific Character Set (0008,0005). Этот атрибут должен быть включен, если расширенные или заменяющие наборы символов могут использоваться в любом из атрибутов идентификатора запроса. В противном случае он не должен включаться.
Это означает, что Specific Character Set (0008,0005) включается, если SCU поддерживает расширенные или заменяющие наборы символов в контексте данной услуги. Он не будет включен, если SCU не поддерживает расширенные или заменяющие наборы символов.
Ключевые атрибуты и допустимые для запроса значения должны быть определены в определении SOP-класса для соответствующей информационной модели запроса на введение веществ.
Ответ 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).
Table V.4-1 определяет значения кодов состояния, которые могут быть возвращены в ответе C-FIND. Общие значения кодов состояния и связанные с ними поля определены для услуги DIMSE C-FIND в PS3.7.
Таблица V.4-1. Значения статуса ответа C-FIND
Коды состояния возвращаются в сообщениях-ответах 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 не обязана различать конкретные коды состояния в пределах допустимого диапазона.
Все 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 был успешным.
Все 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.
Ответ со статусом Success не содержит идентификатора. Полное определение см. в PS3.7.
Если совпадений нет, ответы со статусом Pending не отправляются, отправляется только один ответ со статусом Success.
Для генерации совпадений используется следующая процедура.
Ключевые атрибуты сопоставления, содержащиеся в идентификаторе запроса C-FIND, сопоставляются со значениями ключевых атрибутов для каждой сущности запроса. Для каждой сущности, у которой атрибуты соответствуют всем указанным атрибутам сопоставления, строится идентификатор. Этот идентификатор должен содержать все значения атрибутов данной сущности, соответствующие указанным в запросе C-FIND. Для каждого такого идентификатора возвращается ответ. Если ключи сопоставления отсутствуют, совпадений нет; возвращается ответ со статусом Success и без идентификатора.
Установление ассоциации является первой фазой любого экземпляра взаимодействия между равноправными DICOM AE. Процедура согласования ассоциации, определенная в PS3.7 должна использоваться для согласования поддерживаемых SOP-классов.
Поддержка согласования выбора ролей SCP/SCU является необязательной. Расширенное согласование SOP-класса не используется данным классом услуг.
SOP-класс запроса характеристик продукта определяет класс услуг прикладного уровня, облегчающий передачу подробной информации о препаратах, контрастных веществах или устройствах, идентифицируемых штрихкодом или аналогичным идентификатором. Подробная информация предназначена как для автоматизированной обработки, так и для представления оператору системы.
SOP-класс запроса характеристик продукта поддерживает следующие примеры вариантов использования:
Получение действующего вещества, концентрации или других параметров контрастного вещества для включения в SOP-экземпляры изображений, создаваемые при использовании вещества, или для настройки параметров получения изображения (например, частоты ультразвукового датчика)
Получение параметров размера устройства (например, катетера) для использования при калибровке изображений, показывающих это устройство
Получение сетевой ссылки на онлайн-копию «этикетки продукта» (регламентированных данных о назначении и применении) для препарата, контрастного вещества или устройства.
Информационная модель запроса характеристик продукта представлена диаграммой «сущность-связь», показанной на рисунке Section V.6 -1.
В модели присутствует только одна информационная сущность — Product. Атрибуты Product можно найти в следующем модуле в PS3.3.
Table V.6-1 определяет атрибуты информационной модели запроса характеристик продукта:
Таблица V.6-1. Атрибуты информационной модели запроса характеристик продукта
|
Должен извлекаться только с использованием сопоставления единичного значения (Single Value Matching). |
||||
|
>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support” |
||||
|
>>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support” |
||||
|
Зависит от значения Value Type (0040,A040); см. макрос Content Item Macro в PS3.3. |
||||
|
All other Attributes of the Product Characteristics Module |
||||
Product Package Identifier (0044,0001) может не быть глобально уникальным и может конфликтовать с другими идентификаторами, используемыми в рамках учреждения.
Реализация может соответствовать SOP-классу запроса характеристик продукта в роли SCU или SCP. Заявление о соответствии должно быть в формате, определенном в PS3.2.
Реализация, соответствующая SOP-классу запроса характеристик продукта, должна поддерживать запросы к информационной модели, описанной в Section V.6.1.2 с использованием базового поведения SCU для C-FIND, описанного в Section V.4.1.2.
Реализация, соответствующая SOP-классу запроса характеристик продукта в роли SCU, должна указать в своем заявлении о соответствии запрашиваемые возвращаемые ключевые атрибуты и то, как эти атрибуты используются в приложении.
Реализация, соответствующая SOP-классу запроса характеристик продукта в роли SCU, должна указать в своем заявлении о соответствии, как она использует Specific Character Set (0008,0005) при кодировании запросов и интерпретации ответов.
Реализация, соответствующая SOP-классу запроса характеристик продукта, должна поддерживать запросы к информационной модели запроса характеристик продукта, описанной в Section V.6.1.2 с использованием поведения SCP для C-FIND, описанного в Section V.4.1.3.
Реализация, соответствующая SOP-классу запроса характеристик продукта в роли SCP, должна указать в своем заявлении о соответствии поддерживаемые возвращаемые ключевые атрибуты.
Реализация, соответствующая SOP-классу запроса характеристик продукта в роли SCP, должна указать в своем заявлении о соответствии, как она использует Specific Character Set (0008,0005) при кодировании ответов.
SOP-класс запроса разрешения на вещество определяет класс услуг прикладного уровня, позволяющий устройству в месте оказания помощи получить подтверждение соответствия контрастных веществ и других препаратов, вводимых во время процедуры, на основе штрихкода этикетки вещества и идентификатора пациента. Ответом является разрешение продолжить, предупреждение или противопоказание для отображения оператору системы.
SOP-класс запроса разрешения на вещество поддерживает следующие примеры вариантов использования:
SOP-класс запроса разрешения на вещество не определяет механизм, используемый SCP для проверки такого соответствия введения (например, посредством сравнения с информацией об аллергии в электронной медицинской карте пациента). Продолжительность действия разрешения после момента ответа не определяется Стандартом.
Информационная модель запроса разрешения на вещество представлена диаграммой «сущность-связь», показанной на Figure V.6-2.
Атрибуты информационных сущностей можно найти в следующих модулях в PS3.3.
В информационной модели запроса разрешения на вещество используются только отдельные атрибуты этих модулей.
Информационная модель используется в запросе по принципу «снизу вверх»: то есть, имея Product и Patient, либо, в качестве альтернативы, Product и Visit, для предполагаемого акта Substance Administration в текущий момент времени, найти Approval.
IE Visit включена в информационную модель для поддержки тех учреждений, которые идентифицируют пациентов (например, по браслету со штрихкодом) по Admission ID (т.е. идентификатору визита), а не по Patient ID. Это позволяет автоматизировать построение запроса путем сканирования Admission ID. Admission ID может быть сопоставлен с Patient ID со стороны SCP для целей выполнения сопоставления запроса.
Visit идентифицируется атрибутом Admission ID (0038,0010), однако в «Модели реального мира для целей интерфейса Modality-IS» (см. PS3.3), Visit является подчиненной по отношению к Patient; следовательно, Admission ID может быть уникальным только в контексте пациента, а не в контексте учреждения. Использование атрибута Admission ID для идентификации Visit (и, следовательно, Patient) эффективно только в том случае, если Admission ID уникален в контексте учреждения.
Некоторые учреждения, например амбулаторные центры визуализации, не выполняющие «поступление» пациентов, могут использовать Imaging Service Request Identifier или Accession Number в качестве эквивалента Admission ID. SCU данной услуги запроса не обязан знать истинное происхождение или природу идентификатора — достаточно того, что он передается в запросе в атрибуте Admission ID (0038,0010).
Концептуально у акта Substance Administration есть атрибут даты и времени введения, который в данном SOP-классе неявно принимается равным примерно моменту выполнения запроса.
Концептуально у сущности Product есть атрибут дозы, представляющий собой весь продукт, идентифицированный штрихкодом, и запрос касается разрешения на введение всего продукта.
Table V.6-2 определяет атрибуты информационной модели запроса разрешения на вещество.
Таблица V.6-2. Атрибуты информационной модели запроса разрешения на вещество
|
Должен извлекаться только с использованием сопоставления единичного значения (Single Value Matching). Один или оба атрибута Patient ID (0010,0020) и Admission ID (0038,0010) должны присутствовать в запросе в качестве ключа сопоставления |
||||
|
>All Attributes of the Issuer of Patient ID Qualifiers Sequence |
||||
|
Должен извлекаться только с использованием сопоставления единичного значения (Single Value Matching). Один или оба атрибута Patient ID (0010,0020) и Admission ID (0038,0010) должны присутствовать в запросе в качестве ключа сопоставления |
||||
|
Обязательно, если Universal Entity ID (0040,0032) отсутствует; может присутствовать в остальных случаях |
||||
|
Обязательно, если Local Namespace Entity ID (0040,0031) отсутствует; может присутствовать в остальных случаях. |
||||
|
Обязательно, если присутствует Universal Entity ID (0040,0032). |
||||
|
Должен извлекаться только с использованием сопоставления единичного значения (Single Value Matching). Должен присутствовать в запросе в качестве ключа сопоставления. |
||||
|
Должен присутствовать в запросе в качестве ключа сопоставления. |
||||
|
>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
Один или оба атрибута 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) в качестве ключей сопоставления.
Ответ на запрос может иметь статус 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.
Реализация может соответствовать SOP-классу запроса разрешения на вещество в роли SCU или SCP. Заявление о соответствии должно быть в формате, определенном в PS3.2.
Реализация, соответствующая 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) при кодировании запросов и интерпретации ответов.
Реализация, соответствующая SOP-классу запроса разрешения на вещество, должна поддерживать запросы к информационной модели запроса разрешения на вещество, описанной в Section V.6.2.2 с использованием поведения SCP для C-FIND, описанного в Section V.4.1.3. Она должна поддерживать все атрибуты, указанные в информационной модели.
Реализация, соответствующая SOP-классу запроса разрешения на вещество в роли SCP, должна указать в своем заявлении о соответствии, как она обрабатывает обязательные и необязательные ключевые атрибуты сопоставления. Она должна указать, как получает значения для возвращаемых ключевых атрибутов.
Реализация, соответствующая SOP-классу запроса разрешения на вещество в роли SCP, должна указать в своем заявлении о соответствии, как она использует Specific Character Set (0008,0005) при интерпретации запросов, выполнении сопоставления и кодировании ответов.
См. Annex GG.
Требования этого раздела были объединены в класс услуг хранения объектов, не относящихся к пациенту (см. Раздел GG.6.2).
Класс услуг запроса/получения цветовой палитры (Color Palette Query/Retrieve Service Class) определяет класс услуг прикладного уровня, обеспечивающий доступ к составным объектам цветовой палитры (Color Palette).
См. класс услуг базового управления списком заданий (Basic Worklist Management Service Class), Раздел K.1.2 Соглашения.
Чтобы выступать в роли SCP класса услуг запроса/получения цветовой палитры, DICOM AE обладает информацией об атрибутах ряда составных SOP-экземпляров цветовой палитры. Эта информация организована в информационную модель цветовой палитры (Color Palette Information Model).
Два равноправных 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), за исключением того, что существует только один уровень получения.
Информационная модель цветовой палитры идентифицируется SOP-классом, согласованным при установлении ассоциации. SOP-класс состоит из информационной модели и группы услуг DIMSE-C.
Информационная модель цветовой палитры определена таким образом, что определение модели «сущность-связь» и определение ключевых атрибутов аналогичны определённым в информационной модели списка заданий класса услуг базового управления списком заданий.
Информационная модель цветовой палитры основана на одноуровневой сущности:
Экземпляр объекта цветовой палитры содержит атрибуты, связанные с информационной сущностью (IE) объекта цветовой палитры составных IOD, определённых в PS3.3.
См. определение операции C-FIND для класса услуг базового управления списком заданий (K.4.1), заменяя «Worklist» на «Color Palette». Должен использоваться метод поиска «Worklist».
SOP Class UID идентифицирует информационную модель цветовой палитры, в отношении которой должен выполняться C-FIND. Ключевые атрибуты и допустимые для запроса значения определены в определении SOP-класса информационной модели цветовой палитры.
См. определение операции C-MOVE для класса услуг запроса/получения (C.4.2). Расширенное поведение (Extended Behavior) и реляционное получение (Relational-Retrieve) для класса услуг запроса/получения цветовой палитры не определены.
Query/Retrieve Level (0008,0052) не относится к классу услуг запроса/получения цветовой палитры и поэтому не должен присутствовать в идентификаторе. Единственным уникальным ключевым атрибутом идентификатора должен быть SOP Instance UID (0008,0018). SCU должен предоставить один UID или список UID.
См. определение операции C-GET для класса услуг запроса/получения (C.4.3). Расширенное поведение (Extended Behavior) и реляционное получение (Relational-Retrieve) для класса услуг запроса/получения цветовой палитры не определены.
Query/Retrieve Level (0008,0052) не относится к классу услуг запроса/получения цветовой палитры и поэтому не должен присутствовать в идентификаторе. Единственным уникальным ключевым атрибутом идентификатора должен быть SOP Instance UID (0008,0018). SCU должен предоставить один UID или список UID.
Информационная модель цветовой палитры состоит из единственной сущности. В ответ на данный запрос C-FIND SCP должен отправить один ответ C-FIND на каждый подходящий экземпляр цветовой палитры.
Table X.6-1 defines the Attributes of the Color Palette Information Model:
Table X.6-1. Attributes for the Color Palette Information Model
|
Этот атрибут обязателен, если используются расширенные или замещающие наборы символов. См. Раздел C.2.2.2 и Раздел C.4.1.1. |
||||
|
Этот атрибут должен извлекаться с использованием сопоставления единичного значения. |
||||
|
Этот атрибут должен извлекаться с использованием сопоставления единичного значения. |
||||
|
Этот атрибут должен извлекаться с использованием сопоставления единичного значения, сопоставления с подстановочными знаками или универсального сопоставления. |
||||
|
>>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support” |
||||
Реализация может соответствовать одному из SOP-классов информационной модели цветовой палитры в роли SCU, SCP или обеих ролей. Заявление о соответствии (Conformance Statement) должно быть оформлено в формате, определённом в PS3.2.
Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры, должна поддерживать запросы к информационной модели цветовой палитры с использованием поведения SCU C-FIND, описанного для класса услуг базового управления списком заданий (см. Раздел K.4.1.2 и Раздел X.4.1).
Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCU, должна указать в своём заявлении о соответствии, запрашивает ли она возвращаемые ключевые атрибуты типа 3, и перечислить эти необязательные возвращаемые ключевые атрибуты.
Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCU, должна указать в своём заявлении о соответствии, каким образом она использует Specific Character Set (0008,0005) при кодировании запросов и интерпретации ответов.
Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCU, должна поддерживать передачу данных в отношении информационной модели цветовой палитры с использованием базового поведения SCU C-MOVE, описанного для класса услуг запроса/получения (см. Раздел C.4.2.2.1 и Раздел X.4.2).
Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCU, должна поддерживать передачу данных в отношении информационной модели цветовой палитры с использованием базового поведения SCU C-GET, описанного для класса услуг запроса/получения (см. Раздел C.4.3.2.1 и Раздел X.4.3).
Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCP, должна поддерживать запросы к информационной модели цветовой палитры с использованием поведения SCP C-FIND, описанного для класса услуг базового управления списком заданий (см. Раздел K.4.1.3).
Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCP, должна указать в своём заявлении о соответствии, поддерживает ли она возвращаемые ключевые атрибуты типа 3, и перечислить эти необязательные возвращаемые ключевые атрибуты.
Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCP, должна указать в своём заявлении о соответствии, каким образом она использует Specific Character Set (0008,0005) при интерпретации запросов, выполнении сопоставления и кодировании ответов.
Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCP, должна поддерживать передачу данных в отношении информационной модели цветовой палитры с использованием базового поведения SCP C-MOVE, описанного для класса услуг запроса/получения (см. Раздел C.4.2.3.1).
Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCP, генерирующая передачи с использованием операции C-MOVE, должна указать в своём заявлении о соответствии SOP-класс класса услуг хранения цветовой палитры, в рамках которого она поддерживает подоперации C-STORE, порождаемые C-MOVE.
Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCP, должна поддерживать передачу данных в отношении информационной модели цветовой палитры с использованием базового поведения SCP C-GET, описанного для класса услуг запроса/получения (см. Раздел C.4.3.3.1).
Реализация, соответствующая одному из SOP-классов информационной модели цветовой палитры в роли SCP, генерирующая передачи с использованием операции C-GET, должна указать в своём заявлении о соответствии SOP-класс класса услуг хранения цветовой палитры, в рамках которого она поддерживает подоперации C-STORE, порождаемые C-GET.
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.
Получение данных реализуется в отношении информационной модели Composite Instance Root Retrieve, определённой в настоящем Приложении Стандарта DICOM. Конкретный SOP-класс класса услуг запроса/получения состоит из определения информационной модели и группы услуг DIMSE-C.
Два равноправных 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:
Услуга 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.
Услуга 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.
Информационная модель 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 содержит:
Для любой информационной модели Composite Instance Root Retrieve модель «сущность-связь» определяет иерархию сущностей с атрибутами, определёнными для каждого уровня иерархии (например, Composite Instance, Frame).
Атрибуты и сопоставление должны определяться в соответствии с Разделом C.2.2
В данном Приложении определена одна стандартная информационная модель Composite Instance Root Retrieve. Информационная модель Composite Instance Root Retrieve связана с рядом SOP-классов. Определена следующая иерархическая информационная модель Composite Instance Root Retrieve:
Информационная модель Composite Instance Root основана на двухуровневой иерархии:
Уровень Composite Instance является верхним уровнем и содержит только SOP Instance UID. Уровень Frame расположен ниже уровня Composite Instance и содержит только атрибуты, относящиеся к выбору кадров из одного многокадрового объекта изображения.
Следующие правила использования ключей диапазона кадров (Frame Range Keys) применяются как к SCU, создающему такие ключи, так и к SCP, интерпретирующему их.
Выбор кадров, подлежащих включению во вновь созданный SOP-экземпляр в ответ на запрос Composite Instance Root Retrieve уровня FRAME, должен определяться одним из механизмов, определённых в данном разделе, а полученный таким образом список кадров именуется «списком кадров» (Frame List).
Simple Frame List (0008,1161) — многозначный атрибут, содержащий список номеров кадров, каждый из которых указывает кадр, подлежащий включению в возвращаемый объект. Первый кадр исходного экземпляра обозначается как кадр номер 1.
Номера кадров в списке не должны содержать дубликатов и должны монотонно возрастать.
Calculated Frame List (0008,1162) — многозначный атрибут, содержащий список 3-элементных кортежей, каждый из которых представляет поддиапазон кадров, подлежащих включению в возвращаемый объект. Первый кадр исходного экземпляра обозначается как кадр номер 1. Для каждого 3-элементного кортежа:
Разность между первым и вторым числами не обязана быть точным кратным шага.
Если разность между первым и вторым числами является точным кратным шага, то последним кадром поддиапазона будет второе число.
Если первое число больше количества кадров в упомянутом SOP-экземпляре, этот поддиапазон должен игнорироваться.
Поддиапазоны не должны пересекаться, так что последовательность номеров кадров, полученная объединением всех поддиапазонов, не должна содержать дубликатов и должна монотонно возрастать. Значение FFFFFFFFH или любое значение, превышающее количество кадров в упомянутом SOP-экземпляре, в качестве второго значения обозначает конец набора кадров в упомянутом SOP-экземпляре и может встречаться только в последнем 3-элементном кортеже.
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-экземпляров, где время кадров может быть определено с использованием одного или нескольких из следующих атрибутов:
Когда операция 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) или другие атрибуты конкатенации. Если существующий составной экземпляр содержит такие атрибуты, они не должны включаться в новый составной экземпляр.
При построении SOP-классов услуги Composite Instance Root Retrieve используется единая услуга DIMSE-C. Используется следующая операция DIMSE-C:
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 зависит от выбранного уровня.
SOP Class UID идентифицирует информационную модель запроса/получения, в отношении которой должен выполняться C-MOVE. Поддержка SOP Class UID подразумевается Abstract Syntax UID контекста представления, используемого данной операцией C-MOVE.
Атрибут Priority определяет запрошенный приоритет операции C-MOVE и соответствующих подопераций C-STORE относительно других DIMSE-операций, выполняемых тем же SCP.
Обработка запросов приоритета не является обязательной для SCP. Поддерживает ли SCP обработку приоритета и смысл различных уровней приоритета должны быть указаны в заявлении о соответствии SCP. Один и тот же приоритет должен использоваться для всех подопераций C-STORE.
Запрос C-MOVE должен содержать идентификатор. Ответ C-MOVE должен условно содержать идентификатор согласно требованиям Раздела C.4.3.1.3.2.
Идентификатор указан как U в определении примитива C-MOVE в PS3.7, но специализирован для использования с данной услугой.
Идентификатор в запросе C-MOVE должен содержать:
Query/Retrieve Level (0008,0052), определяющий уровень получения
Один из ключей диапазона кадров (Frame Range Keys), если он присутствует в информационной модели для уровня получения
Условно, атрибут Query/Retrieve View (0008,0053). Этот атрибут может быть включён, если Enhanced Multi-Frame Image Conversion было согласовано в процессе расширенного согласования ассоциации. В противном случае он не должен включаться.
Specific Character Set (0008,0005) не должен присутствовать.
Ключи на каждом уровне иерархии и допустимые для уровня получения значения должны определяться в определении SOP-класса информационной модели запроса/получения.
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
Некоторые коды состояния сбоя зависят от реализации.
Реализация SCP должна назначать конкретные коды состояния сбоя путём замены каждого символа 'x' шестнадцатеричной цифрой в диапазоне от 0 до F. Реализация SCP, желающая различать причины значения сбоя «Ошибка: невозможно обработать», должна назначить этим причинам конкретные значения кодов состояния в допустимом диапазоне, указанном в Таблице Y.4-1.
Реализация SCU должна распознавать любой код состояния сбоя в пределах диапазона значений, указанного в Таблице Y.4-1, как индикатор значения сбоя, указанного в таблице. Требование к реализации SCU различать конкретные коды состояния в пределах допустимого диапазона отсутствует.
Включение Number of Remaining Sub-Operations должно осуществляться согласно Разделу C.4.2.1.6
Включение Number of Completed Sub-Operations должно осуществляться согласно Разделу C.4.2.1.7
Включение Number of Failed Sub-Operations должно осуществляться согласно Разделу C.4.2.1.8
Включение Number of Warning Sub-Operations должно осуществляться согласно Разделу C.4.2.1.9.
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 с указанными в запросе.
Расширенное поведение SCU должно соответствовать Разделу C.4.2.2.2, за исключением того, что реляционное получение (Relational-retrieve) не поддерживается.
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, должен содержать:
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-экземпляра, из которого извлекаются кадры, должна использоваться только одна из альтернативных кодировок изображения.
Расширенное поведение SCP должно соответствовать Разделу C.4.2.3.2, за исключением того, что реляционное получение (Relational-retrieve) не поддерживается.
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 зависит от выбранного уровня.
SOP Class UID идентифицирует информационную модель запроса/получения, в отношении которой должен выполняться C-GET. Поддержка SOP Class UID подразумевается Abstract Syntax UID контекста представления, используемого данной операцией C-GET.
Атрибут Priority определяет запрошенный приоритет операции C-GET и соответствующих подопераций C-STORE относительно других DIMSE-операций, выполняемых тем же SCP.
Обработка запросов приоритета не является обязательной для SCP. Поддерживает ли SCP обработку приоритета и смысл различных уровней приоритета должны быть указаны в заявлении о соответствии SCP. Один и тот же приоритет должен использоваться для всех подопераций C-STORE.
Запрос C-GET должен содержать идентификатор. Ответ C-GET должен условно содержать идентификатор согласно требованиям Раздела C.4.3.1.3.2.
Идентификатор указан как U в определении примитива C-GET в PS3.7, но специализирован для использования с данной услугой.
Идентификатор в запросе C-GET должен содержать:
Query/Retrieve Level (0008,0052), определяющий уровень получения
Один из ключей диапазона кадров (Frame Range Keys), если он присутствует в информационной модели для уровня получения
Условно, атрибут Query/Retrieve View (0008,0053). Этот атрибут может быть включён, если Enhanced Multi-Frame Image Conversion было согласовано в процессе расширенного согласования ассоциации. В противном случае он не должен включаться.
Specific Character Set (0008,0005) не должен присутствовать.
Ключи на каждом уровне иерархии и допустимые для уровня получения значения должны определяться в определении SOP-класса информационной модели запроса/получения.
Значения кодов состояния, которые могут возвращаться в ответе C-GET, должны соответствовать Таблице Y.4-2
Table Y.4-2. C-GET Response Status Values for Composite Instance Root Retrieve
Включение Number of Remaining Sub-Operations должно осуществляться согласно Разделу C.4.3.1.5
Включение Number of Completed Sub-Operations должно осуществляться согласно Разделу C.4.3.1.6
Включение Number of Failed Sub-Operations должно осуществляться согласно Разделу C.4.3.1.7
Включение Number of Warning Sub-Operations должно осуществляться согласно Разделу C.4.3.1.8.
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.
Расширенное поведение SCU должно соответствовать Разделу C.4.3.2.2, за исключением того, что реляционное получение (Relational-retrieve) не поддерживается.
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, должен содержать:
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-экземпляра, из которого извлекаются кадры, должна использоваться только одна из альтернативных кодировок изображения.
Расширенное поведение SCP должно соответствовать Разделу C.4.3.3.2, за исключением того, что реляционное получение (Relational-retrieve) не поддерживается.
Установление ассоциации — это первая фаза любого экземпляра взаимодействия между равноправными 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-классов, которые могут использоваться для получения.
Правила указаны в Разделе C.5.3, за исключением того, что подэлемент расширенного согласования (Extended Negotiation), если используется, должен использоваться так, как определено в Разделе Y.5.1.1.
Хотя преобразованные изображения могут быть указаны по их SOP Instance UID в идентификаторе запроса, который всегда находится на уровне экземпляра или ниже, сохраняется необходимость расширенного согласования и указания Query/Retrieve View, чтобы обеспечить сохранение ссылочной целостности в возвращаемых SOP-экземплярах (например, чтобы ссылка на SOP Instance UID указывала на преобразованное изображение или нет, в зависимости от ситуации).
Реляционное получение (Relational-retrieval) неприменимо к данным SOP-классам, поэтому подэлемент расширенного согласования не включает использование этого байта.
Расширенное согласование SOP-класса позволяет равноправным DICOM AE при установлении ассоциации обмениваться информацией ассоциации приложения, определённой конкретными SOP-классами. Это достигается путём определения поля service-class-application-information. Поле service-class-application-information используется для определения поддержки Enhanced Multi-Frame Image Conversion.
Данное согласование не является обязательным. Если оно отсутствует, по умолчанию действует следующее условие:
Инициатор ассоциации (Association-requestor) может использовать по одному подэлементу расширенного согласования SOP-класса на каждый SOP-класс. SOP-класс идентифицируется соответствующим именем абстрактного синтаксиса (Abstract Syntax Name, как определено в PS3.7), за которым следует поле service-class-application-information. Это поле определяет:
Получатель ассоциации (Association-acceptor) для каждого предложенного подэлемента расширенного согласования SOP-класса либо принимает предложение инициатора ассоциации, вернув то же значение (1), либо отклоняет предложение, вернув значение (0).
Если подэлемент расширенного согласования SOP-класса не возвращён получателем ассоциации, поддержка Enhanced Multi-Frame Image Conversion отсутствует (условие по умолчанию).
Если подэлементы расширенного согласования SOP-класса отсутствуют в индикации A-ASSOCIATE, они должны быть опущены в ответе A-ASSOCIATE.
Подэлемент расширенного согласования 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
Подэлемент расширенного согласования 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
В информационной модели Composite Instance Root Retrieve Only информация организована в два уровня, соответствующих одному из двух значений элемента (0008,0052), показанных в Таблице Y.6.1-1.
Использование слова «IMAGE», а не «Composite Instance», обусловлено историческими причинами для обеспечения обратной совместимости с предыдущими редакциями Стандарта. Это не следует понимать так, что составные экземпляры (Composite Instances) типов, отличных от изображения, не включаются на уровне, обозначаемом значением IMAGE.
Информационная модель Composite Instance Root Retrieve Only может быть представлена диаграммой «сущность-связь», показанной на Рисунке Y.6-1
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
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
Запрос C-MOVE или C-GET может выполняться на любом уровне модели запроса/получения. C-MOVE или C-GET, для которого уровень запроса/получения:
IMAGE — означает, что должны быть переданы выбранные отдельные составные экземпляры (Composite Instances)
FRAME — означает, что должен быть создан и передан единственный новый составной экземпляр
Реализация может соответствовать одному из SOP-классов Composite Instance Root Retrieve в роли SCU, SCP или обеих ролей. Заявление о соответствии должно быть оформлено в формате, определённом в PS3.2.
Реализация, соответствующая одному из 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.
Реализация, соответствующая одному из 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.
Реализация, соответствующая одному из SOP-классов Composite Instance Root Retrieve в роли SCP для операций C-GET, должна: 1) поддерживать оба уровня информационной модели Composite Instance Root Retrieve Only
2) поддерживать все три ключа уровня Frame
3) описать в своём заявлении о соответствии преобразования, которые она применяет к многокадровому составному экземпляру при создании нового составного экземпляра, как определено в Разделе Y.3.3.
Реализация, соответствующая одному из 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.
Реализация, соответствующая одному из 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.
SOP-классы группы SOP-классов Composite Instance Root класса услуг запроса/получения идентифицируют информационную модель Composite Instance Root Retrieve Only и поддерживаемые операции DIMSE-C. Стандартные SOP-классы перечислены в Таблице Y.6.1.3-1.
Служба извлечения композитного экземпляра без объёмных данных (Composite Instance Retrieve Without Bulk Data) — это служба в составе класса услуг DICOM «Запрос/получение» (Query/Retrieve), определённого в Приложении C. Возможность получения, предоставляемая данной службой, позволяет прикладному объекту DICOM (AE) получать композитные экземпляры без их пиксельных данных или других потенциально больших атрибутов, определённых в Разделе Z.1.3.
Опция расширенного согласования Enhanced Multi-Frame Image Conversion класса услуг DICOM «Запрос/получение», определённого в Приложении C, также поддерживается для службы извлечения композитного экземпляра без объёмных данных.
Получение выполняется в отношении информационной модели извлечения композитного экземпляра без объёмных данных, определённой в данном Приложении стандарта DICOM. Конкретный SOP-класс класса услуг «Запрос/получение» состоит из определения информационной модели и группы услуг DIMSE-C.
Атрибуты, которые не должны включаться на верхнем уровне набора данных, отправляемого SCP данной службы, определены в Таблице Z.1-1
Это подразумевает, что пиксельные данные внутри элементов Icon Image Sequence (0088,0200) будут сохранены.
Атрибут Waveform Data (5400,1010) не должен включаться внутри Waveform Sequence (5400,0100).
Приватные атрибуты могут сохраняться или отбрасываться SCP службы хранения, как определено в Разделе B.4.1. SCP службы хранения, заявляющий соответствие уровню хранения 2 (полный) класса услуг хранения, может по своему усмотрению возвращать приватные атрибуты в службе извлечения без объёмных данных или нет. Возвращаются ли конкретные приватные атрибуты, должно быть документировано в заявлении о соответствии.
Два равноправных прикладных объекта DICOM (AE) реализуют SOP-класс службы извлечения композитного экземпляра без объёмных данных, при этом один выступает в роли SCU, а другой — в роли SCP. SOP-классы службы извлечения композитного экземпляра без объёмных данных реализуются с использованием услуги DIMSE-C C-GET, как определено в PS3.7.
Приведённые ниже описания услуги DIMSE-C C-GET дают краткий обзор семантики SCU/SCP:
Услуга 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.
Информационная модель извлечения композитного экземпляра без объёмных данных идентифицируется SOP-классом, согласованным при установлении ассоциации. SOP-класс состоит как из информационной модели, так и из группы услуг DIMSE-C.
Этот SOP-класс идентифицирует класс информационной модели извлечения композитного экземпляра без объёмных данных (то есть не SOP-класс сохранённых SOP-экземпляров, о которых располагает информацией SCP).
Определения информационной модели для стандартных SOP-классов службы извлечения композитного экземпляра без объёмных данных определены в данном Приложении. Определение информационной модели извлечения композитного экземпляра без объёмных данных содержит:
Для любой информационной модели извлечения композитного экземпляра без объёмных данных модель «сущность-связь» определяет иерархию сущностей с атрибутами, определёнными для каждого уровня иерархии (например, Composite Instance, Frame).
Атрибуты и сопоставление должны соответствовать Разделу C.2.2
В данном Приложении определена одна стандартная информационная модель извлечения композитного экземпляра без объёмных данных. Информационная модель извлечения композитного экземпляра без объёмных данных связана с единственным SOP-классом. Определена следующая информационная модель извлечения композитного экземпляра без объёмных данных:
Информационная модель извлечения композитного экземпляра без объёмных данных основана на одноуровневой иерархии:
Информационная модель извлечения без объёмных данных может быть представлена диаграммой «сущность-связь», показанной на Рисунке Z.3.1-1.
Уровень Composite Instance является единственным уровнем и содержит только SOP Instance UID.
Для построения SOP-классов службы извлечения композитного экземпляра без объёмных данных используется единственная услуга DIMSE-C. Используется следующая операция DIMSE-C:
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.
SOP Class UID идентифицирует информационную модель запроса/получения, в отношении которой должен выполняться C-GET. Поддержка SOP Class UID подразумевается Abstract Syntax UID контекста представления, используемого данной операцией C-GET.
Атрибут Priority определяет запрошенный приоритет операции C-GET и соответствующих подопераций C-STORE относительно других DIMSE-операций, выполняемых тем же SCP.
Обработка запросов приоритета не является обязательной для SCP. Поддерживает ли SCP обработку приоритета и смысл различных уровней приоритета должны быть указаны в заявлении о соответствии SCP. Один и тот же приоритет должен использоваться для всех подопераций C-STORE.
Запрос C-GET должен содержать идентификатор. Ответ C-GET должен условно содержать идентификатор согласно требованиям Раздела C.4.3.1.3.2.
Идентификатор указан как U в определении примитива C-GET в PS3.7, но специализирован для использования с данной услугой.
Идентификатор в запросе C-GET должен содержать:
Query/Retrieve Level (0008,0052), определяющий уровень получения
Условно, атрибут Query/Retrieve View (0008,0053). Этот атрибут может быть включён, если Enhanced Multi-Frame Image Conversion было согласовано в процессе расширенного согласования ассоциации. В противном случае он не должен включаться.
Query/Retrieve Level (0008,0052) должен быть IMAGE.
Specific Character Set (0008,0005) не должен присутствовать.
Ключи на каждом уровне иерархии и допустимые для уровня получения значения должны определяться в определении SOP-класса информационной модели запроса/получения.
Таблица 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 зависят от реализации.
Реализация SCP должна назначать конкретные коды состояния Failure, заменяя каждый символ 'x' шестнадцатеричной цифрой в диапазоне от 0 до F. Реализация SCP, желающая различать причины значения Failure «Ошибка: невозможно обработать», должна назначать этим причинам конкретные значения кодов состояния в пределах допустимого диапазона, указанного в Таблице Y.4-2.
Реализация SCU должна распознавать любой код состояния Failure в пределах диапазона значений, указанного в Таблице Y.4-2, как индикатор значения Failure, указанного в таблице. Требование различать конкретные коды состояния в пределах допустимого диапазона для реализации SCU отсутствует.
Включение Number of Remaining Sub-Operations должно осуществляться согласно Разделу C.4.3.1.5
Включение Number of Completed Sub-Operations должно осуществляться согласно Разделу C.4.3.1.6
Включение Number of Failed Sub-Operations должно осуществляться согласно Разделу C.4.3.1.7
Включение Number of Warning Sub-Operations должно осуществляться согласно Разделу C.4.3.1.8.
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.
Расширенное поведение SCU должно соответствовать Разделу C.4.3.2.2, за исключением того, что реляционное получение (Relational-retrieve) не поддерживается.
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, должен содержать:
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-экземпляра, из которого извлекаются кадры, должна использоваться только одна из альтернативных кодировок изображения.
Расширенное поведение SCP должно соответствовать Разделу C.4.3.3.2, за исключением того, что реляционное получение (Relational-retrieve) не поддерживается.
Установление ассоциации является первой фазой любого сеанса взаимодействия между равноправными прикладными объектами DICOM. Прикладные объекты, поддерживающие SOP-классы DICOM «Запрос/получение», используют согласование при установлении ассоциации, определяя использование информации о прикладной ассоциации. См. обзор согласования ассоциации в PS3.7.
SOP-классы службы извлечения композитного экземпляра без объёмных данных, которые включают услуги получения на основе операции C-GET, используют подэлемент выбора роли SCP/SCU (SCP/SCU Role Selection Sub-Item) для идентификации SOP-классов, которые могут использоваться для получения.
Правила соответствуют указанным в Разделе C.5.3, за исключением того, что подэлемент расширенного согласования, если он используется, должен использоваться, как определено в Разделе Y.5.1.1.
Хотя преобразованные изображения могут быть указаны по их SOP Instance UID в идентификаторе запроса, который всегда находится на уровне экземпляра, сохраняется потребность в расширенном согласовании и указании Query/Retrieve View, чтобы обеспечить сохранение ссылочной целостности в возвращаемых SOP-экземплярах (например, чтобы было понятно, ссылается ли SOP Instance UID на преобразованное изображение или нет, в зависимости от ситуации).
Реляционное получение (Relational-retrieval) неприменимо к данному SOP-классу, поэтому подэлемент расширенного согласования не включает использование этого байта.
В информационной модели Composite Instance Retrieve Without Bulk Data Only используется только один уровень получения (Retrieve Level).
Таблица Z.6.1-1. Значение уровня получения для извлечения композитного экземпляра без объёмных данных
Использование слова «IMAGE», а не «Composite Instance», обусловлено историческими причинами для обеспечения обратной совместимости с предыдущими редакциями Стандарта. Это не следует понимать так, что композитные экземпляры типов, отличных от изображений, не включаются на уровне, обозначенном значением IMAGE.
Информационная модель Composite Instance Retrieve Without Bulk Data Only имеет только один уровень: IMAGE.
Таблица Z.6-1 определяет ключи на уровне Composite Instance информационной модели запроса/получения извлечения композитного экземпляра без объёмных данных.
Table Z.6-1. Composite Instance Level Keys for the Composite Instance Retrieve Without Bulk Data Information Model
Реализация может соответствовать одному из SOP-классов группы SOP-классов извлечения композитного экземпляра без объёмных данных в роли SCU, SCP или обеих ролях. Заявление о соответствии должно быть оформлено в формате, определённом в PS3.2.
Реализация, соответствующая одному из SOP-классов группы SOP-классов извлечения композитного экземпляра без объёмных данных в роли SCU, должна поддерживать получение в отношении информационной модели запроса/получения, описанной в Разделе Z.6.1.1, с использованием поведения SCU для C-GET, описанного в Разделе Z.4.2.2. Реализация, соответствующая одному из SOP-классов группы SOP-классов извлечения композитного экземпляра без объёмных данных в роли SCU и генерирующая получения с использованием операции C-GET, должна указать в своём заявлении о соответствии SOP-классы класса услуг хранения, в отношении которых она будет поддерживать подоперации C-STORE, генерируемые C-GET.
Реализация, соответствующая одному из SOP-классов группы SOP-классов извлечения композитного экземпляра без объёмных данных в роли SCP, должна поддерживать получение в отношении обоих уровней информационной модели получения, описанной в Разделе Z.6.1.1, с использованием поведения SCP для C-GET, описанного в Разделе Z.4.2.3. Реализация, соответствующая одному из SOP-классов группы SOP-классов извлечения композитного экземпляра без объёмных данных в роли SCP и удовлетворяющая получения с использованием операции C-GET, должна указать в своём заявлении о соответствии SOP-классы класса услуг хранения, в отношении которых она будет поддерживать подоперации C-STORE, генерируемые C-GET.
SOP-классы в группе SOP-классов извлечения композитного экземпляра без объёмных данных класса услуг «Запрос/получение» идентифицируют информационную модель Composite Instance Retrieve Without Bulk Data Only и поддерживаемые операции DIMSE-C. Стандартные SOP-классы перечислены в Таблице Z.6.1.3-1.
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.
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.
Классы сервисов запроса/получения шаблона импланта определяют классы сервисов прикладного уровня, обеспечивающие доступ к композитным объектам Implant Template и Implant Assembly Template.
Ключевые атрибуты служат двум целям: они могут использоваться как ключевые атрибуты сопоставления или как возвращаемые ключевые атрибуты. Ключевые атрибуты сопоставления используются для сопоставления (критерии, применяемые в запросе C-FIND для определения того, соответствует ли сущность запросу). Возвращаемые ключевые атрибуты используются для указания желаемых возвращаемых атрибутов (какие элементы, помимо ключевых атрибутов сопоставления, должны быть возвращены в ответе C-FIND).
Ключи сопоставления обычно используются в предложении SQL «where». Возвращаемые ключи обычно используются в предложении SQL «select» для передачи значений атрибутов.
Ключевые атрибуты сопоставления могут иметь Тип «обязательный» (R) или «необязательный» (O). Возвращаемые ключевые атрибуты могут иметь Тип 1, 1C, 2, 2C, 3, как определено в PS3.5.
Для того чтобы служить SCP класса сервиса запроса/получения шаблона импланта, DICOM AE обладает информацией об атрибутах ряда композитных экземпляров SOP Implant Template или Implant Assembly Template. Эта информация организована в информационную модель. Информационные модели для различных классов SOP, указанных в настоящем Приложении, определены в Section BB.6.
Два равноправных 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 совпадает с семантикой, определённой в разделе «Определение сервиса» сервисного класса запроса/получения, за исключением того, что имеется только один уровень получения.
Информационные модели 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.
Информационные модели Implant Template основаны на одноуровневой сущности:
Экземпляр объекта Implant Template содержит атрибуты, связанные с информационной сущностью (IE) объекта Implant Template композитных IOD, как определено в PS3.3.
Информационная модель Implant Assembly Template основана на одноуровневой сущности:
Экземпляр объекта Implant Assembly Template содержит атрибуты, связанные с информационной сущностью (IE) объекта Implant Assembly Template композитных IOD, как определено в PS3.3.
Информационная модель Implant Template Group основана на одноуровневой сущности:
Экземпляр объекта Implant Template Group содержит атрибуты, связанные с информационной сущностью (IE) объекта Implant Template Group композитных IOD, как определено в PS3.3.
См. определение операции C-FIND для класса сервиса базового управления рабочим списком (K.4.1), заменив «Worklist» на «Implant Template». Должен использоваться метод поиска «Worklist».
UID класса SOP определяет соответственно информационную модель Implant Template или Implant Assembly Template, относительно которой выполняется C-FIND. Ключевые атрибуты и допустимые для запроса значения определены в определениях классов SOP для информационной модели Implant Template и Implant Assembly Template.
При получении нескольких экземпляров Implant Template с одинаковым Implant Part Number принимающее приложение должно использовать Effective DateTime (0068,6226) для определения нужного экземпляра.
SCP этого класса SOP должен поддерживать уровень хранения 2 (полный), определённый в Section B.4.1.
См. определение операции 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.
См. определение согласования ассоциации для класса сервиса базового управления рабочим списком (K.5).
Информационная модель Implant Template состоит из одной сущности. В ответ на заданный запрос C-FIND SCP должен отправить один ответ C-FIND на каждый подходящий экземпляр Implant Template.
Информационная модель Implant Assembly Template состоит из одной сущности. В ответ на заданный запрос C-FIND SCP должен отправить один ответ C-FIND на каждый подходящий экземпляр Implant Assembly Template.
Информационная модель Implant Template Group состоит из одной сущности. В ответ на заданный запрос C-FIND SCP должен отправить один ответ C-FIND на каждый подходящий экземпляр Implant Template Group.
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
|
Этот атрибут обязателен, если используются расширенные или заменяющие наборы символов. См. Section C.2.2.2 and Section C.4.1.1. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению, сопоставления с подстановочными знаками или универсального сопоставления. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению, сопоставления с подстановочными знаками или универсального сопоставления. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению, сопоставления с подстановочными знаками или универсального сопоставления. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению, сопоставления с подстановочными знаками или универсального сопоставления. |
||||
|
Этот атрибут должен быть получен с использованием сопоставления последовательностей или универсального сопоставления. |
||||
|
Должен быть получен с использованием сопоставления по списку UID. |
||||
|
Должен быть получен с использованием сопоставления по списку UID. |
||||
|
Этот атрибут должен быть получен с использованием сопоставления последовательностей или универсального сопоставления. |
||||
|
Должен быть получен с использованием сопоставления по списку UID. |
||||
|
Должен быть получен с использованием сопоставления по списку UID. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению или сопоставления диапазона. |
||||
|
Этот атрибут должен быть получен с использованием сопоставления последовательностей или универсального сопоставления. |
||||
|
Должен быть получен с использованием сопоставления по списку UID. |
||||
|
Должен быть получен с использованием сопоставления по списку UID. |
||||
|
Этот атрибут должен быть получен с использованием сопоставления последовательностей или универсального сопоставления. |
||||
|
Этот атрибут должен быть получен с использованием сопоставления по единственному значению или универсального сопоставления. |
||||
|
>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
|
Этот атрибут должен быть получен с использованием сопоставления последовательностей или универсального сопоставления. |
||||
|
>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
|
Этот атрибут должен быть получен с использованием сопоставления последовательностей или универсального сопоставления. |
||||
|
>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
|
Этот атрибут должен быть получен с использованием сопоставления последовательностей или универсального сопоставления. |
||||
|
>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
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
|
Этот атрибут обязателен, если используются расширенные или заменяющие наборы символов. См. Section C.2.2.2 and Section C.4.1.1. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению, сопоставления с подстановочными знаками или универсального сопоставления. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению, сопоставления с подстановочными знаками или универсального сопоставления. |
||||
|
Этот атрибут должен быть получен с использованием сопоставления по единственному значению или универсального сопоставления. |
||||
|
>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
|
Должен быть получен с использованием сопоставления последовательностей или универсального сопоставления. |
||||
|
Должен быть получен с использованием сопоставления по списку UID. |
||||
|
Должен быть получен с использованием сопоставления по списку UID. |
||||
|
Должен быть получен с использованием сопоставления последовательностей или универсального сопоставления. |
||||
|
Должен быть получен с использованием сопоставления по списку UID. |
||||
|
Должен быть получен с использованием сопоставления по списку UID. |
||||
|
Должен быть получен с использованием сопоставления последовательностей или универсального сопоставления. |
||||
|
Должен быть получен с использованием сопоставления по списку UID. |
||||
|
Должен быть получен с использованием сопоставления по списку UID. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению, сопоставления с подстановочными знаками или универсального сопоставления. |
||||
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
|
Этот атрибут обязателен, если используются расширенные или заменяющие наборы символов. См. Section C.2.2.2 and Section C.4.1.1. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению, сопоставления с подстановочными знаками или универсального сопоставления. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению, сопоставления с подстановочными знаками или универсального сопоставления. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению или сопоставления диапазона. |
||||
|
Должен быть получен с использованием сопоставления последовательностей или универсального сопоставления |
||||
|
Должен быть получен с использованием сопоставления по списку UID. |
||||
|
Должен быть получен с использованием сопоставления по списку UID. |
||||
Реализация может соответствовать одному из классов SOP информационных моделей Implant Template, Implant Assembly Template или Implant Template Group в роли SCU, SCP, любой комбинации из двух этих ролей или всех трёх. Заявление о соответствии должно иметь формат, определённый в PS3.2.
Реализация, соответствующая одному из классов 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) при кодировании запросов и интерпретации ответов.
Реализация, соответствующая одному из классов SOP информационных моделей Implant Template, Implant Assembly Template или Implant Template Group, в роли SCU должна поддерживать передачи к соответствующей информационной модели с использованием базового поведения C-MOVE SCU, описанного для сервисного класса запроса/получения (см. Section C.4.2.2.1 and Section BB.4.2).
Реализация, соответствующая одному из классов SOP информационных моделей Implant Template, Implant Assembly Template или Implant Template Group, в роли SCU должна поддерживать передачи к соответствующей информационной модели с использованием базового поведения C-GET SCU, описанного для сервисного класса запроса/получения (см. Section C.4.3.2).
Реализация, соответствующая одному из классов 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) при интерпретации запросов, выполнении сопоставления и кодировании ответов.
Реализация, соответствующая одному из классов 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.
Реализация, соответствующая одному из классов 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.
Классы 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:
Настоящее приложение определяет сервис и классы 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-1, Таблица CC.1.1-1 и Таблица CC.1.1-2 определяют, как должны обрабатываться изменения состояния унифицированного этапа процедуры.
Следующие взаимодействия представляют собой пример последовательности событий и переходов состояний. Обратите внимание, что описанные здесь сервисы 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
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
Сервисы 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 соответственно.
Данная операция позволяет SCU запросить у SCP изменение состояния экземпляра унифицированного этапа процедуры (UPS). Данная операция вызывается SCU посредством DIMSE-сервиса N-ACTION.
DICOM AE, заявляющие соответствие классу SOP UPS Pull в роли SCU и/или SCP, должны поддерживать типы действий и информацию о действии, указанные в Таблица CC.2.1-1.
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.
Выполняющий SCU может пожелать сохранить Transaction UID в энергонезависимой памяти. Это позволило бы SCU сохранить контроль над UPS после восстановления после сбоя.
Если два 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.
Перед отправкой изменения состояния на CANCELED выполняющий SCU может выполнить N-SET значений Reason For Cancellation, Procedure Step Discontinuation Reason Code Sequence, Contact Display Name или Contact URI, чтобы предоставить наблюдающим SCU сведения об обстоятельствах отмены.
Чтобы запросить отмену 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.
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 вышел из строя.
После успешного изменения состояния экземпляра 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-2 определяет значения кодов состояния, которые могут возвращаться в ответе N-ACTION. Общие значения кодов состояния и поля, связанные со значениями кодов состояния, определены для сервиса DIMSE N-ACTION в PS3.7.
Table CC.2.1-2. N-ACTION Response Status Values [for Change UPS State]
Данная операция позволяет SCU, не контролирующему данный экземпляр унифицированного этапа процедуры (UPS), запросить у SCP отмену этого экземпляра. Данная операция вызывается SCU посредством DIMSE-сервиса N-ACTION.
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
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.
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-2 определяет значения кодов состояния, которые могут возвращаться в ответе N-ACTION. Общие значения кодов состояния и поля, связанные со значениями кодов состояния, определены для сервиса DIMSE N-ACTION в PS3.7.
Table CC.2.2-2. N-ACTION Response Status Values [for Request UPS Cancel]
Данная операция позволяет SCU подписаться у SCP для получения N-EVENT-REPORT о последующих изменениях состояния экземпляра UPS либо отменить подписку, чтобы больше не получать такие N-EVENT-REPORT. Данная операция вызывается SCU посредством DIMSE-сервиса N-ACTION.
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
|
Matching Keys (see Section CC.2.3.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
See Section GGG.1 “Introduction” in PS3.17 Reliable Watchers and Deletion Locks for further discussion of deletion locks.
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 было успешно изменено.
При подписке на конкретный экземпляр SCU также может ожидать получения начального N-EVENT-REPORT, содержащего текущее состояние данного экземпляра UPS. При глобальной подписке со значением Deletion Lock, равным TRUE, SCU может ожидать получения начальных N-EVENT-REPORT для каждого экземпляра, которым в данный момент управляет SCP. Начальные N-EVENT-REPORT для вновь созданных экземпляров, полученные в результате глобальной подписки, будут представлены как переходы в состояние SCHEDULED.
Пользовательский агент 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.
По получении запроса 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.
SCP, поддерживающий фильтрованную глобальную подписку (Filtered Global Subscription), должен создавать подписку экземпляра для каждого экземпляра UPS, который соответствовал бы запросу C-FIND с ключами сопоставления, предоставленными в запросе подписки.
SCP должен поддерживать ту же логику сопоставления, что используется для C-FIND (см. Раздел CC.2.8.3).
Таблица 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]
Данная операция позволяет SCP уведомить SCU об изменении состояния экземпляра UPS либо об изменении состояния самого SCP. Данная операция вызывается SCP посредством DIMSE-сервиса N-EVENT-REPORT.
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
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.
Уведомление UPS Cancel Requested включает AE запрашивающего SCU, что может быть полезно выполняющему SCU при оценке значимости/полномочности запроса на отмену.
В уведомлении также могут быть предоставлены 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 подвергся холодному запуску, и т. п.
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:
Значение 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 не обязан ставить сообщение в очередь или повторять попытку, и это не должно подразумевать какого-либо влияния на список подписки или блокировки удаления.
Для сервиса N-EVENT-REPORT не определены специфичные для сервисного класса значения состояния. См.PS3.7 for general response Status Codes.
Данная операция позволяет SCU дать указание SCP создать унифицированный этап процедуры. Данная операция вызывается SCU посредством DIMSE-сервиса N-CREATE.
Прикладная сущность, заявляющая соответствие классу SOP UPS Push в роли SCU, должна предоставлять все обязательные атрибуты, указанные в Таблица CC.2.5-3. Могут также предоставляться дополнительные атрибуты, определённые IOD UPS.
Прикладная сущность, заявляющая соответствие классу SOP UPS Push в роли SCP, должна поддерживать все обязательные атрибуты, указанные в Таблица CC.2.5-3. Также могут поддерживаться дополнительные атрибуты, определённые IOD 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
Для уменьшения объёма и сложности Таблица 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
Table CC.2.5-2b. UPS Content Item Macro
|
Тип значения, закодированного в данном элементе «имя-значение». |
||||||||
|
Значение даты и времени для данного элемента «имя-значение». |
||||||||
|
Кодированное значение понятия данного элемента «имя-значение». |
||||||||
|
Единицы измерения числового значения данного элемента «имя-значение». |
||||||||
|
Базовый CID 82 “Measurement Unit” |
||||||||
Table CC.2.5-2c. Referenced Instances and Access Macro
Table CC.2.5-2d. HL7V2 Hierarchic Designator Macro
Table CC.2.5-2e has been retired. See PS3.4-2025d.
Table CC.2.5-2g. Storage Macro
Table CC.2.5-2h. Issuer of Patient ID Qualifiers Macro
|
Обязательно, если Universal Entity ID (0040,0032) присутствует в данном элементе со значением. |
||||||||
|
Атрибуты Assigning Facility Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching). |
||||||||
|
>Include Table CC.2.5-2d “HL7V2 Hierarchic Designator Macro” |
||||||||
|
Атрибуты Assigning Jurisdiction Code Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching). |
||||||||
|
Базовый CID 5001 “Country” для кодов стран. |
||||||||
|
Атрибуты Assigning Agency or Department Code Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching). |
||||||||
Данная таблица объединяет требования к атрибутам для нескольких сервисов 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
|
(see CC.2.6.3) |
||||||||
|
Обязательно, если используется расширенный или заменяющий набор символов |
||||||||
|
См. CC.2.5.1.3.1 |
Однозначно идентифицирует класс SOP унифицированного этапа процедуры. См. Section CC.3.1 for further explanation. |
|||||||
|
Экземпляр SOP передаётся в Affected SOP Instance UID (0000,1000) |
Экземпляр SOP передаётся в Requested SOP Instance UID (0000,1001) |
Экземпляр SOP передаётся в Requested SOP Instance UID (0000,1001) |
Однозначно идентифицирует экземпляр SOP UPS. SOP Instance UID должен извлекаться с использованием сопоставления по одному значению (Single Value Matching). |
|||||
|
All other Attributes of the SOP Common Module |
||||||||
|
Unified Procedure Step Scheduled Procedure Information Module |
||||||||
|
Scheduled Procedure Step Priority должен извлекаться с использованием сопоставления по одному значению (Single Value Matching). |
||||||||
|
Scheduled Procedure Step Modification DateTime должен извлекаться с использованием сопоставления по одному значению (Single Value Matching) или сопоставления по диапазону (Range Matching). |
||||||||
|
Если значение не предоставлено SCU, SCP должен заполнить Worklist Label, например, используя значение по умолчанию либо назначив экземпляр UPS логическому рабочему списку. |
||||||||
|
Атрибуты Scheduled Station Name Code Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching). |
||||||||
|
Атрибуты Scheduled Station Class Code Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching). |
||||||||
|
Атрибуты Scheduled Station Geographic Location Code Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching). |
||||||||
|
Атрибуты Scheduled Human Performers Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching). |
||||||||
|
Атрибуты Scheduled Human Performers Code Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching). |
||||||||
|
Scheduled Procedure Step Start DateTime должен извлекаться с использованием сопоставления по одному значению (Single Value Matching) или сопоставления по диапазону (Range Matching). |
||||||||
|
Expected Completion DateTime должен извлекаться с использованием сопоставления по одному значению (Single Value Matching) или сопоставления по диапазону (Range Matching). |
||||||||
|
Scheduled Procedure Step Expiration DateTime должен извлекаться с использованием сопоставления по одному значению (Single Value Matching) или сопоставления по диапазону (Range Matching). |
||||||||
|
Атрибуты Scheduled Workitem Code Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching). |
||||||||
|
Input Readiness State должен извлекаться с использованием сопоставления по одному значению (Single Value Matching). |
||||||||
|
Атрибуты Input Information Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching). |
||||||||
|
>Include Table CC.2.5-2c “Referenced Instances and Access Macro” |
||||||||
|
Обязательно, если ожидается, что рабочий элемент приведёт к созданию каких-либо составных экземпляров DICOM, чей IOD содержит IE Study. Возможны ситуации, когда исполнитель не использует Study Instance UID, предложенный планировщиком. |
||||||||
|
Атрибуты 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 |
||||||||
|
Обязательно, если субъект рабочего элемента требует идентификации, либо если ожидается, что рабочий элемент приведёт к созданию объектов, идентифицирующих субъект. |
||||||||
|
>Include Table CC.2.5-2h “Issuer of Patient ID Qualifiers Macro” |
||||||||
|
>>Include Table CC.2.5-2h “Issuer of Patient ID Qualifiers Macro” |
||||||||
|
Обязательно, если Sex Parameters for Clinical Use Category Code Sequence (0010,0046) равен (131232, DCM, «Specified»). Может присутствовать в остальных случаях. |
||||||||
|
Обязательно, если Sex Parameters for Clinical Use Category Code Sequence (0010,0046) равен (131232, DCM, «Specified»). Может присутствовать в остальных случаях. |
||||||||
|
>Include Table CC.2.5-2c “Referenced Instances and Access Macro” |
||||||||
|
>Include Table CC.2.5-2d “HL7V2 Hierarchic Designator Macro” |
||||||||
|
Атрибуты Admitting Diagnoses Code Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching). |
||||||||
|
Может быть «изменено», пока UPS находится в состоянии SCHEDULED, путём отмены и повторного создания с «правильными» значениями. |
||||||||
|
Order Placer Identifier Sequence должен получаться только с помощью сопоставления последовательности (Sequence Matching). |
||||||||
|
>>Include Table CC.2.5-2d “HL7V2 Hierarchic Designator Macro” |
||||||||
|
Атрибуты Order Placer Identifier Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching). |
||||||||
|
>>Include Table CC.2.5-2d “HL7V2 Hierarchic Designator Macro” |
||||||||
|
Атрибуты Order Filler Identifier Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching). |
||||||||
|
>>Include Table CC.2.5-2d “HL7V2 Hierarchic Designator Macro” |
||||||||
|
All other Attributes of the Unified Procedure Step Relationship Module |
||||||||
|
All Attributes of the Patient Demographic Module |
||||||||
|
All other Attributes of the Patient Medical Module |
||||||||
|
All Attributes of the Visit Identification Module |
||||||||
|
All Attributes of the Visit Status Module |
||||||||
|
All Attributes of the Visit Admission Module |
||||||||
|
Procedure Step State должен извлекаться с использованием сопоставления по одному значению (Single Value Matching) |
||||||||
|
>>Include Table CC.2.5-2b “UPS Content Item Macro” |
||||||||
|
>>>Include Table CC.2.5-2b “UPS Content Item Macro” |
||||||||
|
Если UPS State (0074,1000) изменяется на CANCELED, а данный атрибут не имеет значения, SCP должен заполнить его текущими датой и временем. |
||||||||
|
Unified Procedure Step Performed Procedure Information Module |
||||||||
|
См. CC.2.5.1.3.2. |
||||||||
|
Должно быть указано, если известно. Ключ возврата обязателен, если задан. Атрибуты Actual Human Performers Sequence должны получаться только с помощью сопоставления последовательности (Sequence Matching). |
||||||||
|
>>>Include Table CC.2.5-2a “UPS Code Sequence Macro” |
||||||||
|
>>Include Table CC.2.5-2b “UPS Content Item Macro” |
||||||||
|
Если соответствующие выходные объекты отсутствуют, данная последовательность может не содержать элементов. |
||||||||
|
>Include Table CC.2.5-2c “Referenced Instances and Access Macro” |
||||||||
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).
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 определяет значения кодов состояния, которые могут возвращаться в ответе N-CREATE. Общие значения кодов состояния и поля, связанные со значениями кодов состояния, определены для сервиса DIMSE N-CREATE в PS3.7.
Данная операция позволяет SCU установить значения атрибутов экземпляра UPS и предоставить сведения о конкретном реальном UPS, находящемся под контролем данного SCU. Данная операция вызывается SCU посредством DIMSE-сервиса N-SET.
Прикладная сущность, заявляющая соответствие классу SOP UPS Pull в роли SCU, может по своему выбору изменять подмножество атрибутов, поддерживаемых SCP. Прикладная сущность, заявляющая соответствие в роли SCP классу SOP UPS Pull, должна поддерживать атрибуты, указанные вTable CC.2.5-3
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.
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-1 определяет значения кодов состояния, которые могут возвращаться в ответе N-SET. Общие значения кодов состояния и поля, связанные со значениями кодов состояния, определены для сервиса DIMSE N-SET в PS3.7.
Table CC.2.6-1. N-SET Response Status Values [for Set Unified Procedure Step Information]
Данная операция позволяет SCU получить от SCP сведения о конкретном реальном этапе процедуры, представленном как экземпляр унифицированного этапа процедуры. Данная операция вызывается SCU посредством DIMSE-сервиса N-GET.
Прикладная сущность, заявляющая соответствие классам SOP UPS Pull или UPS Watch в роли SCU, может по своему выбору получать подмножество значений атрибутов, поддерживаемых SCP. Прикладная сущность, заявляющая соответствие в роли SCP этим классам SOP, должна поддерживать атрибуты, указанные вTable CC.2.5-3.
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.
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-1 определяет значения кодов состояния, которые могут возвращаться в ответе N-GET. Общие значения кодов состояния и поля, связанные со значениями кодов состояния, определены для сервиса DIMSE N-GET в PS3.7.
Данная операция позволяет SCU найти и получить сведения об интересующих его экземплярах унифицированного этапа процедуры, которыми управляет SCP. Данная операция вызывается SCU посредством DIMSE-сервиса C-FIND. SCP обрабатывает такие запросы, сопоставляя управляемые им экземпляры UPS с ключами, присутствующими в идентификаторе, и возвращает ответы C-FIND.
SCU может выполнять поиск экземпляра UPS с намерением начать работу над одним из них либо с намерением подписаться на отслеживание хода выполнения данного экземпляра.
В ответ на данный запрос C-FIND SCP может отправить несколько ответов C-FIND (то есть по одному ответу C-FIND на каждый подходящий элемент рабочего списка). Каждый элемент рабочего списка описывает одну задачу и связанную с ней информацию.
Информационная модель унифицированного этапа процедуры представлена диаграммой «сущность-связь», показанной на Рисунок CC.2.8-1.
В модели присутствует только одна информационная сущность — унифицированный этап процедуры. Атрибуты унифицированного этапа процедуры можно найти вTable CC.2.5-3.
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.
Атрибут Priority определяет запрошенный приоритет операции C-FIND по отношению к другим операциям DIMSE, выполняемым тем же SCP.
Обработка запросов приоритета не является обязательной для SCP. Поддерживает ли SCP обработку приоритета и значение различных уровней приоритета должны быть указаны в заявлении о соответствии SCP.
Both the C-FIND request and response contain an Identifier encoded as a Data Set (see PS3.5).
Идентификатор в запросе 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 для соответствующей информационной модели унифицированного этапа процедуры.
Ответ 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). Данный атрибут должен быть включён, если какие-либо атрибуты времени в идентификаторе ответа подлежат явной интерпретации в указанном местном часовом поясе. В противном случае он не должен присутствовать, то есть не должен передаваться со значением нулевой длины.
Все 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 был выполнен успешно.
Все 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.
Ответ со статусом Success не содержит идентификатора. Полное определение см. вPS3.7.
Если совпадений нет, ответы со статусом Pending не отправляются — отправляется только один ответ со статусом Success.
Двусторонняя аутентификация машин/пользователей/приложений возможна на этапе установления ассоциации (см. PS3.7 и PS3.15). PS3.7 предоставляет код состояния Failure 0124H «Refused: Not authorized». Дальнейшее требование или документирование функций аутентификации и/или авторизации со стороны SCU или SCP выходит за рамки данного класса SOP.
Для формирования ответов о совпадениях используются следующие шаги.
Сопоставить ключевые атрибуты сопоставления (Matching Key Attributes), содержащиеся в идентификаторе запроса C-FIND, со значениями ключевых атрибутов каждого элемента рабочего списка.
Если ключи сопоставления отсутствуют, то совпадений нет — вернуть ответ со статусом Success и без идентификатора.
Для каждой сущности, атрибуты которой соответствуют всем указанным ключевым атрибутам сопоставления, сформировать идентификатор. Данный идентификатор должен содержать все значения атрибутов данной сущности, соответствующие ключевым атрибутам сопоставления и возврата (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-2 определяет значения кодов состояния, которые могут возвращаться в ответе C-FIND. Общие значения кодов состояния и поля, связанные со значениями кодов состояния, определены для сервиса DIMSE C-FIND в PS3.7.
Table CC.2.8-2. C-FIND Response Status Values [for Search for Unified Procedure Step]
Коды состояния возвращаются в сообщениях ответа 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 различала конкретные коды состояния внутри допустимого диапазона, отсутствуют.
С IOD унифицированного этапа процедуры связано пять классов SOP UPS. Каждый класс SOP поддерживает различные виды взаимодействия с экземпляром UPS (также называемым элементом рабочего списка).
Класс SOP UPS Push позволяет системам-SCU:
Класс SOP UPS Pull позволяет системам-SCU:
Класс SOP UPS Watch позволяет системам-SCU:
Класс SOP UPS Event позволяет системам-SCU:
Класс SOP UPS Query позволяет системам-SCU:
DICOM AE, заявляющие соответствие одному или нескольким из этих классов SOP, должны поддерживать все сервисы, отмеченные «M», в соответствующих Таблица CC.2-1, Таблица CC.2-2, Таблица CC.2-3, Таблица CC.2-4 и Таблица CC.2-5.
Все экземпляры 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, как показано в следующем списке:
Экземпляр 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).
Установление ассоциации — это первая фаза любого сеанса связи между равноправными 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).
Реализации, заявляющие соответствие любому из классов SOP UPS (UPS Pull, UPS Push, UPS Watch, UPS Event и UPS Query), должны соответствовать требованиям, описанным в следующих разделах, и должны включать в своё заявление о соответствии информацию, описанную ниже.
Реализация может соответствовать любому из классов SOP UPS в роли SCU или SCP. Заявление о соответствии должно быть составлено в формате, определённом вPS3.2.
Реализация, соответствующая любому из классов SOP UPS в роли SCU, должна удовлетворять требованиям соответствия для выполняемых ею операций.
Заявление о соответствии 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).
Реализация, соответствующая любому из классов SOP UPS в роли SCP, должна удовлетворять требованиям соответствия для выполняемых ею операций.
Заявление о соответствии 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).
Классы сервисов верификации аппарата лучевой терапии (RT Machine Verification Service Classes) определяют класс сервиса прикладного уровня, обеспечивающий независимую верификацию геометрических и дозиметрических параметров системы доставки излучения перед проведением лучевой терапии. Классы сервисов предназначены для использования как при обычной (например, фотонной, электронной), так и при терапии частицами (например, протонной, ионной).
В модели верификации аппарата лучевой терапии пользователем сервиса (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.
IOD верификации аппарата являются абстракциями информации, необходимой для проверки правильности настройки системы доставки лечения перед проведением лучевой терапии.
Таблица DD.3.2-1 показывает службы DIMSE, применимые к данным IOD.
Значение параметра «Использование (SCU/SCP)» описано в Разделе H.2.4.
В этом разделе описывается поведение служб DIMSE, специфичное для данного IOD. Общее поведение служб DIMSE специфицировано в PS3.7.
N-CREATE используется для создания экземпляра соответствующего класса SOP верификации аппарата.
N-SET используется для передачи параметров верификации в MPV путём установки атрибутов экземпляра соответствующего класса SOP верификации аппарата.
Все атрибуты таблицы, относящиеся к количеству определённых элементов (например, Number of Wedges, Number of Control Points), задают это количество в команде N-SET. Нумерация в запросе верификации пучков (Beams Verification Request) не обязательно совпадает с нумерацией в референсном RT-плане.
Перечень атрибутов 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
|
(обязательно, если план содержит более одной группы фракций) |
|||
|
>Include Table CC.2.5-2h “Issuer of Patient ID Qualifiers Macro” |
|||
|
(обязательно, если MPV способен верифицировать клинья). См. Раздел DD.3.2.1.1.1. |
|||
|
(обязательно, если MPV способен верифицировать компенсаторы). См. Раздел DD.3.2.1.1.1. |
|||
|
(обязательно, если MPV способен верифицировать блоки). См. Раздел DD.3.2.1.1.1. |
|||
|
(обязательно, если MPV способен верифицировать аппликаторы). См. Раздел DD.3.2.1.1.1. |
|||
|
(обязательно, если MPV способен верифицировать фиксирующие устройства). См. Раздел DD.3.2.1.1.1. |
|||
|
(обязательно, если MPV способен верифицировать болюс). См. Раздел DD.3.2.1.1.1. |
|||
|
All other Attributes of the RT General Machine Verification Module |
|||
|
(обязательно, если Number of Wedges (300A,00D0) не равно нулю; может быть включён один или несколько элементов) |
|||
|
(обязательно, если отправлена Beam Limiting Device Leaf Pairs Sequence (3008,00A0); может быть включён один или несколько элементов) |
|||
|
All other Attributes of the RT Conventional Machine Verification Module |
|||
Перечень атрибутов 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
|
(обязательно, если план содержит более одной группы фракций) |
|||
|
>Include Table CC.2.5-2h “Issuer of Patient ID Qualifiers Macro” |
|||
|
См. Section DD.3.2.1.1.1. |
|||
|
(обязательно, если MPV способен верифицировать клинья). См. Раздел DD.3.2.1.1.1. |
|||
|
(обязательно, если MPV способен верифицировать компенсаторы). См. Раздел DD.3.2.1.1.1. |
|||
|
(обязательно, если MPV способен верифицировать блоки). См. Раздел DD.3.2.1.1.1. |
|||
|
(обязательно, если MPV способен верифицировать аппликаторы). См. Раздел DD.3.2.1.1.1. |
|||
|
См. Section DD.3.2.1.1.1. |
|||
|
(обязательно, если MPV способен верифицировать фиксирующие устройства). См. Раздел DD.3.2.1.1.1. |
|||
|
(обязательно, если MPV способен верифицировать болюс). См. Раздел DD.3.2.1.1.1. |
|||
|
All other Attributes of the RT General Machine Verification Module |
|||
|
(обязательно, если отправлена Beam Limiting Device Leaf Pairs Sequence (3008,00A0); может быть включён один или несколько элементов) |
|||
|
(обязательно, если Number of Range Shifters (300A,0312) не равно нулю; может быть включён один или несколько элементов) |
|||
|
(обязательно, если Number of Lateral Spreading Devices (300A,0330) не равно нулю; может быть включён один или несколько элементов) |
|||
|
(обязательно, если Number of Range Modulators (300A,0340) не равно нулю; может быть включён один или несколько элементов) |
|||
|
(обязательно, если Number of Wedges (300A,00D0) не равно нулю; может быть включён один или несколько элементов) |
|||
|
(обязательно, если Wedge Type (300A,00D3) клина, указанного в Referenced Wedge Number (300C,00C0), равен PARTIAL_STANDARD или PARTIAL_MOTORIZ) |
|||
|
(обязательно, если Snout Sequence включена в RT-план, указанный в Referenced RT Plan Sequence (300C,0002); в данной последовательности допускается только один элемент) |
|||
|
(обязательно, если MPV способен верифицировать компенсаторы диапазона (range shifters)). См. Раздел DD.3.2.1.1.1. |
|||
|
(обязательно, если MPV способен верифицировать устройства бокового рассеивания (lateral spreading devices)). См. Раздел DD.3.2.1.1.1. |
|||
|
(обязательно, если MPV способен верифицировать модуляторы диапазона (range modulators)). См. Раздел DD.3.2.1.1.1. |
|||
|
(обязательно, если Range Modulator Type (300A,0348) равен WHL_MODWEIGHTS) |
|||
|
(обязательно, если Radiation Type (300A,00C6) имеет значение ION) |
|||
|
(обязательно, если Radiation Type (300A,00C6) имеет значение ION) |
|||
|
(обязательно, если Radiation Type (300A,00C6) имеет значение ION) |
|||
|
All other Attributes of the RT Ion Machine Verification Module |
|||
Если MPV не способен выполнить тип верификации, требуемый атрибутом, этот атрибут не должен присутствовать. Если MPV способен выполнить требуемый атрибутом тип верификации, атрибут будет иметь нулевую длину при отсутствии таких модификаторов и будет содержать значения с одним или несколькими элементами при их наличии.
Таблица 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
Значения статуса для N-SET, специфичные для данных классов SOP, определены следующим образом:
Table DD.3.2.1.2-2. RT Ion Machine Verification SOP Class N-SET Status Values
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.
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.
N-GET используется для получения статуса и результатов верификации соответствующего класса SOP верификации аппарата.
Таблица DD.3.2.2.1-1 описывает требования поддержки N-GET для макроса атрибута селектора (Selector Attribute Macro). См. Раздел 5.4 для значения кода типа требования.
Перечень атрибутов 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
|
>Include Table CC.2.5-2h “Issuer of Patient ID Qualifiers Macro” |
||
|
(в данную последовательность должно быть включено ноль или более элементов) |
||
|
>Include Table DD.3.2.2.1-1 “Verification Parameters Selector Attribute Macro” |
||
|
(в данную последовательность должно быть включено ноль или более элементов) |
||
|
>Include Table DD.3.2.2.1-1 “Verification Parameters Selector Attribute Macro” |
||
|
All other Attributes of the RT General Machine Verification Module |
||
|
All other Attributes of the RT Conventional Machine Verification Module if RT Conventional Machine Verification SOP Class is applicable |
||
|
All other Attributes of the RT Ion Machine Verification Module if RT Ion Machine Verification SOP Class is applicable |
||
Таблица 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
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.
N-ACTION используется для инициации верификации параметров экземпляра соответствующего класса SOP верификации аппарата.
Типы действий N-ACTION определены, как показано в Таблице DD.3.2.3-1.
Таблица 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
N-DELETE используется для удаления экземпляра соответствующего класса SOP верификации аппарата.
Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.
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 вручную или автоматически. Такое поведение выходит за рамки Стандарта.
N-EVENT-REPORT используется MPV для уведомления TDS о статусе задачи верификации (успешной или нет) либо для уведомления TDS о том, что верификация ожидает выполнения (выполняется). Кодирование информации о событии уведомления определено в PS3.7.
Аргументы N-EVENT-REPORT определены, как показано в Таблице DD.3.2.5-1.
Специфические коды состояния отсутствуют. См. PS3.7 для кодов состояния ответа.
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 .
Сервисный класс системы отображения (Display System Service Class) позволяет пользователям сервиса получать параметры, относящиеся к подсистеме(ам) отображения.
IOD системы отображения (Display System IOD) представляет собой абстракцию системы мягкого копирования (soft-copy) и является базовой информационной сущностью для контроля состояния системы отображения. Экземпляр SOP системы отображения создаётся SCP при запуске системы отображения и имеет общеизвестный (well-known) UID экземпляра SOP.
Служба DIMSE, показанная в Таблице EE.2.2-1, применима к IOD системы отображения в рамках SOP-класса системы отображения.
В этом разделе описывается поведение служб DIMSE, специфичное для данного IOD. Общее поведение служб DIMSE определено в PS3.7.
N-GET используется для получения информации от экземпляра SOP-класса системы отображения.
Для уменьшения размера и сложности EE.2.2.1-2 используется макро-нотация.
Table EE.2.2.1-1. Table Result Context Macro
Атрибуты, которые могут быть получены, показаны в Таблице EE.2.2.1-2.
Table EE.2.2.1-2. Display System N-GET Attributes
|
(Обязательно, если используется расширенный или заменяющий набор символов) |
||
|
(Обязательно, если Institution Code Sequence (0008,0082) не присутствует. Может присутствовать в остальных случаях.) |
||
|
(Обязательно, если Institution Name (0008,0080) не присутствует. Может присутствовать в остальных случаях.) |
||
|
(Обязательно, если значение Display Function Type (0028,7019) равно GAMMA) |
||
|
(Обязательно, если значение Display Function Type (0028,7019) равно USER_DEFINED) |
||
|
(Обязательно, если значение Display Function Type (0028,7019) равно USER_DEFINED) |
||
|
(Обязательно, если значение Display Function Type (0028,7019) равно USER_DEFINED. Может присутствовать в остальных случаях.) |
||
|
(Обязательно, если присутствует Reflected Ambient Light (2010,0160).) |
||
|
>>>>Include Table EE.2.2.1-1 “Table Result Context Macro” |
||
|
>>>>Include Table EE.2.2.1-1 “Table Result Context Macro” |
||
|
>>>>>>Include Table CC.2.5-2a “UPS Code Sequence Macro” |
||
|
(Обязательно, если Test Pattern Code Sequence (0028,702C) отсутствует в данном элементе. Может присутствовать в остальных случаях.) |
||
|
(Обязательно, если Referenced SOP Instance является многокадровым изображением, ссылка относится не ко всем кадрам, и Referenced Segment Number (0062,000B) не присутствует.) |
||
|
(Обязательно, если Referenced SOP Instance является Segmentation или Surface Segmentation, ссылка относится не ко всем сегментам, и Referenced Frame Number (0008,1160) не присутствует.) |
||
|
>>>>>Include Table CC.2.5-2a “UPS Code Sequence Macro” |
||
|
>>>>Include Table EE.2.2.1-1 “Table Result Context Macro” |
||
|
>>>>>Include Table CC.2.5-2a “UPS Code Sequence Macro” |
||
|
(Обязательно, если значение White Point Flag (0028,7021) равно YES.) |
||
|
(Обязательно, если присутствует Reflected Ambient Light (2010,0160).) |
||
|
>>>>Include Table EE.2.2.1-1 “Table Result Context Macro” |
||
|
(Обязательно, если присутствует Reflected Ambient Light (2010,0160).) |
||
SCU использует N-GET, чтобы запросить у SCP предоставление содержимого экземпляра SOP системы отображения. SCU должен указать в примитиве запроса N-GET UID экземпляра SOP, для которого должны быть возвращены атрибуты.
SCU должен указать список атрибутов системы отображения, для которых должны быть возвращены значения. SCU не должен указывать атрибуты, определённые внутри последовательности, а вместо этого должен указать саму последовательность для возврата целиком.
SCU должен указать в примитиве запроса N-GET общеизвестный UID экземпляра SOP.
SCP должен вернуть значения указанных атрибутов экземпляра SOP системы отображения.
SCP должен вернуть код состояния для запрошенного извлечения экземпляра SOP. Значение кодов состояния Success, Warning и Failure определено в PS3.7.
Заявление о соответствии реализации данного SOP-класса должно следовать PS3.2.
Заявление о соответствии SCU должно определять следующие пункты:
Заявление о соответствии SCP должно определять следующие пункты:
Классы SOP хранения состояний объёмного представления расширяют функциональность сервисного класса хранения (Storage Service Class, определён в Приложении B), добавляя возможность передавать предполагаемое состояние объёмного представления (Volumetric Presentation State) или фиксировать существующее состояние объёмного представления. Эти классы SOP определяют информацию и поведение, которые могут использоваться для представления (отображения) изображений, на которые имеются ссылки внутри этих классов SOP.
Они включают возможность задания:
кадрирования наборов объёмных данных ограничивающим параллелепипедом, наклонными плоскостями и объектами сегментации
преобразований скалярных значений в P-Value или RGB-значения
композитинга нескольких потоков объёма и одного потока объёма с сегментацией
аннотаций, относящихся к объёму и к отображению, включая графику, текст и оверлеи, а также, опционально, ссылки на структурированный контент, задающий клинический контекст для аннотаций
принадлежности к коллекции связанных состояний объёмного представления, предназначенных для совместной обработки или отображения
позиции в наборе последовательно связанных состояний объёмного представления
ссылки на изображение, отображающее вид, описываемый состоянием объёмного представления
Каждое состояние объёмного представления соответствует одному виду (эквивалентно окну изображения (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 выбирает отображение нескольких состояний, входящих в коллекцию отображения, выходит за рамки настоящего стандарта.
Преобразования, заданные в классах SOP хранения состояний объёмного представления, заменяют собой преобразования, которые могут быть заданы в экземплярах SOP изображений, на которые есть ссылка. Если конкретное преобразование отсутствует в экземпляре SOP хранения состояния объёмного представления Volume Rendering, оно считается тождественным преобразованием, и любое эквивалентное преобразование, если оно присутствует в экземплярах SOP изображений, на которые есть ссылка, использоваться не должно.
Атрибуты классов SOP хранения состояний объёмного представления Volume Rendering, относящиеся к представлению, неизменяемы. Они никогда не должны модифицироваться или обновляться; для представления другого варианта представления может быть создан только производный экземпляр SOP с новым UID экземпляра SOP.
Классы SOP хранения состояний объёмного представления Planar MPR поддерживают набор преобразований для построения производных объёмных видов из входных объёмных данных.
Класс SOP хранения состояния объёмного представления Grayscale Planar MPR задаёт полутоновый объёмный вид из одного входного объёма. Последовательность преобразований от объёмных входных данных к значениям P-Value явно определена в эталонном конвейере, описанном на Рисунке FF.2-1.
Класс SOP хранения состояния объёмного представления Compositing Planar MPR задаёт вид с истинными цветами из одного или нескольких входных объёмов. Последовательность преобразований от объёмных входных данных к значениям PCS-Value явно определена в эталонном конвейере, описанном на Рисунке 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.
Классы SOP хранения состояний объёмного представления Volume Rendering поддерживают набор преобразований для построения производных объёмных видов из входных объёмных данных. Атрибуты, составляющие состояния объёмного представления Volume Rendering, определены в контексте эталонных конвейеров, описанных в настоящем разделе. Хотя эталонные конвейеры подразумевают определённый порядок выполнения операций объёмного рендеринга — классификации, передискретизации, затенения и композитинга, — конкретный порядок применения этих операций любым устройством, заявляющим соответствие настоящему стандарту, зависит от реализации и выходит за рамки настоящего стандарта. Ответственность за преобразование стандартных атрибутов в параметры, соответствующие конкретному порядку операций, реализованному в приложении просмотра, лежит на этом приложении.
Класс SOP хранения состояния объёмного представления Volume Rendering задаёт объёмный вид из одного входного объёма для построения вида, полученного объёмным рендерингом. Последовательность преобразований от объёмных входных данных к значениям PCS-Value явно определена в эталонном конвейере, описанном на Рисунке 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 последующие элементы.
Класс SOP хранения состояния объёмного представления Multiple Volume Rendering задаёт объёмный вид из более чем одного входного объёма. Последовательность преобразований от объёмных входных данных к значениям PCS-Value явно определена в эталонном конвейере, описанном на Рисунке FF.2.1.2.1-3. Конкретные алгоритмы объёмного рендеринга могут отличаться, но должны давать сходный внешний вид.
Предполагается, что все входные объёмы пространственно зарегистрированы относительно системы координат отсчёта состояния объёмного представления. Конкретный этап обработки, на котором выполняется передискретизация для достижения этой пространственной регистрации, является решением, принимаемым при реализации.
Каждый элемент в Volume Stream Sequence (0070,1A08) формирует один вход для компоновщика RGBA (RGBA Compositor).
Преобразование в значения PCS-Value выполняется после объёмного рендеринга.
Этот компонент преобразует объём RGBA в вид, полученный объёмным рендерингом, в соответствии с параметрами модуля Render Geometry. Реализация этого компонента зависит от конкретного устройства, но обычно включает такие этапы обработки, как вычисление градиента для нахождения нормалей, используемых в операции затенения, передискретизацию объёмных данных, затенение в соответствии с параметрами модуля Render Shading и композитинг передискретизированных данных для построения итогового вида, полученного объёмным рендерингом.
Этот компонент преобразует объёмную аннотацию, заданную в модуле Volumetric Graphic Annotation, в графический оверлей для двумерного вида, полученного объёмным рендерингом. Роль этого компонента — оценить объёмные графические аннотации, определить, какие графические элементы видны в виде, полученном объёмным рендерингом, и предоставить графику, накладываемую слоями на вид.
Входными данными для компонента графической проекции являются:
Алгоритм преобразования графической проекции определяет, видна ли каждая объёмная графическая аннотация в текущем виде, полученном объёмным рендерингом, с учётом объёмных данных, геометрии объёмного рендеринга (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).
Состояние объёмного представления может принимать несколько объёмов в качестве входных данных. Объём определён в Разделе 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).
Могут быть заданы комбинации методов кадрирования. Например, все входы могут быть кадрированы с использованием глобального кадрирования ограничивающим параллелепипедом в дополнение к другому методу кадрирования, применённому к одному или нескольким отдельным входам состояния объёмного представления.
Модуль 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 является входом для компонента объёмного рендеринга.
В настоящее время определено два типа компонентов классификации для преобразования скалярных входных данных в RGBA. Определены следующие компоненты:
One Input -> RGBA: этот компонент принимает реконструированные данные от одного входа в Volumetric Presentation State Input Sequence (0070,1201) и формирует выходные значения RGB и Alpha. Этот компонент классификации задаётся в элементе Presentation State Classification Component Sequence (0070,1801):
Two Inputs -> RGBA: этот компонент принимает реконструированные данные от двух входов в Volumetric Presentation State Input Sequence (0070,1201) и формирует выходные значения RGB и Alpha. Этот компонент используется в случае, когда требуется выполнить двумерное цветовое отображение. Этот компонент классификации задаётся в элементе Presentation State Classification Component Sequence (0070,1801):
Определено два типа компонентов композитинга для смешивания двух входных источников данных RGBA (либо одного RGBA и одного RGB). Определены следующие компоненты:
RGB Compositor: этот компонент принимает два входа RGBA (при этом один вход Alpha является опциональным) и объединяет данные в единый выход RGB. Каждый элемент Presentation State Compositor Component Sequence (0070,1805) задаёт один компонент RGB Compositor:
RGBA Compositor: этот компонент принимает два входа RGBA и объединяет данные в единый выход RGB и единый выход Alpha.
Component Type (0070,1802) задаёт компонент, определённый в каждом элементе Presentation State Classification Component Sequence (0070,1801), который, в свою очередь, по условиям управляет остальным содержимым элемента, обеспечивая необходимую спецификацию компонента. Внутренняя структура каждого компонента в виде блок-схемы приведена ниже:
Количество старших битов, извлекаемых из каждого входа, задаётся значением 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
Весовые передаточные функции, вычисляющие весовые коэффициенты, используемые функцией композитинга (Compositor Function) в зависимости от значений Alpha1 и Alpha2, задаются в виде весовых таблиц соответствия (LUT) в компонентах RGB Compositor и RGBA Compositor. Компоненты RGB Compositor и RGBA Compositor идентичны, за исключением композитинга дополнительной компоненты Alpha в RGBA Compositor:
Поскольку каждая весовая таблица 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) от ошибок переполнения.
Состояния объёмного представления предоставляют два способа аннотирования видов:
Аннотации на виде обеспечивают применение свободного неформатированного текста или векторной графики, как описано в Разделе 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.
В состояниях объёмного представления определено несколько различных стилей анимации. В общем случае стиль анимации изменяет либо входные данные, либо обработку, либо геометрию вида для получения изменяющегося вида представления. В настоящем разделе описан каждый из стилей анимации и способ получения анимированного вида.
Значение 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); в этом случае входы обрабатываются совместно для формирования кадра анимированного вида.
Например, пары входных элементов могут представлять один и тот же входной объём в определённый момент времени с двумя разными сегментационными кадрированиями (представляющими разные структуры органов), которые смешиваются в единый вид.
Значение 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 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.
Типичным применением этого стиля анимации является перемещение вдоль кривой, проходящей по центру толстой кишки или кровеносного сосуда.
Значение Presentation Animation Style (0070,1A01), равное FLYTHROUGH, указывает, что задаётся анимация пролёта (Flythrough Animation). В этом стиле анимации состояние объёмного представления задаёт исходный вид, полученный объёмным рендерингом, и заданное перемещение вида вдоль пути через объём. См. Рисунок FF.2.4.2.4-1.
Значение 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) в градусах в секунду, хотя рекомендуется, чтобы изменения направления на концах диапазона вращения были плавными, что подразумевает замедление вращения по мере приближения к конечным точкам.
Компоновка нескольких состояний объёмного представления не задаётся процессом объёмного преобразования. Однако в состояниях объёмного представления есть атрибуты, которые могут влиять на общую компоновку отображения.
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.
В дополнение к поведению для сервисного класса хранения, заданному в Разделе 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 хранения структурированных отчётов.
В дополнение к требованиям к заявлению о соответствии для сервисного класса хранения, заданным в Разделе B.4.3 «Требования к заявлению о соответствии», для классов SOP хранения состояний объёмного представления заданы следующие дополнительные требования:
В заявлении о соответствии любой реализации, заявляющей соответствие классу SOP хранения состояния объёмного представления в качестве SCU, должно быть документировано следующее поведение:
Для SCU класса SOP хранения состояния объёмного представления, создающего экземпляр SOP данного класса SOP, — способ получения атрибутов, относящихся к представлению, из отображаемого изображения, вмешательства оператора или значений по умолчанию, а также способ их включения в IOD.
Для SCU класса SOP хранения состояния объёмного представления — классы SOP хранения изображений, также поддерживаемые данным SCU, на которые могут ссылаться экземпляры класса SOP хранения состояния объёмного представления.
В заявлении о соответствии любой реализации, заявляющей соответствие классу SOP хранения состояния объёмного представления в качестве SCP, должно быть документировано следующее поведение:
Для SCP класса SOP хранения состояния объёмного представления, отображающего изображение, на которое ссылается экземпляр SOP данного класса SOP, — способ, которым атрибуты, относящиеся к представлению, используются для влияния на отображение изображения.
Для SCP класса SOP хранения состояния объёмного представления — классы SOP хранения изображений, также поддерживаемые данным SCP, на которые могут ссылаться экземпляры класса SOP хранения состояния объёмного представления.
Для SCP класса SOP хранения состояния объёмного представления — поддерживается ли модуль Presentation Animation, и если не поддерживается, — какие уведомления (или их отсутствие) предоставляются пользователю о том, что контекстная информация не отображается.
Для SCP класса SOP хранения состояния объёмного представления — поддерживаются ли ссылки на экземпляры структурированных отчётов, и если не поддерживаются, — какие уведомления (или их отсутствие) предоставляются пользователю о том, что контекстная информация не отображается.
Класс службы хранения непациентных объектов определяет класс сервиса прикладного уровня, который позволяет одной DICOM AE отправлять SOP-экземпляр непациентского корневого информационного объекта другой DICOM AE.
SOP-экземпляр непациентского объекта соответствует информационной модели IOD составного экземпляра, заданной в PS3.3, у которой в корне не находится информационная сущность Patient. SOP-экземпляры непациентских объектов всё же могут содержать идентифицируемую информацию, связанную с пациентом, например SOP-экземпляры Inventory.
Класс службы хранения непациентных объектов включает несколько SOP-классов, каждый из которых использует IOD, определённый в PS3.3 (см. Раздел GG.3). Класс службы хранения непациентных объектов использует службу DIMSE C-STORE, определённую в PS3.7. Успешное завершение C-STORE имеет следующую семантику:
Поддержка класса службы хранения непациентных объектов не подразумевает поддержку каких-либо связанных классов службы запроса/получения.
Продолжительность хранения также зависит от реализации, но описывается в заявлении о соответствии SCP.
Класс службы хранения непациентных объектов предназначен для использования в различных средах: например, для передачи SOP-экземпляров с рабочих станций на другие рабочие станции или в архивы, из архивов на рабочие станции и т. д.
Правила согласования ассоциации, определённые в PS3.7, применяются к SOP-классам данного класса службы. Специфичная для SOP-класса прикладная информация (расширенное согласование) не используется.
Услуги прикладного уровня, охватываемые определением класса службы хранения непациентных объектов, задаются SOP-классами, указанными в Таблице GG.3-1.
Этот раздел определяет поведение SCU и SCP для службы хранения непациентных объектов. Механизмом передачи SOP-экземпляров между равноправными DICOM AE служит DIMSE-C служба C-STORE, как описано в PS3.7.
Помимо поведения, определённого в этом разделе, могут существовать требования к поведению, специфичные для конкретного SOP-класса, как описано в Разделе GG.6.
DICOM AE, заявляющая соответствие любому из SOP-классов хранения непациентных объектов в роли SCU, должна быть способна отправить SOP-экземпляр, удовлетворяющий требованиям соответствующего IOD. Служба вызывается SCU посредством использования запроса DIMSE C-STORE, применяемого совместно с SOP-классом.
SCU должен распознавать статус службы C-STORE и предпринимать соответствующие действия в зависимости от успешного или неуспешного завершения службы. Служба хранения непациентных объектов не предъявляет к SCU иных требований, кроме различения успешных и неуспешных ответов C-STORE. Это поведение должно быть документировано в заявлении о соответствии.
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.
Коды статуса возвращаются в сообщениях-ответах DIMSE (см. PS3.7). Значения кода, указанные в столбце «Status Codes», возвращаются в элементе команды Status (0000,0900).
Реализация может соответствовать любому из SOP-классов хранения непациентных объектов в роли SCU, SCP или обоих. Заявление о соответствии должно иметь формат, определённый в PS3.2.
Реализация, соответствующая SOP-классу службы хранения непациентных объектов в роли SCU, должна указать в своём заявлении о соответствии:
Является ли реализация создателем SOP-экземпляров для данного SOP-класса.
Могут существовать специфичные для SOP-класса требования к заявлению о соответствии для создателей SOP-экземпляров. См. Раздел GG.6.
Поведение SCU в каждом случае неуспешного статуса ответа C-STORE.
Реализация, соответствующая SOP-классу службы хранения непациентных объектов в роли SCP, должна указать в своём заявлении о соответствии:
Могут существовать специфичные для SOP-класса требования к заявлению о соответствии для приложений, интерпретирующих SOP-экземпляры для отображения или дальнейшей обработки. См. Раздел GG.6.
Этот раздел определяет специфичное для SOP-класса поведение соответствующих приложений.
Реализация, соответствующая SOP-классу хранения протокола размещения в роли SCU и являющаяся создателем SOP-экземпляров, должна указать в своём заявлении о соответствии:
Способ получения значений атрибутов IOD протокола размещения из отображаемых изображений, макетов, вмешательства оператора или значений по умолчанию.
Любые частные атрибуты, используемые в качестве значения Selector Attribute (0072,0026) в Image Set Selector Sequence, Filter Operations Sequence или Sorting Operations Sequence.
Необязательные атрибуты, которые могут быть включены в SOP-экземпляр протокола размещения.
Реализация, соответствующая SOP-классу хранения протокола размещения в роли SCP и интерпретирующая содержимое экземпляров этого SOP-класса для управления отображением изображений, должна применять все обязательные атрибуты протокола размещения и предполагаемого представления к наборам отображаемых изображений. Такая реализация должна указать в своём заявлении о соответствии:
Диапазон сред отображения, которые поддерживает приложение (например, количество экранов, размер экранов, перекрывающиеся области изображения).
Необязательные атрибуты IOD протокола размещения, которые приложение способно интерпретировать, и те, которые не поддерживаются.
Описание поведения приложения, когда значение Partial Data Display Handling (0072,0208) равно ADAPT_LAYOUT или имеет нулевую длину.
Описание поведения приложения, когда среда отображения экземпляра протокола размещения отличается от среды отображения приложения, применительно к сохранению макета в сравнении с пространственным разрешением.
SOP-классы хранения изображений, для которых поддерживается SOP-класс хранения протокола размещения для управления отображением.
Реализация, соответствующая SOP-классу хранения цветовой палитры в роли SCU и являющаяся создателем SOP-экземпляров, должна указать в своём заявлении о соответствии:
Реализация, соответствующая SOP-классу хранения цветовой палитры в роли SCP и интерпретирующая содержимое экземпляров этого SOP-класса для воздействия на отображение изображений, должна применять все обязательные атрибуты цветовой палитры и предполагаемого представления к соответствующим отображаемым изображениям.
Реализация, соответствующая SOP-классу хранения цветовой палитры в роли SCP и интерпретирующая содержимое экземпляров этого SOP-класса для воздействия на отображение изображений, должна указать в своём заявлении о соответствии:
Реализация, являющаяся SCU SOP-класса Generic Implant Template Storage, Implant Assembly Template Storage или Implant Template Group Storage, может изменять информацию в SOP-экземпляре, который она ранее отправила или получила. Когда такой SOP-экземпляр изменён и отправлен SCP, ему должен быть присвоен новый SOP Instance UID, если происходит добавление, удаление или изменение любого атрибута в составе:
Ссылочная целостность между наборами связанных SOP-экземпляров должна поддерживаться.
Реализация, соответствующая SOP-классам хранения протокола определённой процедуры CT и/или XA в роли SCP, не должна изменять ограничения, для которых значение Modifiable Constraint Flag (0082,0038) равно NO.
Изменение ограничений протокола меняет семантику SOP-экземпляра хранения протокола определённой процедуры CT или XA.
Утверждения основаны на подтверждениях (assertions). Получение или формирование подтверждения будет взаимодействовать с организационными политиками аутентификации и авторизации. Например, утверждение может быть получено по ошибке в составе передачи записи о пациенте.
Реализация, соответствующая 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.
Классы служб запроса/извлечения протоколов определённых процедур определяют классы сервисов прикладного уровня, обеспечивающие доступ к композитным объектам Defined Procedure Protocol.
Ключевые атрибуты служат двум целям: они могут использоваться как ключевые атрибуты сопоставления или как возвращаемые ключевые атрибуты. Ключевые атрибуты сопоставления используются для сопоставления (критерии, применяемые в запросе C-FIND для определения того, соответствует ли сущность запросу). Возвращаемые ключевые атрибуты используются для указания желаемых возвращаемых атрибутов (какие элементы, помимо ключевых атрибутов сопоставления, должны быть возвращены в ответе C-FIND).
Ключи сопоставления обычно используются в предложении SQL «where». Возвращаемые ключи обычно используются в предложении SQL «select» для передачи значений атрибутов.
Ключевые атрибуты сопоставления могут иметь Тип «обязательный» (R) или «необязательный» (O). Возвращаемые ключевые атрибуты могут иметь Тип 1, 1C, 2, 2C, 3, как определено в PS3.5 Data Structure and Semantics.
Для того чтобы служить SCP класса сервиса запроса/извлечения протоколов определённых процедур, DICOM AE обладает информацией об атрибутах ряда композитных экземпляров SOP Defined Procedure Protocol. Эта информация организована в информационную модель. Информационные модели для различных классов SOP, указанных в настоящем Приложении, определены в Section HH.6.
Два равноправных 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 совпадает с семантикой, определённой в разделе «Определение сервиса» сервисного класса запроса/получения, за исключением того, что имеется только один уровень получения.
Информационные модели протоколов определённых процедур определяются классом 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.
Информационные модели протоколов определённых процедур основаны на одноуровневой сущности:
Экземпляр объекта Defined Procedure Protocol содержит атрибуты, связанные с информационной сущностью (IE) объекта Procedure Protocol композитных IOD, как определено в PS3.3 Information Object Definitions.
См. определение операции C-FIND для Section K.4.1.3.1 “"Worklist" Search Method”, заменив «Worklist» на «Defined Procedure Protocol». Должен использоваться метод поиска «Worklist».
UID класса SOP определяет информационную модель протоколов определённых процедур, относительно которой выполняется C-FIND. Ключевые атрибуты и допустимые для запроса значения определены в определениях классов SOP для информационной модели протоколов определённых процедур.
См. определение операции C-MOVE для Section C.4.2 “C-MOVE Operation”. Для классов сервисов запроса/извлечения протоколов определённых процедур не определены ни расширенное поведение, ни реляционное получение.
Query/Retrieve Level (0008,0052) не имеет отношения к классам сервисов запроса/извлечения протоколов определённых процедур и поэтому не должен присутствовать в идентификаторе. Единственным уникальным ключевым атрибутом идентификатора должен быть SOP Instance UID (0008,0018). SCU должен предоставить один UID или список UID.
См. определение операции C-GET для Section C.4.2 “C-MOVE Operation”. Для классов сервисов запроса/извлечения протоколов определённых процедур не определены ни расширенное поведение, ни реляционное получение.
См. определение согласования ассоциации для Section K.5 “Association Negotiation”.
Информационная модель протоколов определённых процедур состоит из одной сущности. В ответ на заданный запрос C-FIND SCP должен отправить один ответ C-FIND на каждый подходящий экземпляр Defined Procedure Protocol.
Таблица HH.6-1 определяет атрибуты информационной модели протоколов определённых процедур.
Таблица HH.6-1. Атрибуты для информационной модели протоколов определённых процедур
|
Этот атрибут является обязательным, если используются расширенные или заменяющие наборы символов. См. Section C.2.2.2 и Section C.4.1.1. |
||||
|
Этот атрибут должен быть получен с использованием сопоставления последовательностей или универсального сопоставления. |
||||
|
>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
|
Этот атрибут должен быть получен с использованием сопоставления последовательностей или универсального сопоставления. |
||||
|
>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
|
Должен быть получен с использованием сопоставления по единственному значению, сопоставления с подстановочными знаками или универсального сопоставления. |
||||
|
Этот атрибут должен быть получен с использованием сопоставления последовательностей или универсального сопоставления. |
||||
|
>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
|
Этот атрибут должен быть получен с использованием сопоставления последовательностей или универсального сопоставления. |
||||
|
>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
|
Этот атрибут должен быть получен с использованием сопоставления последовательностей или универсального сопоставления. |
||||
|
>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
|
Должен быть получен с использованием сопоставления по списку UID. |
||||
|
Должен быть получен с использованием сопоставления по списку UID. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению, сопоставления с подстановочными знаками или универсального сопоставления. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению или сопоставления по диапазону. См. дополнительные сведения в описании атрибута Instance Creation Time. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению или сопоставления по диапазону. Если и Instance Creation Date, и Instance Creation Time указаны для сопоставления по диапазону, они должны рассматриваться как единый атрибут DateTime, например, диапазон дат с 5 по 7 июля и диапазон времени с 10:00 до 18:00 задают период времени, начинающийся 5 июля в 10:00 и заканчивающийся 7 июля в 18:00. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению, сопоставления с подстановочными знаками или универсального сопоставления. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению, сопоставления с подстановочными знаками или универсального сопоставления. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению, сопоставления с подстановочными знаками или универсального сопоставления. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению, сопоставления с подстановочными знаками или универсального сопоставления. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению, сопоставления с подстановочными знаками или универсального сопоставления. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению, сопоставления с подстановочными знаками или универсального сопоставления. |
||||
|
Этот атрибут должен быть получен с использованием сопоставления последовательностей или универсального сопоставления. |
||||
|
>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
|
Этот атрибут должен быть получен с использованием сопоставления последовательностей или универсального сопоставления. |
||||
|
>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
Реализация может соответствовать одному или нескольким SOP-классам запроса/извлечения протоколов определённых процедур в роли SCU или SCP. Заявление о соответствии должно быть представлено в формате, определённом в PS3.2.
Реализация, соответствующая классу 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) при кодировании запросов и интерпретации ответов.
Реализация, соответствующая классу SOP Defined Procedure Protocol Information Model - MOVE в роли SCU, должна поддерживать передачи в отношении информационной модели протоколов определённых процедур с использованием базового поведения SCU C-MOVE, описанного для сервисного класса запроса/получения (см. Section C.4.2.2.1 и Section HH.4.2).
Реализация, соответствующая классу SOP Defined Procedure Protocol Information Model - GET в роли SCU, должна поддерживать передачи в отношении информационной модели протоколов определённых процедур с использованием базового поведения SCU C-GET, описанного для сервисного класса запроса/получения (см. Section C.4.3.2).
Реализация, соответствующая классу 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) при интерпретации запросов, выполнении сопоставления и кодировании ответов.
Реализация, соответствующая классу 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.
Реализация, соответствующая классу SOP Defined Procedure Protocol Information Model - GET в роли SCP, должна поддерживать извлечения в отношении информационной модели протоколов определённых процедур с использованием базового поведения SCP C-GET, описанного для сервисного класса запроса/получения в Section C.4.3.3.
Классы служб запроса/извлечения утверждений протоколов определяют классы сервисов прикладного уровня, обеспечивающие доступ к композитным объектам Protocol Approval.
Ключевые атрибуты служат двум целям: они могут использоваться как ключевые атрибуты сопоставления или как возвращаемые ключевые атрибуты. Ключевые атрибуты сопоставления используются для сопоставления (критерии, применяемые в запросе C-FIND для определения того, соответствует ли сущность запросу). Возвращаемые ключевые атрибуты используются для указания желаемых возвращаемых атрибутов (какие элементы, помимо ключевых атрибутов сопоставления, должны быть возвращены в ответе C-FIND).
Ключи сопоставления обычно используются в предложении SQL «where». Возвращаемые ключи обычно используются в предложении SQL «select» для передачи значений атрибутов.
Ключевые атрибуты сопоставления могут иметь Тип «обязательный» (R) или «необязательный» (O). Возвращаемые ключевые атрибуты могут иметь Тип 1, 1C, 2, 2C, 3, как определено в PS3.5 Data Structure and Semantics.
Для того чтобы служить SCP класса сервиса запроса/извлечения утверждений протоколов, DICOM AE обладает информацией об атрибутах ряда композитных экземпляров SOP Protocol Approval. Эта информация организована в информационную модель. Информационные модели для различных классов SOP, указанных в настоящем Приложении, определены в Section II.6.
Два равноправных 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 совпадает с семантикой, определённой в разделе «Определение сервиса» сервисного класса запроса/получения, за исключением того, что имеется только один уровень получения.
Информационные модели утверждений протоколов определяются классом SOP, согласованным во время установления ассоциации. Каждый класс SOP состоит из информационной модели и группы сервисов DIMSE-C.
Информационные модели утверждений протоколов определены в Section II.6, при этом определение модели «сущность-связь» и определение ключевых атрибутов аналогичны определённым для информационной модели рабочего списка класса сервиса базового управления рабочим списком.
Информационные модели утверждений протоколов основаны на одноуровневой сущности:
Экземпляр объекта Protocol Approval содержит атрибуты, связанные с информационной сущностью (IE) Approval композитных IOD, как определено в PS3.3 Information Object Definitions.
См. определение операции C-FIND для класса сервиса базового управления рабочим списком (Section K.4.1), заменив «Worklist» на «Approval». Должен использоваться метод поиска «Worklist».
UID класса SOP определяет информационную модель утверждений протоколов, относительно которой выполняется C-FIND. Ключевые атрибуты и допустимые для запроса значения определены в определениях классов SOP для информационной модели утверждений протоколов.
См. определение операции C-MOVE для сервисного класса запроса/получения (Section C.4.2). Для классов сервисов запроса/извлечения утверждений протоколов не определены ни расширенное поведение, ни реляционное получение.
Query/Retrieve Level (0008,0052) не имеет отношения к классам сервисов запроса/извлечения утверждений протоколов и поэтому не должен присутствовать в идентификаторе. Единственным уникальным ключевым атрибутом идентификатора должен быть SOP Instance UID (0008,0018). SCU должен предоставить один UID или список UID.
См. определение операции C-GET для сервисного класса запроса/получения (Section C.4.2). Для классов сервисов запроса/извлечения утверждений протоколов не определены ни расширенное поведение, ни реляционное получение.
См. определение согласования ассоциации для класса сервиса базового управления рабочим списком (Section K.5).
Информационная модель утверждений протоколов состоит из одной сущности. В ответ на заданный запрос C-FIND SCP должен отправить один ответ C-FIND на каждый подходящий экземпляр Protocol Approval.
Таблица II.6-1 определяет атрибуты информационной модели утверждений протоколов.
Поскольку утверждения протоколов, как правило, имеют значение только в контексте утверждаемого экземпляра протокола, многие запросы будут искать утверждения, содержащие конкретный экземпляр протокола в Approval Subject Sequence (0044,0109).
Table II.6-1. Attributes for the Protocol Approval Information Model
|
Этот атрибут является обязательным, если используются расширенные или заменяющие наборы символов. См. Section C.2.2.2 и Section C.4.1.1. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению или сопоставления диапазона. |
||||
|
Должен быть получен с использованием сопоставления по единственному значению или сопоставления диапазона. Если и Instance Creation Date, и Instance Creation Time указаны для сопоставления диапазона, они рассматриваются как единый атрибут DateTime, например, диапазон дат с 5 по 7 июля и диапазон времени с 10:00 до 18:00 задаёт период времени, начинающийся 5 июля в 10:00 и заканчивающийся 7 июля в 18:00. |
||||
|
Должен быть получен с использованием сопоставления по списку UID. |
||||
|
Должен быть получен с использованием сопоставления по списку UID. |
||||
|
>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
|
>>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
|
>>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
|
>>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
|
>>>Include Table 8-1a “Расширенный макрос кодированных записей SCU/SCP с поддержкой SCU, поддержкой ключей сопоставления и обязательным значением” |
||||
|
Этот атрибут должен быть получен с использованием сопоставления по единственному значению или сопоставления диапазона. |
||||
|
Этот атрибут должен быть получен с использованием сопоставления по единственному значению или сопоставления диапазона. |
||||
Реализация может соответствовать одному или нескольким классам SOP запроса/извлечения утверждений протоколов в роли SCU или SCP. Заявление о соответствии должно быть оформлено в формате, определённом в PS3.2.
Реализация, соответствующая классу 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) при кодировании запросов и интерпретации ответов.
Реализация, соответствующая классу SOP Protocol Approval Information Model - MOVE в роли SCU, должна поддерживать передачи данных для информационной модели утверждений протоколов с использованием базового поведения SCU C-MOVE, описанного для сервисного класса запроса/получения (см. Section C.4.2.2.1 и Section II.4.2).
Реализация, соответствующая классу SOP Protocol Approval Information Model - GET в роли SCU, должна поддерживать передачи данных для информационной модели утверждений протоколов с использованием базового поведения SCU C-GET, описанного для сервисного класса запроса/получения (см. Section C.4.3.2).
Реализация, соответствующая классу 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) при интерпретации запросов, выполнении сопоставления и кодировании ответов.
любое поведение, связанное с невозвратом подходящих экземпляров (например, невозврат более старого экземпляра утверждения, который был заменён/перекрыт более новым экземпляром утверждения).
Реализация, соответствующая классу 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.
Реализация, соответствующая классу SOP Protocol Approval Information Model - GET в роли SCP, должна поддерживать извлечение данных для информационной модели утверждений протоколов с использованием базового поведения SCP C-GET, описанного для сервисного класса запроса/получения в Section C.4.3.3.
Класс службы запроса/извлечения инвентаризации определяет прикладной класс сервиса, обеспечивающий обнаружение композитных объектов Inventory и доступ к ним.
См. Класс базовой службы управления рабочим списком, раздел K.1.2 «Условные обозначения».
Каждый 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), за исключением того, что имеется только один уровень извлечения.
Информационная модель запроса/извлечения (Q/R) инвентаризации основана на определении модели «сущность-связь» и определении ключевых атрибутов, аналогичных определённым в Классе базовой службы управления рабочим списком, раздел K.2 «Определение информационной модели рабочего списка».
Информационная модель Q/R инвентаризации представляет собой одноуровневую сущность:
Хотя композитные SOP-экземпляры Inventory, являющиеся предметом данного сервисного класса, содержат атрибуты, связанные с несколькими информационными сущностями (см. раздел 7.13.6 «Inventory» в PS3.3), информационная модель Q/R инвентаризации оперирует только атрибутами информационной сущности Inventory IOD Inventory.
Таблица JJ.2-1 определяет атрибуты информационной модели Q/R инвентаризации.
Table JJ.2-1. Attributes for the Inventory Q/R Information Model
См. также дополнительные возвращаемые атрибуты в идентификаторе ответа, указанные в разделе JJ.4.2.2.1.
Более подробное определение этих атрибутов приведено в разделе C.38.1 «Inventory Module» в PS3.3
См. определение операции C-FIND для Класса базовой службы управления рабочим списком (раздел K.4.1), заменив «Worklist» на «Inventory». Должен использоваться метод поиска «Worklist».
C-FIND выполняется относительно информационной модели Q/R инвентаризации (раздел JJ.2). Ключевые атрибуты и допустимые для запроса значения определены в информационной модели Q/R инвентаризации.
См. определение операции C-MOVE для сервисного класса запроса/извлечения (раздел C.4.2). Для службы запроса/извлечения инвентаризации не определены ни расширенное поведение (Extended Behavior), ни реляционное извлечение (Relational-Retrieve).
Уровень запроса/извлечения (Query/Retrieve Level) (0008,0052) не имеет значения для службы запроса/извлечения инвентаризации и поэтому не должен присутствовать в идентификаторе. Уникальным ключевым атрибутом идентификатора является SOP Instance UID (0008,0018). SCU должен указать один UID или список UID.
См. определение операции C-GET для сервисного класса запроса/извлечения (раздел C.4.3). Для службы запроса/извлечения инвентаризации не определены ни расширенное поведение (Extended Behavior), ни реляционное извлечение (Relational-Retrieve).
Уровень запроса/извлечения (Query/Retrieve Level) (0008,0052) не имеет значения для службы запроса/извлечения инвентаризации и поэтому не должен присутствовать в идентификаторе. Уникальным ключевым атрибутом идентификатора является SOP Instance UID (0008,0018). SCU должен указать один UID или список UID.
SOP-классы службы запроса/извлечения инвентаризации идентифицируют информационную модель Q/R инвентаризации и поддерживаемые операции DIMSE-C. Определены стандартные SOP-классы, приведённые в таблице JJ.4-1.
Реализация может соответствовать одному из SOP-классов службы запроса/извлечения инвентаризации в роли SCU, SCP или обеих ролях. Заявление о соответствии должно иметь формат, определённый в PS3.2.
Реализация, соответствующая SOP-классу Inventory FIND в роли SCU, должна поддерживать запросы к информационной модели Q/R инвентаризации, используя поведение SCU C-FIND, описанное для Класса базовой службы управления рабочим списком (см. раздел K.4.1.2 и раздел JJ.3.1).
Реализация, соответствующая SOP-классу Inventory MOVE в роли SCU, должна поддерживать передачи по информационной модели Q/R инвентаризации, используя базовое поведение SCU C-MOVE, описанное для сервисного класса запроса/извлечения (см. раздел C.4.2.2.1 и раздел JJ.3.2).
Реализация, соответствующая SOP-классу Inventory GET в роли SCU, должна поддерживать передачи по информационной модели Q/R инвентаризации, используя базовое поведение SCU C-GET, описанное для сервисного класса запроса/извлечения (см. раздел C.4.3.2.1 и раздел JJ.3.3).
Реализация, соответствующая 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
|
Обязателен, если в каких-либо атрибутах ответа на запрос используются расширенные или заменяющие наборы символов. |
|||
|
Обязателен, если SOP-экземпляр Inventory доступен через SOP-классы Inventory MOVE или Inventory GET. |
|||
|
Обязателен, если SOP-экземпляр Inventory доступен через службу Non-Patient Instance (см. раздел 12 «Non-Patient Instance Service and Resources» в PS3.18). |
|||
|
Обязателен, если SOP-экземпляр Inventory находится в формате файла DICOM и доступен через протокол, отличный от DICOM (см. приложение P «Stored File Access Through Non-DICOM Protocols (Normative)» в PS3.3). |
|||
|
Обязателен, если File Access URI (0008,0409) является относительной ссылкой на путь. |
|||
|
Обязателен, если Container File Type (0008,040A) — ZIP, TAR или TARGZIP. |
|||
Более подробное определение этих атрибутов, включая определённые термины и перечислимые значения, приведено в разделе C.38.3 «Inventory Creation Module» в PS3.3. В этом разделе атрибуты применяются к сохранённым, относящимся к пациенту композитным SOP-экземплярам, таким как изображения, тогда как здесь они применяются к SOP-экземплярам Inventory.
Реализация, соответствующая классу Inventory MOVE в роли SCP, должна поддерживать передачи по информационной модели Q/R инвентаризации, используя базовое поведение SCP C-MOVE, описанное для сервисного класса запроса/извлечения (см. раздел C.4.2.3.1). Реализация должна поддерживать SOP-класс Inventory Storage (см. приложение GG) для субопераций C-STORE, порождаемых операцией C-MOVE.
Реализация, соответствующая SOP-классу Inventory GET в роли SCP, должна поддерживать передачи по информационной модели Q/R инвентаризации, используя базовое поведение SCP C-GET, описанное для сервисного класса запроса/извлечения (см. раздел C.4.3.3.1). Реализация должна поддерживать SOP-класс Inventory Storage (см. приложение GG) для субопераций C-STORE, порождаемых операцией C-GET.
Класс службы управления хранилищем определяет класс службы прикладного уровня, который обеспечивает одноранговое управление постоянным хранением составных экземпляров SOP. Класс службы допускает асинхронные операции между пользователем класса службы (SCU) и поставщиком класса службы (SCP).
DICOM поддерживает всевозможные одноранговые взаимодействия систем в области биомедицинской визуализации. Во многих организациях одна или несколько систем отвечают за долгосрочное управление хранимыми экземплярами SOP. Данный класс службы поддерживает сценарии взаимодействия, связанные с таким долгосрочным управлением хранением.
Каждый SOP-класс класса службы управления хранилищем образуется сочетанием общей группы служб DIMSE и конкретной информационной объектной дефиниции.
Службы DIMSE-N, применимые ко всем SOP-классам класса службы управления хранилищем, показаны в Таблице KK.1-1.
Службы и протокол DIMSE-N определены в Разделе 10 “DIMSE-N” в PS3.7. Дополнительные ограничения на эти службы, такие как конкретные типы действий и событий, определены для каждого SOP-класса.
SOP-классы класса службы управления хранилищем определены с использованием IOD, указанных в Таблице KK.1-2.
Дополнительные ограничения на эти IOD, такие как конкретные атрибуты, необходимые для различных типов действий, определены для каждого SOP-класса.
Установление ассоциации — это первая фаза любого случая взаимодействия между одноранговыми DICOM AE. Правила согласования ассоциации, определённые в Приложении D “Согласование ассоциации (нормативное)” в PS3.7, используются для согласования поддерживаемых SOP-классов и ролей одноранговых AE.
Реализации могут ограничивать установление ассоциации условием обмена информацией, связанной с безопасностью, такой как идентификация и авторизация приложения, либо в рамках согласования ассоциации DICOM, либо вне области действия протокола DICOM. См. Раздел YYYY.6 “Соображения безопасности” в PS3.17.
Поддержка согласования выбора ролей SCP/SCU обязательна. Расширенное согласование SOP-класса для данного класса службы не определено.
SCU открывает ассоциацию, когда желает запросить у SCP выполнение операции управления хранилищем.
SCP обычно открывает ассоциацию, когда сообщает о состоянии, либо завершил запрошенную операцию, либо достиг иного условия завершения, например сбоя. Установление такой ассоциации включает согласование роли SCP/SCU.
SCP может попытаться выдать N-EVENT-REPORT в той же ассоциации, что и инициирующий N-ACTION, но эта операция может завершиться неудачей, поскольку SCU вправе в любой момент освободить ассоциацию, по которой был отправлен запрос N-ACTION.
Поскольку DICOM по умолчанию отводит инициатору ассоциации роль SCU, SCP (то есть инициатор ассоциации) согласовывает роль SCP посредством согласования выбора ролей SCP/SCU (см. Раздел D.3.3.4 “Согласование выбора ролей SCP/SCU” в PS3.7).
При ответе по другой ассоциации SCP использует то же имя AE (AE Title), что и в исходной ассоциации, поскольку стандарт DICOM определяет службу между двумя одноранговыми приложениями, каждое из которых идентифицируется именем AE. Таким образом, SCP должен последовательно идентифицироваться во всех транзакциях с конкретным одноранговым узлом в рамках SOP-класса.
После установления ассоциации одноранговое взаимодействие между 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-приложения класса службы управления хранилищем.
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 более не активен и не должен использоваться повторно.
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.
SOP-класс определяет пять состояний формирования инвентаризации со связанными переходами между состояниями (см. Рисунок KK.2-1). Некоторые переходы связаны с получением и обработкой запросов N-ACTION (обозначены стрелками с подписями на рисунке).
После запроса Initiate формирование переходит в состояние PROCESSING. Формирование продолжается и без дальнейших операций N-ACTION достигает одного из двух конечных состояний — COMPLETE или FAILURE.
Формирование может быть приостановлено (PAUSED) либо по запросу N-ACTION, либо из-за внутренних условий SCP, например временной нехватки ресурсов. Формирование может быть возвращено в состояние PROCESSING запросом Resume либо внутренними действиями SCP.
Из состояния PROCESSING или PAUSED формирование может быть переведено в конечное состояние CANCELED запросом Cancel либо внутренними действиями SCP.
DICOM AE, заявляющие о соответствии данному SOP-классу в роли SCU и/или SCP, должны поддерживать типы действий и информацию о действии, указанные в Таблице KK.2-1. Описания атрибутов информации о действии приведены в Разделе B.30 “Inventory Creation IOD” в PS3.3.
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) может иметь нулевую длину, что означает универсальное совпадение со всеми исследованиями в хранилище (то есть исчерпывающую инвентаризацию).
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.
По получении запроса 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
|
Attribute List warning (предупреждение о списке атрибутов) — один или несколько ключевых атрибутов не поддерживаются для сопоставления |
|||
|
Ошибочно указанный аргумент — один из предоставленных параметров не согласован для использования |
|||
|
Прочие статусы 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).
Существующий экземпляр SOP инвентаризации, включённый по ссылке, может не иметь Transaction UID (0008,1195), если его создание не было инициировано транзакцией SOP-класса создания инвентаризации.
Может быть сформирован экземпляр 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).
DICOM AE, заявляющие о соответствии данному SOP-классу в роли SCU и/или SCP, должны поддерживать типы событий и информацию о событии, указанные в Таблице KK.2-2. Описания атрибутов информации о событии приведены в Разделе B.30 “Inventory Creation IOD” в PS3.3.
В информации о событии 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.
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).
По получении уведомления N-EVENT-REPORT SCU должен вернуть посредством примитива ответа N-EVENT-REPORT код статуса ответа N-EVENT-REPORT, применимый к обработке им соответствующего уведомления. Статус Success означает, что SCU успешно получил уведомление. Статус Failure означает, что SCU не обрабатывает уведомление.
Реализация может заявлять соответствие данному SOP-классу в роли SCU, SCP или обеих. Заявление о соответствии должно быть в формате, определённом в PS3.2.
Реализация, соответствующая SOP-классу создания инвентаризации в роли SCU, должна удовлетворять требованиям соответствия в отношении:
Реализация, соответствующая SOP-классу создания инвентаризации в роли SCP, должна удовлетворять требованиям соответствия в отношении:
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)
ключевые атрибуты, поддерживаемые для сопоставления в составе Scope of Inventory Sequence (0008,0400)
Требования соответствия для SCP в отношении созданных экземпляров SOP инвентаризации подробно изложены в Разделе GG.6.6.1.
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).