PS3.7

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

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

NEMA снимает с себя ответственность за любые телесные повреждения, имущественный или иной ущерб любого характера, будь то специальный, косвенный, последующий или компенсационный, прямо или косвенно вытекающий из публикации, использования, применения или полагания на данный документ. 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), все права сохранены.

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

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

Настоящая часть стандарта DICOM определяет Элемент службы сообщений DICOM (DIMSE). DIMSE определяет Элемент прикладной службы (как службу, так и протокол), используемый равноправными Прикладными сущностями DICOM для обмена медицинскими изображениями и связанной информацией.

DIMSE предоставляет свои службы, опираясь на протокол DIMSE. Протокол DIMSE определяет правила кодирования, необходимые для построения Сообщений. Сообщение состоит из Набора команд (определяемого в настоящей части стандарта DICOM), за которым следует условный Набор данных (определяемый в PS3.5).

Настоящая часть определяет:

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

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

PS3.3, Information Object Definitions, определяет набор определений информационных объектов, к которым могут быть применены службы, определённые в настоящей части
PS3.5, Data Structure and Encoding, описывает правила кодирования, необходимые для построения условного Набора данных, передаваемого в Сообщении, как указано в настоящей части
Настоящая часть определяет протоколы и службы, необходимые для реализации Сервисных классов, описанных в PS3.4

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

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

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

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

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

[ISO 8649] ISO. 1988. Information processing systems - Open Systems Interconnection - Service definition for the Association Control Service Element (ACSE).

[ISO 8822] ISO. 1988. Information processing systems - Open Systems Interconnection - Connection oriented presentation service definition.

[ISO/IEC 9595] ISO. 1991. Information processing systems - Open Systems Interconnection - Common Management Information Service Definition.

[ISO/IEC 9834-1] ISO. 2012. Information processing systems - Open Systems Interconnection - Procedures for the operation of OSI Registration Authorities: General procedures and top arcs of the ASN.1 Object Identifier tree.

[RFC1510] IETF. September 1993. The Kerberos Network Authentication Service (V5). http://tools.ietf.org/html/rfc1510 .

[RFC2289] IETF. February 1998. A One-Time Password System. http://tools.ietf.org/html/rfc2289 .

[RFC6750] IETF. October 2012. The OAuth 2.0 Authorization Framework: Bearer Token Usage. http://tools.ietf.org/html/rfc6750 .

[RFC7519] IETF. May 2015. JSON Web Token (JWT). http://tools.ietf.org/html/rfc7519 .

[RFC7662] IETF. October 2015. OAuth 2.0 Token Introspection. http://tools.ietf.org/html/rfc7662 .

[SAML] OASIS. 15 March 2005. SAML Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 OASIS Standard. https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf .

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

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

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

Настоящая часть Стандарта основана на концепциях, изложенных в [ISO 7498-1], и использует следующие термины, определённые в нём:

ApplicationEntity: См. [ISO 7498-1].
Application Process: См. [ISO 7498-1].
Protocol: См. [ISO 7498-1].
Protocol Data Unit: См. [ISO 7498-1].
Service: См. [ISO 7498-1].
Transfer Syntax: См. [ISO 7498-1].

3.2 Определения условных обозначений служб

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

Service Provider: См. [ISO/TR 8509].
Service User: См. [ISO/TR 8509].
Confirmed Service: См. [ISO/TR 8509].
Non-confirmed Service: См. [ISO/TR 8509].
Primitive: См. [ISO/TR 8509].
Request (Primitive): См. [ISO/TR 8509].
Indication (Primitive): См. [ISO/TR 8509].
Response (Primitive): См. [ISO/TR 8509].
Confirm (Primitive): См. [ISO/TR 8509].

3.3 Определения службы представления

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

Abstract Syntax: См. [ISO 8822].
Abstract Syntax Name: См. [ISO 8822].
Presentation Context: См. [ISO 8822].
Presentation Data Value: См. [ISO 8822].

3.4 Определения службы ACSE

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

Association: См. [ISO 8649].
Application Context: См. [ISO 8649].
Association Control Service Element (ACSE): См. [ISO 8649].
Association Initiator: См. [ISO 8649].

3.5 Определения службы CMIS

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

Functional Unit: См. [ISO/IEC 9595].
Kernel Functional Unit: См. [ISO/IEC 9595].

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

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

Attribute: См. Attribute в PS3.1 .
Command: См. Command в PS3.1 .
Command Stream: См. Command Stream в PS3.1 .
Data Stream: См. Data Stream в PS3.1 .
Message: См. Message в PS3.1 .
Service-Object Pair Class (SOP Class): См. Service-Object Pair Class в PS3.1 .

3.7 Определения службы верхнего уровня DICOM

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

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

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

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

Service Class: См. Service Class в PS3.4 .
Service Class User (SCU): См. Service Class User в PS3.4 .
Service Class Provider (SCP): См. Service Class Provider в PS3.4 .
Service-Object Pair Instance (SOP Instance): См. Service-Object Pair Instance в PS3.4 .
Related General SOP Class: См. Related General SOP Class в PS3.4 .

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

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

Data Element: См. Data Element в PS3.5 .
Data Set: См. Data Set в PS3.5 .
Default Character Repertoire: См. Default Character Repertoire в PS3.5 .
Element Number: См. Element Number в PS3.5 .
Group Number: См. Group Number в PS3.5 .
Implicit VR: См. Implicit VR в PS3.5 .
Little Endian: См. Little Endian в PS3.5 .
Unique Identifier (UID): См. Unique Identifier в PS3.8 .

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

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

DICOM Message Service Element (DIMSE): Конкретный Элемент прикладной службы, определённый в настоящей части стандарта DICOM.
DIMSE-C Services: Подмножество служб DIMSE, поддерживающее операции над композитными экземплярами SOP, связанными с композитными определениями информационных объектов, с равноправными Пользователями служб DIMSE.
DIMSE-N Services: Подмножество служб DIMSE, поддерживающее операции и уведомления над нормализованными экземплярами SOP, связанными с нормализованными определениями информационных объектов, с равноправными Пользователями служб DIMSE.
DIMSE Service Group (DSG): Конкретный набор из одной или более служб DIMSE, определяющий операции и/или уведомления, которые могут быть выполнены над структурой данных.
DIMSE Service Provider: Абстракция совокупности тех сущностей, которые предоставляют службы DIMSE равноправным Пользователям служб DIMSE.
DIMSE Service User: Та часть Прикладной сущности, которая использует Элемент службы сообщений DICOM.
Extended Negotiation: Обмен прикладной информацией между равноправными AE DICOM при установлении ассоциации, определяемый спецификациями конкретного Сервисного класса.
Implementation Class UID: Уникальный идентификатор конкретного класса реализации.
Invoking DIMSE Service User: Пользователь службы DIMSE, инициирующий операцию или уведомление DIMSE.
Performing DIMSE Service User: Пользователь службы DIMSE, выполняющий операцию или уведомление DIMSE, инициированное равноправным Пользователем службы DIMSE.

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

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

ACR: American College of Radiology
ACSE: Элемент управления ассоциацией
ASCII: American Standard Code for Information Interchange
AE: Прикладная сущность
ANSI: American National Standards Institute
CEN TC251: Comite Europeen de Normalisation - Technical Committee 251 - Medical Informatics
CMIS: Общая служба управления информацией
CMISE: Элемент общей службы управления информацией
DICOM: Цифровая визуализация и связь в медицине
DIMSE: Элемент службы сообщений DICOM
DIMSE-C: Элемент службы сообщений DICOM — композитный
DIMSE-N: Элемент службы сообщений DICOM — нормализованный
HL7: Health Level 7
IEEE: Institute of Electrical and Electronics Engineers
ISO: International Standards Organization
JIRA: Japan Medical Imaging and Radiological Systems Industries Association
NEMA: National Electrical Manufacturers Association
OSI: Взаимодействие открытых систем
PDU: Блок данных протокола
PDV: Значение данных представления
SOP: Пара сервис-объект
TCP/IP: Transmission Control Protocol/Internet Protocol
VM: Кратность значения
VR: Представление значения
UID: Уникальный идентификатор
UL: Верхний уровень

5 Условные обозначения

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

(=): Значение параметра равно значению параметра в столбце слева.
-: Не применимо. Параметр не должен присутствовать.
C: Параметр является условным. Условие(я) определены текстом, описывающим параметр.
M: Обязательное использование
MF: Обязательное с фиксированным значением
U: Использование данного параметра определяется пользователем службы DIMSE
UF: Необязательный с фиксированным значением

6 Контекст службы

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

6.1 Модель обмена сообщениями DICOM

Рисунок 5-1 в PS3.1 представляет общую модель связи стандарта DICOM, охватывающую как сетевую (онлайн), так и обмен через носители информации (офлайн) связь. Прикладные сущности могут использовать любой из следующих транспортных механизмов:

службу сообщений DICOM и службу верхнего уровня, обеспечивающую независимость от конкретной физической сетевой коммуникационной поддержки и протоколов, таких как TCP/IP,
API веб-службы DICOM и службу HTTP, позволяющую использовать общие гипертекстовые и связанные протоколы для передачи служб DICOM,
базовую службу файлов DICOM, обеспечивающую доступ к носителям информации независимо от конкретных физических форматов хранения носителей и файловых структур, или
связь в реальном времени DICOM, обеспечивающую передачу метаданных DICOM в реальном времени на основе SMPTE и RTP.

PS3.7 посвящена службе сообщений DICOM, и здесь базовая эталонная модель OSI используется для моделирования взаимосвязи медицинского оборудования для визуализации. Как показано на Рисунке 6.1-1, различают несколько уровней коммуникационных протоколов. DICOM использует службу верхнего уровня OSI для отделения обмена сообщениями DICOM на прикладном уровне от коммуникационной поддержки, предоставляемой нижними уровнями.

Граница службы верхнего уровня OSI позволяет равноправным Прикладным сущностям устанавливать Ассоциации, передавать Сообщения и завершать Ассоциации. Для этой границы DICOM принял стандарты OSI (служба представления, дополненная Элементом управления ассоциацией). Это простая служба, которая изолирует прикладной уровень DICOM от конкретного стека протоколов, используемого на уровнях коммуникационной поддержки.

Протокол верхнего уровня DICOM дополняет TCP/IP. Он объединяет протоколы верхнего уровня OSI в единый протокол, простой для реализации, обеспечивая при этом те же службы и функции, что и стек OSI.

Служба верхнего уровня DICOM определена в PS3.8.

DICOM Communication Model for Message Exchange

Рисунок 6.1-1. Модель обмена сообщениями DICOM

6.2 Структура прикладного уровня DICOM

Прикладная сущность DICOM и Элементы службы, которые она включает, показаны на Рисунке 6.2-1.

Примечание

Приложения настоящей части определяют некоторые аспекты Прикладной сущности DICOM.

Основа любой Прикладной сущности DICOM определяется следующими частями стандарта DICOM:

PS3.3, Information Object Definitions, предоставляет модели данных и Атрибуты, используемые в качестве основы для определения экземпляров SOP, над которыми выполняются операции службами, определёнными в настоящей части. Такие экземпляры SOP используются для представления реальных проявлений изображений, исследований, пациентов и т.д.
PS3.4, Service Class Specifications, определяет набор операций, которые могут быть выполнены над экземплярами SOP. Такие операции могут включать хранение, поиск информации, печать и т.д.
PS3.5, Data Structure and Encoding, описывает кодирование Наборов данных, которыми обмениваются для выполнения вышеуказанных служб
PS3.6, Data Dictionary, содержит реестр Элементов данных DICOM, используемых для представления Атрибутов Классов SOP

Прикладная сущность DICOM использует службы ассоциации и представления данных службы верхнего уровня OSI, определённой в PS3.8. Элемент управления ассоциацией (ACSE) дополняет службу уровня представления службами установления и завершения ассоциации. В случае TCP/IP полный эквивалент ACSE предоставляется службой верхнего уровня DICOM. Для стека point-to-point DICOM минимальное подмножество ACSE предоставляется Сетевой/Транспортной/Сетевой службой.

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

DIMSE-C поддерживает операции, связанные с композитными Классами SOP, и обеспечивает эффективную совместимость с предыдущими версиями стандарта DICOM.
DIMSE-N поддерживает операции, связанные с нормализованными Классами SOP, и предоставляет расширенный набор объектно-ориентированных операций и уведомлений. Он основан на Модели системного управления OSI и, более конкретно, на определении Общей службы управления информацией OSI (CMIS).

Рисунок 6.2-1. Структура прикладного уровня DICOM

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

6.3 Структура сообщений DICOM и набор команд

Информация передаётся через сетевой интерфейс DICOM в DICOM-Сообщении. Сообщение состоит из Набора команд, за которым следует условный Набор данных (определение Набора данных см. в PS3.5). Набор команд используется для указания операций/уведомлений, которые должны быть выполнены над Набором данных или с его использованием.

Набор команд состоит из Командных элементов. Командные элементы содержат закодированные значения каждого отдельного поля Набора команд в соответствии с семантикой, указанной в протоколе DIMSE (см. Раздел 9.2 и Раздел 10.2). Каждый Командный элемент состоит из явного Тега, Длины значения и Поля значения.

Общая структура DICOM-Сообщения показана на Рисунке 6.3-1.

Рисунок 6.3-1. Структура сообщений DICOM

6.3.1 Структура набора команд

Командные элементы в Наборе команд должны быть упорядочены по возрастанию номера Тега командного элемента. Тег командного элемента однозначно идентифицирует Командный элемент и должен встречаться в Наборе команд не более одного раза. Кодирование Набора команд должно осуществляться с прямым порядком байтов (Little Endian), как определено в PS3.5. Требования к наличию Командного элемента в Наборе команд определены в протоколе DIMSE.

Примечание

Использование частных Командных элементов было выведено из употребления в данной версии стандарта DICOM.
Кодирование соответствует кодированию Элемента данных с неявным VR, определённому в PS3.5.

Командный элемент состоит из трёх полей: Тега командного элемента, Длины значения и Поля значения.

Тег командного элемента: Упорядоченная пара 16-битных целых чисел без знака, представляющая Номер группы, за которым следует Номер элемента.

Примечание

Все Теги командных элементов имеют Номер группы 0000. См. Приложение E для Реестра Командных элементов, содержащего полный список всех Командных элементов, которые могут быть использованы в Наборе команд.
В частности, Набору команд не разрешается содержать какие-либо Элементы данных, такие как перечисленные в PS3.6.

Длина значения: 32-битное целое число без знака, представляющее явную Длину как количество байтов (чётное), составляющих Значение. Она не включает длину полей Тега командного элемента или Длины значения.

Поле значения: Чётное количество байтов, содержащее Значение(я) Командного элемента.

Тип команды Значения(ий), хранящихся в этом поле, определяется Представлением значения (VR) Командного элемента. VR для данного Командного элемента можно определить с помощью Словаря команд в Приложении E. VR Командных элементов должен соответствовать указанным в Словаре команд. Определения VR можно найти в PS3.5

Кратность значения (VM) указывает, сколько Значений с данным VR может быть помещено в Поле значения. Если VM больше единицы, несколько Значений должны быть разделены в Поле значения, как определено в PS3.5. VM для данного Командного элемента можно определить с помощью Словаря команд в Приложении E.

Примечание

Командный элемент Command Length to End (0000,0001) выведен из употребления. Реализации могут отправлять его по причинам обратной совместимости. Реализации, соответствующие DICOM V3.0, не должны полагаться на его наличие для своей работы.
Определение длины Сообщения фактически достигается за счёт того факта, что Значение данных представления (передающее каждый фрагмент Сообщения) разделяется, как определено службой верхнего уровня OSI и связанным Заголовком управления сообщением (см. PS3.8). Это является следствием того, что протокол UL DICOM V3.0 или протокол представления OSI в явном виде передаёт длину PDV.

7 Обзор служб

Элемент служб сообщений DICOM поддерживает взаимодействие между равноправными пользователями службы DIMSE. Пользователь службы DIMSE действует в одной из двух ролей:

Инициирующий пользователь службы DIMSE
Выполняющий пользователь службы DIMSE

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

Примитив запроса
примитив индикации
примитив ответа
примитив подтверждения

Эти примитивы (которые показаны на Рисунке 7-1) используются следующим образом для успешного завершения службы DIMSE:

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

7.1 Типы служб

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

служба уведомлений
служба операций

Рисунок 7-1. Примитивы службы DIMSE

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

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

7.2 Взаимодействие пользователя службы DIMSE

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

Уведомление или операция реализуется как взаимодействие «запрос-ответ», выполняемое в контексте установленной прикладной ассоциации. Обычно один пользователь службы DIMSE запрашивает выполнение определённой операции (или обработку уведомления), а другой пользователь службы DIMSE пытается выполнить операцию (или обработать уведомление), а затем сообщает о результате попытки.

При участии в операциях или уведомлениях пользователь службы DIMSE принимает на себя одну из двух ролей:

он выполняет операции (над экземплярами SOP, за которые он несёт ответственность), которые были инициированы равноправным пользователем службы DIMSE. Он также может генерировать уведомления об изменении состояния для экземпляров SOP одному или нескольким равноправным пользователям службы DIMSE. Эти уведомления могут вызываться в результате операций, инициированных другими пользователями службы DIMSE.
он инициирует выполнение операции на равноправном пользователе службы DIMSE. Он также может принимать уведомления от равноправного пользователя службы DIMSE.

Эти роли показаны на Рисунке 7.2-1.

Примечание

Роль a) (называемая ролью Агента в терминологии ISO) используется реализацией, соответствующей Классу службы DICOM в качестве SCP.
Роль b) (называемая ролью Менеджера в терминологии ISO) используется реализацией, соответствующей Классу службы DICOM в качестве SCU.

Рисунок 7.2-1. Поток операций и уведомлений

7.3 Режимы службы

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

синхронный
асинхронный

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

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

Выбор режима (синхронный или асинхронный) определяется во время установления ассоциации. Синхронный режим служит режимом по умолчанию и должен поддерживаться всеми пользователями службы DIMSE. Асинхронный режим является необязательным, и максимальное количество незавершённых операций/уведомлений согласуется во время установления ассоциации. Это согласование выполняется с помощью информации прикладной ассоциации, как определено в Приложении D.

7.4 Службы ассоциации

Элемент служб сообщений DICOM не предоставляет отдельных служб для установления и завершения прикладных ассоциаций. В этом разделе представлен обзор того, как прикладная сущность, использующая службу DIMSE, использует службы ассоциации, определённые в PS3.8.

Во время фазы установления ассоциации пользователь службы DIMSE должен обмениваться инициализационной информацией, используя параметры службы верхнего уровня A-ASSOCIATE (см. Рисунок 7.4-1), которые включают:

Прикладной контекст
Требования к представительскому уровню и сеансу
Специфичная для DIMSE пользовательская информация
Информация прикладной ассоциации

Службы A-RELEASE и A-ABORT, определённые в PS3.8, должны использоваться для завершения ассоциации.

Примечание

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

7.4.1 Установление ассоциации

Служба A-ASSOCIATE вызывается пользователем службы DIMSE для установления ассоциации с равноправным пользователем службы DIMSE. Установление ассоциации всегда является первой фазой обмена сообщениями DICOM.

Инициирующий и отвечающий пользователи службы DIMSE должны включать информацию прикладной ассоциации в примитив запроса и примитив ответа соответственно. Значение этого параметра зависит от прикладного контекста. Дополнительные сведения об использовании информации прикладной ассоциации см. в Приложении D.

7.4.2 Завершение ассоциации

Служба A-RELEASE вызывается пользователем службы DIMSE для запроса упорядоченного завершения ассоциации между равноправными пользователями службы DIMSE. Настоящая часть Стандарта не определяет какого-либо использования параметров службы A-RELEASE.

DICOM Application Entity and Association

Рисунок 7.4-1. Прикладная сущность DICOM и ассоциация

Служба A-ABORT вызывается пользователем службы DIMSE для запроса немедленного (аварийного) завершения ассоциации между равноправными пользователями службы DIMSE. Инициирующий пользователь службы DIMSE службы A-ABORT должен включить (в поле пользовательской информации A-ABORT) параметр источника прерывания. Параметр источника прерывания указывает инициирующий источник прерывания. Он принимает одно из следующих символических значений:

Поставщик службы DIMSE
Пользователь службы DIMSE

Ссылка на PS3.8 для получения дополнительной информации о службах A-RELEASE и A-ABORT.

7.5 Службы DIMSE

Поскольку способы применения операций к композитным экземплярам SOP отличаются от способов применения операций и уведомлений к нормализованным экземплярам SOP, определены две группы служб DIMSE:

DIMSE-N: службы, применимые к нормализованным экземплярам SOP
DIMSE-C: службы, применимые к композитным экземплярам SOP

Таблица 7.5-1. Службы DIMSE

Имя	Группа	Тип
C-STORE	DIMSE-C	операция
C-GET	DIMSE-C	операция
C-MOVE	DIMSE-C	операция
C-FIND	DIMSE-C	операция
C-ECHO	DIMSE-C	операция
N-EVENT-REPORT	DIMSE-N	уведомление
N-GET	DIMSE-N	операция
N-SET	DIMSE-N	операция
N-ACTION	DIMSE-N	операция
N-CREATE	DIMSE-N	операция
N-DELETE	DIMSE-N	операция

Примечание

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

7.5.1 Службы DIMSE-C

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

7.5.1.1 Службы операций

DIMSE-C предоставляет следующие службы операций, которые все являются подтверждаемыми службами, и поэтому ожидается ответ:

Служба C-STORE вызывается пользователем службы DIMSE для запроса хранения информации о композитном экземпляре SOP равноправным пользователем службы DIMSE.
Служба C-FIND вызывается пользователем службы DIMSE для сопоставления последовательности строк атрибутов с атрибутами набора экземпляров SOP, управляемых равноправным пользователем службы DIMSE. Служба C-FIND возвращает для каждого совпадения список запрошенных атрибутов и их значений.
Служба C-GET вызывается пользователем службы DIMSE для получения информации об одном или нескольких композитных экземплярах SOP от равноправного пользователя службы DIMSE на основе атрибутов, предоставленных Инициирующим пользователем службы DIMSE.
Служба C-MOVE вызывается пользователем службы DIMSE для перемещения информации об одном или нескольких композитных экземплярах SOP от равноправного пользователя службы DIMSE к третьему пользователю службы DIMSE на основе атрибутов, предоставленных Инициирующим пользователем службы DIMSE.
Служба C-ECHO вызывается пользователем службы DIMSE для проверки сквозной связи с равноправным пользователем службы DIMSE.

Примечание

Основные различия между операциями C-GET и C-MOVE заключаются в следующем:
1. подоперации C-STORE, возникающие в результате C-GET, выполняются в той же ассоциации, что и C-GET. При C-MOVE возникающие подоперации C-STORE выполняются в отдельной ассоциации.
2. операция C-MOVE поддерживает выполнение подопераций C-STORE с прикладной сущностью, отличной от той, которая инициировала C-MOVE (перемещение третьей стороной).
В случае, когда прикладная сущность желает запросить получение одного или нескольких изображений для хранения, она может использовать либо операцию C-GET, либо C-MOVE самой себе. Ожидается, что в большинстве сред C-MOVE является более простым решением, несмотря на то, что требуются две ассоциации. Использование службы C-GET может быть нешироко реализовано. Она может применяться в особых случаях, когда система не поддерживает множественные ассоциации. Она была оставлена в этой версии Стандарта для обратной совместимости с предыдущими версиями Стандарта.

7.5.2 Службы DIMSE-N

Службы DIMSE-N предоставляют как службы уведомлений, так и службы операций, применимые к нормализованным экземплярам SOP.

7.5.2.1 Служба уведомлений

DIMSE-N предоставляет единственную службу уведомлений — N-EVENT-REPORT. Служба N-EVENT-REPORT вызывается пользователем службы DIMSE для сообщения о событии, касающемся экземпляра SOP, равноправному пользователю службы DIMSE. Эта служба является подтверждаемой службой, и ожидается ответ.

7.5.2.2 Службы операций

DIMSE-N предоставляет следующие службы операций, которые все являются подтверждаемыми службами, и поэтому ожидается ответ:

Служба N-GET вызывается пользователем службы DIMSE для запроса получения информации от равноправного пользователя службы DIMSE.
Служба N-SET вызывается пользователем службы DIMSE для запроса изменения информации равноправным пользователем службы DIMSE.
Служба N-ACTION вызывается пользователем службы DIMSE для запроса равноправному пользователю службы DIMSE выполнить действие.
Служба N-CREATE вызывается пользователем службы DIMSE для запроса равноправному пользователю службы DIMSE создать экземпляр класса SOP.
Служба N-DELETE вызывается пользователем службы DIMSE для запроса равноправному пользователю службы DIMSE удалить экземпляр класса SOP.

7.5.3 Процедуры DIMSE

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

Каждая служба DIMSE выполняется посредством использования одного или нескольких примитивов службы. То, как равноправные пользователи службы DIMSE используют примитивы службы и реагируют на них, определяется процедурами службы.

7.5.3.1 Подоперации

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

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

7.5.3.2 Множественные ответы

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

7.5.3.3 Отмена

Некоторые службы DIMSE допускают отмену службы с помощью примитивов службы. Это позволяет Инициирующему пользователю службы DIMSE запросить прекращение службы DIMSE после завершения примитива запроса, но до завершения примитива подтверждения.

Таблица 7.5-2 перечисляет каждую службу DIMSE и связанную с ней информацию о процедурах. Полные спецификации процедур службы определены в Разделах 9 и 10 для DIMSE-C и DIMSE-N соответственно.

Таблица 7.5-2. Службы и процедуры DIMSE

Имя	Подоперации	Множественные ответы	Отмена
C-STORE	-	-	-
C-GET	M	C	M
C-MOVE	M	C	M
C-FIND	-	C	M
C-ECHO	-	-	-
N-EVENT-REPORT	-	-	-
N-GET	-	-	-
N-SET	-	-	-
N-ACTION	-	-	-
N-CREATE	-	-	-
N-DELETE	-	-	-

8 Обзор протокола

8.1 Протокол DIMSE

Этот раздел предоставляет обзор конечного автомата протокола DIMSE. Конечный автомат протокола DIMSE определяет процедуры и правила кодирования, необходимые для построения сообщений, используемых для обмена командными запросами и ответами между равноправными пользователями службы DIMSE (например, двумя сущностями приложений DICOM). Связь между сообщениями и различными типами примитивов служб показана на Рисунке 7-1.

Конечный автомат протокола DIMSE принимает примитивы запросов и ответов службы DIMSE от пользователя службы DIMSE и строит сообщения, определенные процедурами, описанными в 9.3 и 10.3. Конечный автомат протокола DIMSE принимает сообщения и передает их пользователю службы DIMSE посредством примитивов индикации и подтверждения.

Процедуры определяют правила передачи сообщений, несущих командные запросы и ответы. Эти правила определяют интерпретацию различных полей в командной части сообщения. Они не определяют, что Инициирующий пользователь службы DIMSE должен делать с запрошенной информацией (частью набора данных сообщения), а также как Выполняющий пользователь службы DIMSE должен обрабатывать операцию.

Сообщения могут быть фрагментированы. Фрагментация сообщений, обмен которыми осуществляется между равноправными сущностями приложений DICOM, и служба P-DATA, используемая для обмена этими фрагментами сообщений, определены в Приложении F.

Примечание

Эти фрагменты сообщений называются блоками данных прикладного протокола (APDU) в терминологии OSI.

Примитив запроса Инициирующего пользователя службы DIMSE приводит к созданию сообщения, несущего командный запрос (с дополнительным связанным набором данных). Каждое сообщение вызывает примитив индикации у Выполняющего пользователя службы DIMSE.

Примитивы ответа Выполняющего пользователя службы DIMSE приводят к созданию сообщения, несущего командный ответ (с дополнительным связанным набором данных). Каждое сообщение вызывает примитив подтверждения у Инициирующего пользователя службы DIMSE.

