Ericsson Nikola Tesla d. d. (Хорватия) (стр. 12 )

Таблица 34 – Перечень клинических документов прецедента [W. P-1.UC-1.7] «Согласовать запрос на открепление»

№	Тип документа	Наименование документа	Ссылка на спецификацию	Кратность	Примечание
CDA	Дополнение к согласию на прикрепление к медицинской организации, оказывающей первичную медико-санитарную помощь	[RF-17]	[1..1]
XDW	Документ рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи»	[RF-14]	[1..1]

Рабочий процесс «Прикрепление граждан к организациям первичной медико-санитарной помощи» находится в состоянии ST05 - Завершен (Откреплен) (Attachment Terminated) после выполнения перехода TR10 - Запрос на открепление согласован (Detachment Request Accepted) в соответствии с требованием данного процесса.

Если прецедент выполнен неуспешно, Информационная система получает сообщение со сведениями о возникших ошибках.

[W. P-1.UC-1.8] «Отклонить запрос на открепление» Введение

Прецедент [W. P-1.UC-1.8] «Отклонить запрос на открепление» предназначен для отклонения запроса на открепление от медицинской организации уполномоченным специалистом.

Перечень состояний процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи» приведен в приложении А.2, переходы процесса приведены в приложении А.3.

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

Входной информацией прецедента является набор документов рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи», приведенный в таблице 35.

Таблица 35 – Перечень входных клинических документов прецедента [W. P-1.UC-1.8] «Отклонить запрос на открепление»

№	Тип документа	Наименование документа	Ссылка на спецификацию	Кратность	Примечание
XDW	Документ рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи»	[RF-14]	[1..1]
CDA	Дополнение к согласию на прикрепление к медицинской организации, оказывающей первичную медико-санитарную помощь	[RF-17]	[1..1]

Обработка

Диаграмма последовательности прецедента приведена на рисунке 10.

Рисунок 10 – Диаграмма последовательности прецедента [W. P-1.UC-1.8] «Отклонить запрос на открепление»

Спецификация прецедента приведена в таблице 36.

Таблица 36 – Спецификация прецедента [W. P-1.UC-1.8] «Отклонить запрос на открепление»

Параметр	Описание
Краткое описание	Информационная система формирует документы и осуществляет отправку набора документов в Платформу для регистрации метаданных в Реестре документов и хранении в Репозитории документов.
Действующие лица	Информационная система (Information system), роль – источник данных; Платформа (Platform), роль – потребитель данных;
Предусловие	Пользователь ИС прошел процедуру аутентификации, установлена пользовательская сессия, маркер безопасности SAML 2.0, подписан сертификатом Службы контроля доступа Платформы; Пользователь ИС, отправивший запрос должен иметь Полномочия на клинический процесс (healthcare activity mandate) на пациента; Рабочий процесс находится в состоянии ST01 – На рассмотрении (Attachment pending); Информационная система извлекла необходимый набор документов посредством прецедента [W. P-1.UC-1.3] «Получить список документов для согласования».
Постусловие	Если прецедент выполнен успешно, то: Метаданные набора документов успешно зарегистрированы в Реестре документов, и набор документов успешно сохранен в Репозитории документов Платформы. Список документов определен в разделе «Выходная информация» данного прецедента; В Платформе проведена обработка полученного запроса в соответствии с требованиями данного прецедента; Рабочий процесс «Прикрепление граждан к организациям первичной медико-санитарной помощи» переходит в состояние ST02 - Активен (Attachment active); В противном случае информационная система получает информацию о возникших ошибках при обработке запроса.
Основной сценарий	Информационная система обновляет XDW документ «Прикрепление граждан к организациям первичной медико-санитарной помощи»; Информационная система отправляет сообщение Платформе (ProvideAndRegisterDocumentSetRequest), используя IHE транзакцию [ITI-41] «Предоставить и зарегистрировать набор документов (Provide and Register Document Set-b)»; Платформа получает сообщение (ProvideAndRegisterDocumentSetRequest) и осуществляет валидацию полученного запроса, в соответствии с требованиями к формированию и отправке документов для регистрации в Платформе; Альтернативный сценарий 3a – Запрос не прошел валидацию. Платформа осуществляет проверку имеет ли пользователь, отправляющий запрос Полномочий на клинический процесс (healthcare activity mandate); Альтернативный сценарий 4a – Пользователь отправляющий запрос не имеет Полномочий на клинический процесс (healthcare activity mandate). Платформа сохраняет XDW документ рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи» в Репозитории документов и регистрирует в Реестре документов Платформы; Платформа запускает таймер отсчета времени по истечению срока ожидания согласования открепления - ДT02; Платформа отправляет ответное сообщение (ProvideAndRegisterDocumentSetResponse) Информационной системе; Информационная система получает ответное сообщение (ProvideAndRegisterDocumentSetResponse) от Платформы; Сценарий завершается успешно.
Альтернативный сценарий 3а.	Запрос не валидный. Платформа отправляет сообщение об ошибке; Информационная система получает сообщение об ошибке. Сценарий завершается сообщением об ошибке
Альтернативный сценарий 4а.	Пользователь отправляющий запрос не имеет Полномочий на клинический процесс (healthcare activity mandate). Платформа отправляет сообщение об ошибке; Информационная система получает сообщение об ошибке. Сценарий завершается сообщением об ошибке

