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

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

ID	Требование	Источник возникновения
Общие требования к прецеденту
В рамках интеграционного взаимодействия по процессу «Прикрепление граждан к организациям первичной медико-санитарной помощи» для использования сервисов Платформы организация здравоохранения, использующая Информационную систему, должна быть зарегистрирована в Регистре организаций Здравоохранения Платформы
Данные организации, подразделения и приложения должны быть определены в заголовке SOAP каждого запроса, отправленного в Платформу. Элемент SOAP заголовка, предназначенный для указания организации: From. ehkz:organizationID. Организация должна быть идентифицирована с использованием OID организации здравоохранения. Элемент SOAP заголовка, предназначенный для указания приложения: From. ehkz:applicationID. Приложение должно быть идентифицировано с использованием OID приложения. Элемент SOAP заголовка, предназначенный для указания подразделения: From. ehkz:departmentID. Подразделение должно быть идентифицировано с использованием OID подразделения. Организация, Подразделение и Приложение должны быть зарегистрированы в Платформе. Приложение должно относиться к организации. Подразделение должно относиться к организации.
Информационное взаимодействие в рамках прецедента должно сопровождаться отправкой сообщений аудита в соответствии с требованиями, приведёнными в документе [RF-11]
Элементы и атрибуты, указанные в сообщении запроса, для которых определены типы данных такие как date, time или dateTime, либо должны определять часовой пояс в соответствии с правилами, определенными в стандарте ISO 8601, либо в случае если часовой пояс не определен в сообщении запроса, то указанные дата и время должны расцениваться Платформой как указанные в часовом поясе города Астаны (+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>
	Требования к формированию документов	Шаг 1
Информационная система должна генерировать клинический документ в формате HL7 CDA R2. Клинический документ должен соответствовать требованиям к шаблону CDA документа «Согласие на прикрепление к медицинской организации, оказывающей первичную медико-санитарную помощь» [RF-16]	Шаг 1
Информационная система должна предоставлять автору подписывать CDA документ «Согласие на прикрепление к медицинской организации, оказывающей первичную медико-санитарную помощь» электронной цифровой подписью. Данные автора, создавшего и ответственного за документ, должны находиться в элементе 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
	Информационная система должна генерировать документ рабочего процесса в формате XDW. Документ должен соответствовать требования для шаблона документа рабочего процесса «Рабочий процесс» [RF-14]	Шаг 1
Рабочий процесс «Прикрепление граждан к организациям первичной медико-санитарной помощи» должен быть в состоянии ST01 – На рассмотрении (Attachment pending), после выполнения перехода «TR01 – Запрос на прикрепление зарегистрирован (Request for Attachment)»	Шаг 1
Информационная система должна сгенерировать уникальный идентификатор рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи» (OID). OID процесса должен создаваться как UUID, конвертируемый в префиксное целое число с корневым (root) OID для идентификаторов процесса (1.2.398.7.1.14.1.4). Идентификатор процесса должен быть идентичен идентификатору экземпляра рабочего процесса (workflowID) (XDW. WorkflowDocument. workflowInstanceId) представленный в XDW документе рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи». Пример идентификатора рабочего процесса 1.2.398.7.1.14.1.4.222108572223065003571162018299908374491	Шаг 1
	Требования к отправке документов для регистрации в Платформе
Запрос на регистрацию набора документов должен соответствовать требованиям транзакции [ITI-41] «Предоставить и зарегистрировать набор документов (Provide and Register Document Set-b)», приведенным в документе [RF-12]	Шаг 2
	Информационная система должна отправлять клинические документы в формате CDA и XDW документы рабочего процесса в одном наборе представлении документов (XDSSubmissionSet)	Шаг 2
Идентификатор экземпляра рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи» (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()	Шаг 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 документ рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи», 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()	Шаг 2
Идентификатор прикрепления (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()	Шаг 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_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);	Альтернативный сценарий 3а.
При условии, если пользователь отправляющий запрос не имеет полномочия на требование (demand mandate) должен быть предоставлен как минимум один из следующих допустимых групп ошибок: ERR_SEC_AUT – errors related to authorization of user access to patient data (перечень ошибок авторизации для последующего доступа к данным пациента приведен в приложении Б.5);	Альтернативный сценарий 4а.
При условии, если запрос отправлен не в период кампании прикрепления должен быть предоставлен как минимум один из следующих допустимых групп ошибок: ERR_MAN_PRC - business process errors (перечень ошибок бизнес процесса приведен в приложении Б.2).	Альтернативный сценарий 5a1а
Если время согласования на прикрепление не установлено, или установлено со значением "0", то рабочий процесс остается в состоянии ST01-На рассмотрении (Attachment pending) Требования к конфигурации времени согласования процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи» приведены в документе [RF-27]	Шаг 9
Требования для отправки уведомлений
Платформа должна зарегистрировать подписку на Организацию (медицинского работника, согласовавшего специалиста) на получение уведомлений при публикации документа или обновления его метаданных рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи» при регистрации и сохранении документа в Регистре/Репозитории документов Платформы	Шаг 6
Для отправки уведомлений о метаданных документа для ИС МЗ РК должна использоваться IHE транзакция [ITI-53] «Уведомить о метаданных документа» (Document Metadata Notify), для МИС РК должна использоваться IHE транзакция [ITI-70] – «Запрос на получение уведомлений» (Pull Notification) интеграционного профиля IHE DSUB.	Шаг 8
Платформа должна отправить уведомление о необходимости согласования Информационной системе согласующего органа, задачей которого является обработка заявок на прикрепление/открепление	Шаг 8

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

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