8.2 Протокол ассоциации

Установление ассоциации включает двух пользователей службы DIMSE: один является инициатором запроса ассоциации, а другой — акцептором ассоциации. Пользователь службы DIMSE может инициировать установление ассоциации, используя службу A-ASSOCIATE, описанную в PS3.8.

Среди параметров службы A-ASSOCIATE присутствует контекст приложения, который помимо прочего определяет правила, необходимые для согласования информации инициализации, соответствующей различным сущностям приложений DICOM. Контексты приложения, разрешенные для DIMSE, указаны в Приложении A.

8.3 Соответствие

Разработчики соответствуют протоколу DIMSE только путем соответствия классу SOP, как определено в PS3.2 и PS3.4. Разработчики не соответствуют протоколу DIMSE напрямую и не обязаны включать заявление о соответствии DIMSE в декларации соответствия, за исключением случаев, предусмотренных PS3.4.

9 DIMSE-C

9.1 Службы

9.1.1 Служба C-STORE

Служба C-STORE используется пользователем службы DIMSE для сохранения составного экземпляра SOP на равноправном пользователе службы DIMSE. Это подтверждаемая служба.

9.1.1.1 Параметры C-STORE

Таблица 9.1-1 перечисляет параметры этой службы.

Таблица 9.1-1. Параметры C-STORE

Имя параметра DIMSE-C	Req/Ind	Rsp/Conf
Message ID	M	U
Message ID Being Responded To	-	M
Affected SOP Class UID	M	U(=)
Affected SOP Instance UID	M	U(=)
Priority	M	-
Move Originator Application Entity Title	U	-
Move Originator Message ID	U	-
Data Set	M	-
Status	-	M

9.1.1.1.1 Message ID

Этот параметр идентифицирует операцию. Он используется для отличия данной операции от других уведомлений или операций, которые могут выполняться поставщиком службы DIMSE. Никакие два одинаковых значения Message ID (0000,0110) не должны использоваться для незавершенных операций или уведомлений.

Примечание

Включение этого параметра в подтверждение допускалось в предыдущих версиях настоящего стандарта, но этот режим использования теперь удален. Этот параметр может быть включен в подтверждение, но в таком случае Инициирующий пользователь службы DIMSE не должен придавать этому параметру какого-либо семантического значения.
Рекомендуется, чтобы Message ID (0000,0110) был уникальным в пределах ассоциации для поддержки процедур отладки.

9.1.1.1.2 Message ID Being Responded To

Этот параметр указывает Message ID (0000,0110) запроса/индикации операции, к которому применяется данный ответ/подтверждение.

9.1.1.1.3 Affected SOP Class UID

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

9.1.1.1.4 Affected SOP Instance UID

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

9.1.1.1.5 Priority

Этот параметр указывает приоритет операции C-STORE. Он должен быть одним из LOW, MEDIUM или HIGH.

9.1.1.1.6 Move Originator Application Entity Title

Этот параметр указывает заголовок AE сущности приложения DICOM, которая инициировала операцию C-MOVE, в рамках которой выполняется данная подоперация C-STORE.

9.1.1.1.7 Move Originator Message ID

Этот параметр указывает Message ID (0000,0110) примитива запроса/индикации C-MOVE, в рамках которого выполняется данная подоперация C-STORE.

9.1.1.1.8 Data Set

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

9.1.1.1.9 Status

Этот параметр содержит уведомление об ошибке или успешном выполнении операции. Он должен быть включен Выполняющим пользователем службы DIMSE в ответ/подтверждение. В ответе/подтверждении могут встречаться следующие типы статусов (см. также Приложение C):

Отклонено: нехватка ресурсов (значение статуса зависит от класса службы) — указывает, что Выполняющий пользователь службы DIMSE не смог сохранить составной экземпляр SOP из-за нехватки ресурсов.
Отклонено: класс SOP не поддерживается (0122H) — указывает, что Выполняющий пользователь службы DIMSE не смог сохранить составной экземпляр SOP, так как класс SOP не поддерживается.
Ошибка: невозможно понять (значение статуса зависит от класса службы) — указывает, что Выполняющий пользователь службы DIMSE не смог сохранить составной экземпляр SOP, так как он не может понять определенные элементы данных.
Ошибка: набор данных не соответствует классу SOP (значение статуса зависит от класса службы) — указывает, что Выполняющий пользователь службы DIMSE не смог сохранить составной экземпляр SOP, так как набор данных не соответствует классу SOP.
Предупреждение (значение статуса зависит от класса службы) — указывает, что Выполняющий пользователь службы DIMSE смог сохранить составной экземпляр SOP, но обнаружил вероятную ошибку.
Успех (0000H) — указывает, что составной экземпляр SOP был успешно сохранен.
Дублирующий вызов (0210H) — указывает, что указанный Message ID (0000,0110) назначен другому уведомлению или операции.
Недопустимый экземпляр SOP (0117H) — указывает, что указанный UID экземпляра SOP подразумевает нарушение правил формирования UID.
Неверный тип аргумента (0212H) — указывает, что один из предоставленных параметров не был согласован для использования в ассоциации между пользователями службы DIMSE.
Нераспознанная операция (0211H) — указывает, что операция не является одной из согласованных между пользователями службы DIMSE.
Отклонено: не авторизован (0124H) — указывает, что равноправный пользователь службы DIMSE не был авторизован для сохранения составного экземпляра SOP.

9.1.1.2 Процедуры службы C-STORE

Применяются следующие процедуры C-STORE:

Инициирующий пользователь службы DIMSE запрашивает у Выполняющего пользователя службы DIMSE сохранение составного экземпляра SOP путем выдачи примитива C-STORE Request поставщику службы DIMSE.
Поставщик службы DIMSE выдает примитив C-STORE indication Выполняющему пользователю службы DIMSE.
Выполняющий пользователь службы DIMSE сообщает о принятии или отклонении примитива C-STORE Request путем выдачи примитива C-STORE response поставщику службы DIMSE,
Поставщик службы DIMSE выдает примитив C-STORE confirmation Инициирующему пользователю службы DIMSE, завершая операцию C-STORE.

Выполняющий пользователь службы DIMSE может вернуть примитив C-STORE response со статусом Failed или Refused до того, как Инициирующий пользователь службы DIMSE полностью передаст всю индикацию C-STORE (набор данных). Примитив C-STORE response со статусом Success или Warning не должен возвращаться до тех пор, пока Выполняющий пользователь службы DIMSE не получит всю индикацию C-STORE.

Примечание

Такое возникновение ответа «Failed» часто называется преждевременным ответом об отказе.

9.1.2 Служба C-FIND

Служба C-FIND используется пользователем службы DIMSE для сопоставления набора атрибутов с атрибутами набора составных экземпляров SOP, поддерживаемых равноправным пользователем службы DIMSE. Это подтверждаемая служба.

9.1.2.1 Параметры C-FIND

См. Таблица 9.1-2.

Таблица 9.1-2. Параметры C-FIND

Имя параметра DIMSE-C	Req/Ind	Rsp/Conf	CnclReq/CnclInd
Message ID	M	U	-
Message ID Being Responded To	-	M	M
Affected SOP Class UID	M	U(=)	-
Priority	M	-	-
Identifier	M	C	-
Status	-	M	-

9.1.2.1.1 Message ID

Примечание

Включение этого параметра в подтверждение допускалось в предыдущих версиях настоящего стандарта, но этот режим использования теперь удален. Этот параметр может быть включен в подтверждение, но в таком случае Инициирующий пользователь службы DIMSE не должен придавать этому параметру какого-либо семантического значения.
Рекомендуется, чтобы Message ID (0000,0110) был уникальным в пределах ассоциации для поддержки процедур отладки.

9.1.2.1.2 Message ID Being Responded To

Этот параметр указывает Message ID (0000,0110) запроса/индикации, к которому применяется данный ответ/подтверждение.

9.1.2.1.3 Affected SOP Class UID

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

9.1.2.1.4 Priority

Этот параметр указывает приоритет операции C-FIND. Он должен быть одним из LOW, MEDIUM или HIGH.

9.1.2.1.5 Identifier

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

В ответе/подтверждении это тот же список атрибутов со значениями этих атрибутов в конкретном составном экземпляре SOP, для которого обнаружено совпадение. Он должен отправляться только в том случае, если Status (0000,0900) равен Pending (не допускается для других статусов).

Список атрибутов и правила формирования указаны в PS3.4.

9.1.2.1.6 Status

Указывает статус ответа. Он может принимать любое из следующих значений (см. также Приложение C):

Успех (0000H) — указывает, что обработка совпадений завершена. Он не должен содержать совпадающего Identifier.
Pending (значение статуса зависит от класса службы) — указывает, что обработка совпадений инициирована или продолжается. Он должен содержать совпадающий Identifier.
Отклонено: нехватка ресурсов (значение статуса зависит от класса службы) — указывает, что обработка операции C-FIND была прекращена из-за нехватки ресурсов. Это может быть начальным ответом на C-FIND или может быть отправлено после ряда ответов C-FIND со статусом Pending. Этот ответ не должен содержать совпадающего Identifier.
Отклонено: класс SOP не поддерживается (0122H) — указывает, что обработка операции C-FIND была прекращена, так как класс SOP не поддерживается. Этот ответ не должен содержать совпадающего Identifier.
Отмена (FE00H) — указывает, что обработка операции C-FIND была прекращена вследствие примитива C-FIND Cancel Indication. Ответ не должен содержать Identifier.
Failed (значение статуса зависит от класса службы) — указывает, что операция C-FIND завершилась неудачей у Выполняющего пользователя службы DIMSE.
Предупреждение (значение статуса зависит от класса службы) — указывает, что Выполняющий пользователь службы DIMSE завершил операцию C-FIND, и набор возвращенных совпадающих Identifier может быть неполным.
Отклонено: не авторизован (0124H) — указывает, что равноправный пользователь службы DIMSE не был авторизован для инициирования операции C-FIND.
Дублирующий вызов (0210H) — указывает, что указанный Message ID (0000,0110) назначен другому уведомлению или операции.
Нераспознанная операция (0211H) — указывает, что операция не является одной из согласованных между пользователями службы DIMSE.
Неверный тип аргумента (0212H) — указывает, что один из предоставленных параметров не был согласован для использования в ассоциации между пользователями службы DIMSE.

9.1.2.2 Процедуры службы C-FIND

Следующие процедуры службы C-FIND применяются к инициирующему пользователю службы DIMSE:

Инициирующий пользователь службы DIMSE запрашивает Выполняющего пользователя службы DIMSE сопоставить Identifier с атрибутами всех экземпляров SOP, известных Выполняющему пользователю службы DIMSE, путем выдачи примитива C-FIND Request поставщику службы DIMSE. Если запрос отклоняется поставщиком службы DIMSE, следующие процедуры не применяются.
В любой момент до получения примитива C-FIND confirmation со статусом, отличным от Pending, Инициирующий пользователь службы DIMSE может запросить Выполняющего пользователя службы DIMSE отменить службу путем выдачи примитива C-FIND Cancel Request поставщику службы DIMSE.
Инициирующий пользователь службы DIMSE получает примитив C-FIND confirmation для каждого уникального совпадения Identifier с набором атрибутов составного экземпляра SOP.
Инициирующий пользователь службы DIMSE получает окончательный примитив C-FIND confirmation.

Примечание

В вышеописанных процедурах (c) может предшествовать (b).

Следующие процедуры службы C-FIND применяются к Выполняющему пользователю службы DIMSE:

Когда Выполняющий пользователь службы DIMSE получает индикацию C-FIND от поставщика службы DIMSE, он сопоставляет Identifier с атрибутами известных составных экземпляров SOP.
В любой момент после индикации C-FIND Выполняющий пользователь службы DIMSE может получить индикацию C-FIND Cancel.
Если индикация C-FIND Cancel получена до завершения обработки индикации C-FIND, операция C-FIND прерывается; в противном случае следующая процедура не применяется.
Выполняющий пользователь службы DIMSE выдает ответ C-FIND со статусом Cancel поставщику службы DIMSE для указания того, что операция C-FIND была отменена. Следующие процедуры не применяются.
Для каждого совпадения Выполняющий пользователь службы DIMSE выдает ответ C-FIND со статусом Pending и совпадающим Identifier.
При завершении операции C-FIND (как успешной, так и неудачной) Выполняющий пользователь службы DIMSE выдает ответ C-FIND со статусом Refused, Failed, Warning или Success поставщику службы DIMSE.

Следующие процедуры службы C-FIND применяются к поставщику службы DIMSE:

Когда поставщик службы DIMSE получает примитив C-FIND Request от Инициирующего пользователя службы DIMSE, он выдает примитив C-FIND indication Выполняющему пользователю службы DIMSE.
Когда поставщик службы DIMSE получает примитив C-FIND Cancel Request от Инициирующего пользователя службы DIMSE, он выдает индикацию C-FIND Cancel Выполняющему пользователю службы DIMSE.
Когда поставщик службы DIMSE получает примитив C-FIND response от Выполняющего пользователя службы DIMSE, он выдает примитив C-FIND confirmation Инициирующему пользователю службы DIMSE.

Выполняющий пользователь службы DIMSE может вернуть примитив C-FIND response со статусом Failed или Refused до того, как Инициирующий пользователь службы DIMSE полностью передаст всю индикацию C-FIND (набор данных). Примитив C-FIND response со статусом Success или Warning не должен возвращаться до тех пор, пока Выполняющий пользователь службы DIMSE не получит всю индикацию C-FIND.

Примечание

Такое возникновение ответа «Failed» часто называется преждевременным ответом об отказе.

9.1.3 Служба C-GET

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

9.1.3.1 Параметры C-GET

См. Таблица 9.1-3.

Таблица 9.1-3. Параметры C-GET

Имя параметра DIMSE-C	Req/Ind	Rsp/Conf	CnclReq/CnclInd
Message ID	M	U	-
Message ID Being Responded To	-	M	M
Affected SOP Class UID	M	U(=)	-
Priority	M	-	-
Identifier	M	U	-
Status	-	M	-
Number of Remaining Sub-operations	-	C	-
Number of Completed Sub-operations	-	C	-
Number of Failed Sub-operations	-	C	-
Number of Warning Sub-operations	-	C	-

9.1.3.1.1 Message ID

Примечание

Включение этого параметра в подтверждение допускалось в предыдущих версиях настоящего стандарта, но этот режим использования теперь удален. Этот параметр может быть включен в подтверждение, но в таком случае Инициирующий пользователь службы DIMSE не должен придавать этому параметру какого-либо семантического значения.
Рекомендуется, чтобы Message ID (0000,0110) был уникальным в пределах ассоциации для поддержки процедур отладки.

9.1.3.1.2 Message ID Being Responded To

Этот параметр указывает Message ID (0000,0110) запроса/индикации, к которому применяется данный ответ/подтверждение.

9.1.3.1.3 Affected SOP Class UID

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

9.1.3.1.4 Priority

Этот параметр указывает приоритет операции C-GET. Он должен быть одним из LOW, MEDIUM или HIGH. Этот приоритет также должен использоваться для всех подопераций.

9.1.3.1.5 Identifier

В запросе/индикации это список атрибутов для сопоставления со значениями атрибутов известных составных экземпляров SOP Выполняющего пользователя службы DIMSE. Список допустимых атрибутов и правила формирования указаны в PS3.4.

Примечание

Для Identifier в ответе/подтверждении указано значение U, однако службы, определенные в PS3.4, использующие этот примитив, могут налагать обязательные или условные требования к его присутствию.

В ответе/подтверждении это список атрибутов, предоставляющих информацию о статусе операции C-GET. Список допустимых атрибутов и правила, определяющие использование Identifier, указаны в PS3.4.

9.1.3.1.6 Status

Указывает статус ответа. Он может принимать любое из следующих значений (см. также Приложение C):

Успех (0000H) — указывает, что обработка совпадений и всех подопераций завершена.
Pending (значение статуса зависит от класса службы) — указывает, что обработка совпадений и подопераций инициирована или продолжается.
Отклонено: нехватка ресурсов (значение статуса зависит от класса службы) — указывает, что обработка операции C-GET была прекращена из-за нехватки ресурсов. Это может быть начальным ответом на запрос C-GET или может быть отправлено после ряда статусов Pending.
Отклонено: класс SOP не поддерживается (0122H) — указывает, что обработка операции C-GET была прекращена, так как класс SOP не поддерживается.
Отмена (FE00H) — указывает, что обработка операции C-GET была прекращена вследствие примитива C-GET Cancel indication.
Failed (значение статуса зависит от класса службы) — указывает, что операция C-GET завершилась неудачей у Выполняющего пользователя службы DIMSE.
Дублирующий вызов (0210H) — указывает, что указанный Message ID (0000,0110) назначен другому уведомлению или операции.
Неверный тип аргумента (0212H) — указывает, что один из предоставленных параметров не был согласован для использования в ассоциации между пользователями службы DIMSE.
Нераспознанная операция (0211H) — указывает, что операция не является одной из согласованных между пользователями службы DIMSE.
Отклонено: не авторизован (0124H) — указывает, что равноправный пользователь службы DIMSE не был авторизован для инициирования операции C-GET.
Предупреждение (значение статуса зависит от класса службы) — указывает, что Выполняющий пользователь службы DIMSE смог выполнить подоперации, но обнаружил вероятную ошибку в одной или нескольких из них.

9.1.3.1.7 Number of Remaining Sub-Operations

Указывает количество оставшихся подопераций C-STORE, которые будут вызваны данной операцией C-GET. Он может быть включен в любой ответ/подтверждение и должен быть включен, если статус равен Pending.

9.1.3.1.8 Number of Completed Sub-Operations

Указывает количество подопераций C-STORE, вызванных данной операцией C-GET, которые успешно завершились. Он может быть включен в любой ответ/подтверждение и должен быть включен, если статус равен Pending.

9.1.3.1.9 Number of Failed Sub-Operations

Указывает количество подопераций C-STORE, вызванных данной операцией C-GET, которые завершились неудачей. Он может быть включен в любой ответ/подтверждение и должен быть включен, если статус равен Pending.

9.1.3.1.10 Number of Warning Sub-Operations

Указывает количество подопераций C-STORE, вызванных данной операцией C-GET, которые привели к ответам с предупреждением (Warning). Он может быть включен в любой ответ/подтверждение и должен быть включен, если статус равен Pending.

9.1.3.2 Процедуры службы C-GET

Следующие процедуры службы C-GET применяются к инициирующему пользователю службы DIMSE:

Инициирующий пользователь службы DIMSE запрашивает Выполняющего пользователя службы DIMSE сопоставить Identifier с атрибутами всех экземпляров SOP, известных Выполняющему пользователю службы DIMSE, и создать подоперацию C-STORE для каждого совпадения. Этот запрос осуществляется путем выдачи примитива C-GET Request поставщику службы DIMSE. Если запрос отклоняется поставщиком службы DIMSE, следующие процедуры не применяются.
В любой момент до получения примитива C-GET confirmation со статусом, отличным от Pending, Инициирующий пользователь службы DIMSE может запросить Выполняющего пользователя службы DIMSE отменить службу путем выдачи примитива C-GET Cancel Request поставщику службы DIMSE.
Инициирующий пользователь службы DIMSE может получать примитивы C-GET confirmation со статусом Pending во время обработки операции C-GET.
Инициирующий пользователь службы DIMSE получает окончательный примитив C-GET confirmation.

Примечание

В вышеописанных процедурах (c) может предшествовать (b).

Следующие процедуры службы C-GET применяются к Выполняющему пользователю службы DIMSE:

Когда Выполняющий пользователь службы DIMSE получает индикацию C-GET от поставщика службы DIMSE, он сопоставляет Identifier с атрибутами известных составных экземпляров SOP и создает подоперацию C-STORE для каждого совпадения.
В любой момент после индикации C-GET Выполняющий пользователь службы DIMSE может получить индикацию C-GET Cancel.
Если индикация C-GET Cancel получена до завершения обработки индикации C-GET, операция C-GET прекращается; в противном случае следующая процедура не применяется.
Выполняющий пользователь службы DIMSE выдает ответ C-GET со статусом Cancel поставщику службы DIMSE для указания того, что операция C-GET была отменена. Следующие процедуры не применяются.
Для каждого совпадения Выполняющий пользователь службы DIMSE C-GET инициирует подоперацию C-STORE в той же ассоциации, что и C-GET. В этой подоперации Выполняющий пользователь службы DIMSE C-GET становится Инициирующим пользователем службы DIMSE C-STORE. Выполняющий пользователь службы DIMSE C-STORE является Инициирующим пользователем службы DIMSE C-GET.
Во время обработки операции C-GET Выполняющий пользователь службы DIMSE может выдавать примитивы C-GET response со статусом Pending.
При завершении операции C-GET (как успешной, так и неудачной) Выполняющий пользователь службы DIMSE выдает ответ C-GET со статусом Refused, Failed или Success поставщику службы DIMSE.

Следующие процедуры службы C-GET применяются к поставщику службы DIMSE:

Когда поставщик службы DIMSE получает примитив C-GET Request от Инициирующего пользователя службы DIMSE, он выдает примитив C-GET indication Выполняющему пользователю службы DIMSE.
Когда поставщик службы DIMSE получает примитив C-GET Cancel Request от Инициирующего пользователя службы DIMSE, он выдает индикацию C-GET Cancel Выполняющему пользователю службы DIMSE.
Когда поставщик службы DIMSE получает примитив C-GET response от Выполняющего пользователя службы DIMSE, он выдает примитив C-GET confirmation Инициирующему пользователю службы DIMSE.

Выполняющий пользователь службы DIMSE может вернуть примитив C-GET response со статусом Failed или Refused до того, как Инициирующий пользователь службы DIMSE полностью передаст всю индикацию C-GET (набор данных). Примитив C-GET response со статусом Success или Warning не должен возвращаться до тех пор, пока Выполняющий пользователь службы DIMSE не получит всю индикацию C-GET.

Примечание

Такое возникновение ответа «Failed» часто называется преждевременным ответом об отказе.

9.1.4 Служба C-MOVE

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

9.1.4.1 Параметры C-MOVE

См. Таблица 9.1-4.

Таблица 9.1-4. Параметры C-MOVE

Имя параметра DIMSE-C	Req/Ind	Rsp/Conf	CnclReq/CnclInd
Message ID	M	U	-
Message ID Being Responded To	-	M	M
Affected SOP Class UID	M	U(=)	-
Priority	M	-	-
Move Destination	M	-	-
Identifier	M	U	-
Status	-	M	-
Number of Remaining Sub-operations	-	C	-
Number of Completed Sub-operations	-	C	-
Number of Failed Sub-operations	-	C	-
Number of Warning Sub-operations	-	C	-

9.1.4.1.1 Message ID

Примечание

Включение этого параметра в подтверждение допускалось в предыдущих версиях настоящего стандарта, но этот режим использования теперь удален. Этот параметр может быть включен в подтверждение, но в таком случае Инициирующий пользователь службы DIMSE не должен придавать этому параметру какого-либо семантического значения.
Рекомендуется, чтобы Message ID (0000,0110) был уникальным в пределах ассоциации для поддержки процедур отладки.

9.1.4.1.2 Message ID Being Responded To

Этот параметр указывает Message ID (0000,0110) запроса/индикации, к которому применяется данный ответ/подтверждение.

9.1.4.1.3 Affected SOP Class UID

9.1.4.1.4 Priority

Этот параметр указывает приоритет операции C-MOVE. Он должен быть одним из LOW, MEDIUM или HIGH. Этот приоритет также должен использоваться для всех подопераций.

9.1.4.1.5 Move Destination

Этот параметр указывает заголовок AE целевой сущности приложения DICOM, на которую выполняются подоперации C-STORE.

9.1.4.1.6 Identifier

Примечание

В ответе/подтверждении это список атрибутов, предоставляющих информацию о статусе операции C-MOVE. Список допустимых атрибутов и правила, определяющие использование Identifier, указаны в PS3.4.

9.1.4.1.7 Status

Указывает статус ответа. Он может принимать любое из следующих значений (см. также Приложение C):

Успех (0000H) — указывает, что обработка совпадений и всех подопераций завершена.
Pending (значение статуса зависит от класса службы) — указывает, что обработка совпадений и подопераций инициирована или продолжается.
Отклонено: нехватка ресурсов (значение статуса зависит от класса службы) — указывает, что обработка операции C-MOVE была прекращена из-за нехватки ресурсов. Это может быть начальным ответом на C-MOVE или может быть отправлено после ряда статусов Pending.
Отклонено: класс SOP не поддерживается (0122H) — указывает, что обработка операции C-MOVE была прекращена, так как класс SOP не поддерживается.
Отклонено: получатель перемещения неизвестен (значение статуса зависит от класса службы) — указывает, что обработка операции C-MOVE была прекращена, так как Move Destination неизвестен.
Отмена (FE00H) — указывает, что обработка операции C-MOVE была прекращена вследствие примитива C-MOVE Cancel indication.
Failed (значение статуса зависит от класса службы) — указывает, что операция C-MOVE завершилась неудачей у Выполняющего пользователя службы DIMSE.
Дублирующий вызов (0210H) — указывает, что указанный Message ID (0000,0110) назначен другому уведомлению или операции.
Неверный тип аргумента (0212H) — указывает, что один из предоставленных параметров не был согласован для использования в ассоциации между пользователями службы DIMSE.
Нераспознанная операция (0211H) — указывает, что операция не является одной из согласованных между пользователями службы DIMSE.
Отклонено: не авторизован (0124H) — указывает, что равноправный пользователь службы DIMSE не был авторизован для инициирования операции C-MOVE.
Предупреждение (значение статуса зависит от класса службы) — указывает, что Выполняющий пользователь службы DIMSE смог выполнить подоперации, но обнаружил вероятную ошибку в одной или нескольких из них.

9.1.4.1.8 Number of Remaining Sub-Operations

Указывает количество оставшихся подопераций C-STORE, которые будут вызваны данной операцией C-MOVE. Он может быть включен в любой ответ/подтверждение и должен быть включен, если статус равен Pending.

9.1.4.1.9 Number of Completed Sub-Operations

Указывает количество подопераций C-STORE, вызванных данной операцией C-MOVE, которые успешно завершились. Он может быть включен в любой ответ/подтверждение и должен быть включен, если статус равен Pending.

9.1.4.1.10 Number of Failed Sub-Operations

Указывает количество подопераций C-STORE, вызванных данной операцией C-MOVE, которые завершились неудачей. Он может быть включен в любой ответ/подтверждение и должен быть включен, если статус равен Pending.

9.1.4.1.11 Number of Warning Sub-Operations

Указывает количество подопераций C-STORE, вызванных данной операцией C-MOVE, которые привели к ответам с предупреждением (Warning). Он может быть включен в любой ответ/подтверждение и должен быть включен, если статус равен Pending.

9.1.4.2 Процедуры службы C-MOVE

Следующие процедуры службы C-MOVE применяются к инициирующему пользователю службы DIMSE:

Инициирующий пользователь службы DIMSE запрашивает Выполняющего пользователя службы DIMSE сопоставить Identifier с атрибутами всех экземпляров SOP, известных Выполняющему пользователю службы DIMSE, и создать подоперацию C-STORE для каждого совпадения. Этот запрос осуществляется путем выдачи примитива C-MOVE Request поставщику службы DIMSE. Если запрос отклоняется поставщиком службы DIMSE, следующие процедуры не применяются.
В любой момент до получения примитива C-MOVE confirmation со статусом, отличным от Pending, Инициирующий пользователь службы DIMSE может запросить Выполняющего пользователя службы DIMSE отменить службу путем выдачи примитива C-MOVE Cancel Request поставщику службы DIMSE.
Инициирующий пользователь службы DIMSE может получать примитивы C-MOVE confirmation со статусом Pending во время обработки операции C-MOVE.
Инициирующий пользователь службы DIMSE получает окончательный примитив C-MOVE confirmation.

Примечание

В вышеописанных процедурах (c) может предшествовать (b).

