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

1. API Create Approval

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

Перевірити запит на основі схеми JSON

Авторизація

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

2. Перевірити скоупи користувачів approval:create на можливість виконання даної операції

Логіка

1. Апрували виконуються в асинхронний спосіб

2. Користувач може сворити апрувал тільки для співробітника його юридичної особи

   1. client_id з токену повинен бути поєднаним з employee_id від об'єкту granted_to.

   2. granted_to.employee_id повинен бути активним.

3. Тільки користувачі з типами працівника "DOCTOR", "SPECIALIST", "ASSISTANT" можуть створювати апрувал

   1. Перевірити granted_to.identifier.value: employee_type = "DOCTOR"/"SPECIALIST"/"ASSISTANT" і працівник у статусі APPROVED у базі даних

      1. у разі помилки повернути - 422 з повідомленням “Invalid employee type“

4. Якщо блок service_request наявний в запиті

   1. Get Service_request details

       (тільки в статусі active)

   2. використовуй Response.permitted_resources як ресурси для апрувал (може бути епізод (episode) або diagnostic_report).

5. якщо блок forbidden_group вказано в запиті

   1. Перевірити, що заборона група з запиту існує та is_active в БД

      1. в разі помилки повернути - 404 (not found)

6. Перевірити patient_id: 

   1. якщо належить person, тоді отримати/GET auth_method з MPI використовуючи {patient_id}
      

      1. якщо це OTP:

         1. надіслати SMS до auth_phone за допомогою сервісу  otp_verification  POST /verifications

         2. зберегти апрувал в БД 

         3. зберегти authentication_method_current.type та номер в БД
            

         4. повернути authentication_method_current.type = OTP

      2. якщо це офлайн

         1. зберегти апрувал в БД

         2. зберегти authentication_method_current.type та номер в БД

         3. повернути  authentication_method_current.type = offline

      3. якщо це null:

         1. повернути помилку error 409 (Person hasn’t active authentication methods. It is necessary to add)

   2. якщо належить до preperson:

      1. зберегти апрувал до БД

      2. встановити статус апрувал status = active

      3. встановити по апрувал urgent = null 

Перевірити access_level

1. Перевірити, що access_level відповідає granted_resources:

   1. в разі помилки повернути код 422 ("Resource types [\"$.granted_resources[].code\"] not allowed to use write access_level")

Перевірити authorize_with

Пацієнт може передати id його auth_method з яким він має намір дати апрувал. Потрібний метод автентифікації (auth method) може бути знайдений за допомогою Get person's auth methods

1. перевірити що auth_method.id це UUID

   1. в разі помилки код 422

2. знайти auth method в MPI.person_authentication_method

   1. в разі помилки код 422, "such authentication method doesn't exist"

3. знайти auth method даного пацієнта, де  MPI.person_authentication_method.person_id = $.patient.id

   1. в разі помилки код 422, "such authentication method does not belong to this person"

4. перевірити, що auth_method.type = NA

   1. повернути помилку 422, "Сannot be confirmed by a method with type= NA. Use a different method."

5. перевірити, що даний метод активний ( authentication_method.ended_at > now() та is_active = true)

Дане поле опціональне/не обов'язкове та вказане в некількох полях authorize_with та зберігає type та phone_number в approvals.urgent.authentication_method_current.

Якщо апрувал не має даних полів, тоді вибрати той метод, який повертається з mpi як person's default method.

Додаткова логіка

1. Всі апрували в статусі "new" повинні бути видалені через 12 годин після створення - env. configuration parameter

2. Всі апрувалз на forbidden_group має власний expires_at конфігуруємий параметр (не довше, ніж для інших апрувалів) - env. configuration parameter