Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Оновив згідно CSI-291
Table of Contents

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

...

  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 

...

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

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

granted_resources

access_level

access to

resources

episode_of_care

read

Читання всіх даних, вказаних в епізоді на апрувал

diagnostic_report

read

Читання всіх даних, вказаних в діагностичному звіті на апрувал

care_plan

read

Читання всіх даних, вказаних в плані лікування на апрувал

care_plan

write

Створення активностей для плану лікування

service_request

episode_of_care

diagnostic_report

read

Читання данних з permitted_resources в запиті апрувала

forbidden_group

forbidden_group

read

Читання всіх медичних даних з елементами (codes/services/service_groups) вказаних в апрувалі на заборонені групи

Перевірити authorize_with

...

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

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