Следующие процедуры службы C-MOVE применяются к Выполняющему пользователю службы DIMSE:

Когда Выполняющий пользователь службы DIMSE получает индикацию C-MOVE от поставщика службы DIMSE, он сопоставляет Identifier с атрибутами известных составных экземпляров SOP и создает подоперацию C-STORE для каждого совпадения.
В любой момент после индикации C-MOVE Выполняющий пользователь службы DIMSE может получить индикацию C-MOVE Cancel.
Если индикация C-MOVE Cancel получена до завершения обработки запроса C-MOVE, операция C-MOVE прекращается; в противном случае следующая процедура не применяется.
Выполняющий пользователь службы DIMSE выдает ответ C-MOVE со статусом Cancel поставщику службы DIMSE для указания того, что операция C-MOVE была отменена. Следующие процедуры не применяются.
Для каждого совпадающего составного экземпляра SOP Выполняющий пользователь службы DIMSE C-MOVE инициирует подоперацию C-STORE в ассоциации, отличной от C-MOVE. В этой подоперации Выполняющий пользователь службы DIMSE C-MOVE становится Инициирующим пользователем службы DIMSE C-STORE. Выполняющий пользователь службы DIMSE C-STORE может как быть, так и не быть Инициирующим пользователем службы DIMSE C-MOVE.
Во время обработки операции C-MOVE Выполняющий пользователь службы DIMSE может выдавать примитивы C-MOVE response со статусом Pending.
При завершении операции C-MOVE (как успешной, так и неудачной) Выполняющий пользователь службы DIMSE выдает ответ C-MOVE со статусом Refused, Failed или Success поставщику службы DIMSE.

Следующие процедуры службы C-MOVE применяются к поставщику службы DIMSE:

Когда поставщик службы DIMSE получает примитив C-MOVE Request от Инициирующего пользователя службы DIMSE, он выдает примитив C-MOVE indication Выполняющему пользователю службы DIMSE.
Когда поставщик службы DIMSE получает примитив C-MOVE Cancel Request от Инициирующего пользователя службы DIMSE, он выдает индикацию C-MOVE Cancel Выполняющему пользователю службы DIMSE.
Когда поставщик службы DIMSE получает примитив C-MOVE response от Выполняющего пользователя службы DIMSE, он выдает примитив C-MOVE confirmation Инициирующему пользователю службы DIMSE.

Выполняющий пользователь службы DIMSE может вернуть примитив C-MOVE response со статусом Failed или Refused до того, как Инициирующий пользователь службы DIMSE полностью передаст всю индикацию C-MOVE (набор данных). Примитив C-MOVE response со статусом Success или Warning не должен возвращаться до тех пор, пока Выполняющий пользователь службы DIMSE не получит всю индикацию C-MOVE.

Примечание

Примечания: Такое возникновение ответа «Failed» часто называется преждевременным ответом об отказе.

9.1.5 Служба C-ECHO

Служба C-ECHO вызывается пользователем службы DIMSE для проверки сквозного соединения с равноправным пользователем службы DIMSE. Это подтверждаемая служба.

9.1.5.1 Параметры C-ECHO

Таблица 9.1-5. Параметры C-ECHO

Имя параметра DIMSE-C	Req/Ind	Rsp/Conf
Message ID	M	U
Message ID Being Responded To	-	M
Affected SOP Class UID	M	U(=)
Status	-	M

9.1.5.1.1 Message ID

Примечание

Включение этого параметра в подтверждение допускалось в предыдущих версиях настоящего стандарта, но этот режим использования теперь удален. Этот параметр может быть включен в подтверждение, но в таком случае Инициирующий пользователь службы DIMSE не должен придавать этому параметру какого-либо семантического значения.
Рекомендуется, чтобы Message ID (0000,0110) был уникальным в пределах ассоциации для поддержки процедур отладки.

9.1.5.1.2 Message ID Being Responded To

Этот параметр указывает Message ID (0000,0110) запроса/индикации, к которому применяется данный ответ/подтверждение.

9.1.5.1.3 Affected SOP Class UID

Для запроса/индикации этот параметр указывает класс SOP экземпляра SOP для проверки. Он может быть включен в ответ/подтверждение. Если он включен в ответ/подтверждение, этот параметр должен быть равен значению в запросе/индикации.

9.1.5.1.4 Status

Указывает статус ответа. Он может принимать любое из следующих значений (см. также Приложение C):

Успех (0000H) — указывает на успешное выполнение операции.
Отклонено: класс SOP не поддерживается (0122H) — указывает, что был указан класс SOP, отличный от Verification SOP Class, который не поддерживается.
Дублирующий вызов (0210H) — указывает, что указанный Message ID (0000,0110) назначен другому уведомлению или операции.
Неверный тип аргумента (0212H) — указывает, что один из предоставленных параметров не был согласован для использования в ассоциации между пользователями службы DIMSE.
Нераспознанная операция (0211H) — указывает, что был указан класс SOP, отличный от Verification SOP Class, который не распознает операцию C-ECHO.

9.1.5.2 Процедуры службы C-ECHO

Применяются следующие процедуры C-ECHO:

Инициирующий пользователь службы DIMSE запрашивает проверку связи с Выполняющим пользователем службы DIMSE путем выдачи примитива C-ECHO Request поставщику службы DIMSE.
Поставщик службы DIMSE выдает примитив C-ECHO indication Выполняющему пользователю службы DIMSE.
Выполняющий пользователь службы DIMSE проверяет связь путем выдачи примитива C-ECHO response поставщику службы DIMSE.
Поставщик службы DIMSE выдает примитив C-ECHO confirmation Инициирующему пользователю службы DIMSE, завершая операцию C-ECHO.

9.2 Последовательность вызовов

9.2.1 Типы служб

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

9.2.2 Ограничения использования

Эти службы могут быть вызваны только в контексте установленной ассоциации.

9.2.3 Прерываемые процедуры

Эти службы не прерывают никакие другие процедуры служб.

9.2.4 Прерывающие процедуры

Эти службы прерываются процедурой службы A-ABORT.

9.3 Протокол

Этот раздел определяет протокол, необходимый для выполнения набора операций DIMSE-C. Представления значений (VR), указанные в следующих таблицах, должны кодироваться, как определено в PS3.5.

9.3.1 Протокол C-STORE

Информация, необходимая для примитивов DIMSE-C C-STORE Request и C-STORE Indication, передается в сообщении C-STORE-RQ. Информация, необходимая для примитивов DIMSE-C C-STORE response и C-STORE confirmation, передается в сообщении C-STORE-RSP.

9.3.1.1 C-STORE-RQ

Сообщение C-STORE-RQ содержит поля, определенные в Таблице 9.3-1. Каждое поле должно соответствовать кодированию DICOM и представлению значений, как определено в PS3.5. Поля обязательны, как указано в определении службы C-STORE, если не отмечено иное в Таблице 9.3-1. Поля, не указанные в определении службы C-STORE, но присутствующие в Таблице 9.3-1, требуются протоколом DIMSE-C.

Таблица 9.3-1. Поля сообщения C-STORE-RQ

Поле сообщения	Тег	VR	VR	Описание поля
Command Group Length	(0000,0000)	UL	1	Четное число байтов от конца поля значения до начала следующей группы.
Affected SOP Class UID	(0000,0002)	UI	1	UID класса SOP сохраняемого экземпляра SOP.
Command Field	(0000,0100)	US	1	Это поле отличает операцию DIMSE-C, передаваемую данным сообщением. Значение этого поля должно быть установлено в 0001H для сообщения C-STORE-RQ.
Message ID	(0000,0110)	US	1	Зависящее от реализации значение. Оно отличает данное сообщение от других сообщений.
Priority	(0000,0700)	US	1	Приоритет должен быть установлен в одно из следующих значений: LOW = 0002H MEDIUM = 0000H HIGH = 0001H
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, что в сообщении присутствует набор данных. Оно должно быть установлено в любое значение, отличное от 0101H (Null).
Affected SOP Instance UID	(0000,1000)	UI	1	Содержит UID сохраняемого экземпляра SOP.
Move Originator Application Entity Title	(0000,1030)	AE	1	Содержит заголовок AE сущности приложения DICOM, которая инициировала операцию C-MOVE, в рамках которой выполняется данная подоперация C-STORE.
Move Originator Message ID	(0000,1031)	US	1	Содержит Message ID (0000,0110) сообщения C-MOVE-RQ, в рамках которого выполняется данная подоперация C-STORE.
Data Set	(no tag)	-	-	Прикладной набор данных.

Примечание

Содержимое составных определений информационных объектов, закодированных как последовательность элементов данных, определено в PS3.3 и PS3.4

9.3.1.2 C-STORE-RSP

Сообщение C-STORE-RSP содержит поля, определенные в Таблице 9.3-2 и в Приложении C. Каждое поле должно соответствовать кодированию DICOM и представлению значений, как определено в PS3.5 стандарта DICOM. Поля обязательны, как указано в определении службы C-STORE, если не отмечено иное в Таблице 9.3-2. Поля, не указанные в определении службы C-STORE, но присутствующие в Таблице 9.3-2, требуются протоколом DIMSE-C.

Таблица 9.3-2. Поля сообщения C-STORE-RSP

Поле сообщения	Тег	VR	VR	Описание поля
Command Group Length	(0000,0000)	UL	1	Четное число байтов от конца поля значения до начала следующей группы.
Affected SOP Class UID	(0000,0002)	UI	1	Содержит класс SOP сохраненного экземпляра SOP.
Command Field	(0000,0100)	US	1	Это поле отличает операцию DIMSE-C, передаваемую данным сообщением. Значение этого поля должно быть установлено в 8001H для сообщения C-STORE-RSP.
Message ID Being Responded To	(0000,0120)	US	1	Должно быть установлено в значение поля Message ID (0000,0110), использованное в связанном сообщении C-STORE-RQ.
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, что в сообщении нет набора данных, и должно быть установлено в значение 0101H (Null).
Status	(0000,0900)	US	1	Значение этого поля зависит от типа статуса. Приложение C определяет кодирование типов статусов, определенных в определении службы.
Affected SOP Instance UID	(0000,1000)	UI	1	Содержит UID сохраненного экземпляра SOP.

9.3.1.3 Процедуры протокола C-STORE

Процедуры C-STORE инициируются Инициирующим пользователем службы DIMSE путем выдачи примитива C-STORE Request. При получении примитива C-STORE Request конечный автомат протокола DIMSE-C должен:

построить сообщение, передающее C-STORE-RQ
отправить сообщение, используя службу P-DATA request (см. 8.1)

При получении сообщения, передающего C-STORE-RQ, конечный автомат протокола DIMSE-C должен выдать примитив C-STORE indication Выполняющему пользователю службы DIMSE.

При получении примитива C-STORE response, выданного Выполняющим пользователем службы DIMSE, конечный автомат протокола DIMSE-C должен:

построить сообщение, передающее C-STORE-RSP
отправить сообщение, используя службу P-DATA request (см. 8.1)

При получении сообщения, передающего C-STORE-RSP, конечный автомат протокола DIMSE-C должен выдать примитив C-STORE confirmation Инициирующему пользователю службы DIMSE, тем самым завершая процедуру C-STORE.

Выполняющий пользователь службы DIMSE может вернуть C-STORE-RSP со статусом Failed или Refused до того, как Инициирующий пользователь службы DIMSE полностью передаст сообщение запроса C-STORE-RQ (это называется преждевременным ответом об отказе). При получении этого C-STORE-RSP со статусом Failed или Refused Инициирующий пользователь службы DIMSE может завершить сообщение до его полной отправки (т.е. установить бит Last Fragment в 1 в Data PDV для этого сообщения, см. Приложение F). После этого он может вызвать другую операцию или уведомление. Нарушением протокола является установка Инициирующим пользователем службы DIMSE бита Last Fragment в 1 до полной передачи сообщения C-STORE-RQ, если он не получил C-STORE-RSP со статусом Failed или Refused на этот запрос.

Примечание

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

9.3.2 Протокол C-FIND

Информация, необходимая для примитивов DIMSE-C C-FIND Request и C-FIND Indication, передаётся в сообщении C-FIND-RQ. Информация, необходимая для примитивов DIMSE-C C-FIND response и confirmation, передаётся в сообщении C-FIND-RSP. Информация, необходимая для примитивов C-FIND Cancel Request и C-FIND Cancel Indication, передаётся в сообщении C-CANCEL-FIND-RQ.

9.3.2.1 C-FIND-RQ

Сообщение C-FIND-RQ содержит поля, как определено в Таблице 9.3-3. Каждое поле должно соответствовать кодированию DICOM и Представлению значения, как определено в PS3.5. Поля являются обязательными, как указано в определении службы C-FIND, если не отмечено иное в Таблице 9.3-3. Поля, не указанные в определении службы C-FIND, но присутствующие в Таблице 9.3-3, требуются протоколом DIMSE-C.

Таблица 9.3-3. Поля сообщения C-FIND-RQ

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Affected SOP Class UID	(0000,0002)	UI	1	UID SOP Class, связанный с этой операцией.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-C, передаваемую этим сообщением. Значение этого поля должно быть установлено в 0020H для сообщения C-FIND-RQ.
Message ID	(0000,0110)	US	1	Зависящее от реализации значение, отличающее это сообщение от других сообщений.
Priority	(0000,0700)	US	1	Приоритет должен быть установлен в одно из следующих значений: LOW = 0002H MEDIUM = 0000H HIGH = 0001H
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, что набор данных присутствует в сообщении. Он должен быть установлен в любое значение, отличное от 0101H (Null).
Identifier	(no tag)	-	-	Набор данных, кодирующий идентификатор для сопоставления. См. Раздел 9.1.2.1.5.

Примечание

Реализации, требующие совместимости с предыдущими версиями настоящего Стандарта, должны устанавливать поле Command Data Set Type (0000,0800) в 0102H (Identifier).

9.3.2.2 C-FIND-RSP

Сообщение C-FIND-RSP содержит поля, как определено в Таблице 9.3-4 и в Приложении C. Каждое поле должно соответствовать кодированию DICOM и Представлению значения, как определено в PS3.5. Поля являются обязательными, как указано в определении службы C-FIND, если не отмечено иное в Таблице 9.3-4. Поля, не указанные в определении службы C-FIND, но присутствующие в Таблице 9.3-4, требуются протоколом DIMSE-C.

Таблица 9.3-4. Поля сообщения C-FIND-RSP

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Affected SOP Class UID	(0000,0002)	UI	1	UID SOP Class, связанный с операцией.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-C, передаваемую этим сообщением. Значение этого поля должно быть установлено в 8020H для сообщения C-FIND-RSP.
Message ID Being Responded To	(0000,0120)	US	1	Должно быть установлено в значение поля Message ID (0000,0110), использованного в связанном сообщении C-FIND-RQ.
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, присутствует ли набор данных в сообщении. Это поле должно быть установлено в значение 0101H (Null), если набор данных отсутствует; любое другое значение указывает, что набор данных включён в сообщение.
Status	(0000,0900)	US	1	Значение этого поля зависит от типа состояния. Приложение C определяет кодирование типов состояния, определённых в определении службы.
Identifier	(no tag)	-	-	Набор данных, кодирующий совпавший идентификатор. См. Раздел 9.1.2.1.5.

9.3.2.3 C-CANCEL-FIND-RQ

Сообщение C-CANCEL-FIND-RQ содержит поля, как определено в Таблице 9.3-5. Каждое поле должно соответствовать кодированию DICOM и Представлению значения, как определено в PS3.5. Поля являются обязательными, как указано в определении службы C-FIND, если не отмечено иное в Таблице 9.3-5. Поля, не указанные в определении службы C-FIND, но присутствующие в Таблице 9.3-5, требуются протоколом DIMSE-C.

Таблица 9.3-5. Поля сообщения C-CANCEL-FIND-RQ

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-C, передаваемую этим сообщением. Значение этого поля должно быть установлено в 0FFFH для сообщения C-CANCEL-FIND-RQ.
Message ID Being Responded To	(0000,0120)	US	1	Должно быть установлено в значение поля Message ID (0000,0110), использованного в связанном сообщении C-FIND-RQ.
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, что набор данных отсутствует в сообщении и должен быть установлен в значение 0101H.

9.3.2.4 Процедуры протокола C-FIND

Процедуры C-FIND инициируются Инициирующим пользователем службы DIMSE путём выдачи примитива C-FIND Request. При получении примитива C-FIND Request конечный автомат протокола DIMSE-C должен:

создать сообщение, передающее C-FIND-RQ
отправить сообщение с использованием службы P-DATA request (см. 8.1)

При получении сообщения, передающего C-FIND-RQ, конечный автомат протокола DIMSE-C должен выдать примитив C-FIND indication Выполняющему пользователю службы DIMSE.

Конечный автомат протокола DIMSE-C должен:

принять ноль или более примитивов C-FIND response, содержащих статус Pending, выданных Выполняющим пользователем службы DIMSE, за которыми следует один примитив C-FIND response, содержащий окончательный статус
для каждого примитива C-FIND response, содержащего статус Pending, конечный автомат протокола DIMSE-C должен:
1. создать сообщение, передающее (Pending) C-FIND-RSP
2. отправить сообщение с использованием службы P-DATA request (см. 8.1)
для примитива C-FIND response, содержащего окончательный статус, конечный автомат протокола DIMSE-C должен:
1. создать сообщение, передающее (окончательное) C-FIND-RSP
2. отправить сообщение с использованием службы P-DATA request (см. 8.1)

При получении сообщения, передающего C-FIND-RSP, конечный автомат протокола DIMSE-C должен:

если сообщение указывает статус Pending, выдать примитив C-FIND confirmation Инициирующему пользователю службы DIMSE со статусом Pending
если сообщение указывает окончательный статус, выдать примитив C-FIND confirmation Инициирующему пользователю службы DIMSE с окончательным статусом, завершая таким образом процедуру C-FIND

Примечание

Процедуры C-FIND могут быть отменены в любое время Инициирующим пользователем службы DIMSE. Это осуществляется путём выдачи Инициирующим пользователем службы DIMSE примитива C-CANCEL Request.

Выполняющий пользователь службы DIMSE может вернуть C-FIND-RSP со статусом Failed или Refused до того, как Инициирующий пользователь службы DIMSE полностью передаст запросное сообщение C-FIND-RQ (это называется ранним ответом об ошибке). При получении такого C-FIND-RSP со статусом Failed или Refused Инициирующий пользователь службы DIMSE может завершить сообщение до его полной отправки (т.е. установить бит Last Fragment в 1 в Data PDV для этого сообщения, см. Приложение F). После этого он может вызвать другую операцию или уведомление. Нарушением протокола является установка Инициирующим пользователем службы DIMSE бита Last Fragment в 1 до полной передачи сообщения C-FIND-RQ, если он не получил C-FIND-RSP со статусом Failed или Refused на этот запрос.

Примечание

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

9.3.3 Протокол C-GET

Информация, необходимая для примитивов DIMSE-C C-GET Request и C-GET Indication, передаётся в сообщении C-GET-RQ. Информация, необходимая для примитивов DIMSE-C C-GET response и confirmation, передаётся в сообщении C-GET-RSP. Информация, необходимая для примитивов C-GET Cancel Request и Cancel Indication, передаётся в сообщении C-CANCEL-GET-RQ.

9.3.3.1 C-GET-RQ

Сообщение C-GET-RQ содержит поля, как определено в Таблице 9.3-6. Каждое поле должно соответствовать кодированию DICOM и Представлению значения, как определено в PS3.5. Поля являются обязательными, как указано в определении службы C-GET, если не отмечено иное в Таблице 9.3-6. Поля, не указанные в определении службы C-GET, но присутствующие в Таблице 9.3-6, требуются протоколом DIMSE-C.

Таблица 9.3-6. Поля сообщения C-GET-RQ

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Affected SOP Class UID	(0000,0002)	UI	1	UID SOP Class, связанный с этой операцией.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-C, передаваемую этим сообщением. Значение этого поля должно быть установлено в 0010H для сообщения C-GET-RQ.
Message ID	(0000,0110)	US	1	Зависящее от реализации значение, отличающее это сообщение от других сообщений.
Priority	(0000,0700)	US	1	Приоритет должен быть установлен в одно из следующих значений: LOW = 0002H MEDIUM = 0000H HIGH = 0001H
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, что набор данных присутствует в сообщении. Он должен быть установлен в любое значение, отличное от 0101H (Null).
Identifier	(no tag)	-	-	Набор данных, кодирующий атрибуты, предоставляющие информацию о состоянии операции C-GET. См. Раздел 9.1.3.1.5.

Примечание

9.3.3.2 C-GET-RSP

Сообщение C-GET-RSP содержит поля, как определено в Таблице 9.3-7 и в Приложении C. Каждое поле должно соответствовать кодированию DICOM и Представлению значения, как определено в PS3.5. Поля являются обязательными, как указано в определении службы C-GET, если не отмечено иное в Таблице 9.3-7. Поля, не указанные в определении службы C-GET, но присутствующие в Таблице 9.3-7, требуются протоколом DIMSE-C.

Таблица 9.3-7. Поля сообщения C-GET-RSP

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Affected SOP Class UID	(0000,0002)	UI	1	UID SOP Class, связанный с операцией.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-C, передаваемую этим сообщением. Значение этого поля должно быть установлено в 8010H для сообщения C-GET-RSP.
Message ID Being Responded To	(0000,0120)	US	1	Должно быть установлено в значение поля Message ID (0000,0110), использованного в связанном сообщении C-GET-RQ.
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, присутствует ли набор данных в сообщении. Это поле должно быть установлено в значение 0101H (Null), если набор данных отсутствует; любое другое значение указывает, что набор данных включён в сообщение.
Status	(0000,0900)	US	1	Значение этого поля зависит от типа состояния. Приложение C определяет кодирование типов состояния, определённых в определении службы.
Number of Remaining Sub-operations	(0000,1020)	US	1	Количество оставшихся подопераций C-STORE, которые должны быть вызваны для этой операции C-GET.
Number of Completed Sub-operations	(0000,1021)	US	1	Количество подопераций C-STORE, вызванных этой операцией C-GET, которые завершились успешно.
Number of Failed Sub-operations	(0000,1022)	US	1	Количество подопераций C-STORE, вызванных этой операцией C-GET, которые завершились неудачей.
Number of Warning Sub-operations	(0000,1023)	US	1	Количество подопераций C-STORE, вызванных этой операцией C-GET, которые сгенерировали ответы с предупреждением.
Identifier	(no tag)	-	-	Набор данных, кодирующий совпавший идентификатор. См. Раздел 9.1.3.1.5.

Примечание

Список допустимых атрибутов и правила, определяющие использование идентификатора, указаны в PS3.4.

9.3.3.3 C-CANCEL-GET-RQ

Сообщение C-CANCEL-GET-RQ содержит поля, как определено в Таблице 9.3-8. Каждое поле должно соответствовать кодированию DICOM и Представлению значения, как определено в PS3.5. Поля являются обязательными, как указано в определении службы C-GET, если не отмечено иное в Таблице 9.3-8. Поля, не указанные в определении службы C-GET, но присутствующие в Таблице 9.3-8, требуются протоколом DIMSE-C.

Таблица 9.3-8. Поля сообщения C-CANCEL-GET-RQ

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-C, передаваемую этим сообщением. Значение этого поля должно быть установлено в 0FFFH для сообщения C-CANCEL-GET-RQ.
Message ID Being Responded To	(0000,0120)	US	1	Должно быть установлено в значение поля Message ID (0000,0110), использованного в связанном сообщении C-GET-RQ.
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, что набор данных отсутствует в сообщении и должен быть установлен в значение 0101H.

9.3.3.4 Процедуры протокола C-GET

Процедуры C-GET инициируются Инициирующим пользователем службы DIMSE путём выдачи примитива C-GET Request. При получении примитива C-GET Request конечный автомат протокола DIMSE-C должен:

создать сообщение, передающее C-GET-RQ
отправить сообщение с использованием службы P-DATA request (см. 8.1).

При получении сообщения, передающего C-GET-RQ, конечный автомат протокола DIMSE-C должен выдать примитив C-GET indication Выполняющему пользователю службы DIMSE.

Конечный автомат протокола DIMSE-C должен:

принять ноль или более примитивов C-GET response, содержащих статус Pending, выданных Выполняющим пользователем службы DIMSE, за которыми следует один примитив C-GET response, содержащий окончательный статус
для каждого примитива C-GET response, содержащего статус Pending, конечный автомат протокола DIMSE-C должен:
1. создать сообщение, передающее (Pending) C-GET-RSP
2. отправить сообщение с использованием службы P-DATA request (см. 8.1)
для примитива C-GET response, содержащего окончательный статус, конечный автомат протокола DIMSE-C должен:
1. создать сообщение, передающее (окончательное) C-GET-RSP
2. отправить сообщение с использованием службы P-DATA request (см. 8.1)

Примечание

Примитив C-GET indication инициирует подоперацию, идентичную операции C-STORE. Однако для подоперации C-STORE пользователи службы DIMSE меняются ролями инициирующего и выполняющего (т.е. Инициирующий пользователь службы DIMSE становится Выполняющим пользователем службы DIMSE и т.д.).

При получении сообщения, передающего C-GET-RSP, конечный автомат протокола DIMSE-C должен:

если сообщение указывает статус Pending, выдать примитив C-GET confirmation Инициирующему пользователю службы DIMSE со статусом Pending
если сообщение указывает окончательный статус, выдать примитив C-GET confirmation Инициирующему пользователю службы DIMSE с окончательным статусом, завершая таким образом процедуру C-GET

Примечание

Процедуры C-GET могут быть отменены в любое время Инициирующим пользователем службы DIMSE. Это осуществляется путём выдачи Инициирующим пользователем службы DIMSE примитива C-CANCEL Request.

Выполняющий пользователь службы DIMSE может вернуть C-GET-RSP со статусом Failed или Refused до того, как Инициирующий пользователь службы DIMSE полностью передаст запросное сообщение C-GET-RQ (это называется ранним ответом об ошибке). При получении такого C-GET-RSP со статусом Failed или Refused Инициирующий пользователь службы DIMSE может завершить сообщение до его полной отправки (т.е. установить бит Last Fragment в 1 в Data PDV для этого сообщения, см. Приложение F). После этого он может вызвать другую операцию или уведомление. Нарушением протокола является установка Инициирующим пользователем службы DIMSE бита Last Fragment в 1 до полной передачи сообщения C-GET-RQ, если он не получил C-GET-RSP со статусом Failed или Refused на этот запрос.

Примечание

9.3.4 Протокол C-MOVE

Информация, необходимая для примитивов DIMSE-C C-MOVE Request и C-MOVE Indication, передаётся в сообщении C-MOVE-RQ. Информация, необходимая для примитивов DIMSE-C C-MOVE response и confirmation, передаётся в сообщении C-MOVE-RSP. Информация, необходимая для примитивов C-MOVE Cancel request и Cancel indication, передаётся в сообщении C-CANCEL-MOVE-RQ.

9.3.4.1 C-MOVE-RQ

Сообщение C-MOVE-RQ содержит поля, как определено в Таблице 9.3-9. Каждое поле должно соответствовать кодированию DICOM и Представлению значения, как определено в PS3.5. Поля являются обязательными, как указано в определении службы C-MOVE, если не отмечено иное в Таблице 9.3-9. Поля, не указанные в определении службы C-GET-MOVE, но присутствующие в Таблице 9.3-9, требуются протоколом DIMSE-C.

Таблица 9.3-9. Поля сообщения C-MOVE-RQ

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Affected SOP Class UID	(0000,0002)	UI	1	UID SOP Class, связанный с этой операцией.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-C, передаваемую этим сообщением. Значение этого поля должно быть установлено в 0021H для сообщения C-MOVE-RQ.
Message ID	(0000,0110)	US	1	Зависящее от реализации значение, отличающее это сообщение от других сообщений.
Priority	(0000,0700)	US	1	Приоритет должен быть установлен в одно из следующих значений: LOW = 0002H MEDIUM = 0000H HIGH = 0001H
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, что набор данных присутствует в сообщении. Он должен быть установлен в любое значение, отличное от 0101H (Null).
Move Destination	(0000,0600)	AE	1	Должно быть установлено в DICOM AE Title (заголовок AE) целевого DICOM AE, для которого выполняются подоперации C-STORE.
Identifier	(no tag)	-	-	Набор данных, кодирующий идентификатор для сопоставления. См. Раздел 9.1.4.1.6.

