Ціль

1. Даний веб-сервіс (WS) розроблено для створення дозволу на сутність, що є агрегуючою сутністю (контекстом) для інших сутностей (episode_of_care, diagnostic_report, care_plan), АБО заборонену групу АБО дігностичний звіт, АБО на service_request з врахуванням його permitted_resources АБО на відміну взаємодії чи процедури.

2. Дозволи обробляються асинхронним шляхом.

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

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

1. API Create Approval

Авторизація

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

   1. в разі помилки - повернути 401 (“Invalid access token”) в разі неуспішної валідації

2. Перевірити, що токен дійсний

   1. в разі помилки - повернути 401 (“Invalid access token”)

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

   1. повернути 403 (“Your scope does not allow to access this resource. Missing allowances: approval:create ”) в разі невалідних скоупів

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

Перевірити користувача

1. Granted_to.employee_id повинні бути активні

   1. в разі помилки - повернути 422 “Should be active“

2. Перевірити, що співробітник належіть тій самій юридичній особі що і користувач:

   1. client_id з токену повинен бути пов'язаний з employee_id з об'єкту granted_to.

      1. в разі помилки - повернути 422 “Employee <employee_id> doesn't belong to your legal entity“

Перевірити ресурси чи блоки ресурсів

1. Дозволи відпрацьовуються асинхронно

Перевірити ресурси

1. якщо episode_of_care вказано в запиті як код ресурсу

   1. Перевірити, що episode_of_care в рапиті існує та знаходиться в статусі активний або закритий в DB

      1. в разі помилки - повернути 422 (Episode is canceled)

2. якщо diagnostic_report вказано в запиті як код ресурсу

   1. Перевірити, що блок diagnostic_report в запиті існує в фінальному статусі в DB

      1. в разі помилки - повернути 422 (Diagnostic report in \"entered_in_error\" status can not be referenced or Diagnostic report with such id is not found)

3. якщо care_plan вказано в запиті як код ресурсу

   1. Перевірити care_plan з запиту присутній в DB

      1. в разі помилки - повернути 422 (Care plan with such id is not found)

   2. Перевірити, що в запиті відсутні інші об'єкти

      1. в разі помилки - повернути 422 (Approval for care plan can not contain other entities)

4. якщо взаємодія наявна вказана в запиті як код ресурсу

   1. Перевірити, що взаємодія з запиту присутня в DB

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

5. якщо процедура присутня в запиті як блок ресурсу

   1. Перевірити, що процедура з запиту присутня в DB

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

Перевірити service_request

1. Якщо блок service_request присутній в запиті

   1. Get Service_request details (тільки в активному стані)

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

Перевірити forbidden_group

1. Якщо блок forbidden_group вказано в запиті

   1. Check forbidden group in the request exists and is_active in DB

      1. in case of error return - 404 (not found)

Перевірити diagnoses_group

1. Якщо diagnoses_group block вказано в запиті

   1. Check diagnoses_group in the request exists and is_active in DB

      1. in case of error return - 404 (not found)

Перевірити пацієнта

1. Якщо patient block вказано в запиті

   1. Отримати patient_id з URL:

      1. Перевірити, що person_id з запиту відповідає patient_id з URL

         1. в разі помилки - повернути 404 (“Approval for one patient can not be created in another patient’s context”)

      2. існує та is_active в DB

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

Перевірити блок child_resource

1. Якщо child_resource не пустий:

   1. перевірити, що access_level == read

      1. в разі помилки - повернути 422 ("$.access_level. value is not allowed in enum")

   2. перевірити, що контекст $.child_resource.identifier.value відповідає $.resource.identifier.value

      1. в разі помилки - повернути 422 (Child resource context id is not equal to granted resource id)

   3. перевірити, що service_requests / forbidden_groups / diagnoses_group / patients не заповнені

      1. в разі помилки - повернути 422 (schema does not allow additional properties)

   4. перевірити, що максимальна кількість сутностей в ресурсі = 1

      1. в разі помилки - повернути 422 ($.resources.expected a maximum of 1 items but got 2)

Перевірити authentication_method персони

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

   1. якщо належить person, то GET auth_method використовує MPI {patient_id}

      1. якщо це OTP:

         1. направити SMS на auth_phone по otpч_verification сервіс POST /verifications

         2. зберегти погодження до DB

         3. зберегти authentication_method_current.type та номер до DB

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

      2. якщо оф-лайн

         1. зберегти доступ до DB

         2. зберегти authentication_method_current.type and number to DB

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

      3.  якщо це null:

         1. повернути error 409 (Person does not have active authentication method)

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

      1. зберегти погодження до DB

      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 може бути знайдений шляхом Get person's auth methods

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

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

2. знайти метод автентифікації в MPI.person_authentication_method

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

3. знайти метод автентифікації пацієнта, де 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.

Відмінити існуючий дозвіл

Знайти, якщо існують активні та дійсні дозволи, надані поточним patient_id, для тих же granted_resources, granted_to та access_level з запиту.

• Якщо знайдено - встановити їх статус на terminated. Такод, встановити updated_at та updated_by поточному користувачу.

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

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

2. Всі дозволи з forbidden_group має свій власний expires_at config parameter - env. configuration parameter

3. Всі дозволи з care_plan має свій власний expires_at config parameter - env. configuration parameter

4. Всі дозволи на картку пацієнта має свій власний expires_at config parameter - env. configuration parameter

5. Дозволи з child_resources буде створено на сутність, яка є контекстом для child_resources

6. Для дозволів на child_resource з ресурсом або service_request:

   1. встановити child_resource до блоку reason

   2. встановити service_request до блоку reason

7. Перевірити, чи granted_resource та\чи reason мають коди заборонених груп:

   1. якщо є записи з заборонених груп

      1. перевірити тип authentication_method для пацієнта

         1. якщо тип 'OTP' відправити SMS (Код <code> для доступу до даних про ВІЛ/РПП eHealth )

   2. якщо немає записів з заборонених груп та блок diagnoses_group вказано в запиті

      1. якщо група діагнозів містить коди з довідника ICD10:

         1. перевірити тип authentication_method для пацієнта

            1. якщо тип 'OTP' відправити SMS (Код <code>: доступ на групу діагнозів {diagnoses_group_code} eHealth )

      2. якщо група діагнозів містить коди з довідника ICPC2:

         1. перевірити тип authentication_method для пацієнта

            1. якщо тип 'OTP' відправити SMS (Код <code> доступ на групу діагнозів {diagnoses_group_code} eHealth )

   3. якщо відсутні коди заборонених груп

      1. перевірити тип authentication_method по пацієнту

         1. якщо тип = 'OTP' відправити SMS (Код авторизації дій в системі eHealth: <code>')