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

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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

  1. API Create Approval

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

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

Авторизація

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

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

Логіка

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

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 в запиті апрувала

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

  • No labels