Примечание

9.3.4.2 C-MOVE-RSP

Сообщение C-MOVE-RSP содержит поля, как определено в Таблице 9.3-10 и в Приложении C. Каждое поле должно соответствовать кодированию DICOM и Представлению значения, как определено в PS3.5. Поля являются обязательными, как указано в определении службы C-MOVE, если не отмечено иное в Таблице 9.3-10. Поля, не указанные в определении службы C-MOVE, но присутствующие в Таблице 9.3-10, требуются протоколом DIMSE-C.

Таблица 9.3-10. Поля сообщения C-MOVE-RSP

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Affected SOP Class UID	(0000,0002)	UI	1	UID SOP Class, связанный с операцией.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-C, передаваемую этим сообщением. Значение этого поля должно быть установлено в 8021H для сообщения C-MOVE-RSP.
Message ID Being Responded To	(0000,0120)	US	1	Должно быть установлено в значение поля Message ID (0000,0110), использованного в связанном сообщении C-MOVE.
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, присутствует ли набор данных в сообщении. Это поле должно быть установлено в значение 0101H (Null), если набор данных отсутствует; любое другое значение указывает, что набор данных включён в сообщение.
Status	(0000,0900)	US	1	Значение этого поля зависит от типа состояния. Приложение C определяет кодирование типов состояния, определённых в определении службы.
Number of Remaining Sub-operations	(0000,1020)	US	1	Количество оставшихся подопераций C-STORE, которые должны быть вызваны для этой операции C-MOVE.
Number of Completed Sub-operations	(0000,1021)	US	1	Количество подопераций C-STORE, вызванных этой операцией C-MOVE, которые завершились успешно.
Number of Failed Sub-operations	(0000,1022)	US	1	Количество подопераций C-STORE, вызванных этой операцией C-MOVE, которые завершились неудачей.
Number of Warning Sub-operations	(0000,1023)	US	1	Количество подопераций C-STORE, вызванных этой операцией C-MOVE, которые сгенерировали ответы с предупреждением.
Identifier	(no tag)	-	-	Набор данных, кодирующий атрибуты, предоставляющие информацию о состоянии операции C-MOVE. См. Раздел 9.1.4.1.6.

9.3.4.3 C-CANCEL-MOVE-RQ

Сообщение C-CANCEL-MOVE-RQ содержит поля, как определено в Таблице 9.3-11. Каждое поле должно соответствовать кодированию DICOM и Представлению значения, как определено в PS3.5. Поля являются обязательными, как указано в определении службы C-MOVE, если не отмечено иное в Таблице 9.3-11. Поля, не указанные в определении службы C-MOVE, но присутствующие в Таблице 9.3-11, требуются протоколом DIMSE-C.

Таблица 9.3-11. Поля сообщения C-CANCEL-MOVE-RQ

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-C, передаваемую этим сообщением. Значение этого поля должно быть установлено в 0FFFH для сообщения C-CANCEL-MOVE-RQ.
Message ID Being Responded To	(0000,0120)	US	1	Должно быть установлено в значение поля Message ID (0000,0110), использованного в связанном сообщении C-MOVE-RQ.
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, что набор данных отсутствует в сообщении и должен быть установлен в значение 0101H.

9.3.4.4 Процедуры протокола C-MOVE

Процедуры C-MOVE инициируются Инициирующим пользователем службы DIMSE путём выдачи примитива C-MOVE Request. При получении примитива C-MOVE Request конечный автомат протокола DIMSE-C должен:

создать сообщение, передающее C-MOVE-RQ
отправить сообщение с использованием службы P-DATA request (см. 8.1)

При получении сообщения, передающего C-MOVE-RQ, конечный автомат протокола DIMSE-C должен выдать примитив C-MOVE indication Выполняющему пользователю службы DIMSE.

Конечный автомат протокола DIMSE-C должен:

принять ноль или более примитивов C-MOVE response, содержащих статус Pending, выданных Выполняющим пользователем службы DIMSE, за которыми следует один примитив C-MOVE response, содержащий окончательный статус
для каждого примитива C-MOVE response, содержащего статус Pending, конечный автомат протокола DIMSE-C должен:
1. создать сообщение, передающее (Pending) C-MOVE-RSP
2. отправить сообщение с использованием службы P-DATA request (см. 8.1)
для примитива C-MOVE response, содержащего окончательный статус, конечный автомат протокола DIMSE-C должен:
1. создать сообщение, передающее (окончательное) C-MOVE-RSP
2. отправить сообщение с использованием службы P-DATA request (см. 8.1)

Примечание

Примитив C-MOVE indication инициирует подоперацию, идентичную операции C-STORE.

При получении сообщения, передающего C-MOVE-RSP, конечный автомат протокола DIMSE-C должен:

если сообщение указывает статус Pending, выдать примитив C-MOVE confirmation Инициирующему пользователю службы DIMSE со статусом Pending;
если сообщение указывает окончательный статус, выдать примитив C-MOVE confirmation Инициирующему пользователю службы DIMSE с окончательным статусом, завершая таким образом процедуру C-MOVE

Примечание

Процедуры C-MOVE могут быть отменены в любое время Инициирующим пользователем службы DIMSE. Это должно осуществляться путём выдачи Инициирующим пользователем службы DIMSE примитива C-CANCEL Request.

Выполняющий пользователь службы DIMSE может вернуть C-MOVE-RSP со статусом Failed или Refused до того, как Инициирующий пользователь службы DIMSE полностью передаст запросное сообщение C-MOVE-RQ (это называется ранним ответом об ошибке). При получении такого C-MOVE-RSP со статусом Failed или Refused Инициирующий пользователь службы DIMSE может завершить сообщение до его полной отправки (т.е. установить бит Last Fragment в 1 в Data PDV для этого сообщения, см. Приложение F). После этого он может вызвать другую операцию или уведомление. Нарушением протокола является установка Инициирующим пользователем службы DIMSE бита Last Fragment в 1 до полной передачи сообщения C-MOVE-RQ, если он не получил C-MOVE-RSP со статусом Failed или Refused на этот запрос.

Примечание

9.3.5 Протокол C-ECHO

Информация, необходимая для примитивов DIMSE-C C-ECHO Request и C-ECHO Indication, передаётся в сообщении C-ECHO-RQ. Информация, необходимая для примитивов DIMSE-C C-ECHO response и confirmation, передаётся в сообщении C-ECHO-RSP.

9.3.5.1 C-ECHO-RQ

Сообщение C-ECHO-RQ содержит поля, как определено в Таблице 9.3-12. Каждое поле должно соответствовать кодированию DICOM и Представлению значения, как определено в PS3.5. Поля являются обязательными, как указано в определении службы C-ECHO, если не отмечено иное в Таблице 9.3-12. Поля, не указанные в определении службы C-ECHO, но присутствующие в Таблице 9.3-12, требуются протоколом DIMSE-C.

Таблица 9.3-12. Поля сообщения C-ECHO-RQ

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Affected SOP Class UID	(0000,0002)	UI	1	UID SOP Class, связанный с этой операцией.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-C, передаваемую этим сообщением. Значение этого поля должно быть установлено в 0030H для сообщения C-ECHO-RQ.
Message ID	(0000,0110)	US	1	Зависящее от реализации значение, отличающее это сообщение от других сообщений.
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, что набор данных отсутствует в сообщении и должен быть установлен в значение 0101H.

9.3.5.2 C-ECHO-RSP

Сообщение C-ECHO-RSP содержит поля, как определено в Таблице 9.3-13 и в Приложении C. Каждое поле должно соответствовать кодированию DICOM и Представлению значения, как определено в PS3.5. Поля являются обязательными, как указано в определении службы C-ECHO, если не отмечено иное в Таблице 9.3-13. Поля, не указанные в определении службы C-ECHO, но присутствующие в Таблице 9.3-13, требуются протоколом DIMSE-C.

Таблица 9.3-13. Поля сообщения C-ECHO-RSP

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Affected SOP Class UID	(0000,0002)	UI	1	UID SOP Class, связанный с операцией.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-C, передаваемую этим сообщением. Значение этого поля должно быть установлено в 8030H для сообщения C-ECHO-RSP.
Message ID Being Responded To	(0000,0120)	US	1	Должно быть установлено в значение поля Message ID (0000,0110), использованного в связанном сообщении C-ECHO-RQ.
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, что набор данных отсутствует в сообщении и должен быть установлен в значение 0101H.
Status	(0000,0900)	US	1	Указывает состояние ответа. Должно иметь значение Success (успех).

9.3.5.3 Процедуры протокола C-ECHO

Процедуры C-ECHO инициируются Инициирующим пользователем службы DIMSE путём выдачи примитива C-ECHO Request. При получении примитива C-ECHO Request конечный автомат протокола DIMSE-C должен:

создать сообщение, передающее C-ECHO-RQ
отправить сообщение с использованием службы P-DATA request (см. 8.1)

При получении сообщения, передающего C-ECHO-RQ, конечный автомат протокола DIMSE-C должен выдать примитив C-ECHO indication Выполняющему пользователю службы DIMSE.

При получении примитива C-ECHO response, выданного Выполняющим пользователем службы DIMSE, конечный автомат протокола DIMSE-C должен:

создать сообщение, передающее C-ECHO-RSP
отправить сообщение с использованием службы P-DATA request (см. 8.1)

При получении сообщения, передающего C-ECHO-RSP, конечный автомат протокола DIMSE должен выдать примитив C-ECHO confirmation Инициирующему пользователю службы DIMSE, завершая таким образом процедуру C-ECHO.

10 DIMSE-N

10.1 Службы

В следующих разделах описаны службы DIMSE-N. Поведение этих служб также описано в PS3.4. Affected SOP Class UID в команде DIMSE-N не обязательно должен совпадать с SOP Class UID в контексте представления, согласованном для ассоциации, по которой была отправлена команда DIMSE-N. В PS3.4 указаны допустимые комбинации.

10.1.1 Служба N-EVENT-REPORT

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

10.1.1.1 Параметры N-EVENT-REPORT

Таблица 10.1-1 перечисляет параметры этой службы.

Таблица 10.1-1. Параметры N-EVENT-REPORT

Имя параметра DIMSE	Req/Ind	Rsp/Conf
Message ID	M	-
Message ID Being Responded To	-	M
Affected SOP Class UID	M	U(=)
Affected SOP Instance UID	M	U(=)
Event Type ID	M	C(=)
Event Information	U	-
Event Reply	-	C
Status	-	M

10.1.1.1.1 Message ID

Этот параметр идентифицирует операцию. Он используется для того, чтобы отличить эту операцию от других уведомлений или операций, которые могут выполняться поставщиком службы DIMSE. Два одинаковых значения Message ID (0000,0110) не должны использоваться для незавершённых операций или уведомлений.

Примечание

Рекомендуется, чтобы Message ID (0000,0110) был уникальным в пределах ассоциации для поддержки процедур отладки.

10.1.1.1.2 Message ID Being Responded To

Этот параметр указывает Message ID (0000,0110) запроса/индикации уведомления, к которому относится данный ответ/подтверждение.

10.1.1.1.3 Affected SOP Class UID

Для запроса/индикации этот параметр указывает SOP Class экземпляра SOP для данного события. Он может быть включён в ответ/подтверждение. Если он включён в ответ/подтверждение, значение этого параметра должно быть равно значению в запросе/индикации.

10.1.1.1.4 Affected SOP Instance UID

Для запроса/индикации этот параметр указывает SOP Instance для данного события. Он может быть включён в ответ/подтверждение. Если он включён в ответ/подтверждение, значение этого параметра должно быть равно значению в запросе/индикации.

10.1.1.1.5 Event Type ID

Этот параметр указывает тип сообщаемого события. Он может быть включён в ответ/подтверждение об успехе и должен быть включён, если включён параметр Event Reply.

Примечание

Спецификации классов служб, содержащиеся в PS3.4, определяют любое использование параметра Event Type ID в приложении.

10.1.1.1.6 Event Information

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

Примечание

Спецификации классов служб, содержащиеся в PS3.4, определяют любое использование параметра Event Information в приложении.

10.1.1.1.7 Event Reply

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

Примечание

Спецификации классов служб, содержащиеся в PS3.4, определяют любое использование параметра Event Reply в приложении.

10.1.1.1.8 Status

Этот параметр содержит уведомление об ошибке или об успехе операции. Выполняющий пользователь службы DIMSE должен включать его в любой ответ/подтверждение. Могут возникать следующие типы статуса (см. также Приложение C):

Конфликт класса и экземпляра (0119H) — указывает, что указанный SOP Instance не является членом указанного SOP Class.
Дублирующий вызов (0210H) — указывает, что указанный Message ID (0000,0110) назначен другому уведомлению или операции.
Недопустимое значение аргумента (0115H) — указывает, что указанное значение информации о событии было вне диапазона или иным образом неприемлемо.
Недопустимый SOP Instance (0117H) — указывает, что указанный UID SOP Instance подразумевает нарушение правил построения UID.
Аргумент неверного типа (0212H) — указывает, что один из переданных параметров не был согласован для использования в ассоциации между пользователями службы DIMSE.
Отсутствует аргумент (0114H) — указывает, что указанная информация о событии не распознана.
Отсутствует тип события (0113H) — указывает, что указанный Event Type не был распознан.
Отсутствует SOP Class (0118H) — указывает, что SOP Class не был распознан.
Отсутствует SOP Instance (0112H) — указывает, что SOP Instance не был распознан.
Сбой обработки (0110H) — указывает, что при обработке операции возникла общая ошибка.
Ограничение ресурсов (0213H) — указывает, что операция не была выполнена из-за ограничения ресурсов.
Успех (0000H) — указывает на успешное уведомление.
Нераспознанная операция (0211H) — указывает, что операция не является одной из согласованных между пользователями службы DIMSE.

10.1.1.2 Процедуры службы N-EVENT-REPORT

Применяются следующие процедуры N-EVENT-REPORT:

Инициирующий пользователь службы DIMSE сообщает о событии выполняющему пользователю службы DIMSE, выдавая примитив N-EVENT-REPORT Request поставщику службы DIMSE.
Поставщик службы DIMSE выдаёт примитив N-EVENT-REPORT indication выполняющему пользователю службы DIMSE.
Выполняющий пользователь службы DIMSE сообщает о принятии или отклонении примитива N-EVENT-REPORT Request, выдавая примитив N-EVENT-REPORT response поставщику службы DIMSE.
Поставщик службы DIMSE выдаёт примитив N-EVENT-REPORT confirmation инициирующему пользователю службы DIMSE, завершая уведомление N-EVENT-REPORT.

Выполняющий пользователь службы DIMSE может вернуть примитив N-EVENT-REPORT response со статусом Failed или Refused до того, как инициирующий пользователь службы DIMSE полностью передаст индикацию N-EVENT-REPORT (Data Set). Примитив N-EVENT-REPORT response со статусом Success или Warning не должен возвращаться до тех пор, пока выполняющий пользователь службы DIMSE не получит всю индикацию N-EVENT-REPORT.

Примечание

Такое возникновение ответа "Failed" часто называется преждевременным ответом о сбое (early failed response).

10.1.2 Служба N-GET

Служба N-GET используется пользователем службы DIMSE для извлечения значений атрибутов у равноправного пользователя службы DIMSE. Это подтверждаемая служба.

10.1.2.1 Параметры N-GET

Таблица 10.1-2 перечисляет параметры этой службы.

Таблица 10.1-2. Параметры N-GET

Имя параметра DIMSE	Req/Ind	Rsp/Conf
Message ID	M	-
Message ID Being Responded To	-	M
Requested SOP Class UID	M	-
Requested SOP Instance UID	M	-
Attribute Identifier List	U	-
Affected SOP Class UID	-	U
Affected SOP Instance UID	-	U
Attribute List	-	C
Status	-	M

10.1.2.1.1 Message ID

Примечание

Рекомендуется, чтобы Message ID (0000,0110) был уникальным в пределах ассоциации для поддержки процедур отладки.

10.1.2.1.2 Message ID Being Responded To

Этот параметр указывает Message ID (0000,0110) запроса/индикации операции, к которому относится данный ответ/подтверждение.

10.1.2.1.3 Requested SOP Class UID

Этот параметр указывает SOP Class, для которого должны быть извлечены значения атрибутов.

10.1.2.1.4 Requested SOP Instance UID

Этот параметр указывает SOP Instance, для которого должны быть извлечены значения атрибутов.

10.1.2.1.5 Attribute Identifier List

Этот параметр содержит набор идентификаторов атрибутов, значения которых должны быть возвращены выполняющим пользователем службы DIMSE. Если этот параметр опущен, предполагаются все идентификаторы атрибутов. Определения атрибутов находятся в спецификации Information Object Definition в PS3.3.

10.1.2.1.6 Affected SOP Class UID

Этот параметр может быть включён в ответ/подтверждение. Если он включён в ответ/подтверждение, значение этого параметра должно быть равно значению параметра Requested SOP Class UID, использованному в запросе/индикации.

10.1.2.1.7 Affected SOP Instance UID

Этот параметр указывает SOP Instance, для которого возвращаются значения атрибутов. Он может быть включён в любой ответ/подтверждение, и при включении должен быть равен значению параметра Requested SOP Instance UID (0000,1001), использованному при вызове.

10.1.2.1.8 Attribute List

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

10.1.2.1.9 Status

Предупреждение списка атрибутов (0107H) — указывает, что одно или несколько значений атрибутов не были прочитаны, так как указанный атрибут не был распознан. Значения атрибутов, которые удалось прочитать, возвращаются.
Конфликт класса и экземпляра (0119H) — указывает, что указанный SOP Instance не является членом указанного SOP Class.
Дублирующий вызов (0210H) — указывает, что указанный Message ID (0000,0110) назначен другому уведомлению или операции.
Недопустимый SOP Instance (0117H) — указывает, что указанный UID SOP Instance подразумевает нарушение правил построения UID.
Аргумент неверного типа (0212H) — указывает, что один из переданных параметров не был согласован для использования в ассоциации между пользователями службы DIMSE.
Отсутствует SOP Class (0118H) — указывает, что SOP Class не был распознан.
Отсутствует SOP Instance (0112H) — указывает, что SOP Instance не был распознан.
Сбой обработки (0110H) — указывает, что при обработке операции возникла общая ошибка.
Ограничение ресурсов (0213H) — указывает, что операция не была выполнена из-за ограничения ресурсов.
Успех (0000H) — указывает на успешную операцию.
Нераспознанная операция (0211H) — указывает, что операция не является одной из согласованных между пользователями службы DIMSE.
Отказано: не авторизован (0124H) — указывает, что равноправный пользователь службы DIMSE не был авторизован для вызова операции.
Предупреждение (значение статуса зависит от класса службы) — указывает, что выполняющий пользователь службы DIMSE вернул не все необязательные атрибуты.
Сбой (значение статуса зависит от класса службы) — указывает, что выполняющий пользователь службы DIMSE не смог завершить операцию.

10.1.2.2 Процедуры службы N-GET

Применяются следующие процедуры N-GET:

Инициирующий пользователь службы DIMSE запрашивает у выполняющего пользователя службы DIMSE извлечение значения(ий) атрибута, выдавая примитив N-GET Request поставщику службы DIMSE.
Поставщик службы DIMSE выдаёт примитив N-GET indication выполняющему пользователю службы DIMSE.
Если операция может быть выполнена, выполняющий пользователь службы DIMSE извлекает запрошенные значения атрибутов и формирует ответ, указывающий на принятие примитива N-GET Request, выдавая примитив N-GET response поставщику службы DIMSE. В этом случае следующая процедура не применяется.
Если операция не может быть выполнена, выполняющий пользователь службы DIMSE отклоняет запрос N-GET, выдавая примитив N-GET response с соответствующим кодом ошибки поставщику службы DIMSE.
Поставщик службы DIMSE выдаёт примитив N-GET confirmation инициирующему пользователю службы DIMSE, завершая операцию N-GET.

10.1.3 Служба N-SET

Служба N-SET используется пользователем службы DIMSE для запроса модификации значений атрибутов у равноправного пользователя службы DIMSE. Это подтверждаемая служба.

10.1.3.1 Параметры N-SET

Таблица 10.1-3 перечисляет параметры этой службы.

Таблица 10.1-3. Параметры N-SET

Имя параметра DIMSE	Req/Ind	Rsp/Conf
Message ID	M	-
Message ID Being Responded To	-	M
Requested SOP Class UID	M	-
Requested SOP Instance UID	M	-
Modification List	M	-
Attribute List	-	U
Affected SOP Class UID	-	U
Affected SOP Instance UID	-	U
Status	-	M

10.1.3.1.1 Message ID

Примечание

Рекомендуется, чтобы Message ID (0000,0110) был уникальным в пределах ассоциации для поддержки процедур отладки.

10.1.3.1.2 Message ID Being Responded To

10.1.3.1.3 Requested SOP Class UID

Этот параметр указывает SOP Class, для которого должны быть изменены значения атрибутов.

10.1.3.1.4 Requested SOP Instance UID

Этот параметр указывает SOP Instance, для которого должны быть изменены значения атрибутов.

10.1.3.1.5 Modification List

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

10.1.3.1.6 Attribute List

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

10.1.3.1.7 Affected SOP Class UID

10.1.3.1.8 Affected SOP Instance UID

Этот параметр указывает SOP Instance, для которого были изменены значения атрибутов. Он может быть включён в любой ответ/подтверждение, и при включении должен быть равен значению параметра Requested SOP Instance UID (0000,1001), использованному при вызове.

10.1.3.1.9 Status

Конфликт класса и экземпляра (0119H) — указывает, что указанный SOP Instance не является членом указанного SOP Class.
Дублирующий вызов (0210H) — указывает, что указанный Message ID (0000,0110) назначен другому уведомлению или операции.
Недопустимое значение атрибута (0106H) — указывает, что указанное значение атрибута было вне диапазона или иным образом неприемлемо.
Значение атрибута вне диапазона (0116H) — указывает, что указанное значение атрибута было вне диапазона или иным образом неприемлемо. Значения атрибутов, которые можно было изменить, были изменены.
Аргумент неверного типа (0212H) — указывает, что один из переданных параметров не был согласован для использования в ассоциации между пользователями службы DIMSE.
Недопустимый SOP Instance (0117H) — указывает, что указанный UID SOP Instance подразумевает нарушение правил построения UID.
Отсутствует значение атрибута (0121H) — указывает, что требуемое значение атрибута не было передано.
Отсутствует атрибут (0105H) — указывает, что тег указанного атрибута не был распознан.
Предупреждение списка атрибутов (0107H) — указывает, что одно или несколько значений атрибутов не были изменены, так как указанные атрибуты не были распознаны. Значения атрибутов, которые можно было изменить, были изменены.
Отсутствует SOP Class (0118H) — указывает, что SOP Class не был распознан.
Отсутствует SOP Instance (0112H) — указывает, что SOP Instance не был распознан.
Сбой обработки (0110H) — указывает, что при обработке операции возникла общая ошибка.
Ограничение ресурсов (0213H) — указывает, что операция не была выполнена из-за ограничения ресурсов.
Успех (0000H) — указывает на успешную операцию.
Нераспознанная операция (0211H) — указывает, что операция не является одной из согласованных между пользователями службы DIMSE.
Отказано: не авторизован (0124H) — указывает, что равноправный пользователь службы DIMSE не был авторизован для вызова операции.
Сбой (значение статуса зависит от класса службы) — указывает, что операция не была выполнена, так как некоторые условия для операции не были соблюдены.
Предупреждение (значение статуса зависит от класса службы) — указывает, что операция была выполнена частично или с изменёнными условиями.

10.1.3.2 Процедуры службы N-SET

Применяются следующие процедуры N-SET:

Инициирующий пользователь службы DIMSE запрашивает у выполняющего пользователя службы DIMSE модификацию значения(ий) атрибута, выдавая примитив N-SET Request поставщику службы DIMSE.
Поставщик службы DIMSE выдаёт примитив N-SET indication выполняющему пользователю службы DIMSE.
Если операция может быть выполнена, выполняющий пользователь службы DIMSE изменяет запрошенные значения атрибутов и формирует ответ, указывающий на принятие примитива N-SET Request, выдавая примитив N-SET response поставщику службы DIMSE. В этом случае следующая процедура не применяется.
Если операция не может быть выполнена, выполняющий пользователь службы DIMSE отклоняет запрос N-SET, выдавая примитив N-SET response с соответствующим кодом ошибки поставщику службы DIMSE.
Поставщик службы DIMSE выдаёт примитив N-SET confirmation инициирующему пользователю службы DIMSE, завершая операцию N-SET.

Выполняющий пользователь службы DIMSE может вернуть примитив N-SET response со статусом Failed или Refused до того, как инициирующий пользователь службы DIMSE полностью передаст индикацию N-SET (Data Set). Примитив N-SET response со статусом Success или Warning не должен возвращаться до тех пор, пока выполняющий пользователь службы DIMSE не получит всю индикацию N-SET.

Примечание

Такое возникновение ответа "Failed" часто называется преждевременным ответом о сбое (early failed response).

10.1.4 Служба N-ACTION

Служба N-ACTION используется пользователем службы DIMSE для запроса действия у равноправного пользователя службы DIMSE. Это подтверждаемая служба.

10.1.4.1 Параметры N-ACTION

Таблица 10.1-4 перечисляет параметры этой службы.

Таблица 10.1-4. Параметры N-ACTION

Имя параметра DIMSE	Req/Ind	Rsp/Conf
Message ID	M	-
Message ID Being Responded To	-	M
Requested SOP Class UID	M	-
Requested SOP Instance UID	M	-
Action Type ID	M	C(=)
Action Information	U	-
Affected SOP Class UID	-	U
Affected SOP Instance UID	-	U
Action Reply	-	C
Status	-	M

10.1.4.1.1 Message ID

Примечание

Рекомендуется, чтобы Message ID (0000,0110) был уникальным в пределах ассоциации для поддержки процедур отладки.

10.1.4.1.2 Message ID Being Responded To

10.1.4.1.3 Requested SOP Class UID

Этот параметр указывает SOP Class, для которого должно быть выполнено действие.

10.1.4.1.4 Requested SOP Instance UID

Этот параметр указывает SOP Instance, над которым должно быть выполнено действие.

10.1.4.1.5 Action Type ID

Этот параметр указывает конкретное действие, которое должно быть выполнено. Он может быть включён в ответ/подтверждение об успехе и должен быть включён, если включён параметр Action Reply.

Примечание

Спецификации классов служб, содержащиеся в PS3.4, определяют любое использование параметра Action Type ID (0000,1008) в приложении.

10.1.4.1.6 Action Information

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

Примечание

Спецификации классов служб, содержащиеся в PS3.4, определяют любое использование параметра Action Information в приложении.

10.1.4.1.7 Affected SOP Class UID

10.1.4.1.8 Affected SOP Instance UID

Этот параметр указывает SOP Instance, над которым должно быть выполнено действие. Он может быть включён в любой ответ/подтверждение, и при включении должен быть равен значению параметра Requested SOP Instance UID (0000,1001), использованному при вызове.

10.1.4.1.9 Action Reply

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

Примечание

Спецификации классов служб, содержащиеся в PS3.4, определяют любое использование параметра Action Reply в приложении.

10.1.4.1.10 Status

Этот параметр содержит уведомление об ошибке или об успехе операции. Выполняющий пользователь службы DIMSE должен включать его в любой ответ/подтверждение. Может возникать следующий тип статуса (см. также Приложение C):

