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

...

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

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

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

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

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

   1. Get Service_request details

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

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

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

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

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

5. Перевірити 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 

...

Перевірити authorize_with

...

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

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