Обмен документами между медицинскими учреждениями (стр. 5 )

Формат запроса «AdhocQueryRequest» приведен в 1.

Стандартным запросам транзакции ITI-18 «Запросить набор документов» профиля IHE XDS присвоены идентификаторы (Query IDs), указанные в таблице 6. Данные идентификаторы используются в параметре запроса (AdhocQueryRequest) для того, чтобы ссылаться на запрос, хранимый в Реестре документов (Document Registry). Идентификаторы имеют формат UUID. Параметры запросов приведены в

Если идентификатор не поддерживается, тогда должно возвращаться сообщение об ошибке.

Таблица 6 – Идентификаторы запросов

№	Наименование запроса	Идентификатор запроса
Найти документы (FindDocuments)	urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d
Найти наборы представления (FindSubmissionSets)	urn:uuid:f26abbcb-ac74-4422-8a30- edb644bbc1a9
Найти папки (FindFolders)	urn:uuid:958f3006-baad-4929-a4de-ff1114824431
Получить все (GetAll)	urn:uuid:10b545ea-725c-446d-9b95-8aeb444eddf3
Получить документы (GetDocuments)	urn:uuid:5c4f972b-d56b-40ac-a5fc-c8ca9b40b9d4
Получить папки (GetFolders)	urn:uuid:5737b14c-8a1a-4539-b659-e03a34a5e1e4
Получить связи/ассоциации (GetAssociations)	urn:uuid:a7ae438b-4bc2-4642-93e9-be891f7bb155
Получить документы и связи/ассоциации (GetDocumentsAndAssociations)	urn:uuid:bab9529a-4a10-40b3-a01f-f68a615d247a
Получить наборы представления (GetSubmissionSets)	urn:uuid:51224314-5390-4169-9b91-b1980040715a
Получить наборы представления и содержимое (GetSubmissionSetAndContents)	urn:uuid:e8e3cb2c-e39c-46b9-99e4-c12f57260b83
Получить папки и содержимое (GetFolderAndContents)	urn:uuid:b909a503-523d-4517-8acf-8e5834dfc4c7
Получить папки для документов (GetFoldersForDocument)	urn:uuid:10cae35a-c7f9-4cf5-b61e-fc3278ffb578
Получить связанные документы (GetRelatedDocuments)	urn:uuid:d90e5407-b356-4d91-a89f-873917b4b0e6
Найти документы по идентификатору (FindDocumentsByReferenceId)	urn:uuid:12941a89-e02e-4be5-967c-ce4bfc8fe492

Обработка

На рисунке 2

Рисунок 2 представлена диаграмма последовательности, отражающая обмен сообщениями в рамках транзакции ITI-18 «Запросить набор документов» (Registry Stored Query).

Рисунок 2 – Диаграмма последовательности транзакции ITI-18 «Запросить набор документов» (Registry Stored Query)

Основной сценарий:

Потребитель документов (Document Consumer) направляет запрос набора документов (Registry Stored Query) Реестру документов (Document Registry); Реестр документов (Document Registry) обрабатывает запрос и направляет ответ на запрос набора документов (RegistryStoredQueryResponse) Потребителю документов (Document Consumer).

Пример SOAP-запроса (RegistryStoredQueryRequest) Потребителя документов (Document Consumer) в рамках транзакции ITI-18 «Запросить набор документов» приведен в Приложении 1.1.

Пример SOAP-ответа (RegistryStoredQueryResponse) Реестра документов (Document Registry) в рамках транзакции ITI-18 «Запросить набор документов» приведен в Приложении 1.2.

Каждый выполняемый запрос и ответ транзакции ITI-18 «Запросить набор документов» (Registry Stored Query) должен сопровождаться отправкой сообщений аудита (Audit message) в Журнал регистрации событий в соответствии c требованиями транзакции ITI-20 «Записать в журнал событий» (Record Audit Event) профиля IHE ATNA [RF-5]. Структура сообщений аудита приведена в приложении Г.1.