Конфликт класса и экземпляра (0119H) — указывает, что указанный SOP Instance не является членом указанного SOP Class.
Дублирующий вызов (0210H) — указывает, что указанный Message ID (0000,0110) назначен другому уведомлению или операции.
Недопустимое значение аргумента (0115H) — указывает, что указанное значение информации о действии было вне диапазона или иным образом неприемлемо.
Недопустимый SOP Instance (0117H) — указывает, что указанный UID SOP Instance подразумевает нарушение правил построения UID.
Аргумент неверного типа (0212H) — указывает, что один из переданных параметров не был согласован для использования в ассоциации между пользователями службы DIMSE.
Отсутствует действие (0123H) — указывает, что указанный Action Type не поддерживается.
Отсутствует аргумент (0114H) — указывает, что указанная информация о действии не поддерживается.
Отсутствует SOP Class (0118H) — указывает, что SOP Class не был распознан.
Отсутствует SOP Instance (0112H) — указывает, что SOP Instance не был распознан.
Сбой обработки (0110H) — указывает, что при обработке операции возникла общая ошибка.
Ограничение ресурсов (0213H) — указывает, что операция не была выполнена из-за ограничения ресурсов.
Успех (0000H) — указывает на успешную операцию.
Нераспознанная операция (0211H) — указывает, что операция не является одной из согласованных между пользователями службы DIMSE.
Отказано: не авторизован (0124H) — указывает, что равноправный пользователь службы DIMSE не был авторизован для вызова операции.
Сбой (значение статуса зависит от класса службы) — указывает, что операция не была выполнена, так как некоторые условия для операции не были соблюдены.
Предупреждение (значение статуса зависит от класса службы) — указывает, что операция была выполнена частично или с изменёнными условиями.

10.1.4.2 Процедуры службы N-ACTION

Применяются следующие процедуры N-ACTION:

Инициирующий пользователь службы DIMSE запрашивает у выполняющего пользователя службы DIMSE выполнение действия над управляемым SOP Instance, выдавая примитив N-ACTION Request поставщику службы DIMSE.
Поставщик службы DIMSE выдаёт примитив N-ACTION indication выполняющему пользователю службы DIMSE.
Если операция может быть выполнена, выполняющий пользователь службы DIMSE применяет действие к указанному SOP Instance и формирует ответ, указывающий на принятие примитива N-ACTION Request, выдавая примитив N-ACTION response поставщику службы DIMSE. В этом случае следующая процедура не применяется. Action Reply может быть включён в успешный ответ.
Если операция не может быть выполнена, выполняющий пользователь службы DIMSE отклоняет запрос N-ACTION, выдавая примитив N-ACTION response с соответствующим кодом ошибки поставщику службы DIMSE.
Поставщик службы DIMSE выдаёт примитив N-ACTION confirmation инициирующему пользователю службы DIMSE, завершая операцию N-ACTION.

Выполняющий пользователь службы DIMSE может вернуть примитив N-ACTION response со статусом Failed или Refused до того, как инициирующий пользователь службы DIMSE полностью передаст индикацию N-ACTION (Data Set). Примитив N-ACTION response со статусом Success или Warning не должен возвращаться до тех пор, пока выполняющий пользователь службы DIMSE не получит всю индикацию N-ACTION.

Примечание

Такое возникновение ответа "Failed" часто называется преждевременным ответом о сбое (early failed response).

10.1.5 Служба N-CREATE

Служба N-CREATE используется пользователем службы DIMSE для запроса равноправному пользователю службы DIMSE создать новый управляемый SOP Instance с его идентификацией и значениями связанных с ним атрибутов, а также одновременно зарегистрировать его идентификацию. Это подтверждаемая служба.

10.1.5.1 Параметры N-CREATE

Таблица 10.1-5 перечисляет параметры этой службы.

Таблица 10.1-5. Параметры N-CREATE

Имя параметра DIMSE	Req/Ind	Rsp/Conf
Message ID	M	-
Message ID Being Responded To	-	M
Affected SOP Class UID	M	U(=)
Affected SOP Instance UID	U	C
Attribute List	U	U
Status	-	M

10.1.5.1.1 Message ID

Примечание

Рекомендуется, чтобы Message ID (0000,0110) был уникальным в пределах ассоциации для поддержки процедур отладки.

10.1.5.1.2 Message ID Being Responded To

10.1.5.1.3 Affected SOP Class UID

Для запроса/индикации этот параметр указывает SOP Class нового SOP Instance, который должен быть создан выполняющим пользователем службы DIMSE. Выполняющий пользователь службы DIMSE назначает новому SOP Instance набор значений атрибутов, как указано в определении его SOP Class. Для ответа/подтверждения этот параметр указывает SOP Class созданного SOP Instance. Он может быть включён в ответ/подтверждение. Если он включён в ответ/подтверждение, значение этого параметра должно быть равно значению в запросе/индикации.

10.1.5.1.4 Affected SOP Instance UID

Для запроса/индикации этот параметр указывает SOP Instance, который используется выполняющим пользователем службы DIMSE. Если UID SOP Instance не передан инициирующим пользователем службы DIMSE, выполняющий пользователь службы DIMSE назначает значение для этой идентификации экземпляра. Для ответа/подтверждения этот параметр может быть включён только в ответ/подтверждение об успехе и должен быть включён, если он не был передан инициирующим пользователем службы DIMSE.

10.1.5.1.5 Attribute List

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

10.1.5.1.6 Status

Дублирующий вызов (0210H) — указывает, что указанный Message ID (0000,0110) назначен другому уведомлению или операции.
Дублирующий SOP Instance (0111H) — указывает, что новое значение управляемого SOP Instance, переданное инициирующим пользователем службы DIMSE, уже было зарегистрировано для управляемого SOP Instance указанного SOP Class.
Недопустимое значение атрибута (0106H) — указывает, что указанное значение атрибута было вне диапазона или иным образом неприемлемо.
Значение атрибута вне диапазона (0116H) — указывает, что указанное значение атрибута было вне диапазона или иным образом неприемлемо. SCP применит значение по умолчанию или не включит атрибут в созданный экземпляр.
Недопустимый SOP Instance (0117H) — указывает, что указанный UID SOP Instance подразумевает нарушение правил построения UID.
Отсутствует атрибут (0120H) — указывает, что требуемый атрибут не был передан.
Отсутствует значение атрибута (0121H) — указывает, что требуемое значение атрибута не было передано и значение по умолчанию недоступно.
Аргумент неверного типа (0212H) — указывает, что один из переданных параметров не был согласован для использования в ассоциации между пользователями службы DIMSE.
Отсутствует атрибут (0105H) — указывает, что тег указанного атрибута не был распознан.
Предупреждение списка атрибутов (0107H) — указывает, что один или несколько указанных атрибутов не были распознаны и не включены в созданный экземпляр.
Отсутствует SOP Class (0118H) — указывает, что SOP Class не был распознан.
Сбой обработки (0110H) — указывает, что при обработке операции возникла общая ошибка.
Ограничение ресурсов (0213H) — указывает, что операция не была выполнена из-за ограничения ресурсов.
Успех (0000H) — указывает на успешную операцию.
Нераспознанная операция (0211H) — указывает, что операция не является одной из согласованных между пользователями службы DIMSE.
Отказано: не авторизован (0124H) — указывает, что равноправный пользователь службы DIMSE не был авторизован для вызова операции.
Сбой (значение статуса зависит от класса службы) — указывает, что выполняющий пользователь службы DIMSE не создал экземпляр.
Предупреждение (значение статуса зависит от класса службы) — указывает, что выполняющий пользователь службы DIMSE создал экземпляр, но не выполнил все указанные операции.

10.1.5.2 Процедуры службы N-CREATE

Применяются следующие процедуры N-CREATE:

Инициирующий пользователь службы DIMSE запрашивает создание и регистрацию нового управляемого SOP Instance, выдавая примитив N-CREATE Request поставщику службы DIMSE.
Поставщик службы DIMSE выдаёт примитив N-CREATE indication выполняющему пользователю службы DIMSE.
Если операция может быть выполнена, выполняющий пользователь службы DIMSE создаёт и регистрирует новый управляемый SOP Instance и формирует ответ, указывающий на принятие примитива N-CREATE Request, выдавая примитив N-CREATE response поставщику службы DIMSE. В этом случае следующая процедура не применяется.
Если операция не может быть выполнена, выполняющий пользователь службы DIMSE отклоняет запрос N-CREATE, выдавая примитив N-CREATE response с соответствующим кодом ошибки поставщику службы DIMSE.
Поставщик службы DIMSE выдаёт примитив N-CREATE confirmation инициирующему пользователю службы DIMSE, завершая операцию N-CREATE.

Выполняющий пользователь службы DIMSE может вернуть примитив N-CREATE response со статусом Failed или Refused до того, как инициирующий пользователь службы DIMSE полностью передаст индикацию N-CREATE (Data Set). Примитив N-CREATE response со статусом Success или Warning не должен возвращаться до тех пор, пока выполняющий пользователь службы DIMSE не получит всю индикацию N-CREATE.

Примечание

Такое возникновение ответа "Failed" часто называется преждевременным ответом о сбое (early failed response).

10.1.6 Служба N-DELETE

Служба N-DELETE используется инициирующим пользователем службы DIMSE для запроса равноправному пользователю службы DIMSE удалить управляемый SOP Instance и отменить регистрацию его идентификации. Это подтверждаемая служба.

10.1.6.1 Параметры N-DELETE

Таблица 10.1-6 перечисляет параметры этой службы.

Таблица 10.1-6. Параметры N-DELETE

Имя параметра DIMSE	Req/Ind	Rsp/Conf
Message ID	M	-
Message ID Being Responded To	-	M
Requested SOP Class UID	M	-
Requested SOP Instance UID	M	-
Affected SOP Class UID	-	U
Affected SOP Instance UID	-	U
Status	-	M

10.1.6.1.1 Message ID

Примечание

Рекомендуется, чтобы Message ID (0000,0110) был уникальным в пределах ассоциации для поддержки процедур отладки.

10.1.6.1.2 Message ID Being Responded To

10.1.6.1.3 Requested SOP Class UID

Этот параметр указывает SOP Class, который должен быть удалён.

10.1.6.1.4 Requested SOP Instance UID

Этот параметр указывает SOP Instance, который должен быть удалён.

10.1.6.1.5 Affected SOP Class UID

Этот параметр может быть включён в ответ/подтверждение. Если он включён в ответ/подтверждение, значение этого параметра должно быть равно значению параметра, использованному в запросе/индикации.

10.1.6.1.6 Affected SOP Instance UID

Этот параметр указывает SOP Instance, который был удалён. Он может быть включён в любой ответ/подтверждение, и при включении должен быть равен значению параметра Requested SOP Instance UID (0000,1001), использованному при вызове.

10.1.6.1.7 Status

Конфликт класса и экземпляра (0119H) — указывает, что указанный SOP Instance не является членом указанного SOP Class
Дублирующий вызов (0210H) — указывает, что указанный Message ID (0000,0110) назначен другому уведомлению или операции
Недопустимый SOP Instance (0117H) — указывает, что указанный UID SOP Instance подразумевает нарушение правил построения UID
Аргумент неверного типа (0212H) — указывает, что один из переданных параметров не был согласован для использования в ассоциации между пользователями службы DIMSE
Отсутствует SOP Class (0118H) — указывает, что SOP Class не был распознан
Отсутствует SOP Instance (0112H) — указывает, что SOP Instance не был распознан
Сбой обработки (0110H) — указывает, что при обработке операции возникла общая ошибка
Ограничение ресурсов (0213H) — указывает, что операция не была выполнена из-за ограничения ресурсов
Успех (0000H) — указывает на успешную операцию
Нераспознанная операция (0211H) — указывает, что операция не является одной из согласованных между пользователями службы DIMSE
Отказано: не авторизован (0124H) — указывает, что равноправный пользователь службы DIMSE не был авторизован для вызова операции.

10.1.6.2 Процедуры службы N-DELETE

Применяются следующие процедуры N-DELETE:

Инициирующий пользователь службы DIMSE запрашивает у выполняющего пользователя службы DIMSE удаление управляемого SOP Instance, выдавая примитив N-DELETE Request поставщику службы DIMSE.
Поставщик службы DIMSE выдаёт примитив N-DELETE indication выполняющему пользователю службы DIMSE.
Если операция может быть выполнена, выполняющий пользователь службы DIMSE удаляет указанный управляемый SOP Instance и формирует ответ, указывающий на принятие примитива N-DELETE Request, выдавая примитив N-DELETE response поставщику службы DIMSE. В этом случае следующая процедура не применяется.
Если операция не может быть выполнена, выполняющий пользователь службы DIMSE отклоняет запрос N-DELETE, выдавая примитив N-DELETE response с соответствующим кодом ошибки поставщику службы DIMSE.
Поставщик службы DIMSE выдаёт примитив N-DELETE confirmation инициирующему пользователю службы DIMSE, завершая операцию N-DELETE.

10.2 Последовательность вызовов

10.2.1 Типы служб

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

10.2.2 Ограничения использования

Эти службы могут быть вызваны только в контексте установленной ассоциации.

10.2.3 Прерванные процедуры

Эти службы не прерывают никакие другие процедуры службы.

10.2.4 Процедуры прерывания

Эти службы прерываются процедурой службы A-ABORT.

10.3 Протокол

В этом разделе определяется протокол, необходимый для выполнения набора операций и уведомлений DIMSE-N. Представления значений (VR), указанные в следующих таблицах, должны кодироваться, как определено в PS3.5.

10.3.1 Протокол N-EVENT-REPORT

Информация, необходимая для примитивов DIMSE-N N-EVENT-REPORT Request и N-EVENT-REPORT Indication, передаётся в сообщении N-EVENT-REPORT-RQ. Информация, необходимая для примитивов DIMSE-N N-EVENT-REPORT response и confirmation, передаётся в сообщении N-EVENT-REPORT-RSP.

10.3.1.1 N-EVENT-REPORT-RQ

Сообщение N-EVENT-REPORT-RQ содержит поля, как определено в Таблица 10.3-1. Каждое поле должно соответствовать кодированию DICOM и представлению значений, как определено в PS3.5. Поля обязательны, как указано в N-EVENT-REPORT определении службы, если не указано иное в Таблица 10.3-1. Поля, не указанные в N-EVENT-REPORT определении службы, но присутствующие в Таблица 10.3-1 требуются протоколом DIMSE-N.

Таблица 10.3-1. Поля сообщения N-EVENT-REPORT-RQ

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Affected SOP Class UID	(0000,0002)	UI	1	UID SOP Class экземпляра SOP, для которого произошло это событие.
Command Field	(0000,0100)	US	1	Это поле различает уведомление DIMSE-N, передаваемое этим сообщением. Значение этого поля должно быть установлено в 0100H для сообщения N-EVENT-REPORT-RQ.
Message ID	(0000,0110)	US	1	Зависящее от реализации значение, отличающее это сообщение от других сообщений.
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, присутствует ли набор данных в сообщении. Это поле должно быть установлено в значение 0101H, если набор данных отсутствует; любое другое значение указывает, что набор данных включён в сообщение.
Affected SOP Instance UID	(0000,1000)	UI	1	Содержит UID экземпляра SOP, для которого произошло это событие.
Event Type ID	(0000,1002)	US	1	Значения для этого поля зависят от приложения.
Event Information	(no tag)	-	-	Зависящий от приложения набор данных, содержащий дополнительную информацию, относящуюся к операции.

Примечание

Спецификации класса службы, содержащиеся в PS3.4 определяют значения, необходимые для параметра Event Type ID.
Спецификации класса службы, содержащиеся в PS3.4 определяют набор данных, необходимый для параметра Event Information.

10.3.1.2 N-EVENT-REPORT-RSP

Сообщение N-EVENT-REPORT-RSP содержит поля, как определено в Таблица 10.3-2 and Приложение C. Каждое поле должно соответствовать кодированию DICOM и представлению значений, как определено в PS3.5. Поля обязательны, как указано в N-EVENT-REPORT определении службы, если не указано иное в Таблица 10.3-2. Поля, не указанные в N-EVENT-REPORT определении службы, но присутствующие в Таблица 10.3-2 требуются протоколом DIMSE-N.

Таблица 10.3-2. Поля сообщения N-EVENT-REPORT-RSP

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Affected SOP Class UID	(0000,0002)	UI	1	UID SOP Class экземпляра SOP, для которого произошло это событие.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-N, передаваемую этим сообщением. Значение этого поля должно быть установлено в 8100H для сообщения N-EVENT-REPORT-RSP.
Message ID Being Responded To	(0000,0120)	US	1	Должен быть установлен в значение поля Message ID (0000,0110), использованного в связанном сообщении N-EVENT-REPORT-RQ.
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, присутствует ли набор данных в сообщении. Это поле должно быть установлено в значение 0101H, если набор данных отсутствует; любое другое значение указывает, что набор данных включён в сообщение.
Status	(0000,0900)	US	1	Значение этого поля зависит от типа состояния. Приложение C определяет кодирование типов состояния, определённых в определении службы.
Affected SOP Instance UID	(0000,1000)	UI	1	Содержит UID экземпляра SOP, для которого произошло это событие.
Event Type ID	(0000,1002)	US	1	Значения для этого поля зависят от приложения.
Event Reply	(no tag)	-	-	Зависящий от приложения набор данных, содержащий дополнительную информацию, относящуюся к операции.

Примечание

Спецификации класса службы, содержащиеся в PS3.4 определяют значения, необходимые для параметра Event Type ID.
Спецификации класса службы, содержащиеся в PS3.4 определяют набор данных, необходимый для параметра Event Reply, относящегося к каждому определённому Event Type ID.

10.3.1.3 Процедуры протокола N-EVENT-REPORT

Процедуры отчётов N-EVENT-REPORT инициируются инициирующим пользователем службы DIMSE, выдающим примитив N-EVENT-REPORT Request. При получении примитива N-EVENT-REPORT Request конечный автомат протокола DIMSE-N должен:

создать сообщение, передающее N-EVENT-REPORT-RQ
отправить сообщение, используя службу запросов P-DATA (см. 8.1)

При получении сообщения, передающего N-EVENT-REPORT-RQ, конечный автомат протокола DIMSE-N должен выдать примитив индикации N-EVENT-REPORT выполняющему пользователю службы DIMSE.

При получении примитива ответа N-EVENT-REPORT, выданного выполняющим пользователем службы DIMSE , конечный автомат протокола DIMSE-N должен:

создать сообщение, передающее N-EVENT-REPORT-RSP
отправить сообщение, используя службу запросов P-DATA (см. Раздел 8.1)

При получении сообщения, передающего N-EVENT-REPORT-RSP, конечный автомат протокола DIMSE-N должен выдать примитив подтверждения N-EVENT-REPORT инициирующему пользователю службы DIMSE, тем самым завершая процедуру уведомления.

Выполняющий пользователь службы DIMSE может вернуть N-EVENT-REPORT-RSP со статусом Failed или Refused до того, как полное сообщение запроса N-EVENT-REPORT-RQ будет полностью передано инициирующим пользователем службы DIMSE (это называется ранним ответом об ошибке). При получении этого N-EVENT-REPORT-RSP со статусом Failed или Refused инициирующий пользователь службы DIMSE может завершить сообщение до его полной отправки (т.е. установить бит Last Fragment в 1 в Data PDV для этого сообщения, см. Приложение F). После этого он может инициировать другую операцию или уведомление. Нарушением протокола является установка инициирующим пользователем службы DIMSE бита Last Fragment в 1 до полной передачи сообщения N-EVENT-REPORT-RQ, если он не получил N-EVENT-REPORT-RSP со статусом Failed или Refused на этот запрос.

Примечание

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

10.3.2 Протокол N-GET

Информация, необходимая для примитивов DIMSE-N N-GET Request и N-GET Indication, передаётся в сообщении N-GET-RQ. Информация, необходимая для примитивов DIMSE-N N-GET response и confirmation, передаётся в сообщении N-GET-RSP.

10.3.2.1 N-GET-RQ

Сообщение N-GET-RQ содержит поля, как определено в Таблица 10.3-3. Каждое поле должно соответствовать кодированию DICOM и представлению значений, как определено в PS3.5. Поля обязательны, как указано в N-GET определении службы, если не указано иное в Таблица 10.3-3. Поля, не указанные в N-GET определении службы, но присутствующие в Таблица 10.3-3 требуются протоколом DIMSE-N.

Таблица 10.3-3. Поля сообщения N-GET-RQ

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Requested SOP Class UID	(0000,0003)	UI	1	UID SOP Class экземпляра SOP, для которого должны быть получены значения атрибутов.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-N, передаваемую этим сообщением. Значение этого поля должно быть установлено в 0110H для сообщения N-GET-RQ.
Message ID	(0000,0110)	US	1	Зависящее от реализации значение, отличающее это сообщение от других сообщений.
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, что в сообщении не должно быть набора данных. Это поле должно быть установлено в значение 0101H).
Requested SOP Instance UID	(0000,1001)	UI	1	Содержит UID экземпляра SOP, для которого должны быть получены значения атрибутов.
Attribute Identifier List	(0000,1005)	AT	1-n	Это поле содержит тег атрибута для каждого из n атрибутов, применимых к операции N-GET.

10.3.2.2 N-GET-RSP

Сообщение N-GET-RSP содержит поля, как определено в Таблица 10.3-4 and Приложение C. Каждое поле должно соответствовать кодированию DICOM и представлению значений, как определено в PS3.5. Поля обязательны, как указано в N-GET определении службы, если не указано иное в Таблица 10.3-4. Поля, не указанные в N-GET определении службы, но присутствующие в Таблица 10.3-4 требуются протоколом DIMSE-N.

Таблица 10.3-4. Поля сообщения N-GET-RSP

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Affected SOP Class UID	(0000,0002)	UI	1	UID SOP Class экземпляра SOP, для которого возвращаются значения атрибутов.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-N, передаваемую этим сообщением. Значение этого поля должно быть установлено в 8110H для сообщения N-GET-RSP.
Message ID Being Responded To	(0000,0120)	US	1	Должен быть установлен в значение поля Message ID (0000,0110), использованного в связанном сообщении N-GET-RQ.
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, присутствует ли набор данных в сообщении. Это поле должно быть установлено в значение 0101H, если набор данных отсутствует; любое другое значение указывает, что набор данных включён в сообщение.
Status	(0000,0900)	US	1	Значение этого поля зависит от типа состояния. Приложение C определяет кодирование типов состояния, определённых в определении службы.
Affected SOP Instance UID	(0000,1000)	UI	1	Содержит UID экземпляра SOP, для которого возвращаются значения атрибутов.
Attribute List	(no tag)	-	-	Это поле кодируется как набор данных. Один элемент данных кодируется для каждого возвращённого значения атрибута.

Примечание

Допустимое содержимое Attribute List, закодированное как последовательность элементов данных, определяется в Information Object Definition (PS3.3) и спецификациях класса службы (PS3.4).

10.3.2.3 Процедуры протокола N-GET

Процедуры N-GET инициируются инициирующим пользователем службы DIMSE, выдающим примитив N-GET Request. При получении примитива N-GET Request конечный автомат протокола DIMSE-N должен:

создать сообщение, передающее N-GET-RQ
отправить сообщение, используя службу запросов P-DATA (см. 8.1)

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

При получении примитива ответа N-GET, выданного выполняющим пользователем службы DIMSE, конечный автомат протокола DIMSE-N должен:

создать сообщение, передающее N-GET-RSP
отправить сообщение, используя службу запросов P-DATA (см. 8.1)

При получении сообщения, передающего N-GET-RSP, конечный автомат протокола DIMSE-N должен выдать примитив подтверждения N-GET инициирующему пользователю службы DIMSE, тем самым завершая процедуру N-GET.

10.3.3 Протокол N-SET

Информация, необходимая для примитивов DIMSE-N N-SET Request и N-SET Indication, передаётся в сообщении N-SET-RQ. Информация, необходимая для примитивов DIMSE-N N-SET response и confirmation, передаётся в сообщении N-SET-RSP. Поля, не указанные в определении службы N-SET, но присутствующие в Таблица 10.3-3 требуются протоколом DIMSE-N.

10.3.3.1 N-SET-RQ

Сообщение N-SET-RQ содержит поля, как определено в Таблица 10.3-5. Каждое поле должно соответствовать кодированию DICOM и представлению значений, как определено в PS3.5. Поля обязательны, как указано в N-SET определении службы, если не указано иное в Таблица 10.3-5. Поля, не указанные в N-SET определении службы, но присутствующие в Таблица 10.3-5 требуются протоколом DIMSE-N.

Таблица 10.3-5. Поля сообщения N-SET-RQ

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Requested SOP Class UID	(0000,0003)	UI	1	UID SOP Class экземпляра SOP, для которого должны быть изменены значения атрибутов.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-N, передаваемую этим сообщением. Значение этого поля должно быть установлено в 0120H для сообщения N-SET-RQ.
Message ID	(0000,0110)	US	1	Зависящее от реализации значение, отличающее это сообщение от других сообщений.
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, что набор данных присутствует в сообщении. Он должен быть установлен в любое значение, отличное от 0101H (Null).
Requested SOP Instance UID	(0000,1001)	UI	1	Содержит UID экземпляра SOP, для которого должны быть изменены значения атрибутов.
Modification List	(no tag)	-	-	Это поле кодируется как набор данных. Один элемент данных кодируется для каждого атрибута и значения атрибута, применимых к операции.

Примечание

Допустимое содержимое Modification List, закодированное как последовательность элементов данных, определяется в Information Object Definition (PS3.3) и спецификациях класса службы (PS3.4).

10.3.3.2 N-SET-RSP

Сообщение N-SET-RSP содержит все поля, как определено в Таблица 10.3-6 и в Приложение C. Каждое поле должно соответствовать кодированию DICOM и представлению значений, как определено в PS3.5. Поля обязательны, как указано в N-SET определении службы, если не указано иное. Поля, не указанные в N-SET определении службы, но присутствующие в Таблица 10.3-6 требуются протоколом DIMSE-N.

Таблица 10.3-6. Поля сообщения N-SET-RSP

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Affected SOP Class UID	(0000,0002)	UI	1	UID SOP Class экземпляра SOP, для которого были изменены значения атрибутов.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-N, передаваемую этим сообщением. Значение этого поля должно быть установлено в 8120H для сообщения N-SET-RSP.
Message ID Being Responded To	(0000,0120)	US	1	Должен быть установлен в значение поля Message ID (0000,0110), использованного в связанном сообщении N-SET-RQ.
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, присутствует ли набор данных в сообщении. Это поле должно быть установлено в значение 0101H, если набор данных отсутствует; любое другое значение указывает, что набор данных включён в сообщение.
Status	(0000,0900)	US	1	Значение этого поля зависит от типа состояния. Приложение C определяет кодирование типов состояния, определённых в определении службы.
Affected SOP Instance UID	(0000,1000)	UI	1	Содержит UID экземпляра SOP, для которого были изменены значения атрибутов.
Attribute List	(no tag)	-	-	Это поле кодируется как набор данных. Один элемент данных кодируется для каждого атрибута и значения атрибута, применимых к операции.

Примечание

10.3.3.3 Процедуры протокола N-SET

Процедуры N-SET инициируются инициирующим пользователем службы DIMSE, выдающим примитив N-SET Request. При получении примитива N-SET Request конечный автомат протокола DIMSE-N должен:

создать сообщение, передающее N-SET-RQ
отправить сообщение, используя службу запросов P-DATA (см. 8.1)

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

При получении примитива ответа N-SET, выданного выполняющим пользователем службы DIMSE, конечный автомат протокола DIMSE-N должен:

создать сообщение, передающее N-SET-RSP
отправить сообщение, используя службу запросов P-DATA (см. 8.1)

При получении сообщения, передающего N-SET-RSP, конечный автомат протокола DIMSE-N должен выдать примитив подтверждения N-SET инициирующему пользователю службы DIMSE, тем самым завершая процедуру N-SET.

