API. Cancel Care plan_UA

Ціль

Даний веб-сервіс дозволяє відмінити План лікування для випадків, коли від нього відмовились або план був заведений помилково.

Основні положення

1. Він може бути відмінений автором Плану лікування, який має дозвіл від пацієнта на редагування Плану лікування

2. Відміна повинна бути підписана електронним ключем. Так, всі дані по Плану лікування (без даних активностей) необхідно надати.

3. Статус Плану лікування міняється в асинхронний спосіб. Результат задачі є посилання на деталі плану лікування.

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

Apiary

Авторизація

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

  • Повернути (401, 'unauthorized'), якщо валідація неуспішна

• Перевірити, що по токену не закінчився строк дії

  • у випадку помилки - повернути код (401, 'unauthorized')

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

  • Повернути (403, 'invalid scopes') в разі невалідних скоупів/scope(s)

Перевірити юридичну особу

• Отримати client_id з токену

• Перевірити статус юридичної особи на відповідність ACTIVE

  • В разі помилки - повернути код 409 ('Legal entity must be ACTIVE')

• Перевірити тип юридичної особи в конфігураційних параметрах me_allowed_transactions_le_types

  • В разі помилки - повернути код 409 ('Action is not allowed for the legal entity type')

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

• Отримати ідентифікатор user_id з токену.

• Перевірити, що користувач є активним співробітником та має погодження, яке:

  • визначений як автор плану лікування та має активний дозвіл від пацієнта на редагування плану лікування (ідентифікатор плану лікування з URL)

  • повернути 403 ('Access denied') у випадку, коли співробітник не є автором плану лікування, або не має права на редагування

Перевірити консистентність даних

• Впевнитись, що наданий план лікування пов'язаний з пацієнтом (з URL)

  • Повернути 404 (not found) у випадку помилки

Перевірити електронний підпис

• Перевірити, що електронний підпис валідний та дійсний

• Перевірити, що електронний підпис належить користувачу

  • перевірити, що DRFO з електронного підпису та party.tax_id користувача відповідають

Перевірити зміну статусу

• Отримати план лікування по id

• Перевірити статус:

  • Статус плану лікування повинен помінятися у відповідності до Care plan status model.

    • Повернути 409 ('Care plan in status <cancelled/completed> cannot be cancelled') у випадку помилки

Перевірити причини статусу

Перевірити заповненість даних в полі $.status_reason

• Перевірити, що тип поля відповідає концепції кодування

• Перевірити, що концепція кодування відповідає значенням довідника eHealth/care_plan_cancel_reasons 

• Перевірити значення на належність у довіднику, вказаному вище

Перевірити активності

• Отримати активності плану лікування

• Перевірити, що план лікування не має хоча б однієї активності або всі активності не в final status. 

  • Повернути 409 ('Care plan has unfinished activities'), якщо знайдена хоча б одна активність не в фінальному статусі

Перевірити контент

Підписний контент має відповідати плану лікування в БД/DB для змін

1. Відобразити план лікування з БД/DB

2. Виключити з підписного контенту $.status_reason

3. Порівняти отриманий План лікування з підписним контентом

   1. У випадку, якщо два об'єкти не співпадуть - повернути 422 ('Signed content doesn't match with previously created care plan')

Логіка сервісу

1. Зберегти підписний контент до файлового сховища

2. Оновити статус плану лікування (також оновити updated_at, updated_by)

3. Встановити $.status_reason та $.status_history