Функциональные требования прецедента приведены в таблице 29.

Таблица 37 – Функциональные требования к прецеденту [W. P-1.UC-1.8] «Отклонить запрос на открепление»

ID	Требование	Источник возникновения
Общие требования к прецеденту
В рамках интеграционного взаимодействия по процессу «Прикрепление граждан к организациям первичной медико-санитарной помощи» для использования сервисов Платформы Информационная система Медицинской организации должна быть зарегистрирована в Регистре организаций Здравоохранения Платформы
Данные организации, подразделения и приложения должны быть определены в заголовке SOAP каждого запроса, отправленного в Платформу. Элемент SOAP заголовка, предназначенный для указания организации: From. ehkz:organizationID. Организация должна быть идентифицирована с использованием OID организации здравоохранения. Элемент SOAP заголовка, предназначенный для указания приложения: From. ehkz:applicationID. Приложение должно быть идентифицировано с использованием OID приложения. Элемент SOAP заголовка, предназначенный для указания подразделения: From. ehkz:departmentID. Подразделение должно быть идентифицировано с использованием OID подразделения. Организация, Подразделение и Приложение должны быть зарегистрированы в Платформе. Приложение должно относиться к организации. Подразделение должно относиться к организации.
Информационное взаимодействие в рамках прецедента должно сопровождаться отправкой сообщений аудита в соответствии с требованиями, приведёнными в документе [RF-11]
Элементы и атрибуты, указанные в сообщении запроса, для которых определены типы данных такие как date, time или dateTime, либо должны определять часовой пояс в соответствии с правилами, определенными в стандарте ISO 8601 [RF-7], либо в случае если часовой пояс не определен в сообщении запроса, то указанные дата и время должны расцениваться Платформой как указанные в часовом поясе города Астаны (+06:00). - Примеры для date: <start>2002-09-24+08:00</start> <start>2002-09-24Z</start> <start>2002-09-24</start> (будет интерпретировано как2002-09-24+06:00) - Примеры для time: <start>09:30:10-03:00</start> <start>09:30:10Z</start> <start>09:30:10</start> (будет интерпретировано как 09:30:10+06:00) - Примеры для dateTime: <startdate>2002-05-30T09:30:10+08:00</startdate> <startdate>2002-05-30T09:30:10Z</startdate> <startdate>2002-05-30T09:30:10</startdate> (будет интерпретировано как 2002-05-30T09:30:10+06:00) В исходящих сообщениях Платформа всегда должна возвращать дату и время в часовом поясе города Астаны: - Пример для date: <start>2002-09-24+06:00</start> или <start>2002-09-24</start> - Пример для time: <start>09:30:10+06:00</start> или <start>09:30:10</start> - Пример для dateTime: <startdate>2002-05-30T09:30:10+06:00</startdate> или <startdate>2002-05-30T09:30:10</startdate>
Требования к формированию документов
Информационная система должна генерировать документ рабочего процесса в формате XDW. Документ должен соответствовать требования для шаблона документа рабочего процесса «Рабочий процесс» [RF-14]	Шаг 1
Рабочий процесс «Прикрепление граждан к организациям первичной медико-санитарной помощи» должен быть в состоянии «ST02 - Активен» после выполнения перехода «TR11 - Запрос на открепление отклонен (Detachment Request Refused)»	Шаг 1
Требования к отправке документов для регистрации в Платформе
Запрос на регистрацию набора документов должен соответствовать требованиям транзакции [ITI-41] «Предоставить и зарегистрировать набор документов (Provide and Register Document Set-b)», приведенным в документе [RF-12]	Шаг 2
XDW документ рабочего процесса должен быть зарегистрирован в Реестре документов как замена XDW документу рабочего процесса предыдущего состояния (связь с предыдущим XDW документом в XDSSubmissionSet) [Association[@associationType=urn:ihe:iti:2007:AssociationType:RPLC]	Шаг 2
Идентификатор экземпляра рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи» (workflowID) должен быть указан в элементе DocumentEntry. referenceListId в документах (XDW документ рабочего процесса» и в элементе XDSDocumentEntry сообщения [ITI-41] «Предоставить и зарегистрировать набор документов (Provide and Register Document Set-b)». Выражение XPath элемента referenceListId в сообщении ITI-41: ExtrinsicObject/ Slot[@name="urn:ihe:iti:xds:2013:referenceIdList"]/ValueList/Value/text() Выражение XPath элемента идентификатора экземпляра рабочего процесса в XDW документе рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи»: XDW. WorkflowDocument/workflowInstanceId/text()	Шаг 2
В сообщении [ITI-41] «Предоставить и зарегистрировать набор документов (Provide and Register Document Set-b)» XDSDocumentEntry XDW документа рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи» должен указать состояние текущего процесса в элементе DocumentEntry. processState. Значение данного элемента должно быть идентично состоянию последнего перехода, определенного в XDW документе рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи» в соответствии с диаграммой состояний. Перечень переходов, начальные и конечные состояния приведены в приложении  А.3. Выражение XPath элемента DocumentEntry. processState в сообщении ITI-41: ExtrinsicObject/ Slot[@name=" ehe:xds:metadata. processState"]/ValueList/Value/text() Выражение XPath кода перехода, указанного в XDW документе рабочего процесса: XDW. WorkflowDocument/TaskList/XDWTask[0]/taskData/ws-ht:taskDetails/ws-ht:name/text()	Шаг 2
Идентификационные и демографические данные пациента должны быть идентичны в следующих документах: XDW документ рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи» и в записи XDSDocumentEntries сообщения [ITI-41] «Предоставить и зарегистрировать набор документов (Provide and Register Document Set-b)». Выражение XPath элемента Пациент (patient) в XDW документе рабочего «Прикрепление граждан к организациям первичной медико-санитарной помощи»: //XDW. WorkflowDocument/patient/hl7:id@root Выражение XPath элемента Пациент (patient) в записи XDSDocumentEntry сообщения ITI-41: //ProvideAndRegisterDocumentSetRequest/SubmitObjectsRequest/ RegistryObjectList/ExtrinsicObject/Slot[name="sourcePatientId"]/ ValueList/Value/text()	Шаг 2
Идентификатор прикрепления (attachmentID) должен быть указан в элементе DocumentEntry. attachmentID в документах (XDW документ рабочего процесса и в элементе XDSDocumentEntry сообщения [ITI-41] «Предоставить и зарегистрировать набор документов (Provide and Register Document Set-b)». Идентификатор прикрепления должен быть идентичен, идентификатору экземпляра рабочего процесса приведённом в XDW документе рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи». Выражение XPath идентификатора прикрепления в сообщении ITI-41: ExtrinsicObject/ Slot[@name="urn:ehe:xds:metadata:attachmentID"]/ValueList/Value/text()	Шаг 2
Требования к валидации документов в Платформе
Запрос на регистрацию набора документов должен соответствовать требованиям транзакции [ITI-41] «Предоставить и зарегистрировать набор документов (Provide and Register Document Set-b)», приведенным в документе [RF-12]	Шаг 3
Механизмы обработки ошибок и исключений должны соответствовать требованиям транзакции [ITI-41] «Предоставить и зарегистрировать набор документов (Provide and Register Document Set-b)», приведенным в документе [RF-12]	Шаг 3
При условии, если запрос не прошел валидацию на стороне Платформы должен быть предоставлен как минимум один из следующих допустимых групп ошибок: ERR_SEC_DSG – errors related to validation of digital signature (перечень ошибок цифровой подписи приведен в приложении Б.5); ERR_MAN_XML – XML validation errors (перечень ошибок валидации XML сообщения приведен в приложении Б.2); ERR_MAN_PRC - business process errors (перечень ошибок бизнес процесса приведен в приложении Б.2); ERR_MAN_RUL – business and application rules errors (перечень ошибок бизнес правил и приложения приведен в приложении Б.2); ERR_XDS_RUL – errors related to validation of XDS messages according to application rules (перечень ошибок валидации XDS сообщений, в соответствии с правилами приложений приведен в приложении Б.4); ERR_SEC_AUT – errors related to authorization of user access to patient data (перечень ошибок авторизации для последующего доступа к данным пациента приведен в приложении Б.5);	Альтернативный сценарий 3а.
При условии, если пользователь отправляющий запрос не имеет полномочия на требование (demand mandate) должен быть предоставлен как минимум один из следующих допустимых групп ошибок: ERR_SEC_AUT – errors related to authorization of user access to patient data (перечень ошибок авторизации для последующего доступа к данным пациента приведен в приложении Б.5);	Альтернативный сценарий 4а.

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

Выходной информацией является зарегистрированный набор документов в Реестре документов/Репозитории документов Платформы, приведенные в таблице 30.