Выполняющий пользователь службы DIMSE может вернуть N-SET-RSP со статусом Failed или Refused до того, как полное сообщение запроса N-SET-RQ будет полностью передано инициирующим пользователем службы DIMSE (это называется ранним ответом об ошибке). При получении этого N-SET-RSP со статусом Failed или Refused инициирующий пользователь службы DIMSE может завершить сообщение до его полной отправки (т.е. установить бит Last Fragment в 1 в Data PDV для этого сообщения, см. Приложение F). После этого он может инициировать другую операцию или уведомление. Нарушением протокола является установка инициирующим пользователем службы DIMSE бита Last Fragment в 1 до полной передачи сообщения N-SET-RQ, если он не получил N-SET-RSP со статусом Failed или Refused на этот запрос.

Примечание

10.3.4 Протокол N-ACTION

Информация, необходимая для примитивов DIMSE-N N-ACTION Request и N-ACTION Indication, передаётся в сообщении N-ACTION-RQ. Информация, необходимая для примитивов DIMSE-N N-ACTION response и confirmation, передаётся в сообщении N-ACTION-RSP.

10.3.4.1 N-ACTION-RQ

Сообщение N-ACTION-RQ содержит поля, как определено в Таблица 10.3-7. Каждое поле должно соответствовать кодированию DICOM и представлению значений, как определено в PS3.5. Поля обязательны, как указано в N-ACTION определении службы, если не указано иное в Таблица 10.3-7. Поля, не указанные в N-ACTION определении службы, но присутствующие в Таблица 10.3-7 требуются протоколом DIMSE-N.

Таблица 10.3-7. Поля сообщения N-ACTION-RQ

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Requested SOP Class UID	(0000,0003)	UI	1	UID SOP Class экземпляра SOP, для которого должно быть выполнено действие.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-N, передаваемую этим сообщением. Значение этого поля должно быть установлено в 0130H для сообщения N-ACTION-RQ.
Message ID	(0000,0110)	US	1	Зависящее от реализации значение, отличающее это сообщение от других сообщений.
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, присутствует ли набор данных в сообщении. Это поле должно быть установлено в значение 0101H, если набор данных отсутствует; любое другое значение указывает, что набор данных включён в сообщение.
Requested SOP Instance UID	(0000,1001)	UI	1	Содержит UID экземпляра SOP, для которого должно быть выполнено действие.
Action Type ID	(0000,1008)	US	1	Значения для этого поля зависят от приложения.
Action Information	(no tag)	-	-	Зависящий от приложения набор данных, содержащий дополнительную информацию, относящуюся к операции.

Примечание

Спецификации класса службы, содержащиеся в PS3.4 определяют значения, необходимые для параметра Action Type ID (0000,1008).
Спецификации класса службы, содержащиеся в PS3.4 определяют набор данных, необходимый для параметра Action Information.

10.3.4.2 N-ACTION-RSP

Сообщение N-ACTION-RSP содержит поля, как определено в Таблица 10.3-8 and Приложение C. Каждое поле должно соответствовать кодированию DICOM и представлению значений, как определено в PS3.5. Поля обязательны, как указано в N-ACTION определении службы, если не указано иное в Таблица 10.3-8. Поля, не указанные в N-ACTION определении службы, но присутствующие в Таблица 10.3-8 требуются протоколом DIMSE-N.

Таблица 10.3-8. Поля сообщения N-ACTION-RSP

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Affected SOP Class UID	(0000,0002)	UI	1	UID SOP Class экземпляра SOP, для которого было выполнено действие.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-N, передаваемую этим сообщением. Значение этого поля должно быть установлено в 8130H для сообщения N-ACTION-RSP.
Message ID Being Responded To	(0000,0120)	US	1	Должен быть установлен в значение поля Message ID (0000,0110), использованного в связанном сообщении N-ACTION-RQ.
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, присутствует ли набор данных в сообщении. Это поле должно быть установлено в значение 0101H, если набор данных отсутствует; любое другое значение указывает, что набор данных включён в сообщение.
Status	(0000,0900)	US	1	Значение этого поля зависит от типа состояния. Приложение C определяет кодирование типов состояния, определённых в определении службы.
Affected SOP Instance UID	(0000,1000)	UI	1	Содержит UID экземпляра SOP, для которого было выполнено действие.
Action Type ID	(0000,1008)	US	1	Значения для этого поля зависят от приложения.
Action Reply	(no tag)	-	-	Зависящий от приложения набор данных, содержащий дополнительную информацию, относящуюся к операции.

Примечание

Спецификации класса службы, содержащиеся в PS3.4 определяют значения, необходимые для параметра Action Type ID (0000,1008).
Спецификации класса службы, содержащиеся в PS3.4 определяют набор данных, необходимый для параметра Action Reply, относящегося к каждому определённому Action Type ID.
Спецификации класса службы, содержащиеся в PS3.4 определяют кодирование параметра Action Reply.

10.3.4.3 Процедуры протокола N-ACTION

Процедуры N-ACTION инициируются инициирующим пользователем службы DIMSE, выдающим примитив N-ACTION Request. При получении примитива N-ACTION Request конечный автомат протокола DIMSE-N должен:

создать сообщение, передающее N-ACTION-RQ
отправить сообщение, используя службу запросов P-DATA (см. 8.1)

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

При получении примитива ответа N-ACTION, выданного выполняющим пользователем службы DIMSE, конечный автомат протокола DIMSE-N должен:

создать сообщение, передающее N-ACTION-RSP
отправить сообщение, используя службу запросов P-DATA (см. 8.1)

При получении сообщения, передающего N-ACTION-RSP, конечный автомат протокола DIMSE-N должен выдать примитив подтверждения N-ACTION инициирующему пользователю службы DIMSE, тем самым завершая процедуру N-ACTION.

Выполняющий пользователь службы DIMSE может вернуть N-ACTION-RSP со статусом Failed или Refused до того, как полное сообщение запроса N-ACTION-RQ будет полностью передано инициирующим пользователем службы DIMSE (это называется ранним ответом об ошибке). При получении этого N-ACTION-RSP со статусом Failed или Refused инициирующий пользователь службы DIMSE может завершить сообщение до его полной отправки (т.е. установить бит Last Fragment в 1 в Data PDV для этого сообщения, см. Приложение F). После этого он может инициировать другую операцию или уведомление. Нарушением протокола является установка инициирующим пользователем службы DIMSE бита Last Fragment в 1 до полной передачи сообщения N-ACTION-RQ, если он не получил N-ACTION-RSP со статусом Failed или Refused на этот запрос.

Примечание

10.3.5 Протокол N-CREATE

Информация, необходимая для примитивов DIMSE-N N-CREATE Request и N-CREATE Indication, передаётся в сообщении N-CREATE-RQ. Информация, необходимая для примитивов DIMSE-N N-CREATE response и confirmation, передаётся в сообщении N-CREATE-RSP.

10.3.5.1 N-CREATE-RQ

Сообщение N-CREATE-RQ содержит поля, как определено в Таблица 10.3-9. Каждое поле должно соответствовать кодированию DICOM и представлению значений, как определено в PS3.5. Поля обязательны, как указано в N-CREATE определении службы, если не указано иное в Таблица 10.3-9. Поля, не указанные в N-CREATE определении службы, но присутствующие в Таблица 10.3-9 требуются протоколом DIMSE-N.

Таблица 10.3-9. Поля сообщения N-CREATE-RQ

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Affected SOP Class UID	(0000,0002)	UI	1	UID SOP Class экземпляра SOP, который должен быть создан.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-N, передаваемую этим сообщением. Значение этого поля должно быть установлено в 0140H для сообщения N-CREATE-RQ.
Message ID	(0000,0110)	US	1	Зависящее от реализации значение, отличающее это сообщение от других сообщений.
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, присутствует ли набор данных в сообщении. Это поле должно быть установлено в значение 0101H, если набор данных отсутствует; любое другое значение указывает, что набор данных включён в сообщение.
Affected SOP Instance UID	(0000,1000)	UI	1	Содержит UID экземпляра SOP, который должен быть создан.
Attribute List	(no tag)	-	-	Это поле кодируется как набор данных. Один элемент данных кодируется для каждого атрибута и значения атрибута, применимых к операции.

Примечание

10.3.5.2 N-CREATE-RSP

Сообщение N-CREATE-RSP содержит поля, как определено в Таблица 10.3-10 and Приложение C. Каждое поле должно соответствовать кодированию DICOM и представлению значений, как определено в PS3.5. Поля обязательны, как указано в N-CREATE определении службы, если не указано иное в Table10.3-10. Поля, не указанные в N-CREATE определении службы, но присутствующие в Таблица 10.3-10 требуются протоколом DIMSE-N.

Таблица 10.3-10. Поля сообщения N-CREATE-RSP

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Affected SOP Class UID	(0000,0002)	UI	1	UID SOP Class экземпляра SOP, который был создан.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-N, передаваемую этим сообщением. Значение этого поля должно быть установлено в 8140H для сообщения N-CREATE-RSP.
Message ID Being Responded To	(0000,0120)	US	1	Должен быть установлен в значение поля Message ID (0000,0110), использованного в связанном сообщении N-CREATE-RQ.
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, присутствует ли набор данных в сообщении. Это поле должно быть установлено в значение 0101H, если набор данных отсутствует; любое другое значение указывает, что набор данных включён в сообщение.
Status	(0000,0900)	US	1	Значение этого поля зависит от типа состояния. Приложение C определяет кодирование типов состояния, определённых в определении службы.
Affected SOP Instance UID	(0000,1000)	UI	1	Содержит UID экземпляра SOP, который был создан.
Attribute List	(no tag)	-	-	Это поле кодируется как набор данных. Один элемент данных кодируется для каждого атрибута и значения атрибута, применимых к операции.

Примечание

10.3.5.3 Процедуры протокола N-CREATE

Процедуры N-CREATE инициируются инициирующим пользователем службы DIMSE, выдающим примитив N-CREATE Request. При получении примитива N-CREATE Request конечный автомат протокола DIMSE-N должен:

создать сообщение, передающее N-CREATE-RQ
отправить сообщение, используя службу запросов P-DATA (см. 8.1)

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

При получении примитива ответа N-CREATE, выданного выполняющим пользователем службы DIMSE, конечный автомат протокола DIMSE-N должен:

создать сообщение, передающее N-CREATE-RSP
отправить сообщение, используя службу запросов P-DATA (см. 8.1)

При получении сообщения, передающего N-CREATE-RSP, конечный автомат протокола DIMSE-N должен выдать примитив подтверждения N-CREATE инициирующему пользователю службы DIMSE, тем самым завершая процедуру N-CREATE.

Выполняющий пользователь службы DIMSE может вернуть N-CREATE-RSP со статусом Failed или Refused до того, как полное сообщение запроса N-CREATE-RQ будет полностью передано инициирующим пользователем службы DIMSE (это называется ранним ответом об ошибке). При получении этого N-CREATE-RSP со статусом Failed или Refused инициирующий пользователь службы DIMSE может завершить сообщение до его полной отправки (т.е. установить бит Last Fragment в 1 в Data PDV для этого сообщения, см. Приложение F). После этого он может инициировать другую операцию или уведомление. Нарушением протокола является установка инициирующим пользователем службы DIMSE бита Last Fragment в 1 до полной передачи сообщения N-CREATE-RQ, если он не получил N-CREATE-RSP со статусом Failed или Refused на этот запрос.

Примечание

10.3.6 Протокол N-DELETE

Информация, необходимая для примитивов DIMSE-N N-DELETE Request и N-DELETE Indication, передаётся в сообщении N-DELETE-RQ. Информация, необходимая для примитивов DIMSE-N N-DELETE response и confirmation, передаётся в сообщении N-DELETE-RSP.

10.3.6.1 N-DELETE-RQ

Сообщение N-DELETE-RQ содержит поля, как определено в Таблица 10.3-11. Каждое поле должно соответствовать кодированию DICOM и представлению значений, как определено в PS3.5. Поля обязательны, как указано в N-DELETE определении службы, если не указано иное в Таблица 10.3-11. Поля, не указанные в N-DELETE определении службы, но присутствующие в Таблица 10.3-11 требуются протоколом DIMSE-N.

Таблица 10.3-11. Поля сообщения N-DELETE-RQ

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Requested SOP Class UID	(0000,0003)	UI	1	UID SOP Class экземпляра SOP, который должен быть удалён.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-N, передаваемую этим сообщением. Значение этого поля должно быть установлено в 0150H для сообщения N-DELETE-RQ.
Message ID	(0000,0110)	US	1	Зависящее от реализации значение, отличающее это сообщение от других сообщений.
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, что набор данных отсутствует в сообщении. Оно должно быть установлено в значение 0101H.
Requested SOP Instance UID	(0000,1001)	UI	1	Содержит UID экземпляра SOP, который должен быть удалён.

10.3.6.2 N-DELETE-RSP

Сообщение N-DELETE-RSP содержит поля, как определено в Таблица 10.3-12 and Приложение C. Каждое поле должно соответствовать кодированию DICOM и представлению значений, как определено в PS3.5. Поля обязательны, как указано в N-DELETE определении службы, если не указано иное в Таблица 10.3-12. Поля, не указанные в N-DELETE определении службы, но присутствующие в Таблица 10.3-12 требуются протоколом DIMSE-N.

Таблица 10.3-12. Поля сообщения N-DELETE-RSP

Поле сообщения	Тег	VR	VM	Описание поля
Command Group Length	(0000,0000)	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
Affected SOP Class UID	(0000,0002)	UI	1	UID SOP Class экземпляра SOP, который был удалён.
Command Field	(0000,0100)	US	1	Это поле различает операцию DIMSE-N, передаваемую этим сообщением. Значение этого поля должно быть установлено в 8150H для сообщения N-DELETE-RSP.
Message ID Being Responded To	(0000,0120)	US	1	Должен быть установлен в значение поля Message ID (0000,0110), использованного в связанном сообщении N-DELETE-RQ.
Command Data Set Type	(0000,0800)	US	1	Это поле указывает, что набор данных отсутствует в сообщении. Это поле должно быть установлено в значение 0101H).
Status	(0000,0900)	US	1	Значение этого поля зависит от типа состояния. Приложение C определяет кодирование типов состояния, определённых в определении службы.
Affected SOP Instance UID	(0000,1000)	UI	1	Содержит UID экземпляра SOP, который был удалён.

10.3.6.3 Процедуры протокола N-DELETE

Процедуры N-DELETE инициируются инициирующим пользователем службы DIMSE, выдающим примитив N-DELETE Request. При получении примитива N-DELETE Request конечный автомат протокола DIMSE-N должен:

создать сообщение, передающее N-DELETE-RQ
отправить сообщение, используя службу запросов P-DATA (см. 8.1)

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

При получении примитива ответа N-DELETE, выданного выполняющим пользователем службы DIMSE, конечный автомат протокола DIMSE-N должен:

создать сообщение, передающее N-DELETE-RSP
отправить сообщение, используя службу запросов P-DATA (см. 8.1)

При получении сообщения, передающего N-DELETE-RSP, конечный автомат протокола DIMSE-N должен выдать примитив подтверждения N-DELETE инициирующему пользователю службы DIMSE, тем самым завершая процедуру N-DELETE.

A Использование контекста приложения (Нормативное)

A.1 Определение контекста приложения

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

Две прикладные сущности устанавливают ассоциацию, согласовывая контекст приложения. Инициатор запроса ассоциации предлагает имя контекста приложения, а акцептор возвращает либо то же, либо другое имя контекста приложения. Возвращённое имя определяет контекст приложения, который будет использоваться для данной ассоциации. Предложение альтернативного контекста приложения акцептором обеспечивает механизм ограниченного согласования. Если инициатор запроса не может работать в контексте приложения акцептора, он должен выдать примитив запроса A-Abort. Такое согласование будет способствовать внедрению новых версий протокола обмена сообщениями DICOM в будущем.

A.2 Кодирование и регистрация имени контекста приложения DICOM

Структура имени контекста приложения основана на идентификации объектов OSI (числовая форма), определённой стандартом ISO 8824. Конкретные правила определены в PS3.5. Имена контекста приложения являются зарегистрированными значениями, определёнными ISO 9834-1 для обеспечения глобальной уникальности. Имена контекста приложения должны кодироваться, как определено в PS3.8.

A.2.1 Зарегистрированные имена контекста приложения DICOM

Организация, ответственная за определение и регистрацию имён контекста приложения DICOM, — это ACR-NEMA. ACR-NEMA гарантирует уникальность всех имён контекста приложения DICOM. Выбор зарегистрированных имён контекста приложения DICOM, связанных с конкретной версией DIMSE, а также соответствующие правила согласования определены в этом приложении.

Единое имя контекста приложения DICOM определено для данной версии этого Стандарта. Это имя — «1.2.840.10008.3.1.1.1»

A.2.2 Частные имена контекста приложения

Частные имена контекста приложения также могут использоваться, но они не будут регистрироваться ACR-NEMA. Организации, определяющие частные имена контекста приложения, несут ответственность за получение их надлежащей регистрации, как это определено для идентификаторов объектов OSI. Национальные организации по стандартизации, представляющие ряд стран (например, Великобритания, Франция, Германия, Япония, США и т. д.) в Международной организации по стандартизации, выступают в качестве органа регистрации, определённого ISO 9834-1.

Примечание

Например, в США ANSI присваивает идентификаторы организаций любой подавшей запрос организации. Этот идентификатор состоит из серии из четырёх числовых элементов: 1 (идентифицирует ISO), 2 (идентифицирует ветвь организаций-членов ISO), 840 (идентифицирует ANSI как организацию-член ISO, представляющую США) и xxxxxx (идентифицирует конкретную организацию и выдаётся ANSI). Такой идентификатор может использоваться идентифицированной организацией в качестве корня, к которому она может добавить суффикс, состоящий из одного или нескольких числовых элементов. Идентифицированная организация принимает на себя ответственность за надлежащую регистрацию этих суффиксов для обеспечения уникальности.

Частные имена контекста приложения должны кодироваться, как определено в PS3.8. Идентификатор организации «1.2.840.10008» зарезервирован для DICOM и не должен использоваться для частных имён контекста приложения.

A.3 Инициализация ассоциации для прикладной сущности DICOM

Установление ассоциации включает два AE DICOM, один из которых является инициатором запроса ассоциации, а другой — акцептором ассоциации.

AE DICOM должен инициировать установление ассоциации с использованием службы запросов A-ASSOCIATE, определённой в PS3.8. Он должен предоставить информацию о прикладной ассоциации, как определено в Приложении D.

A.4 Операция/Уведомление для прикладной сущности DICOM

Операции и уведомления используются только в ассоциации. Они приводят к обмену сообщениями с использованием службы запросов P-DATA, определённой в PS3.8.

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

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

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

Примечание

Синхронный/асинхронный режим определяется в рамках одной прикладной сущности, а не в рамках ассоциации между двумя прикладными сущностями. Режим связи в ассоциации может быть двунаправленным, если это согласовано во время согласования ассоциации (т. е. одновременно поддерживаются и операции, и уведомления и т. д.). Ниже приведён пример синхронного режима: AE DICOM A может отправить запрос операции AE DICOM B, а AE DICOM B может отправить запрос уведомления AE DICOM A до ответа на запрос операции от AE A. Это считается синхронным режимом, поскольку каждый AE имеет только одну незавершённую операцию или уведомление.

Выбранный режим (синхронный или асинхронный) определяется во время установления ассоциации. Синхронный режим служит режимом по умолчанию и должен поддерживаться всеми AE DICOM. Асинхронный режим является необязательным, и максимальное количество незавершённых операций или уведомлений согласовывается во время установления ассоциации. Это согласование осуществляется с помощью структуры подэлемента окна асинхронных операций, определённой в Приложении D.

A.5 Разрыв ассоциации для AE DICOM

Только AE DICOM — инициатор запроса ассоциации может инициировать упорядоченное освобождение ассоциации. Это должно выполняться с использованием службы A-RELEASE, определённой в PS3.8.

AE DICOM — инициатор запроса ассоциации не должен освобождать ассоциацию до тех пор, пока все инициированные операции не будут подтверждены.

A.6 Аварийное прерывание ассоциации для AE DICOM

Любой из AE DICOM может инициировать внезапное завершение ассоциации. Это должно выполняться с использованием службы A-ABORT, определённой в PS3.8.

При получении или выдаче примитива службы A-ABORT AE DICOM — инициатор запроса ассоциации и AE DICOM — акцептор ассоциации должны считать любую незавершённую операцию неудачной.

Примечание

Службы ассоциации и службы представления, определённые в службе верхнего уровня в PS3.8, являются полностью соответствующим подмножеством служб, предоставляемых ACSE и уровнем представления OSI.

B Указатель UID имён контекста приложения (Информативное)

Изъято.

C Кодирование типа состояния (Нормативное)

Следующие разделы определяют кодирование типов состояний, поддерживаемых службами DIMSE. Применимость и семантика каждого типа состояния (т. е. предупреждение списка атрибутов и т. д.) определены в службах DIMSE. Каждый тип состояния отнесён к классу состояния и представляет определённое значение состояния в рамках класса состояния.

Примечание

Командный элемент Status (0000,0900) требуется для всех типов состояния.

Все коды состояния назначаются в соответствии со следующим соглашением о классах состояния:

Успех	0000
Предупреждение	0001 or Bxxx or 0107 or 0116
Ошибка	Axxx or Cxxx or 01xx (except 0107 and 0116) or 02xx
Отмена	FE00
Ожидание	FF00 and FF01

Коды состояния со значениями 01xx и 02xx зарезервированы для назначения стандартом DICOM. Эти коды состояния имеют стандартные значения состояния для служб DIMSE, которые не должны изменяться определением класса службы или реализацией.

Коды состояния со значениями Axxx, Bxxx и Cxxx могут назначаться стандартом DICOM или реализацией в соответствии с определением класса службы в PS3.4.

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

C.1 Класс успеха

Состояния в этом классе состояния передают, что операция/уведомление завершилась успешно.

C.1.1 Успех

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0000H.

C.2 Класс ожидания

Состояния в этом классе состояния передают, что операция/уведомление продолжается и ожидаются дополнительные состояния.

C.2.1 Ожидание

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля зависит от класса службы и определено в PS3.4.

C.3 Класс отмены

Состояния в этом классе состояния передают, что операция/уведомление была отменена.

C.3.1 Отмена

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в FE00H.

C.4 Класс предупреждения

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

C.4.1 Предупреждение

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля зависит от класса службы и определено в PS3.4.
Offending Element	(0000,0901)	AT	1-n	Это необязательное поле содержит список элементов, в которых была обнаружена ошибка.
Error Comment	(0000,0902)	LO	1	Это необязательное поле содержит специфическое для приложения текстовое описание обнаруженной ошибки. Примечание Могут использоваться только символы из репертуара символов по умолчанию.

C.4.2 Предупреждение списка атрибутов

Поле состояния	Тег	VR	VM	Описание поля
Affected SOP Class UID	(0000,0002)	UI	1	Это необязательное поле содержит UID класса SOP, для которого атрибуты не были распознаны.
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0107H.
Affected SOP Instance UID	(0000,1000)	UI	1	Это необязательное поле содержит UID экземпляра SOP, для которого атрибуты не были распознаны.
Attribute Identifier List	(0000,1005)	AT	1-n	Это необязательное поле содержит тег атрибута для каждого атрибута, который не был распознан.

C.4.3 Значение атрибута вне диапазона

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0116H.
Modification List/Attribute List	(no tag)	-	-	Необязательно содержит специфический для приложения набор данных для кодирования только недействительных значений атрибутов, переданных в списке модификации N-SET-RQ или в списке атрибутов N-CREATE-RQ.

C.5 Класс ошибки

Состояния в этом классе состояния передают, что операция/уведомление завершилась неудачно и не была выполнена.

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

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля зависит от класса службы и определено в PS3.4.
Offending Element	(0000,0901)	AT	1-n	Это необязательное поле содержит список элементов, в которых была обнаружена ошибка.
Error Comment	(0000,0902)	LO	1	Это необязательное поле содержит зависящее от приложения текстовое описание обнаруженной ошибки. Примечание Могут использоваться только символы из репертуара символов по умолчанию.

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

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля зависит от класса службы и определено в PS3.4.
Offending Element	(0000,0901)	AT	1-n	Это необязательное поле содержит список элементов, в которых была обнаружена ошибка.
Error Comment	(0000,0902)	LO	1	Это необязательное поле содержит зависящее от приложения текстовое описание обнаруженной ошибки. Примечание Могут использоваться только символы из репертуара символов по умолчанию.

C.5.3 Сбой

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля зависит от класса службы и определено в PS3.4.
Offending Element	(0000,0901)	AT	1-n	Это необязательное поле содержит список элементов, в которых была обнаружена ошибка.
Error Comment	(0000,0902)	LO	1	Это необязательное поле содержит зависящее от приложения текстовое описание обнаруженной ошибки. Примечание Могут использоваться только символы из репертуара символов по умолчанию.

C.5.4 Отказано: получатель перемещения неизвестен

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля зависит от класса службы и определено в PS3.4.
Error Comment	(0000,0902)	LO	1	Это необязательное поле содержит зависящее от приложения текстовое описание обнаруженной ошибки. Примечание Могут использоваться только символы из репертуара символов по умолчанию.

C.5.5 Отказано: нехватка ресурсов

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля зависит от класса службы и определено в PS3.4.
Error Comment	(0000,0902)	LO	1	Это необязательное поле содержит зависящее от приложения текстовое описание обнаруженной ошибки. Примечание Могут использоваться только символы из репертуара символов по умолчанию.

C.5.6 Отказано: класс SOP не поддерживается

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0122H.
Error Comment	(0000,0902)	LO	1	Это необязательное поле содержит зависящее от приложения текстовое описание обнаруженной ошибки. Примечание Могут использоваться только символы из репертуара символов по умолчанию.

C.5.7 Конфликт класс-экземпляр

Поле состояния	Тег	VR	VM	Описание поля
Affected SOP Class UID	(0000,0002)	UI	1	Это необязательное поле содержит UID класса SOP, для которого экземпляр SOP не являлся членом.
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0119H.
Affected SOP Instance UID	(0000,1000)	UI	1	Это необязательное поле содержит экземпляр SOP, который не являлся членом указанного класса SOP.

C.5.8 Дубликат экземпляра SOP

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0111H.
Affected SOP Instance UID	(0000,1000)	UI	1	Это необязательное поле содержит UID экземпляра SOP, который уже был назначен другому экземпляру SOP.

C.5.9 Дублирующий вызов

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0210H.

C.5.10 Недопустимое значение аргумента

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0115H.
Affected SOP Class UID	(0000,0002)	UI	1	Это необязательное поле содержит UID класса SOP, для которого значение аргумента было ошибочным.
Affected SOP Instance UID	(0000,1000)	UI	1	Это необязательное поле содержит ID экземпляра SOP, для которого значение аргумента было ошибочным.
Event Type ID	(0000,1002)	US	1	Это необязательное поле содержит UID типа события, которое не было распознано. Разрешено только в N-EVENT-RSP.
Event Information	(no tag)	-	-	По выбору содержит зависящий от приложения набор данных только для кодирования недопустимых значений аргументов, переданных в информации о событии запроса. Разрешено только в N-EVENT-REPORT-RSP.
Action Type ID	(0000,1008)	US	1	Это необязательное поле содержит ID типа действия, которое не было распознано. Разрешено только в N-ACTION-RSP.
Action Information	(no tag)	-	-	По выбору содержит зависящий от приложения набор данных только для кодирования недопустимых значений аргументов, переданных в N-ACTION-RQ. Разрешено только в N-ACTION-RSP.

C.5.11 Недопустимое значение атрибута

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0106H.
Modification List/Attribute List	(no tag)	-	-	По выбору содержит зависящий от приложения набор данных только для кодирования недопустимых значений атрибутов, переданных в списке модификации N-SET-RQ или в списке атрибутов N-CREATE-RQ.

