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

RC_Sign declaration request v3 (modified - UA)

Пов'язана інформація

https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/583402204

Специфікація

Apiary

Процес ініціюється будь-яким співробітником з відповідними скоупами для даної юридичної особи та викликає передачу підписаної персони з допомогою цифрового підпису.

Процес асинхронний. Якщо всі перевірки успішно виконані, асинхронний процес створення персони починається з обробки повідомлення.

Сервісна логіка

  1. Тільки автентифіковані та авторизовані користувачі можуть використовувати даний сервіс.

  2. Тільки запити на декларацію в статусі APPROVED можуть бути підписані.

  3. Запит може бути підписаний тільки співробітником, який працює в тій же самій юридичній особі, в який був створений запит.

Авторизувати користувача

  1. Перевірити валідність токену доступу

    1. Повернути 401 в разі неуспішної валідації

  2. Перевірити скоупи на можливість виконання даної дії (scope = 'declaration_request:sign')

    1. Повернути 403 в разі неуспішних скоупів

Цифровий підпис

Декодувати контент, що закодований в цифровому підписі.
Використати метод по генеруванню цифрового підпису WS. Метод перевіряє цифровий підпис та повертає результат.
Див сервіс specification

Перевірити ДРФО

  1. Перевірити, що ДРФО в деталях сертифікату вказано та є валідним

  2. Перевірити, що ДРФО в деталях сертифікату відповідає ДРФО для Party

    1. Отримати party.tax_id за допомогою employee_id в масиві даних для персони

    2. Порівняти ДРФО зі Сертифікату з party.tax_id

      1. Змінити DRFO та TAX_ID на великі літери

      2. Змінити DRFO та TAX_ID на літери кирилиці

      3. Змінити DRFO на кирилицю та порівняти як літери кирилиці

    3. В разі неуспішнох валідації - згенерувати помилку 422

Мапінг латинських літер з кирилицею

%{"A" => "А", "B" => "В", "C" => "С", "E" => "Е", "H" => "Н", "I" => "І", "K" => "К", "M" => "М", "O" => "О", "P" => "Р", "T" => "Т", "X" => "Х"}

 

Перевірити запит

  1. Перевірити запит, використовуючи схеми JSON (Див specification)

    1. В разі неуспішних валідацій - згенерувати помилку 422

  2. Перевірити статус запиту на декларацію

    1. Якщо статус не APPROVED, - повернути помилку 'Incorrect status'

Перевірити статус верифікації персони

  • перевірити, що verification_status не дорівнює NOT_VERIFIED.

    • в разі помилки - повернути 409, "Patient is not verified"

Перевірити первинну декларації

Отримати parent_declaration_id з IL_DB.declaration_requests.parent_declaration_id.

  • Якщо parent_declaration_id заповнено, перевірити, що первинна декларація існує та має статус 'active'

    • в разі помилки - повирнути 404 ("Active parent declaration was not found")

Перевірити підписний контент

Перевірити декодований підписний контент з попередньо створеним в IL.db.

SELECT data.data_to_be_signed FROM declaration_requests WHERE id = {:id}

В разі, якщо вони не відповідають - згенерувати помилку 422 (message: "Signed content does not match the previously created content")

Перевірити співробітника

Declaration_request може бути підписаний будь-яким співробітником з відповідними скоупами для відповідної legal_entity_id.

  1. Отримати legal_entity_id (client_id) з токену

  2. Отримати employee_id з запиту

  3. Перевірити, що $.client_id=employees.legal_entity_id 

    1. в разі помилки повернути 422 

Перевірити мітку patient_signed

  • Якщо "patient_signed" не наявний в запиті, повернути 422 ("required property patient_signed was not present")

  • Якщо "patient_signed"=false в запиті, повернути 422 ("Patient must sign declaration form")

  • Якщо “patient_signed”=null, перевірити, що parent_declaration_id заповнений,

    • в разі помилки, повернути 422 ("Patient must sign declaration form")

Перевірити читабельний номер декларації

Отримати declaration_number з declarations.declaration_number.

  • якщо вказано повернути 422 - повідомлення 'Declaration with the same declaration_number is already exist in DB' 

Обробка

Зберегти підписану декларацію до сховища даних

  1. Отримати url для завантаження декларації.
    Використовувати метод Request a Secret WS

Parameter

Source

Parameter

Source

action'GET'bucket'DECLARATIONS'resource_id: DECLARATION_ID

resource_name: DECLARATION_NAME

 

2. Оновити підписану декларацію в сховищі даних

Оновити запит на декларацію:

  1. Змінити статус сутності в IL_DB.declaration_request на SIGNED

  2. Встановити updated_at - now() (Отримати поточні дату та час)

  3. Встановити updated_by - user_id (Отримати користувача з токену)

Отримати активні декларації

Здійснити пошук по активним деклараціям з використанням MPI ID

  1. Якщо знайдено, - розірвати їх та створити нову декларацію.

    • Якщо не знайдено - створити нову декларацію.

Призупити декларацію

В разі, якщо знайдено активну декларацію - розірвати всі шляхом зміни статусу на INACTIVE.

В разі, якщо parent_declaration_id для запиту на декларації не вказано - розірвати parent_declaration з вказаною причиною reason = 'auto_reorganization'.

Створити декларацію

  1. Перевірити authentication_method_current

    SELECT authentication_method_current FROM declaration_requests WHERE id = {:id}
    1. Якщо "type" = "OFFLINE"

      1.  встановити статус декларації "PENDING_VERIFICATION"

      2. встановити причину на 'offline'

    2. якщо "type" = "OTP" - встановити статус декларації "ACTIVE" 

    3. якщо "type" = "NA" - перевірити parent_declaration_id, якщо заповнено то встановити статус декларації "ACTIVE"

  2. Перевірити мітку на персоні 'no_tax_id'

    1. якщо 'no_tax_id'=true та parent_declaration_id заповнені

      1. встановити статус декларації "PENDING_VERIFICATION"

      2. встановити причину на 'no_tax_id'

    2. якщо ‘no_tax_id’=true та parent_declaration_id заповнені - встановити статус декларації "ACTIVE"

  3. Створити нову декларацію шляхом додавання нової сутності до таблиці декларацій ops_db без declaration_id.

    1. якщо є доступний запис в таблиці декларацій з тим самим id та declaration_request_id, повернути ok до IL

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