Общие требования, ограничения и допущения к транзакции ITI-18 «Запросить набор документов» (Registry Stored Query) приведены в таблице 7.

Таблица 7 – Общие требования, ограничения и допущения к транзакции IHE XDS ITI-18 «Запросить набор документов» (Registry Stored Query)

Код	Требование, ограничение или допущение	Источник возникновения
Потребитель документов (Document Consumer) должен поддерживать асинхронные веб-сервисы (Asynchronous Web Services Exchange) для транзакций [ITI-18] и [ITI-43]	IHE ITI TF [RF-4] Vol2a, раздел 3.18
Реестр документов (Document Registry) должен поддерживать асинхронные веб-сервисы (Asynchronous Web Services Exchange) для транзакций [ITI-18] и [ITI-42]	IHE ITI TF [RF-4] Vol2a, раздел 3.18
Запрос набора документов (RegistryStoredQueryRequest) должен содержать: Ссылку на предопределенные запросы, хранящиеся в Реестре документов (Document Registry); Параметры запроса, которые должны соответствовать переменным запроса в определении запроса в Реестре документов (Document Registry)	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1
Значение даты/времени создания документа (XDSDocumentEntry. CreationTime) считается удовлетворяющим параметрам запроса при соблюдении условия:        «$XDSDocumentEntryCreationTimeFrom»        <= <=        «XDSDocumentEntry. CreationTime»        < <        «$XDSDocumentEntryCreationTimeTo», где «$XDSDocumentEntryCreationTimeFrom» - параметр запроса, определяющий нижнюю границу значения даты/времени создания документа, «$XDSDocumentEntryCreationTimeTo» - параметр запроса, определяющий верхнюю границу значения даты/времени создания документа.	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.3.3
Если атрибут «DocumentEntry. serviceStartTime» записи о документе (объекта «DocumentEntry») не содержит значения и запрос включает значение «$XDSDocumentEntryServiceStartTimeFrom» или «$XDSDocumentEntryServiceStartTimeTo», тогда эти параметры не должны быть использованы для определения, соответствует ли запросу данная запись о документе (объект «DocumentEntry»).	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.3.3.1
Если атрибут «DocumentEntry. serviceStopTime» записи о документе (объекта «DocumentEntry») не содержит значения и запрос включает значение «$XDSDocumentEntryServiceStopTimeFrom» или «$XDSDocumentEntryServiceStopTimeTo», тогда эти параметры не должны быть использованы для определения, соответствует ли запросу данный «DocumentEntry»	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.3.3.1
	При определении параметра, содержащего кодированное значение, необходимо использовать сокращенную форму формата HL7 V2.5 CE. Только первый (идентификатор) и третий (схема кодирования) элементы должны быть указаны обязательно. Второй элемент должен быть пустым. Ограничения длины HL7 V2.5 не должны применяться. Пример формата приведен ниже: code^^coding-scheme Этот параметр может принимать несколько значений, таким образом, пример кодирования в рамках параметра «Slot» выглядит следующим образом: <Value>('code1^^coding-scheme1')</Value> или <Value>('code1^^coding-scheme1','code2^^coding-scheme2')</Value>	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.3.4
	Должны соблюдаться следующие правила: числа  записываются без кавычек, например: 123; строки записываются с одинарными кавычками, например: ‘urn:oasis:names:tc:ebxml-regrep:StatusType:Approved’; одинарные кавычки в составе строки обозначаются двумя одинарными кавычками, например: ‘Children’’s Hospital’. В предикате LIKE: нижнее подчеркивание (‘_’) соответствует произвольному символу; знак процента (‘%’) соответствует произвольной строке. Формат для множественных значений: (value, value, value, ...) или (value), если указано только одно значение. При кодировании множественных значений может возникнуть потенциальный конфликт между необходимостью кодирования длинного списка значений и ограничением длины схемы на размер значения элемента <Value/>. Значение «Slot» никогда не должно превышать обозначенные схемой ограничения. Таким образом, использование множественных значений внутри «Slot» допускается. Разделение может произойти только между значениями, где каждый элемент «Value» заключен в скобки.	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.3.5
	Семантика «AND/OR» для кодированных элементов должна быть доступна только для параметров с множественными значениями (например, «$XDSDocumentEntryEventCodeList»). Параметры с множественными значениями должны быть закодированы одним из двух способов, примеры которых приведены далее. Параметр, указанный как «Slot» с несколькими значениями должен толковаться как дизъюнкция (семантика OR). Например: <rim:Slot name="$XDSDocumentEntryEventCodeList">    <rim:ValueList>   <rim:Value>('a')</rim:Value>   <rim:Value>('b')</rim:Value>    </rim:ValueList> </rim:Slot> должен соответствовать объекту «XDSDocumentEntry» с атрибутом «eventCodeList», содержащим 'a' или 'b'. Следующий пример аналогичен предыдущему в части результата: <rim:Slot name="$XDSDocumentEntryEventCodeList">    <rim:ValueList>   <rim:Value>('a','b')</rim:Value>   </rim:ValueList> </rim:Slot> Параметр, указанный как несколько элементов «Slot» должен толковаться как конъюнкция (семантика «AND»). Например: <rim:Slot name="$XDSDocumentEntryEventCodeList">    <rim:ValueList>   <rim:Value>('a')</rim:Value>    </rim:ValueList> </rim:Slot> <rim:Slot name="$XDSDocumentEntryEventCodeList">    <rim:ValueList>   <rim:Value>('b')</rim:Value>    </rim:ValueList> </rim:Slot> должен соответствовать объекту «XDSDocumentEntry» с атрибутом «eventCodeList», содержащим одновременно 'a' и 'b'.	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.3.5
