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

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

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

Рабочий процесс «Прикрепление граждан к организациям первичной медико-санитарной помощи» находится в состоянии ST05 – Завершен (Откреплен) (Attachment Terminated) при выполнении перехода (TR09 – Запрос на открепления согласован (Preapproved detachment request) или ST04 - Запрос на открепление на рассмотрении (Detachment Pending) после выполнения перехода TR07 - Запрос на открепление зарегистрирован (Request for Detachment) в соответствии с требованием данного процесса.

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

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

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

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

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

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

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

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

Обработка

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

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

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

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

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

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

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

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>
Требования к формированию документов
Информационная система должна генерировать клинический документ в формате HL7 CDA R2. Клинический документ должен соответствовать требованиям к шаблону CDA документа «Дополнение к согласию на прикрепление к медицинской организации, оказывающей первичную медико-санитарную помощь» [RF-17]	Шаг 1
Информационная система должна предоставлять возможность автору документа подписывать CDA документ «Дополнение к согласию на прикрепление к медицинской организации, оказывающей первичную медико-санитарную помощь» электронной цифровой подписью. Данные работника здравоохранения (HC Professional), создавшего и ответственного за документ, должны находиться в элементе ClinicalDocument. authenticator CDA документа. Информация о работника здравоохранения (HC Professional), определенная в элементе ClinicalDocument. authenticator с code=1 (OID 1.2.398.7.1.4.2.635) должна быть идентична информации элемента ClinicalDocument. author. ИИН работника здравоохранения (HC Professional) определенный в элементе ClinicalDocument. authenticator должен быть идентичен данным ИИН работника здравоохранения (HC Professional) цифрового сертификата, используемого при формировании электронно-цифровой подписи CDA документа. БИН медицинской организации (Medical Organization) определенный в элементе ClinicalDocument. authenticator должен быть идентичен данным БИН медицинской организации (Medical Organization) цифрового сертификата, используемого при формировании электронно-цифровой подписи CDA документа. Электронно-цифровая подпись должна быть сформирована в соответствии с правилами, определенными в приложении  «Требования к формированию ЭЦП» Выражение XPath элемента Authenticator в CDA документе содержащего сведения об ЭЦП пользователя: //ClinicalDocument/ authenticator[./assignedEntity/code/@code="1" and ./assignedEntity/code/@codeSystem="1.2.398.7.1.4.2.635"]/ signatureText	Шаг 1
Информационная система должна предоставлять возможность уполномоченному специалисту подписывать CDA документ электронной цифровой подписью работника здравоохранения. Данные медицинского работника, создавшего и ответственного за документ, должны находиться в элементе ClinicalDocument. authenticator CDA документа. ИИН работника здравоохранения (HC Professional) определенный в элементе ClinicalDocument. authenticator должен быть идентичен данным ИИН работника здравоохранения (HC Professional) цифрового сертификата, используемого при формировании электронно-цифровой подписи CDA документа. БИН медицинской организации (Medical Organization) определенный в элементе ClinicalDocument. authenticator должен быть идентичен данным БИН медицинской организации (Medical Organization) цифрового сертификата, используемого при формировании электронно-цифровой подписи CDA документа. Электронно-цифровая подпись должна быть сформирована в соответствии с правилами, определенными в приложении  «Требования к формированию ЭЦП» Выражение XPath элемента Authenticator в CDA документе содержащего сведения об ЭЦП пользователя: //ClinicalDocument/ authenticator[./assignedEntity/code/@code="2" and ./assignedEntity/code/@codeSystem="1.2.398.7.1.4.2.635"]/ signatureText	Шаг 2
Информационная система должна обновить документ рабочего процесса в формате XDW. Документ должен соответствовать требования для шаблона документа рабочего процесса «Рабочий процесс» [RF-14]	Шаг 3
Рабочий процесс «Прикрепление граждан к организациям первичной медико-санитарной помощи» должен быть в состоянии ST02 - Активен после выполнения перехода TR03 - Запрос на прикрепление согласован (Attachment Request Accepted)	Шаг 3
Требования к отправке документов для регистрации в Платформе
Запрос на регистрацию набора документов должен соответствовать требованиям транзакции [ITI-41] «Предоставить и зарегистрировать набор документов (Provide and Register Document Set-b)», приведенным в документе [RF-12]	Шаг 4
Информационная система должна отправлять клинические документы в формате CDA и XDW документы рабочего процесса в одном наборе представлении документов (XDSSubmissionSet)	Шаг 4
XDW документ рабочего процесса должен быть зарегистрирован в Реестре документов как замена XDW документу рабочего процесса предыдущего состояния (связь с предыдущим XDW документом в XDSSubmissionSet) [Association[@associationType=urn:ihe:iti:2007:AssociationType:RPLC]	Шаг 4
Идентификатор экземпляра рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи» (workflowID) должен быть указан в элементе DocumentEntry. referenceListId в документах (XDW документ рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи», CDA документ «Дополнение к согласию на прикрепление к медицинской организации, оказывающей первичную медико-санитарную помощь» и в элементе 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()	Шаг 4
В сообщении [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()	Шаг 4
Идентификационные и демографические данные пациента должны быть идентичны в следующих документах: XDW документ рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи», CDA документа «Дополнение к согласию на прикрепление к медицинской организации, оказывающей первичную медико-санитарную помощь» и в записи XDSDocumentEntries сообщения [ITI-41] «Предоставить и зарегистрировать набор документов (Provide and Register Document Set-b)». Выражение XPath элемента Пациент (patient) в CDA документе: //ClinicalDocument/recordTarget/id Выражение XPath элемента Пациент (patient) в XDW документе рабочего «Прикрепление граждан к организациям первичной медико-санитарной помощи»: //XDW. WorkflowDocument/patient/hl7:id@root Выражение XPath элемента Пациент (patient) в записи XDSDocumentEntry сообщения ITI-41: //ProvideAndRegisterDocumentSetRequest/SubmitObjectsRequest/ RegistryObjectList/ExtrinsicObject/Slot[name="sourcePatientId"]/ ValueList/Value/text()	Шаг 4
Идентификатор прикрепления (attachmentID) должен быть указан в элементе DocumentEntry. attachmentID в документах (XDW документ рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи», CDA документ «Дополнение к согласию на прикрепление к медицинской организации, оказывающей первичную медико-санитарную помощь» и в элементе XDSDocumentEntry сообщения [ITI-41] «Предоставить и зарегистрировать набор документов (Provide and Register Document Set-b)». Идентификатор прикрепления должен быть идентичен, идентификатору экземпляра рабочего процесса приведённом в XDW документе рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи». Выражение XPath идентификатора прикрепления в сообщении ITI-41: ExtrinsicObject/ Slot[@name="urn:ehe:xds:metadata:attachmentID"]/ValueList/Value/text()	Шаг 4
Требования к валидации документов в Платформе
Запрос на регистрацию набора документов должен соответствовать требованиям транзакции [ITI-41] «Предоставить и зарегистрировать набор документов (Provide and Register Document Set-b)», приведенным в документе [RF-12]	Шаг 4
Механизмы обработки ошибок и исключений должны соответствовать требованиям транзакции [ITI-41] «Предоставить и зарегистрировать набор документов (Provide and Register Document Set-b)», приведенным в документе [RF-12]	Шаг 4
При условии, если запрос не прошел валидацию на стороне Платформы должен быть предоставлен как минимум один из следующих допустимых групп ошибок: 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_CDA_TPL – errors related to CDA document validation against CDA templates for certain type of document (перечень ошибок валидации CDA документов в отношении шаблонов CDA документа определенного типа приведен в приложении Б.3); 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);	Альтернативный сценарий 5а.
При условии, если пользователь отправляющий запрос не имеет полномочия на требование (demand mandate) должен быть предоставлен как минимум один из следующих допустимых групп ошибок: ERR_SEC_AUT – errors related to authorization of user access to patient data (перечень ошибок авторизации для последующего доступа к данным пациента приведен в приложении Б.5);	Альтернативный сценарий 6а.
Требования, относящиеся к обработке запроса на Платформе
Платформа должна извлечь объект Прикрепления данного пациента к медицинской организации (patient. patientPerson. bjectOf. careProvision) из Регистра Пациентов, и установить состояние объекта «Завершен», (patient. patientPerson. bjectOf. careProvision. statusCode) установить дату действия прикрепления пациента на текущую дату (patient. patientPerson. bjectOf. careProvision. effectiveTime. high). Если новая дата действия прикрепления пациента находится в будущем периоде, Платформа не должна устанавливать состояние текущего прикрепления «Завершено». В данном случае, Платформа должна устанавливать только Дату действия текущего прикрепления пациента на значение «Активно» с информации прикрепления полученного запроса.	Шаг 8
Платформа должна создать новый объект прикрепления (Attachment object) - (patient. patientPerson. bjectOf. careProvision) в Регистре пациентов и установить всю необходимую информацию для прикрепления пациента в соответствии с полученным запросом	Шаг 8

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

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