ЕСОЗ - публічна документація

REST API signComposition

API Method

https://app.swaggerhub.com/apis/ehealthua/compositions/2.27.5#/main/signComposition

Бізнес-процес

2. Cтворення/підписання МВ (загальний процес)

5. Продовження / скорочення МВТН

6. Уточнення (preperson -> person) для МВТН

RC_7. Створення МВ “на заміну”

Опис

Метод призначений для підписання Медичного Висновку. За дотримання умов запиту на підписання ЕСОЗ виконує внутрішню задачу SIGN_COMPOSITION.

Опис параметрів

Параметр

Тип

Опис

Параметр

Тип

Опис

compositionId

String ($uuid)

(path)

Ідентифікатор медичного висновку

Задача SIGN_COMPOSITION

Мета

Задача SIGN_COMPOSITION виконується асинхронно, і є задачею по підписанню чернетки медичного висновку всіх типів і категорій. Фінальна ціль задачі — підписати чернетку, провівши перевірки відповідності підписаного контенту, відповідності підписанта та перевірки накладання підпису.
Всі перевірки описані загальним процесом і деталізовані в підпорядкованих документу сторінках.

 

Передумови

  1. Задачу було створено відповідним методом REST API (PATCH/patients/composition/{compositionId}/sign)

  2. Задача має стан PENDING(очікує на перше виконання), або INTERNAL-ERROR(очікує на повторне виконання згідно з логікою і конфігурацією повторних спроб виконання задачі)

Процес

 

 

  1. Перевірка наявності інших задач МВ на підписання — логіка має на меті перевірити, чи є в системі інші задачі для того самого МВ, що очікують на перевірку підпису. Така процедура необхідна для запобігання декількох паралельних запитів на підписання одного і того самого МВ:

    1. Відбувається пошук в task_queue інших задач типу SIGN_COMPOSITION зі статусом відмінним від FAILED

      1. якщо задачі знайдені - поточна задача на підписання закінчується помилкою ANOTHER_SIGN_TASK_ALREADY_EXIST(1142)

      2. якщо не знайдені - процедура продовжує своє виконання

    2. Процедуру завершено успішно, виконання задачі продовжується;

  2. Перевірка затримки підписання: згідно з конфігурацією перевіряє дозволений час затримки між створенням чернетки та безпосереднім підписанням МВ для даної категорії:

    1. Перевіряється конфігурація дозволеної затримки між створенням чернетки і підписанням для даного типу МВ, що вимірюється в максимальній кількості годин

      1. Якщо затримка більше, ніж дозволений період (або менше нуля, чого ніколи не має траплятись), то процедура закінчує виконання задачі з помилкою CREATE_SIGN_DELAY_EXCEEDED (1124)

      2. В інших випадках процедура продовжує своє виконання

    2. Процедура вважається успішно завершеною, задача продовжує своє виконання;

  3. Перевірка накладання: перевіряє чи підпис накладено вірно, і чи є підпис валідним:

    1. Тіло підпису, що надано в запиті передається в сервіс DS засобами RPC методу decode_signed_content

    2. Якщо сервіс

      1. повернув нуллове поле content - процедура завершує виконання задачі помилкою SIGVER_FAILED_NO_PAYLOAD (з поясненням content is null or blank)

      2. повернув порожнє поле content - процедура завершує виконання задачі помилкою SIGVER_FAILED_NO_PAYLOAD ( з поясненням content is blank)

      3. не повернув відповіді (або повернув відповідь невідповідної структур и) процедура завершує виконання задачі помилкою SIGVER_FAILED_BAD_CONTENT (1099)

      4. повернув будь-яке значення в полі validation_error_message процедура завершує виконання задачі помилкою SIGVER_FAILED_BAD_CERT (1020)

      5. повернув жодного підпису - процедура завершує виконання задачі помилкою SIGVER_FAILED_NO_SIGNATURES (1021)

      6. повернув декілька підписів - процедура завершує виконання задачі помилкою SIGVER_FAILED_MULTIPLE_SIGNATURES (1022)

    3. Для кожного з накладених підписів перевіряється значення поля is_valid у відповіді сервісу RPC. Якщо накладено хоча б один невалідний підпис - то процедура завершує виконання задачі з помилкою SIGVER_FAILED_INVALID_SIGNATURE (1023)

    4. Процедура завершує своє виконання успішно, виконання задачі продовжується;

  4. Перевірка відповідності підписаного контенту: перевіряє чи підпис було накладено на відповідний об'єкт запису МВ без будь-яких модифікацій після створення чернетки:

    1. Перевіряє статус об'єкта, що підписується

      1. якщо статус не рівний PRELIMINARY - процедура завершує виконання задачі помилкою CANT_SIGN_NON_PRELIMINARY_COMPOSITION (1041)

      2. в інших випадках — виконання процедури продовжується

    2. Перевіряє контент в підписаному обʼєкті та порівнює з об'єктом Composition

      1. якщо контент не співпадає, процедура завершує виконання задачі помилкою SIGNING_CONTENT_MISMATCH(1042)

      2. в інших випадках — виконання процедури продовжується

    3. Процедуру завершено успішно, виконання задачі продовжується;

  5. Перевірка відповідності підписанта: перевіряє дані в сертифікаті підпису на відповідність даним про автора згідно з Composition.author і даними Employee:

    1. Додаток отримує інформацію про підписанта з сертифікату КЕП з сервісу, а саме - значення поля відповідного до РНОКПП з сертифікату

    2. Відбувається звірка відповідності РНОКПП данним зазначеним в профілі employee, якого було вкказано автором (Composition.author)

      1. Якщо employee.party.no_tax_id == true то перевіяється, що значення ДРФО відповідає хоча б одному з документів для employe.party. При порівнянні також застосовуються правила транслітерації літер

        1. якщо відповідність знайдено, то процедура продовжує своє виконання

        2. якщо відповідності не знайдено - процедура завершує виконання задачі з кодом SIGVER_FAILED_DOCUMENTS_DONT_MATCH(1024)

      2. В усіх іших варіантах перевіряється, що значення employee.party.tax_id дорівнює полю ДРФО в сертифікаті підписанта

        1. якщо поля рівні - процедура завершує своє виконання успішно

        2. якщо не рівні - процедура завершує виконання задачі помилкою SIGVER_FAILED_DRFO_DOESNT_MATCH(1025);

  6. Перевірка зв'язаного МВ: має на меті переконатись, що висновок який вказано в relatesTo існує і має статус FINAL;

  7. Оновлення статусу — змінює статус МВ в БД, а також статус зв'язного МВ (у випадку AMENDED для МВТН);

  8. Збереження МВ — зберігає дані підписаного МВ в об'єктному накопичувачі(ceph);

  9. Для задач типу TEMP-DISABILITY, що були успішно виконані на цьому етапі планується виконання задачі CREATE ERLN RECORD (в стані PENDING).

ЕСОЗ - публічна документація