Значение статуса объектов реестра может быть следующим: urn:oasis:names:tc:ebxml-regrep:StatusType:Approved (утвержденный); urn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated (устаревший) Если Реестр документов (Document Registry) получает посредством транзакции [ITI-18] «Запросить набор документов» значение параметра «$XDSDocumentEntryStatus», которое он не может распознать, тогда Реестр документов (Document Registry) должен игнорировать это значение и обрабатывать транзакцию [ITI-18]  «Запросить набор документов» таким образом, если бы данное значение не было указано.	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.3.6
Атрибут status элемента «AdhocQueryResponse» должен содержать одно из следующих значений: urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success (успешно) urn:ihe:iti:2007:ResponseStatusType:PartialSuccess (частично успешно) urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure (неудачно)	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.3.6.1
	Транзакция [ITI-18] «Запросить набор документов» использует «homeCommunityId», который является глобальным уникальным идентификатором сообщества и используется для конечных точек веб-сервисов для сервисов, которые предоставляют доступ к данным в этом сообществе. «homeCommunityId» структурирован как OID, ограниченный 64 знаками и указанный в синтаксисе URI. Например, «homeCommunityId» - 1.2.3 должен формироваться как «urn: oid:1.2.3»	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.3.8
Наличие или отсутствие необязательного параметра «$XDSDocumentEntryType» вызывает различное поведение Реестра документов (Document Registry). Если данный параметр указан, но Реестр документов (Document Registry) не поддерживает его, тогда Реестр документов (Document Registry) должен игнорировать его. Если данный параметр указан, и Реестр документов (Document Registry) поддерживает его, тогда Реестр документов (Document Registry) возвращает соответствующую информацию: Если Потребитель документов (Document Consumer) не поддерживает опцию «Документы по требованию» (On-Demand Documents Option), тогда он должен отправлять Запрос набора документов (RegistryStoredQueryRequest), который не содержит параметр «$XDSDocumentEntryType». Реестр документов (Document Registry), таким образом, не предоставит записи документов по требованию в ответе; Если Потребитель документов (Document Consumer) поддерживает опцию «Документы по требованию» (On-Demand Documents Option), тогда он имеет возможность указать параметр «$XDSDocumentEntryType», содержащий «uuid» записи документа по требованию в Запросе набора документов (RegistryStoredQueryRequest). Реестр документов (Document Registry) с опцией «Документы по требованию» (On-Demand Documents Option) распознает параметр «$XDSDocumentEntryType» и обработает запрос соответственно. Реестр документов (Document Registry), который не поддерживает опцию «Документы по требованию» (On-Demand Documents Option), проигнорирует параметр «$XDSDocumentEntryType». Поскольку в Реестре документов (Document Registry), который не поддерживает опцию «Документы по требованию» (On-Demand Documents Option), не может существовать никаких записей документов по требованию, то он сгенерирует обычный ответ на запрос.	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.5
ebXML версии 3.0 поддерживает постраничное разбиение результатов запроса. Взаимодействия между возможностями хранения запросов и возможностями разбиения результатов запроса в рамках стандарта не могут гармонично сочетаться и не рекомендуются к совместному применению. Вместо этого рекомендуется использование возможности постраничного разбиения результатов, реализованного на стороне Потребителя документов (Document Consumer). Это может быть достигнуто путем указания returnType=”ObjectRef” для больших запросов. Вследствие чего будет возвращен список ссылок «UUID» вместо объектов (структур XML). Это практикуется для запросов, возвращающих тысячи объектов. Например, следующая последовательность запросов может быть использована для списка большого количества документов: Запрос «Найти документы (FindDocuments)» с returnType=”ObjectRef”, который возвращает большую коллекцию ObjectRefs (UUID); Запрос «Получить документы (GetDocuments)» с returnType=”LeafClass”, инициированный подмножеством UUID, возвращенных в запросе выше, который возвращает детали для построения одной страницы ИЛИ Запрос «Получить документы и ассоциации (GetDocumentsAndAssociations)» с returnType=”LeafClass”, инициированный подмножеством UUID, возвращенных в запросе выше.	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.6
Запрос набора документов (RegistryStoredQueryRequest) и ответ на данный запрос (RegistryStoredQueryResponse) должны передаваться с использованием веб-сервисов.	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.7
Реестр документов (Document Registry) должен принимать запрос набора документов (RegistryStoredQueryRequest) в формате сообщения SOAP и формировать ответ на него (RegistryStoredQueryResponse) в формате сообщения SOAP.	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.7
Потребитель документов (Document Consumer) должен генерировать запрос набора документов (RegistryStoredQueryRequest) в формате сообщения SOAP и принимать ответ на него (RegistryStoredQueryResponse) в формате сообщения SOAP	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.7
Атрибут /wsdl:definitions/@name должен иметь значение «DocumentRegistry»	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.7
Должны быть применены следующие соглашения о наименованиях в WSDL: wsdl:definitions/@name="DocumentRegistry": query message  -> "RegistryStoredQuery_Message" query response  -> "RegistryStoredQuery_Response_Message" portType  -> "DocumentRegistry_PortType" operation  -> "RegistryStoredQuery" SOAP 1.2 binding -> "DocumentRegistry_Binding_Soap12" SOAP 1.2 port  -> "DocumentRegistry_Port_Soap12"	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.7
«targetNamespace» в WSDL должен иметь значение «urn:ihe:iti:xds-b:2007»	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.7
Следующее значение должно быть импортировано (xsd:import) в секцию /definitions/types: namespace=" urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0", schemaLocation="query. xsd"	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.7
Атрибут /definitions/message/part/@element в сообщении запроса набора документов (RegistryStoredQueryRequest) должен быть определен как «query:AdhocQueryRequest»	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.7
Атрибут /definitions/message/part/@element в сообщении ответа по набору документов (RegistryStoredQueryResponse) должен быть определен как «query:AdhocQueryResponse»	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.7
Дополнительные требования к атрибутам: Атрибут Значение /definitions/portType/ operation@name DocumentRegistry_ RegistryStoredQuery /definitions/portType/ operation/input/@wsaw:Action urn:ihe:iti:2007: RegistryStoredQuery /definitions/portType/ operation/output/@wsaw:Action urn:ihe:iti:2007: RegistryStoredQueryResponse /definitions/binding/ operation/soap12:operation/ @soapAction urn:ihe:iti:2007: RegistryStoredQuery	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.7
Для поддержки опции «Асинхронные веб-сервисы (Asynchronous Web Services Exchange Option)» на стороне Потребителя документа (Document Consumer), Реестр документов (Document Registry) должен поддерживать использование неанонимного ответа, содержащего  структуру «Endpoint Reference(EPR)» в заголовке «replyTo» WS-Addressing	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.2.7
Реестр документов (Document Registry) должен: Принимать параметризованный запрос в сообщении «AdhocQueryRequest»; Проверять, все ли обязательные параметры включены в запрос; Возвращать ошибки при следующих условиях: Неизвестный идентификатор запроса (код ошибки «XDSUnknownStoredQuery»); Указаны не все обязательные параметры (код ошибки «XDSStoredQueryParamNumber»). Обрабатывать запросы следующим образом: Для Реестра документов (Document Registry): Извлекать внутренний шаблон реализации запроса на основании идентификатора запроса, предоставленного в запросе; Реестр документов (Document Registry) должен принимать значение homeCommunityId, если оно указано в запросе набора документов (RegistryStoredQueryRequest); Если идентификатор пациента указан в параметре запроса как «неизвестен», тогда Реестр документов (Document Registry) должен вернуть успешно обработанный запрос, не содержащий элементов. Для Инициализирующего шлюза (Initiating Gateway): Инициализирующий шлюз (Initiating Gateway) принимает запрос набора документов (RegistryStoredQueryRequest) по идентификатору пациента, который должен определять: а) какому отвечающему шлюзу (Responding Gateways) должен быть направлен данный запрос; б) какой идентификатор пациента должен использоваться в транзакции [ITI-38] «Межшлюзовый запрос (Cross Gateway Query)». Для каждого определенного отвечающего шлюза (Responding Gateway), инициализирующий шлюз (Initiating Gateway) должен направить запрос с корректным идентификатором пациента, соответствующим сообществу отвечающего шлюза (Responding Gateway) и инициировать транзакцию [ITI-38] «Межшлюзовый запрос (Cross Gateway Query)» для отвечающего шлюза (Responding Gateway). Если Инициализирующий шлюз (Initiating Gateway) сгруппирован с Потребителем документов (Document Consumer), тогда также инициируется запрос набора документов (RegistryStoredQueryRequest) к локальному Реестру документов; Инициализирующий шлюз (Initiating Gateway) принимает запрос набора документов (RegistryStoredQueryRequest) по идентификатору entryUUID или uniqueID, проверив наличие «homeCommunityId». В случае отсутствия «homeCommunityId», необходимо вернуть ошибку с кодом «XDSMissingHomeCommunityId». Если «homeCommunityId» не распознается, тогда необходимо вернуть ошибку с кодом «XDSUnknownCommunity». Определить, с каким отвечающим шлюзом (Responding Gateway) необходимо связаться с использованием «homeCommunityId» для получения конечной точки веб-сервиса отвечающего шлюза (Responding Gateway). Если «homeCommunityId» представляет локальное сообщество, тогда инициализирующий шлюз (Initiating Gateway) должен инициировать запрос набора документов (RegistryStoredQueryRequest) к локальному Реестру документов. Инициализирующий шлюз (Initiating Gateway) должен указать «homeCommunityId» в транзакции [ITI-38] «Межшлюзовый запрос (Cross Gateway Query)» по идентификатору «entryUUID» или «uniqueID», которые идентифицируют сообщество, связанное с отвечающим шлюзом (Responding Gateway); Вернуть метаданные в формате XML в сообщении «AdhocQueryResponse»: Реестр документов (Document Registry) может указать атрибут «homeCommunityID» в любом подходящем элементе; Инициализирующий шлюз (Initiating Gateway) может указать атрибут «homeCommunityID» во всех подходящих элементах. Если Инициализирующий шлюз (Initiating Gateway) соединен с Реестром документов (Document Registry), тогда ответ Реестра документов (Document Registry) может не содержать «homeCommunityID». В этом случае Инициализирующий шлюз (Initiating Gateway) должен добавить «homeCommunityId» своего локального сообщества к ответу Реестра документов (Document Registry) до включения его в консолидированный ответ, направляемый Потребителю документов (Document Consumer). Если returntype = “LeafClass”, тогда элементы «ExtrinsicObject» и «RegistryPackage» должны содержать атрибут ‘home’; Если returntype = “ ObjectRef”, тогда элемент «ObjectRef» должен содержать атрибут ‘home’; Если Инициализирующему шлюзу (Initiating Gateway) не удалось получить соответствующий ответ от выбранного отвечающего шлюза (Responding Gateway), тогда он должен включить в ответ, направляемый Потребителю документов (Document Consumer), код ошибки «XDSUnavailableCommunity» в контексте, обозначающем недоступность отвечающего шлюза (Responding Gateway). В этом случае, и в случае любой другой ошибки на стороне отвечающего шлюза (Responding Gateway), инициализирующий шлюз (Initiating Gateway) должен вернуть Потребителю документов (Document Consumer) статус о невыполнении запроса (если никакая часть запроса не выполнена) или частично успешный статус. Когда Потребитель документов (Document Consumer) получает ответ по набору документов (RegistryStoredQueryResponse) от инициализирующего шлюза (Initiating Gateway), тогда он должен учитывать два аспекта ответа: а) должен быть указан атрибут «homeCommunityId»; б) Потребитель документов (Document Consumer) может не иметь возможности сопоставления идентификатора репозитория напрямую с Репозиторием документов (Document Repository). Потребитель документов (Document Consumer) должен сохранить значение атрибута «homeCommunityId» для будущих взаимодействий с инициализирующим шлюзом (Initiating Gateway). Транзакция [ITI-18] «Запросить набор документов» может содержать в одном сообщении «AdhocQueryResponse» и результат, и ошибки. Для этих целей сообщение «AdhocQueryResponse» содержит в себе одновременно и элемент «RegistryObjectList», и элемент «RegistryErrorList».	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.3
Если реализована опция «Обеспечение базовой конфиденциальности пациента (Basic Patient Privacy Enforcement Option)», тогда: Все Потребители документов (Document Consumer) могут предоставлять список «confidentialityCode» в рамках транзакции [ITI-18] «Запросить набор документов» и Регистр документов должен возвращать только те документы, которые имеют «confidentialityCode» не ниже того, что предоставлен Потребителем документов (Document Consumer); Потребитель документов (Document Consumer) должен предоставлять возможность настройки Политик конфиденциальности пациента (Patient Privacy Policies), Идентификаторов политик конфиденциальности пациента (Patient Privacy Policy Identifiers (OIDs)) и связанной информации, необходимой для понимания и исполнения политик области действия  XDS (XDS Affinity Domain Policy); Потребитель документов (Document Consumer) не должен предоставлять доступ к документам, для которых Потребитель документов (Document Consumer) не может обработать, по крайней мере, один из возвращенных «confidentialityCode». Это гарантирует, что Потребитель документов (Document Consumer) не будет неправильно обрабатывать документы с «confidentialityCode», которые могут быть более строго ограниченными, чем поддерживаемые Потребителем документов (Document Consumer); Потребитель документов (Document Consumer) должен соблюдать политики области действия XDS (XDS Affinity Domain Policies), представленные при помощи «confidentialityCode», находящегося в метаданных, связанных с документом. Потребитель документов (Document Consumer) должен обеспечивать контроль доступа пользователей или бизнес правила для определения деталей кодов конфиденциальности, примененных в результатах запроса.	IHE ITI TF [RF-4] Vol2a, раздел 3.18.4.1.3.5

Выходная информация

Выходной информацией транзакции ITI-18 «Запросить набор документов» профиля IHE XDS является ответ «AdhocQueryResponse» на запрос «AdhocQueryRequest».