Операция регистрации электронного рецепта с ЭЦП

Схема взаимодействия МИС с АИС ЭР в части регистрации электронного рецепта с использованием электронной цифровой подписи ЭЦП

МИС

Выписать электронный рецепт с использованием ЭЦП можно только пациенту, для которого создан ресурс Patient в АИС ЭР.

Ресурс Practitioner так же должен быть создан в АИС ЭР, т.к. при создании ресурса MedicationPrescription на стороне АИС ЭР выполняется проверка целостности ссылок на связанные ресурсы.

При выписке электронного рецепта МИС выполняет следующие действия:

1. Формирует ресурс MedicationPrescription по профилю.
2. Подготавливает ресурс MedicationPrescription для формирования подписи.
3. Формирует подпись.
4. Формирует ресурс Parameters, в body которого помещает ресурс MedicationPrescription (ресурс должен соответствовать профилю) и подпись Signature в формате base64Binary.
5. Отправляет сформированный ресурс Parameters в АИС ЭР, выполняя операцию регистрации ЭР POST MedicationPrescription/$register. В заголовке необходимо указать Content-Type (XML или JSON). Исходя из этого значения на стороне платформы будет принято решение о формате документа, на основе которого формировалась подпись.

АИС ЭР

1. Валидация ресурса MedicationPrescription, полученного от МИС, по профилю. Проверка целостности ссылок на связанные ресурсы. В случае, если ресурс MedicationPrescription не соответствует профилю или не найдены ресурсы по указанным ссылкам, то возвращается ошибка валидации HttpStatusCode 400 BadRequest с описанием проблемы;
2. Если ресурс MedicationPrescription прошел валидацию, то выполняется валидация подписи. Правила подготовки ресурса для подписи одинаковы для МИС и АИС ЭР. Формат определяется значением, которое указал МИС в Content-Type в заголовке операции. Если подпись не прошла валидацию, то возвращается ошибка валидации HttpStatusCode 400 BadRequest "подпись не верна";
   
3. В случае успешной валидации создается ресурс MedicationPrescription и Provenance. Ресурс Provenance содержит подпись ЭР, время создания подписи, формат ресурса, на основе которого формировалась подпись, и ссылку на лицо, ответственное за подпись (см. разработанный профиль);
4. Возвращает ресурс MedicationPrescription.

Правила подготовки ресурса для подписи

1. Для подписи документ должен создаться без форматирования, т. е. без переносов, отступов и пробелов. Допускаются только одиночные пробелы в значениях параметров.
2. Поля в документе необходимо разместить в алфавитном порядке.
   Внутри блоков поля также нужно расположить в алфавитном порядке.
3. В ресурсе MedicationPrescription contained:medication расположить в следующем порядке:
   1. medication, определяющий лекарственное средство как торговое наименование ( "isBrand": true);
   2. medication, определяющий лекарственное средство по МНН ( "isBrand": false).

   Разместить элементы extension в следующем порядке:
   1. extension: medicamentType;
   2. extension: factor;
   3. extension: speedProduction;
   4. extension: MedicationPrescriptionLink.

4. Значения с типом данных decimal необходимо передавать с минимальной точностью до десятых.
   Пример: значение 1 будет считаться не валидным; такое значение необходимо передавать как 1.0
5. Убрать из подписываемого документа ссылки на пациента и врача, удалив patient.reference и prescriber.reference, в которых располагается ссылка на ресурсы с указанием guid. Должны остаться в блоке данных patient поля patient.display и patient.extension:medicationCard. Должны остаться в блоке данных prescriber поля prescriber.display и prescriber.extension:PIN
6. Убрать из подписываемого документа свойство metadata.
7. Убрать из подписываемого документа статус рецепта: атрибут status тип MedicationPrescriptionStatus (FHIR).
8. Убрать из подписываемого документа следующие элементы extension:
   • extension: iteration;
   • extension: quantityInIteration.
9. Ресурс для подписи должен быть приведен к каноническому виду. Правила приведения к каноническому виду для XML и JSON похожи. Ознакомиться с информацией о каноническом виде XML и JSON можно, перейдя по ссылкам Canonical XML  и XML Representation of Resources.
10. Использовать кодировку UTF8.

Операция регистрации электронных рецептов пациента

POST MedicationPrescription/$register

Аутентификация

При работе с FHIR-сервером для получения валидного токена аутентификации необходимо запрашивать scope "EHR.MedicationPrescription.$register"

Входящие параметры

Параметры операции передаются в Body в виде ресурса Parameters

Возвращаемый результат

Возвращаемые коды состояния HTTP

• HttpStatusCode 200 OK - при успешной регистрации ЭР;
• HttpStatusCode 400 BadRequest - если входящие параметры не прошли правила валидации;
• HttpStatusCode 401 Unauthorized - если клиент не авторизован;
• HttpStatusCode 403 Forbidden - если у клиента нет scope EHR.MedicationPrescription.$register.

Примеры