API. Cancel Care Plan activity_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 ('client_id refers to legal entity with type that is not allowed to create medical events transactions')

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

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

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

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

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

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

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

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

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

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

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

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

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

• Отримати активність по id

• Перевірити activity.detail.status:

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

    • Повернути 409 (Invalid activity status) у випадку помилки

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

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

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

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

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

Перевірити пов'язані сутності

• якщо для активності kind = medication_request:

  • Перевірити, що відсутні medication request requests в статусі NEW на основі активності

    • в разі помилки - повернути 409 (Unable to cancel activity with new Medication Request requests).

  • Перевірити, що відсутні medication requests в статусі ACTIVE на основі активності

    • в разі помилки - повернути 409 (Unable to cancel activity with active Medication requests).

• якщо активність kind = service_request:

  • Перевірити, що відсутні service requests в статусі active, in_progress на основі активності

    • в разі помилки - повернути 409 (Unable to cancel activity with <active/in_progress> Service requests).

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

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

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

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

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

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

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

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

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

3. Встановити detail.status_reason