C.5.12 Недопустимый экземпляр SOP

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0117H.
Affected SOP Instance UID	(0000,1000)	UI	1	Это необязательное поле содержит UID экземпляра SOP, нарушивший правила построения UID.

C.5.13 Отсутствующий атрибут

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0120H.
Attribute Identifier List	(0000,1005)	AT	1-n	Это необязательное поле содержит тег атрибута для каждого нераспознанного атрибута.

C.5.14 Отсутствующее значение атрибута

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0121H.
Modification List/Attribute List	(no tag)	-	-	По выбору содержит зависящий от приложения набор данных только для кодирования отсутствующих значений атрибутов, переданных в списке модификации N-SET-RQ или в списке атрибутов N-CREATE-RQ..

C.5.15 Аргумент неверного типа

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0212H.

C.5.16 Нет такого аргумента

Поле состояния	Тег	VR	VM	Описание поля
Affected SOP Class UID	(0000,0002)	UI	1	Это необязательное поле может по выбору содержать UID класса SOP, для которого аргумент не существует.
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0114H.
Event Type ID	(0000,1002)	US	1	Это необязательное поле содержит ID типа события, для которого аргумент не существует. Разрешено только в N-EVENT-REPORT-RSP.
Action Type ID	(0000,1008)	US	1	Это необязательное поле содержит ID типа действия, для которого аргумент не существует. Разрешено только в N-ACTION-RSP.

C.5.17 Нет такого атрибута

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0105H.
Attribute Identifier List	(0000,1005)	AT	1-n	Это необязательное поле содержит тег атрибута для каждого нераспознанного атрибута.

C.5.18 Нет такого типа события

Поле состояния	Тег	VR	VM	Описание поля
Affected SOP Class UID	(0000,0002)	UI	1	Это необязательное поле содержит UID класса SOP, для которого тип события не существует.
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0113H.
Event Type ID	(0000,1002)	US	1	Это необязательное поле содержит ID типа события, которое не существует.

C.5.19 Нет такого экземпляра SOP

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0112H.
Affected SOP Instance UID	(0000,1000)	UI	1	Это необязательное поле содержит UID экземпляра SOP, который не существовал.

C.5.20 Нет такого класса SOP

Поле состояния	Тег	VR	VM	Описание поля
Affected SOP Class UID	(0000,0002)	UI	1	Это необязательное поле содержит UID класса SOP, который не существует.
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0118H.

C.5.21 Сбой обработки

Поле состояния	Тег	VR	VM	Описание поля
Affected SOP Class UID	(0000,0002)	UI	1	Это необязательное поле содержит UID класса SOP, в котором произошел сбой обработки.
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0110H.
Error Comment	(0000,0902)	LO	1	Это необязательное поле содержит зависящее от приложения текстовое описание обнаруженной ошибки. Примечание Могут использоваться только символы из репертуара символов по умолчанию.
Error ID	(0000,0903)	US	1	Это необязательное поле содержит зависящий от приложения код ошибки.
Affected SOP Instance UID	(0000,1000)	UI	1	Это необязательное поле может по выбору содержать UID экземпляра SOP, в котором произошел сбой обработки.

C.5.22 Ограничение ресурсов

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0213H.

C.5.23 Нераспознанная операция

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0211H.

C.5.24 Нет такого типа действия

Поле состояния	Тег	VR	VM	Описание поля
Affected SOP Class UID	(0000,0002)	UI	1	Это необязательное поле содержит UID класса SOP, для которого тип действия не существует.
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0123H.
Action Type ID	(0000,1008)	US	1	Это необязательное поле содержит ID типа действия, которое не существует.

C.5.25 Отказано: не авторизовано

Поле состояния	Тег	VR	VM	Описание поля
Status	(0000,0900)	US	1	Статус подтверждения операции. Значение этого обязательного поля должно быть установлено в 0124H.
Error Comment	(0000,0902)	LO	1	Это необязательное поле содержит зависящее от приложения текстовое описание обнаруженной ошибки. Примечание Могут использоваться только символы из репертуара символов по умолчанию.

D Согласование ассоциации (Нормативное)

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

D.1 Абстрактный синтаксис

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

Каждый абстрактный синтаксис должен идентифицироваться именем абстрактного синтаксиса в форме UID. Прикладные сущности DICOM используют имя абстрактного синтаксиса для идентификации и согласования того, какие классы SOP и связанные с ними параметры поддерживаются в конкретной ассоциации. Имена абстрактных синтаксисов должны быть определены в Определениях сервисных классов, указанных в PS3.4. Каждое определённое имя абстрактного синтаксиса должно иметь одно из следующих значений:

UID класса пары сервис-объект (SOP Class UID)
UID мета-группы пары сервис-объект (Meta SOP Group UID)

D.1.1 UID класса пары сервис-объект (SOP Class UID)

Каждое Определение сервисного класса определяет одно или несколько функционально связанных определений класса пары сервис-объект (SOP), которые задают чётко определённые операции и/или уведомления, которые могут выполняться между равноправными прикладными сущностями DICOM для обеспечения сервиса прикладного уровня. Каждый класс SOP, идентифицируемый UID класса SOP, определяется объединением одной информационной объектной дефиниции (IOD) и конкретного набора из одной или нескольких служб DIMSE, называемого Группой служб DIMSE (DSG) в данном

IOD определяет структуры данных
DSG определяет операции и/или уведомления, которые могут быть выполнены над этой структурой данных.

Два класса SOP, определённые одним Определением сервисного класса, могут различаться по IOD, DSG или обоим. Однако две различные IOD не должны быть частью одного и того же класса SOP. Ð Ð¸ÑÑÐ½Ð¾Ðº D.1-1 показывает взаимосвязи между сервисными классами, IOD, DSG и классами SOP.

Service Class, IOD, DSG and SOP Class Relationships

Рисунок D.1-1. Взаимосвязи сервисного класса, IOD, DSG и класса SOP

Примечание

Двумя примерами сервисных классов являются классы хранения (Storage) и управления исследованием (Study Management). Сервисный класс хранения относится к информационным объектным дефинициям изображений, таким как CT, MR и т.д., а сервисный класс управления исследованием относится к информационной объектной дефиниции исследования.
Для читателей, знакомых с терминологией OSI, понятие класса управляемого объекта (Managed Object Class) эквивалентно классу пары сервис-объект DICOM. Класс SOP определяет как данные (Атрибуты, определённые в информационной объектной дефиниции), так и методы (Операции и Уведомления (DSG), определённые в сервисном классе).

Устанавливая имя абстрактного синтаксиса в конкретное значение UID класса SOP, прикладные сущности DICOM могут согласовывать операции и/или уведомления сервисного класса для каждого определённого класса SOP индивидуально.

D.1.2 UID мета-группы пары сервис-объект (Meta SOP Group UID)

Каждое Определение сервисного класса может по выбору определять один или несколько мета-классов пары сервис-объект, каждый из которых идентифицируется UID мета-класса SOP. Каждый мета-класс SOP представляет объединение набора классов SOP, определённых в сервисном классе.

Устанавливая имя абстрактного синтаксиса в конкретное значение UID мета-класса SOP, прикладные сущности DICOM могут согласовывать операции и/или уведомления сервисного класса для набора определённых классов SOP с использованием единого абстрактного синтаксиса. Рисунок D.1-2 иллюстрирует это.

SOP Class UIDs and Meta SOP Class UIDs and Abstract Syntax Names

Рисунок D.1-2. UID классов SOP, UID мета-классов SOP и имена абстрактных синтаксисов

D.2 Синтаксисы передачи

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

D.3 Установка ассоциации

Установка ассоциации используется для согласования типа данных, подлежащих обмену, и способа кодирования данных. Прикладные сущности DICOM устанавливают ассоциации, используя службу ACSE A-ASSOCIATE, как определено в Части 8 стандарта DICOM. Тремя ключевыми параметрами, передаваемыми в службе A-ASSOCIATE, являются контекст приложения, контекст представления и элементы пользовательской информации. В следующем разделе обсуждаются эти параметры согласования.

Примечание: Служба A-ASSOCIATE выполняется только один раз во время установки ассоциации. Примеры, показанные в данном Разделе, разделяют параметры согласования исключительно в целях пояснения. Читателям следует помнить, что для каждой ассоциации предлагается только один запрос A-ASSOCIATE, и он содержит все параметры согласования.

D.3.1 Контекст приложения

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

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

Примечание

За полной спецификацией см. Приложение A.

D.3.2 Согласование контекстов представления

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

Контекст представления состоит из трёх компонентов: идентификатора контекста представления, имени абстрактного синтаксиса и списка из одного или нескольких имён синтаксисов передачи.

Только один абстрактный синтаксис должен предлагаться для каждого контекста представления. Однако для одного контекста представления может предлагаться несколько синтаксисов передачи, но только один должен быть принят.

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

Рисунок D.3-1 содержит иллюстрацию согласования контекстов представления со следующими ключевыми моментами:

инициатор ассоциации может предлагать несколько контекстов представления для каждой ассоциации;
каждый контекст представления поддерживает один абстрактный синтаксис (относящийся к классу SOP или мета-классу SOP) и один или несколько синтаксисов передачи;
акцептор ассоциации может принять или отклонить каждый контекст представления индивидуально;
акцептор ассоциации выбирает подходящий синтаксис передачи для каждого принятого контекста представления.

Рисунок D.3-1. Согласование контекстов представления

D.3.3 Информация об ассоциации прикладных сущностей DICOM

Равноправные прикладные сущности DICOM согласовывают при установке ассоциации ряд функций, связанных с протоколом DIMSE, используя элемент пользовательской информации ACSE в запросе A-ASSOCIATE. В данном Разделе обсуждаются эти функции.

Когда ассоциация устанавливается между равноправными пользователями служб DIMSE, предполагается базовая функциональная единица (Kernel Functional Unit); следовательно, базовая функциональная единица не должна включаться в элемент пользовательской информации A-ASSOCIATE.

D.3.3.1 Уведомление о максимальной длине PDU прикладного уровня

Уведомление о максимальной длине позволяет связывающимся прикладным сущностям ограничить размер данных для каждого индикатора P-DATA. Каждая прикладная сущность DICOM определяет максимальный размер PDU, который она может получить в данной ассоциации. Поэтому для каждого направления потока данных в ассоциации могут быть заданы различные максимальные длины. Это уведомление является обязательным. Рисунок D.3-2 иллюстрирует уведомление о максимальной длине.

Примечание

За полной спецификацией см. PS3.8.

Рисунок D.3-2. Согласование максимальной длины PDU

D.3.3.2 Уведомление об идентификации реализации

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

Идентификация реализации основывается на двух элементах информации:

UID класса реализации (обязательный)
Имя версии реализации (необязательный)

UID класса реализации уникальным образом идентифицирует конкретный класс реализации. Каждому узлу, заявляющему о соответствии настоящему стандарту, должен быть присвоен UID класса реализации, чтобы отличать его среду реализации от других. Такие UID классов реализации должны быть зарегистрированы реализующей организацией в соответствии с правилами, определёнными в PS3.5. Настоящий стандарт не определяет правила, связанные с назначением такого UID.

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

Уведомление инициаторами и акцепторами ассоциации их соответствующих UID классов реализации является обязательным для всех реализаций, соответствующих настоящему стандарту. Рисунок D.3-3 иллюстрирует уведомление об UID класса реализации.

Рисунок D.3-3. Уведомление об UID класса реализации

В дополнение к UID класса реализации предусмотрена возможность передать имя версии реализации длиной до 16 символов, которое идентифицирует версию реализации для UID класса реализации. Ð Ð¸ÑÑÐ½Ð¾Ðº D.3-4 иллюстрирует уведомление об имени версии реализации. Настоящий стандарт не определяет структуру и правила, связанные с таким именем версии реализации. Отсутствие имени версии реализации означает, что использование одного и того же UID класса реализации двумя узлами гарантирует, что они используют одну и ту же версию реализации.

Примечание

Поскольку UID не подлежит разбору (его структура не предназначена для передачи какой-либо семантической значимости, помимо уникальности), это необязательное имя версии реализации обеспечивает адекватный механизм для различения двух версий одной и той же реализации (один и тот же UID класса реализации).
Ожидается, что если имя версии реализации присутствует, оно будет включать информацию о версии в дополнение к имени реализации. Имя версии реализации должно быть более конкретным, чем UID класса реализации, и не менее; т.е. имя версии реализации не будет иметь то же значение при различных значениях UID класса реализации.

D.3.3.2.1 Структура подэлемента UID класса реализации (A-ASSOCIATE-RQ)

Подэлемент UID класса реализации должен состоять из последовательности обязательных полей фиксированной длины, за которыми следует переменное поле. Только один подэлемент UID класса реализации должен присутствовать в элементе пользовательских данных A-ASSOCIATE-RQ. Таблица D.3-1 показывает последовательность обязательных полей.

Implementation Version Name Notification

Рисунок D.3-4. Уведомление об имени версии реализации

Таблица D.3-1. Поля подэлемента UID класса реализации (A-ASSOCIATE-RQ)

Байты элемента	Имя поля	Описание поля
1	Item-type	52H
2	Reserved	Это зарезервированное поле должно отправляться со значением 00H, но не проверяться на это значение при получении.
3-4	Item-length	Эта длина элемента (Item-length) должна быть равна количеству байтов от первого байта следующего поля до последнего байта поля Implementation-class-uid. Оно должно кодироваться как беззнаковое двоичное число.
5-xxx	Implementation-class-uid	Это переменное поле должно содержать Implementation-class-uid инициатора ассоциации, как определено в Ð Ð°Ð·Ð´ÐµÐ» D.3.3.2. Поле Implementation-class-uid структурировано как UID, определённый в PS3.5.

D.3.3.2.2 Структура подэлемента UID класса реализации (A-ASSOCIATE-AC)

Подэлемент UID класса реализации должен состоять из последовательности обязательных полей фиксированной длины, за которыми следует переменное поле. Только один подэлемент UID класса реализации должен присутствовать в элементе пользовательских данных A-ASSOCIATE-AC. Таблица D.3-2 показывает последовательность обязательных полей.

Таблица D.3-2. Поля подэлемента UID реализации (A-ASSOCIATE-AC)

Байты элемента	Имя поля	Описание поля
1	Item-type	52H
2	Reserved	Это зарезервированное поле должно отправляться со значением 00H, но не проверяться на это значение при получении.
3-4	Item-length	Эта длина элемента (Item-length) должна быть равна количеству байтов от первого байта следующего поля до последнего байта поля Implementation-class-uid. Оно должно кодироваться как беззнаковое двоичное число.
5-xxx	Implementation-class-uid	Это переменное поле должно содержать Implementation-class-uid акцептора ассоциации, как определено в Ð Ð°Ð·Ð´ÐµÐ» D.3.3.2. Поле Implementation-class-uid структурировано как UID, определённый в PS3.5.

D.3.3.2.3 Структура имени версии реализации (A-ASSOCIATE-RQ)

Подэлемент имени версии реализации должен состоять из последовательности обязательных полей фиксированной длины, за которыми следует переменное поле. Только один подэлемент имени версии реализации должен присутствовать в элементе пользовательских данных A-ASSOCIATE-RQ. Таблица D.3-3 показывает последовательность обязательных полей.

Таблица D.3-3. Поля подэлемента имени версии реализации (A-ASSOCIATE-RQ)

Байты элемента	Имя поля	Описание поля
1	Item-type	55H
2	Reserved	Это зарезервированное поле должно отправляться со значением 00H, но не проверяться на это значение при получении.
3-4	Item-length	Эта длина элемента (Item-length) должна быть равна количеству байтов от первого байта следующего поля до последнего байта поля Implementation-version-name. Оно должно кодироваться как беззнаковое двоичное число.
5-xxx	Implementation-version-name	Это переменное поле должно содержать Implementation-version-name инициатора ассоциации, как определено в Ð Ð°Ð·Ð´ÐµÐ» D.3.3.2. Оно должно кодироваться как строка от 1 до 16 символов ISO 646:1990 (базовый набор G0).

D.3.3.2.4 Структура имени версии реализации (A-ASSOCIATE-AC)

Подэлемент имени версии реализации должен состоять из последовательности обязательных полей фиксированной длины, за которыми следует переменное поле. Только один подэлемент имени версии реализации должен присутствовать в элементе пользовательских данных A-ASSOCIATE-AC. Ð¢Ð°Ð±Ð»Ð¸ÑÐ° D.3-4 показывает последовательность обязательных полей.

Таблица D.3-4. Поля подэлемента имени версии реализации (A-ASSOCIATE-AC)

Байты элемента	Имя поля	Описание поля
1	Item-type	55H
2	Reserved	Это зарезервированное поле должно отправляться со значением 00H, но не проверяться на это значение при получении.
3-4	Item-length	Эта длина элемента (Item-length) должна быть равна количеству байтов от первого байта следующего поля до последнего байта поля Implementation-version-name. Оно должно кодироваться как беззнаковое двоичное число.
5-xxx	Implementation-version-name	Это переменное поле должно содержать Implementation-version-name акцептора ассоциации, как определено в Ð Ð°Ð·Ð´ÐµÐ» D.3.3.2. Оно должно кодироваться как строка от 1 до 16 символов ISO 646:1990 (базовый набор G0).

D.3.3.3 Согласование окна асинхронных операций (и подопераций)

Окно асинхронных операций используется для согласования максимального числа незавершённых запросов операций или подопераций (т.е. запросов команд) для каждого направления. Режим синхронных операций является режимом по умолчанию и должен поддерживаться всеми прикладными сущностями DICOM. Это согласование является необязательным.

Инициатор ассоциации передаёт в запросе A-ASSOCIATE:

при согласовании роли SCU для операций — максимальное количество незавершённых операций, которые он может вызывать асинхронно; при согласовании роли SCP для операций — максимальное количество незавершённых подопераций, которые он может вызывать асинхронно; при согласовании роли SCP для уведомлений — максимальное количество уведомлений, которые он может вызывать асинхронно
при согласовании роли SCP для операций — максимальное количество незавершённых операций, которые он может вызывать асинхронно; при согласовании роли SCU для операций — максимальное количество незавершённых подопераций, которые он может выполнять асинхронно; при согласовании роли SCU для уведомлений — максимальное количество уведомлений, которые он может выполнять асинхронно при согласовании роли SCP

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

Акцептор ассоциации передаёт в ответе A-ASSOCIATE:

при согласовании роли SCP для операций — максимальное количество незавершённых операций; при согласовании роли SCU для операций — максимальное количество подопераций, которые он разрешает инициатору ассоциации вызывать асинхронно; при согласовании роли SCU для уведомлений — максимальное количество незавершённых уведомлений, которые он разрешает инициатору ассоциации вызывать асинхронно при согласовании роли SCU. Это число должно быть меньше или равно количеству незавершённых уведомлений, операций и/или подопераций, которые инициатор ассоциации предлагает вызывать (посредством индикации A-ASSOCIATE).
при согласовании роли SCU для операций — максимальное количество незавершённых операций; при согласовании роли SCP для операций — максимальное количество подопераций, которые он разрешает инициатору ассоциации выполнять асинхронно; при согласовании роли SCP для уведомлений — максимальное количество незавершённых уведомлений, которые он разрешает инициатору ассоциации выполнять асинхронно. Это число должно быть меньше или равно количеству незавершённых уведомлений, операций и/или подопераций, которые инициатор ассоциации предлагает выполнять (посредством индикации A-ASSOCIATE).

Значение, равное нулю, указывает, что вышеуказанные параметры не ограничены. Если окно асинхронных операций отсутствует, значение по умолчанию для вышеуказанных параметров должно быть равно единице. Рисунки D.3-5 и D.3-6 иллюстрируют примеры согласования окна асинхронных операций.

Если это согласование отсутствует в индикации A-ASSOCIATE, оно должно быть опущено в ответе A-ASSOCIATE.

Примечание

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

Asynchronous Operations Window Negotiation (Window Being Negotiated Down By DICOM Application Entity "B")

Рисунок D.3-5. Согласование окна асинхронных операций (окно уменьшается прикладной сущностью DICOM "B")

Asynchronous Operations Window Negotiation (Window Being Defaulted to 1, 1 By DICOM Application Entity "B")

Рисунок D.3-6. Согласование окна асинхронных операций (окно устанавливается по умолчанию в 1, 1 прикладной сущностью DICOM "B")

D.3.3.3.1 Структура подэлемента окна асинхронных операций (A-ASSOCIATE-RQ)

Подэлемент окна асинхронных операций должен состоять из последовательности обязательных полей фиксированной длины. Этот подэлемент является необязательным, и в случае поддержки только один подэлемент окна асинхронных операций должен присутствовать в элементе пользовательских данных A-ASSOCIATE-RQ. Ð¢Ð°Ð±Ð»Ð¸ÑÐ° D.3-7 показывает последовательность обязательных полей.

Таблица D.3-7. Поля подэлемента окна асинхронных операций (A-ASSOCIATE-RQ)

Байты элемента	Имя поля	Описание поля
1	Item-type	53H
2	Reserved	Это зарезервированное поле должно отправляться со значением 00H, но не проверяться на это значение при получении.
3-4	Item-length	Эта длина элемента (Item-length) должна быть равна количеству байтов от первого байта следующего поля до последнего байта поля Maximum-number-operations-performed. В случае данного подэлемента она должна иметь фиксированное значение 00000004H encoded as an unsigned binary number.
5-6	Maximum-number-operations-invoked	Это поле должно содержать Maximum-number-operations-invoked, как определено для инициатора ассоциации в Ð Ð°Ð·Ð´ÐµÐ» D.3.3.3. Оно должно кодироваться как беззнаковое двоичное число.
7-8	Maximum-number-operations-performed	Это поле должно содержать Maximum-number-operations-performed, как определено для инициатора ассоциации в Ð Ð°Ð·Ð´ÐµÐ» D.3.3.3. Оно должно кодироваться как беззнаковое двоичное число.

D.3.3.3.2 Структура подэлемента окна асинхронных операций (A-ASSOCIATE-AC)

Подэлемент окна асинхронных операций должен состоять из последовательности обязательных полей фиксированной длины. Этот подэлемент является необязательным, и в случае поддержки только один подэлемент окна асинхронных операций должен присутствовать в элементе пользовательских данных A-ASSOCIATE-AC. Ð¢Ð°Ð±Ð»Ð¸ÑÐ° D.3-8 показывает последовательность обязательных полей.

Таблица D.3-8. Поля подэлемента окна асинхронных операций (A-ASSOCIATE-AC)

Байты элемента	Имя поля	Описание поля
1	Item-type	53H
2	Reserved	Это зарезервированное поле должно отправляться со значением 00H, но не проверяться на это значение при получении.
3-4	Item-length	Эта длина элемента (Item-length) должна быть равна количеству байтов от первого байта следующего поля до последнего байта поля Maximum-number-operations-performed. В случае данного подэлемента она должна иметь фиксированное значение 00000004H encoded as an unsigned binary number.
5-6	Maximum-number-operations-invoked	Это поле должно содержать Maximum-number-operations-invoked, как определено для акцептора ассоциации в Ð Ð°Ð·Ð´ÐµÐ» D.3.3.3 Оно должно кодироваться как беззнаковое двоичное число.
7-8	Maximum-number-operations-performed	Это поле должно содержать Maximum-number-operations-performed, как определено для акцептора ассоциации в Ð Ð°Ð·Ð´ÐµÐ» D.3.3.3. Оно должно кодироваться как беззнаковое двоичное число.

D.3.3.4 Согласование выбора роли SCP/SCU

Согласование выбора роли SCP/SCU позволяет равноправным прикладным сущностям согласовывать роли, в которых они будут выступать для каждого класса SOP или мета-класса SOP, поддерживаемого в ассоциации. Это согласование является необязательным.

Инициатор ассоциации для каждого UID класса SOP или UID мета-класса SOP может использовать один элемент выбора роли SCP/SCU. Класс SOP или мета-класс SOP должен идентифицироваться соответствующим именем абстрактного синтаксиса, за которым следует одно из трёх значений роли:

инициатор ассоциации — только SCU
инициатор ассоциации — только SCP
инициатор ассоциации — как SCU, так и SCP

Если элемент выбора роли SCP/SCU отсутствует, ролью инициатора ассоциации по умолчанию должна быть SCU, а ролью акцептора ассоциации по умолчанию должна быть SCP.

Акцептор ассоциации для каждого предложенного элемента выбора роли SCP/SCU либо принимает предложение инициатора ассоциации, возвращая то же значение (1), либо отклоняет предложение, возвращая значение (0). Акцептор ассоциации не должен возвращать значение (1), если инициатор ассоциации не предложил роль, т.е. отправил значение (0). Инициатор ассоциации должен игнорировать ответ, если он не предложил роль.

Если элемент выбора роли SCP/SCU не возвращён акцептором ассоциации, то ролью инициатора ассоциации должна быть SCU, а ролью акцептора ассоциации должна быть SCP. Рисунок D.3-7 иллюстрирует согласование выбора роли SCP/SCU.

Если элементы выбора роли SCP/SCU не существуют в индикации A-ASSOCIATE, они должны быть опущены в ответе A-ASSOCIATE.

Примечание

Выбор ролей по умолчанию основан на разъяснениях, внесённых в предыдущие версии стандарта. Инициаторы ассоциации, желающие предлагать имена абстрактных синтаксисов с использованием роли SCP, должны поддерживать этот элемент. Акцепторы ассоциации, желающие принимать имена абстрактных синтаксисов с использованием роли SCU, должны поддерживать этот элемент.
Если инициатор ассоциации предлагает элемент выбора роли SCP/SCU для имени абстрактного синтаксиса, но акцептор ассоциации не возвращает элемент выбора роли SCP/SCU для того же имени абстрактного синтаксиса, то предложенные роли не были приняты, и применяются роли по умолчанию (т.е. инициатор ассоциации — SCU, акцептор ассоциации — SCP).

Рисунок D.3-7. Согласование выбора роли SCU/SCP

Примечание

Прикладная сущность DICOM "B" принимает предложенную прикладной сущностью DICOM "A" роль SCU для Storage-MR SOP; следовательно, прикладная сущность DICOM "B" будет выступать в роли SCP. Прикладная сущность DICOM "B" отклоняет предложение роли SCP от прикладной сущности DICOM "A".
Обе прикладные сущности DICOM могут быть как SCU, так и SCP для Storage-CT SOP.
Прикладная сущность DICOM "B" принимает предложенную прикладной сущностью DICOM "A" роль SCU для Print-SOP; следовательно, прикладная сущность DICOM "B" будет выступать в роли SCP.

D.3.3.4.1 Структура подэлемента выбора роли SCP/SCU (A-ASSOCIATE-RQ)

Подэлемент выбора роли SCP/SCU должен состоять из последовательности обязательных полей. Этот подэлемент является необязательным, и в случае поддержки один или несколько подэлементов выбора роли SCP/SCU могут присутствовать в элементе пользовательских данных A-ASSOCIATE-RQ. Инициатор ассоциации может предложить только один подэлемент выбора роли SCP/SCU для каждого UID класса SOP или мета-класса SOP, присутствующего в запросе A-ASSOCIATE. Ð¢Ð°Ð±Ð»Ð¸ÑÐ° D.3-9 показывает последовательность обязательных полей.

Таблица D.3-9. Поля подэлемента выбора роли SCP/SCU (A-ASSOCIATE-RQ)

