Таблица 11 – Перечень клинических документов прецедента [W. P-1.UC-1.1] «Отправить запрос на прикрепление»
№ | Тип документа | Наименование документа | Ссылка на спецификацию | Кратность | Примечание |
CDA | Согласие на прикрепление к медицинской организации, оказывающей первичную медико-санитарную помощь | [RF-16] | [1..1] | ||
XDW | Документ рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи» | [RF-14] | [1..1] |
Рабочий процесс «Прикрепление граждан к организациям первичной медико-санитарной помощи» находится в состоянии ST01 – На рассмотрении (Attachment pending) при выполнении перехода (TR01 – Запрос на прикрепление зарегистрирован (Request for Attachment) в соответствии с требованием данного процесса.
Если прецедент выполнен неуспешно, Информационная система получает сообщение со сведениями о возникших ошибках.
[W. P-1.UC-1.2] «Отправить запрос на смену участка прикрепления» Введение
Прецедент [W. P-1.UC-1.2] «Отправить запрос на смену участка прикрепления» предназначен для смены участка, медицинской организации в пределах одной административно-территориальной единицы. В случае смены медицинской организации пациентом, должен использоваться прецедент [W. P-1] Процесс «Прикрепление граждан к организациям первичной медико-санитарной помощи».
Перечень состояний процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи» приведен в приложении А.2, переходы процесса приведены в приложении А.3.
Входной информацией прецедента является набор документов рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи», приведенный в таблице 12.
Таблица 12 – Перечень входных клинических документов прецедента [W. P-1.UC-1.2] «Отправить запрос на смену участка прикрепления»
№ | Тип документа | Наименование документа | Ссылка на спецификацию | Кратность | Примечание |
CDA | Дополнение к согласию на прикрепление к медицинской организации, оказывающей первичную медико-санитарную помощь | [RF-17] | [1..1] | ||
XDW | Документ рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи» | [RF-14] | [1..1] | Рабочий процесс должен быть в состояниии ST02 - Активен (Attachment active). |
Обработка
Диаграмма последовательности прецедента приведена на рисунке.
Рисунок 4 – Диаграмма последовательности прецедента [W. P-1.UC-1.2] «Отправить запрос на смену участка прикрепления»
Спецификация прецедента приведена в таблице 13.
Таблица 13 – Спецификация прецедента [W. P-1.UC-1.2] «Отправить запрос на смену участка прикрепления»
Параметр | Описание |
Краткое описание | Информационная система формирует документы в соответствии с таблицей 12 и осуществляет отправку набора документов в Платформу для регистрации метаданных в Реестре документов и хранении в Репозитории документов. |
Действующие лица |
|
Предусловие |
|
Постусловие | Если прецедент выполнен успешно, то:
В противном случае информационная система получает информацию о возникших ошибках при обработке запроса. |
Основной сценарий | Информационная система формирует клинические документы в формате XDW и CDA в соответствии с требованиями данного прецедента [RQ. ATCH-9]; Информационная система отправляет сообщение Платформе (ProvideAndRegisterDocumentSetRequest), используя IHE транзакцию [ITI-41] «Предоставить и зарегистрировать набор документов (Provide and Register Document Set-b)»; Платформа получает сообщение (ProvideAndRegisterDocumentSetRequest) и осуществляет валидацию полученного запроса, в соответствии с требованиями к формированию и отправке документов для регистрации в Платформе; Альтернативный сценарий 3a – Запрос не прошел валидацию.. Платформа осуществляет проверку имеет ли пользователь, отправляющий запрос Полномочий на клинический процесс (healthcare activity mandate) на пациента, определенного в CDA документе;Альтернативный сценарий 4a – Пользователь отправляющий запрос не имеет Полномочий на клинический процесс (healthcare activity mandate). Платформа осуществляет проверку причины прикрепления;Альтернативный сценарий 5a – Причиной является кампания прикрепления. Платформа обновляет сведения о прикреплении пациента в Регистре пациентов; Платформа сохраняет XDW документ рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи» и CDA документа «Согласие на прикрепление к медицинской организации, оказывающей первичную медико-санитарную помощь» сохраняет в Репозитории документов и регистрирует в Реестре документов Платформы; Платформа отправляет уведомление об обновлении XDW документа рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи» подписанной Информационной системе; Платформа запускает таймер отсчета времени по истечению срока ожидания согласования прикрепления - ДT01; Платформа отправляет ответное сообщение (ProvideAndRegisterDocumentSetResponse) Информационной системе; Информационная система получает ответное сообщение (ProvideAndRegisterDocumentSetResponse) от Платформы;Сценарий завершается успешно. |
Альтернативный сценарий 3а. | Запрос не валидный. Платформа отправляет сообщение об ошибке; Информационная система получает сообщение об ошибке.Сценарий завершается сообщением об ошибке |
Альтернативный сценарий 4а. | Пользователь отправляющий запрос не имеет полномочия на требование (demand mandate). Платформа отправляет сообщение об ошибке; Информационная система получает сообщение об ошибке.Сценарий завершается сообщением об ошибке |
Альтернативный сценарий 5а. | Причиной является кампания прикрепления. Платформа осуществляет проверку периода кампании прикрепления;Альтернативный сценарий 5a1а – Запрос отправлен не в период кампании прикрепления Переход к шагу 6 основного сценария |
Альтернативный сценарий 5a1а | Запрос отправлен не в период кампании прикрепления Платформа отправляет сообщение об ошибке; Информационная система получает сообщение об ошибке.Сценарий завершается сообщением об ошибке |
Функциональные требования прецедента приведены в таблице 14.
Таблица 14 – Функциональные требования к прецеденту [W. P-1.UC-1.2] «Отправить запрос на смену участка прикрепления»
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 документ «Дополнение к согласию на прикрепление к медицинской организации, оказывающей первичную медико-санитарную помощь» электронной цифровой подписью. Данные автора, создавшего и ответственного за документ, должны находиться в элементе 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/ | Шаг 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 | |
Информационная система должна генерировать документ рабочего процесса в формате XDW. Документ должен соответствовать требования для шаблона документа рабочего процесса «Рабочий процесс» [RF-14] | Шаг 1 | |
Рабочий процесс «Прикрепление граждан к организациям первичной медико-санитарной помощи» должен быть в состоянии ST02 – Активен (Attachment active) после выполнения перехода TR02 – Запрос на прикрепление согласован (Request for Attachment with direct approval) | Шаг 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а | |
Требования, относящиеся к обработке запроса на Платформе | ||
Платформа должна извлечь объект Прикрепления данного пациента к медицинской организации (patient. patientPerson. bjectOf. careProvision) из Регистра Пациентов, и установить состояние объекта «Завершен», (patient. patientPerson. bjectOf. careProvision. statusCode) установить дату действия прикрепления пациента на текущую дату (patient. patientPerson. bjectOf. careProvision. effectiveTime. high). Если новая дата действия прикрепления пациента находится в будущем периоде, Платформа не должна устанавливать состояние текущего прикрепления «Завершено». В данном случае, Платформа должна устанавливать только Дату действия текущего прикрепления пациента на значение «Активно» с информации прикрепления полученного запроса. | ||
Платформа должна создать новый объект прикрепления (Attachment object) - (patient. patientPerson. bjectOf. careProvision) в Регистре пациентов и установить всю необходимую информацию для прикрепления пациента в соответствии с полученным запросом | ||
Если время согласования на прикрепление не установлено, или установлено со значением "0", то рабочий процесс остается в состоянии ST01-На рассмотрении (Attachment pending) Требования к конфигурации времени согласования процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи» приведены в документе [RF-27] | Шаг 9 | |
Требования для отправки уведомлений | ||
Платформа должна зарегистрировать подписку на Организацию (медицинского работника, согласовавшего специалиста) на получение уведомлений при публикации документа или обновления его метаданных рабочего процесса «Прикрепление граждан к организациям первичной медико-санитарной помощи» при регистрации и сохранении документа в Регистре/Репозитории документов Платформы | Шаг 6 | |
Для отправки уведомлений о метаданных документа для ИС МЗ РК должна использоваться IHE транзакция [ITI-53] «Уведомить о метаданных документа» (Document Metadata Notify), для МИС РК должна использоваться IHE транзакция [ITI-70] – «Запрос на получение уведомлений» (Pull Notification) интеграционного профиля IHE DSUB. | Шаг 8 |
Выходная информация
Выходной информацией является зарегистрированный набор документов в Реестре документов/Репозитории документов Платформы, приведенные в таблице 15.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