Байты элемента	Имя поля	Описание поля
1	Item-type	54H
2	Reserved	Это зарезервированное поле должно отправляться со значением 00H, но не проверяться на это значение при получении.
3-4	Item-length	Эта длина элемента (Item-length) должна быть равна количеству байтов от первого байта следующего поля до последнего байта поля SCP Role. Оно должно кодироваться как беззнаковое двоичное число.
5-6	UID-length	Эта длина UID (UID-length) должна быть равна количеству байтов от первого байта следующего поля до последнего байта поля SOP-class-uid. Оно должно кодироваться как беззнаковое двоичное число.
7 -xxx	SOP-class-uid	Это переменное поле должно содержать UID класса SOP или UID мета-класса SOP, который может использоваться для идентификации соответствующего абстрактного синтаксиса, к которому относится данный подэлемент. Оно должно кодироваться как UID, определённый в Ð Ð°Ð·Ð´ÐµÐ» 9 «Ð£Ð½Ð¸ÐºÐ°Ð»ÑÐ½ÑÐµ Ð¸Ð´ÐµÐ½ÑÐ¸ÑÐ¸ÐºÐ°ÑÐ¾ÑÑ (UID)» PS3.5.
xxx	SCU-role	Это байтовое поле должно содержать SCU-role, как определено для инициатора ассоциации в Ð Ð°Ð·Ð´ÐµÐ» D.3.3.4. Оно должно кодироваться как беззнаковое двоичное число и должно использовать одно из следующих значений: 0 - отсутствие поддержки роли SCU 1 - поддержка роли SCU
xxx	SCP-role	Это байтовое поле должно содержать SCP-role, как определено для инициатора ассоциации в Ð Ð°Ð·Ð´ÐµÐ» D.3.3.4. Оно должно кодироваться как беззнаковое двоичное число и должно использовать одно из следующих значений: 0 - отсутствие поддержки роли SCP 1 - поддержка роли SCP.

D.3.3.4.2 Структура подэлемента выбора роли SCP/SCU (A-ASSOCIATE-AC)

Таблица D.3-10. Поля подэлемента выбора роли SCP/SCU (A-ASSOCIATE-AC)

Байты элемента	Имя поля	Описание поля
1	Item-type	54H
2	Reserved	Это зарезервированное поле должно отправляться со значением 00H, но не проверяться на это значение при получении.
3-4	Item-length	Эта длина элемента (Item-length) должна быть равна количеству байтов от первого байта следующего поля до последнего байта поля SCP Role. Оно должно кодироваться как беззнаковое двоичное число.
5-6	UID-length	Эта длина UID (UID-length) должна быть равна количеству байтов от первого байта следующего поля до последнего байта поля SOP-class-uid. Оно должно кодироваться как беззнаковое двоичное число.
7-xxx	SOP-class-uid	Это переменное поле должно содержать UID класса SOP или UID мета-класса SOP, который может использоваться для идентификации соответствующего абстрактного синтаксиса, к которому относится данный подэлемент. Оно должно кодироваться как UID, определённый в Ð Ð°Ð·Ð´ÐµÐ» 9 «Ð£Ð½Ð¸ÐºÐ°Ð»ÑÐ½ÑÐµ Ð¸Ð´ÐµÐ½ÑÐ¸ÑÐ¸ÐºÐ°ÑÐ¾ÑÑ (UID)» PS3.5.
xxx	SCU-role	Это байтовое поле должно содержать SCU-role, как определено в Ð Ð°Ð·Ð´ÐµÐ» D.3.3.4. Оно должно кодироваться как беззнаковое двоичное число и должно использовать одно из следующих значений: 0 - Акцептор ассоциации отклоняет предложение инициатора ассоциации о выборе роли SCU 1 - Акцептор ассоциации принимает предложение инициатора ассоциации о выборе роли SCU
xxx	SCP-role	Это байтовое поле должно содержать SCP-role, как определено для акцептора ассоциации в Ð Ð°Ð·Ð´ÐµÐ» D.3.3.4. Оно должно кодироваться как беззнаковое двоичное число и должно использовать одно из следующих значений: 0 - Акцептор ассоциации отклоняет предложение инициатора ассоциации о выборе роли SCP 1 - Акцептор ассоциации принимает предложение инициатора ассоциации о выборе роли SCP

D.3.3.5 Расширенное согласование класса пары сервис-объект (SOP)

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

Каждая спецификация сервисного класса обязана документировать в рамках своего класса SOP или мета-класса SOP прикладную информацию, которую она поддерживает, и то, как эта информация согласовывается между SCU и SCP. Спецификации сервисных классов должны определять как для роли SCU, так и для роли SCP следующее:

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

Примечание

Использование расширенного согласования класса SOP не ограничивается сервисными классами, определёнными настоящим стандартом. Оно также может использоваться для частным образом определённых сервисных классов.

Инициатор ассоциации может предложить только один подэлемент расширенного согласования класса SOP для каждого UID класса SOP или мета-класса SOP, присутствующего в запросе A-ASSOCIATE.

Если подэлементы расширенного согласования класса SOP не существуют в индикации A-ASSOCIATE, они должны быть опущены в ответе A-ASSOCIATE.

D.3.3.5.1 Структура подэлемента расширенного согласования класса SOP (A-ASSOCIATE-RQ)

Подэлемент расширенного согласования класса SOP должен состоять из последовательности обязательных полей, за которыми следует поле Service-class-application-information (специфичное для каждой спецификации сервисного класса). Этот подэлемент требуется согласно конкретным спецификациям сервисного класса. В элементе пользовательских данных A-ASSOCIATE-RQ могут присутствовать несколько подэлементов расширенного согласования класса SOP, однако только один подэлемент на UID класса SOP должен присутствовать. Ð¢Ð°Ð±Ð»Ð¸ÑÐ° D.3-11 показывает последовательность обязательных полей.

Таблица D.3-11. Поля подэлемента расширенного согласования класса SOP (A-ASSOCIATE-RQ и A-ASSOCIATE-AC)

Байты элемента	Имя поля	Описание поля
1	Item-type	56H
2	Reserved	Это зарезервированное поле должно отправляться со значением 00H, но не проверяться на это значение при получении.
3-4	Item-Length	Эта длина элемента (Item-length) должна быть равна количеству байтов от первого байта следующего поля до последнего байта поля Service-class-application-information. Оно должно кодироваться как беззнаковое двоичное число.
5-6	SOP-class-uid-length	SOP-class-uid-length должна быть равна количеству байтов от первого байта следующего поля до последнего байта поля SOP-class-uid. Оно должно кодироваться как беззнаковое двоичное число.
7-xxx	SOP-class-uid	Идентификатор класса SOP или мета-класса SOP, закодированный как UID, определённый в Ð Ð°Ð·Ð´ÐµÐ» 9 «Ð£Ð½Ð¸ÐºÐ°Ð»ÑÐ½ÑÐµ Ð¸Ð´ÐµÐ½ÑÐ¸ÑÐ¸ÐºÐ°ÑÐ¾ÑÑ (UID)» PS3.5.
xxx-xxx	Service-class-application-information	Это поле должно содержать прикладную информацию, специфичную для спецификации сервисного класса, идентифицированной посредством SOP-class-uid. Семантика и значение этого поля определены в идентифицированной спецификации сервисного класса.

D.3.3.5.2 Структура подэлемента расширенного согласования класса SOP (A-ASSOCIATE-AC)

Подэлемент расширенного согласования класса SOP должен состоять из последовательности обязательных полей, за которыми следует поле Service-class-application-information (специфичное для каждой спецификации сервисного класса). Этот подэлемент требуется согласно конкретным спецификациям сервисного класса. В элементе пользовательских данных A-ASSOCIATE-AC могут присутствовать несколько подэлементов расширенного согласования класса SOP, однако только один подэлемент на UID класса SOP должен присутствовать. Ð¢Ð°Ð±Ð»Ð¸ÑÐ° D.3-11 показывает последовательность обязательных полей.

D.3.3.6 Общее расширенное согласование класса пары сервис-объект (SOP)

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

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

UID сервисного класса передаёт сервисный класс класса SOP.

Примечание

Явная передача сервисного класса может позволить выбор надлежащего формата для Service-class-application-information подэлемента расширенного согласования класса SOP.

UID связанного общего класса SOP передаёт ноль или более связанных общих классов SOP для класса SOP.

Примечание

Рассмотрим пример согласования поддержки для SOP класса хранения журнала процедур (Procedure Log Storage). Этот класс SOP относится к сервисному классу хранения (Storage). Кодирование IOD было бы совместимо с более общим классом SOP хранения Enhanced SR. Поэтому следующий подэлемент общего расширенного согласования мог бы быть включён по выбору:
- SOP Class UID: 1.2.840.10008.5.1.4.1.1.88.40 Procedure Log
- Service Class UID: 1.2.840.10008.4.2 Storage Service Class
- Related General SOP Class UID: 1.2.840.10008.5.1.4.1.1.88.22 Enhanced SR
Связанный класс SOP может отсутствовать, хотя сервисный класс всё ещё может быть включён. Например, может существовать новый класс SOP хранения изображений без связанного класса SOP, определённого в PS3.4, однако для акцептора ассоциации всё ещё полезно получить информацию о том, что новый класс SOP относится к сервисному классу хранения:
- SOP Class UID: 1.2.840.10008.5.1.4.1.1.7.1 MF Single Bit SC Image Storage
- Service Class UID: 1.2.840.10008.4.2 Storage Service Class
- Related General SOP Class UID: (отсутствует)

Инициатор ассоциации может предложить только один подэлемент общего расширенного согласования класса SOP для каждого UID класса SOP, присутствующего в запросе A-ASSOCIATE.

Ответ не требуется, поэтому подэлементы общего расширенного согласования класса SOP должны быть опущены в ответе A-ASSOCIATE.

D.3.3.6.1 Структура подэлемента общего расширенного согласования класса SOP (A-ASSOCIATE-RQ)

Подэлемент общего расширенного согласования класса SOP должен состоять из последовательности обязательных полей, последние два из которых могут иметь нулевую длину. В элементе пользовательских данных A-ASSOCIATE-RQ могут присутствовать несколько подэлементов общего расширенного согласования класса SOP, однако только один подэлемент на UID класса SOP должен присутствовать. Ð¢Ð°Ð±Ð»Ð¸ÑÐ° D.3-12 показывает последовательность обязательных полей.

Таблица D.3-12. Поля подэлемента общего расширенного согласования класса SOP (A-ASSOCIATE-RQ)

Байты элемента	Имя поля	Описание поля
1	Item-type	57H
2	Sub-Item-version	Это поле указывает версию подэлемента. Поля, добавленные к определению подэлемента в последующих редакциях стандарта, не повлияют на семантику ранее определённых полей. Версия подэлемента, определённая в настоящей редакции стандарта, — 0.
3-4	Item-Length	Эта длина элемента (Item-length) должна быть равна количеству байтов от первого байта следующего поля до последнего байта поля Reserved. Оно должно кодироваться как беззнаковое двоичное число.
5-6	SOP-class-uid-length	SOP-class-uid-length должна быть равна количеству байтов в поле SOP-class-uid. Оно должно кодироваться как беззнаковое двоичное число.
7-x	SOP-class-uid	Идентификатор класса SOP, закодированный как UID, определённый в Ð Ð°Ð·Ð´ÐµÐ» 9 «Ð£Ð½Ð¸ÐºÐ°Ð»ÑÐ½ÑÐµ Ð¸Ð´ÐµÐ½ÑÐ¸ÑÐ¸ÐºÐ°ÑÐ¾ÑÑ (UID)» PS3.5.
(x+1) - (x+2)	Service-class-uid-length	Service-class-uid-length должна быть равна количеству байтов в поле Service-class-uid. Оно должно кодироваться как беззнаковое двоичное число.
(x+3) - y	Service-class-uid	Идентификатор сервисного класса, закодированный как UID, определённый в Ð Ð°Ð·Ð´ÐµÐ» 9 «Ð£Ð½Ð¸ÐºÐ°Ð»ÑÐ½ÑÐµ Ð¸Ð´ÐµÐ½ÑÐ¸ÑÐ¸ÐºÐ°ÑÐ¾ÑÑ (UID)» PS3.5.
(y+1) - (y+2)	Related-general-sop-class-identification-length	Related-general-sop-class-identification-length должна быть равна количеству байтов в поле Related-general-sop-class-identification. Должна быть равна нулю, если не идентифицировано ни одного связанного общего класса SOP.
(y+3) - z	Related-general-sop-class-identification	Related-general-sop-class-identification представляет собой последовательность пар подполей длины и UID. Каждая пара подполей должна форматироваться в соответствии с Ð¢Ð°Ð±Ð»Ð¸ÑÐ° D.3-13
(z+1) - k	Reserved	Зарезервировано для дополнительных полей подэлемента. Должно иметь нулевую длину для Версии 0 определения подэлемента.

Таблица D.3-13. Подполя идентификации связанного общего класса SOP

Байты	Имя подполя	Описание подполя
1-2	Related-general-sop-class-uid-length	Related-general-sop-class-uid-length должна быть равна количеству байтов в подполе Related-general-sop-class-uid. Оно должно кодироваться как беззнаковое двоичное число.
3-n	Related-general-sop-class-uid	Идентификатор связанного общего класса SOP, закодированный как UID, определённый в Ð Ð°Ð·Ð´ÐµÐ» 9 «Ð£Ð½Ð¸ÐºÐ°Ð»ÑÐ½ÑÐµ Ð¸Ð´ÐµÐ½ÑÐ¸ÑÐ¸ÐºÐ°ÑÐ¾ÑÑ (UID)» PS3.5.

D.3.3.7 Согласование идентичности пользователя

Согласование идентичности пользователя используется для уведомления акцептора ассоциации об идентичности пользователя инициатора ассоциации. Оно также может запрашивать у акцептора ассоциации ответ с идентичностью сервера. Это согласование является необязательным. Если этот подэлемент отсутствует в запросе A-ASSOCIATE, ответ A-ASSOCIATE не должен содержать подэлемент ответа с идентичностью пользователя.

Инициатор ассоциации передаёт в запросе A-ASSOCIATE:

форму предоставляемой идентичности пользователя: имя пользователя, имя пользователя и пароль, сервисный билет Kerberos, утверждение SAML или JSON Web Token (JWT).
указание на то, запрашивается ли положительный ответ сервера.

Акцептор ассоциации не предоставляет ответ A-ASSOCIATE, если положительный ответ не запрошен и аутентификация пользователя не прошла успешно. Если положительный ответ был запрошен, ответ A-ASSOCIATE должен содержать подэлемент идентичности пользователя. Если используется билет Kerberos, ответ должен включать серверный билет Kerberos.

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

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

Примечание

Контроль авторизации идентичности пользователя может представлять собой простые правила "разрешить/запретить" или более сложные правила области действия. Например, запрос может быть ограничен применением только к возврату информации о пациентах, связанных с идентифицированным пользователем. Вопросы, связанные с контролем авторизации, могут быть очень сложными. Согласование идентичности пользователя передаёт идентичность пользователя для поддержки таких применений, как контроль авторизации и контроль аудита. Оно не определяет их поведение.
Возможность включения пароля вместе с идентичностью пользователя обеспечивает разнообразные защищённые интерфейсы без использования Kerberos. Отправка паролей в открытом виде небезопасна, но существуют системы одноразовых паролей, такие как [RFC2289] и различные смарт-токены, не требующие защиты. Пароль также может быть защищён с помощью TLS или других механизмов.
Для JSON Web Tokens (JWT) [RFC7519] указывает минимальные требования к алгоритмам шифрования, MAC и подписи; другие могут поддерживаться, как описано в Заявлении о соответствии DICOM. Закодированный формат в Primary-field запроса A-ASSOCIATE-RQ совпадает с тем, который может быть включён в поле заголовка HTTP Authorization: Bearer согласно [RFC6750] при доступе к защищённому ресурсу на сервере ресурсов. Если одни и те же механизмы доверия используются как DIMSE SCP, так и сервером ресурсов, содержимое Primary-field может совпадать со значением поля HTTP Authorization: Bearer, что устраняет необходимость преобразования содержимого.
Следует соблюдать осторожность, чтобы не включать излишнее защищённое содержимое из согласования идентичности пользователя в сообщения журнала аудита. Например, пароль, утверждение SAML и JSON Web Token (JWT) могут быть раскрыты, если включены в сообщение журнала. Для получения незащищённой информации об идентичности пользователя из утверждения SAML или JWT может потребоваться такая служба, как служба интроспекции OAuth ([RFC7662]).

User Identity Negotiation (With Server Positive Response Requested)

Рисунок D.3-8. Согласование идентичности пользователя (с запрошенным положительным ответом сервера)

User Identity Negotiation (Application Entity "A" Provides Username Identity)

Рисунок D.3-9. Согласование идентичности пользователя (прикладная сущность "A" предоставляет идентичность имени пользователя)

D.3.3.7.1 Структура подэлемента идентичности пользователя (A-ASSOCIATE-RQ)

Подэлемент согласования идентичности пользователя должен состоять из последовательности обязательных полей фиксированной и переменной длины. Этот подэлемент является необязательным, и в случае поддержки только один подэлемент согласования идентичности пользователя должен присутствовать в элементе пользовательских данных A-ASSOCIATE-RQ. Ð¢Ð°Ð±Ð»Ð¸ÑÐ° D.3-14 показывает последовательность обязательных полей.

Таблица D.3-14. Поля подэлемента согласования идентичности пользователя (A-ASSOCIATE-RQ)

Байты элемента	Имя поля	Описание поля
1	Item-type	58H
2	Reserved	Это зарезервированное поле должно отправляться со значением 00H, но не проверяться на это значение при получении.
3-4	Item-length	Эта длина элемента (Item-length) должна быть равна количеству байтов от первого байта следующего поля до последнего байта последнего отправленного поля. Оно должно кодироваться как беззнаковое двоичное число.
5	User-Identity-Type	Значение поля должно находиться в диапазоне от 1 до 5 со следующими значениями: 1 - Имя пользователя в виде строки в UTF-8 2 - Имя пользователя в виде строки в UTF-8 и пароль 3 - Сервисный билет Kerberos 4 - Утверждение SAML 5 - JSON Web Token (JWT) Другие значения зарезервированы для будущей стандартизации.
6	Positive-response-requested	Значение поля: 0 - ответ не запрашивается 1 - запрашивается положительный ответ
7-8	Primary-field-length	User-Identity-Length должна содержать длину значения User-Identity.
9-n	Primary-field	Это поле должно передавать идентичность пользователя: либо имя пользователя в виде последовательности символов, либо сервисный билет Kerberos, закодированный в соответствии с [RFC1510], либо JWT, закодированный в соответствии с [RFC7519] с использованием частей, закодированных в base64url.
n+1-n+2	Secondary-field-length	Это поле должно быть ненулевым, только если User-Identity-Type имеет значение 2. Оно должно содержать длину вторичного поля.
n+3-m	Secondary-field	Это поле должно присутствовать, только если User-Identity-Type имеет значение 2. Оно должно содержать значение пароля.

D.3.3.7.2 Структура подэлемента идентичности пользователя (A-ASSOCIATE-AC)

Подэлемент идентичности пользователя должен состоять из последовательности обязательных полей фиксированной и переменной длины. Этот подэлемент является необязательным, и в случае поддержки только один подэлемент идентичности пользователя должен присутствовать в элементе пользовательских данных A-ASSOCIATE-AC. Ð¢Ð°Ð±Ð»Ð¸ÑÐ° D.3-15 показывает последовательность обязательных полей.

Таблица D.3-15. Поля подэлемента согласования идентичности пользователя (A-ASSOCIATE-AC)

Байты элемента	Имя поля	Описание поля
1	Item-type	59H
2	Reserved	Это зарезервированное поле должно отправляться со значением 00H, но не проверяться на это значение при получении.
3-4	Item-length	Эта длина элемента (Item-length) должна быть равна количеству байтов от первого байта следующего поля до последнего байта последнего поля. Оно должно кодироваться как беззнаковое двоичное число.
5-6	Server-response-length	Это поле должно содержать количество байтов в Server-response. Может быть равно нулю.
7-n	Server-response	Это поле должно содержать серверный билет Kerberos, закодированный в соответствии с [RFC1510], если значение User-Identity-Type в A-ASSOCIATE-RQ было 3. Это поле должно содержать ответ SAML, если значение User-Identity-Type в A-ASSOCIATE-RQ было 4. Это поле должно иметь нулевую длину, если значение User-Identity-Type в A-ASSOCIATE-RQ было 1 или 2.

Если инициатор ассоциации запросил положительное подтверждение, Server-response должен быть возвращён с серверным билетом Kerberos, если User-Identity-Type — сервисный билет Kerberos (3).

D.3.3.7.3 Отклонение идентичности пользователя

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

Если акцептор ассоциации отклоняет ассоциацию из-за сбоя авторизации, отклонение должно быть указано как отклонение-постоянное (см. PS3.8). Источник должен быть значением (2) «предоставлена служба DICOM UL (функция, связанная с ACSE)». Отклонение указывается как отклонение-постоянное, поскольку повторные попытки с теми же полями идентичности пользователя будут продолжать отклоняться. Должно быть предоставлено другое и действительное имя пользователя, имя пользователя и пароль или билет Kerberos.

Настоящий стандарт не определяет, как акцептор ассоциации выполняет аутентификацию и какие правила применяются к этой аутентификации.

E Словарь команд (Нормативное)

E.1 Реестр командных элементов DICOM

Таблица E.1-1. Командные поля

Тег	Поле сообщения	Keyword	VR	VM	Описание поля
(0000,0000)	Command Group Length	CommandGroupLength	UL	1	Чётное количество байтов от конца поля значения до начала следующей группы.
(0000,0002)	Affected SOP Class UID	AffectedSOPClassUID	UI	1	Затронутый UID SOP Class, связанный с операцией.
(0000,0003)	Requested SOP Class UID	RequestedSOPClassUID	UI	1	Запрашиваемый UID SOP Class, связанный с операцией.
(0000,0100)	Command Field	CommandField	US	1	Это поле различает операцию DIMSE, передаваемую в данном сообщении. Значение этого поля должно быть установлено в одно из следующих значений: 0001H C-STORE-RQ 8001H C-STORE-RSP 0010H C-GET-RQ 8010H C-GET-RSP 0020H C-FIND-RQ 8020H C-FIND-RSP 0021H C-MOVE-RQ 8021H C-MOVE-RSP 0030H C-ECHO-RQ 8030H C-ECHO-RSP 0100H N-EVENT-REPORT-RQ 8100H N-EVENT-REPORT-RSP 0110H N-GET-RQ 8110H N-GET-RSP 0120H N-SET-RQ 8120H N-SET-RSP 0130H N-ACTION-RQ 8130H N-ACTION-RSP 0140H N-CREATE-RQ 8140H N-CREATE-RSP 0150H N-DELETE-RQ 8150H N-DELETE-RSP 0FFFH C-CANCEL-RQ
(0000,0110)	Message ID	MessageID	US	1	Зависящее от реализации значение, отличающее это сообщение от других сообщений.
(0000,0120)	Message ID Being Responded To	MessageIDBeingRespondedTo	US	1	Должен быть установлен в значение поля Message ID (0000,0110), использованного в соответствующем сообщении запроса.
(0000,0600)	Move Destination	MoveDestination	AE	1	Должно быть установлено в DICOM AE Title (заголовок AE) целевого DICOM AE, для которого выполняются подоперации C-STORE.
(0000,0700)	Priority	Priority	US	1	Приоритет должен быть установлен в одно из следующих значений: LOW = 0002H MEDIUM = 0000H HIGH = 0001H
(0000,0800)	Command Data Set Type	CommandDataSetType	US	1	Это поле указывает, присутствует ли набор данных в сообщении. Значение этого поля должно быть установлено в 0101H, если набор данных отсутствует; любое другое значение указывает, что набор данных включён в сообщение.
(0000,0900)	Status	Status	US	1	Подтверждающий статус операции. См. Приложение C.
(0000,0901)	Offending Element	OffendingElement	AT	1-n	Если состояние Cxxx, то это поле содержит список элементов, в которых была обнаружена ошибка.
(0000,0902)	Error Comment	ErrorComment	LO	1	Это поле содержит зависящее от приложения текстовое описание обнаруженной ошибки. Примечание Могут использоваться только символы из репертуара символов по умолчанию.
(0000,0903)	Error ID	ErrorID	US	1	Это поле может по выбору содержать зависящий от приложения код ошибки.
(0000,1000)	Affected SOP Instance UID	AffectedSOPInstanceUID	UI	1	Содержит UID экземпляра SOP, для которого выполнена данная операция.
(0000,1001)	Requested SOP Instance UID	RequestedSOPInstanceUID	UI	1	Содержит UID экземпляра SOP, для которого выполнена данная операция.
(0000,1002)	Event Type ID	EventTypeID	US	1	Значения для этого поля зависят от приложения.
(0000,1005)	Attribute Identifier List	AttributeIdentifierList	AT	1-n	Это поле содержит тег атрибута для каждого из n применимых атрибутов.
(0000,1008)	Action Type ID	ActionTypeID	US	1	Значения для этого поля зависят от приложения.
(0000,1020)	Number of Remaining Sub-operations	NumberOfRemainingSuboperations	US	1	Количество оставшихся подопераций C-STORE, которые должны быть вызваны для данной операции.
(0000,1021)	Number of Completed Sub-operations	NumberOfCompletedSuboperations	US	1	Количество подопераций C-STORE, связанных с данной операцией, которые завершились успешно.
(0000,1022)	Number of Failed Sub-operations	NumberOfFailedSuboperations	US	1	Количество подопераций C-STORE, связанных с данной операцией, которые завершились неудачно.
(0000,1023)	Number of Warning Sub-operations	NumberOfWarningSuboperations	US	1	Количество подопераций C-STORE, связанных с данной операцией, которые сформировали ответы с предупреждением.
(0000,1030)	Move Originator Application Entity Title	MoveOriginatorApplicationEntityTitle	AE	1	Содержит заголовок AE (DICOM AE Title) объекта DICOM AE, который вызвал операцию C-MOVE, в результате которой выполняется данная подоперация C-STORE.
(0000,1031)	Move Originator Message ID	MoveOriginatorMessageID	US	1	Содержит Message ID (0000,0110) сообщения C-MOVE-RQ, в результате которого выполняется данная подоперация C-STORE.

E.2 Изъятые командные поля

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

Таблица E.2-1. Изъятые командные поля

Тег	Поле сообщения	Keyword	VR	VM
(0000,0001)	Command Length to End	CommandLengthToEnd	UL	1
(0000,0010)	Command Recognition Code	CommandRecognitionCode	SH	1
(0000,0200)	Initiator	Initiator	AE	1
(0000,0300)	Receiver	Receiver	AE	1
(0000,0400)	Find Location	FindLocation	AE	1
(0000,0850)	Number of Matches	NumberOfMatches	US	1
(0000,0860)	Response Sequence Number	ResponseSequenceNumber	US	1
(0000,4000)	Dialog Receiver	DialogReceiver	LT	1
(0000,4010)	Terminal Type	TerminalType	LT	1
(0000,5010)	Message Set ID	MessageSetID	SH	1
(0000,5020)	End Message ID	EndMessageID	SH	1
(0000,5110)	Display Format	DisplayFormat	LT	1
(0000,5120)	Page Position ID	PagePositionID	LT	1
(0000,5130)	Text Format ID	TextFormatID	CS	1
(0000,5140)	Normal/Reverse	NormalReverse	CS	1
(0000,5150)	Add Gray Scale	AddGrayScale	CS	1
(0000,5160)	Borders	Borders	CS	1
(0000,5170)	Copies	Copies	IS	1
(0000,5180)	Command Magnification Type	CommandMagnificationType	CS	1
(0000,5190)	Erase	Erase	CS	1
(0000,51A0)	Print	Print	CS	1
(0000,51B0)	Overlays	Overlays	US	1-n

Примечание

Для атрибутов, которые присутствовали в ACR-NEMA 1.0 и 2.0 и были изъяты, спецификации представления значения и кратности значения являются рекомендациями для целей интерпретации их значений в объектах, созданных в соответствии с более ранними редакциями настоящего Стандарта. Эти рекомендации предлагаются как наиболее подходящие для конкретного атрибута; однако нет гарантии, что исторические объекты не будут нарушать некоторые требования или указанные VR и/или VM.

F Использование службы P-DATA прикладной сущностью DICOM (Нормативное)

То, как DICOM-сообщения инкапсулируются в службу P-DATA прикладной сущностью DICOM, описано в PS3.8.

Примечание

Ранее здесь дублировался текст, идентичный тексту в PS3.8.