API. Prequalify Care Plan Activity_UA

Ціль

Даний веб-сервіс (WS) дозволяє перевірии активність плану лікування на можливість визначення чи може медична програма бути використана в даному конкретному випадку чи ні.

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

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

2. Активність повинан бути підписана цифровим підписом (DS)

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

Apiary

Авторизація

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

  • Повернути (401, 'Invalid access token') в разі неуспішної валідації

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

  • в разі помилки - повернути (401, 'Invalid access token')

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

  • Повернути (403, 'Your scope does not allow to access this resource. Missing allowances: care_plan:write') в разі невалідних скоупів

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

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

• Перевірити, що статус юридичної особи = ACTIVE

  • в разі помилки - повернути 409 ('client_id refers to legal entity that is not active')

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

  • в разі помилки - повернути 409 ('client_id refers to legal entity with type that is not allowed to create medical events transactions')

Перевірити план лікування

• Отримати ідентифікатор плану лікування з URL

• Перевірити план лікування:

  • належить пацієнту (з url)

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

  • не в final status

    • в разі помилки - повернути 422 ('Invalid care plan status')

  • Для плану лікування period.end >= current date.

    • в разі помилки - повернути 422 ('Care Plan end date is expired')

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

• Отримати person_id з URL

• Перевірити, що статус пацієнта = active

  • в разі помилки - повернути 409 ('Person is not active')

• Якщо пацієнт є person - перевірити, що verification_status пацієнта не дорівнює NOT_VERIFIED.

  • в разі NOT_VERIFIED - повернути помилку 409, "Patient is not verified"

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

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

• Перевірити, що користувач має активного та погодженого співробітника з юридичної особи згідно (token), що:

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

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

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

Активність повинна бути валідована. Користувач заповнює наступні поля в активності:

Перевірити ідентифікатор плану лікування

Так як ідентифікатор плану лікування повинен міститися в підписаному контенті, $.care_plan очікується в тілі запиту

• Перевірити, що значення відповідає ідентифікатору плану лікування з URL

  • в разі помилки - повернути 409 ('Care Plan from url does not match to Care Plan ID specified in body')

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

Перевірити значення поля $.author, яке є обов'язковим

• Перевірити, що співробітник відноситься до користувача та юридичної особи (from token)

• Співробітник:

  • має активний апрувал на план лікування

  • належить користувачу

    • в разі помилки - повернути 422 ('User is not allowed to create care plan activity for the employee')

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

1. Тип

Перевірити значення поля $.detail.kind, яке є обов'язковим

• Перевірити, що значення типу enum: medication_request, service_request

  • Повернути 422 ('value is not allowed in enum')

2. Продукт

Перевірити значення поля $.detail.product_reference, яке є обов'язковим

Якщо $detail.kind=medication_request:

• Перевірити, що значення це валідне посилання на медичний ресурс.

  • Повернути 422 ('Cannot refer to service for kind = medication_request')

• Перевірити ЛЗ:

  • є в статусі = active

    • в разі помилки - повернути 422 ('Medication should be active')

  • тип є INNM_DOSAGE

    • в разі помилки - повернути 422 ('Medication does not exist')

• Перевірити, що відсутні дублюючі активності (status=scheduled, in_progress) з тим самим ЛЗ в плані лікування

  • Повернути 422 (“Another activity with status ‘scheduled' or ‘in_progress' already exists in the current Care plan”)

Якщо $.detail.kind=service_request:

• Перевірити, що значення є посиланням на сервіс або service_group

  • Повернути 422 ('Cannot refer to medication for kind = service_request')

• Перевірити, що сервіс або service_group активні

  • Повернути 422 ('<Service/Service group> should be active')

• Перевірити, що активності відсутні (status=scheduled, in_progress) з тим самим сервісом або service_group в плані лікування

  • Повернути 422 (“Another activity with status ‘scheduled' or ‘in_progress' already exists in the current Care plan“)

3. Код причини

Перевірити значення поля $.detail.reason_code, якщо вказано

• Перевірити, що значення відповідає значенню довідника eHealth/ICD10_AM/condition_codes

  • in case of error - return 422 ('value is not allowed in enum')

4. Посилання на причини

Перевірити значення поля $.detail.reason_reference, якщо вказано

• Перевірити, що значення є масивом з посиланням на типи condition, observation, diagnostic report, clinical impression.

  • в разі помилки - повернути 422 ('value is not allowed in enum')

• Перевірити, що кожне посилання:

  • це валідне ME

  • належить пацієнту ($.subject)

    • в разі помилки - повернути 422 ('<medical event type> with such ID is not found')

• Якщо $.detail.reason_reference=clinical_impression:

  • Перевірити, що клінічна оцінка це валідне посилання clinical_impression.code.coding.code та конфігураційні параметри CLINICAL_IMPRESSION_PATIENT_CATEGORIES_<CODE.CODING.CODE>_VALIDITY_PERIOD: різниця між now() та датою clinical_impression.inserted_at повинна бути менше ніж значення конфігураційного параметру (вказано в config для відповідної категорії плану лікування) для коду клінічної оцінки

    • в разі помилки - повернути 422 ("Clinical impression with patient category exceeds validity period")

5. Мета

Перевірити значення поля $.detail.goal, якщо вказано

• Перевірити, що значення відповідає значенням словника eHealth/care_plan_activity_goals

  • в разі помилки - повернути 422 ('value is not allowed in enum')

6. Кількість

Перевірити значення поля $.quantity, якщо вказано

• Перевірити, що $.quantity.value вказано, та тип цифровий, більше нуля

  • Повернути помилку валідації схеми 422

• Встановити remaining_quantity.value = $.quantity.value

7. Заплановано

Якщо вказано, перевірити, що наявне одне з полів $.detail.scheduled_[x] field: scheduled_timing, scheduled_period або scheduled_string.

• Повернути 422 ('Only one of the parameters must be present') якщо вказано більше ніж одна

Перевірити значення scheduled_timing, якщо вказано

• Перевірити значення схеми є Timing type

  • в разі помилки - повернути помилку валідації схеми 422

• Якщо вказано, перевірити значення event відповідно значення $.CarePlan.Period

  • in case of error - return 422 ('event is not within care plan period range')

• Якщо вказано, перевірити bounds_period відповідно значення $.CarePlan.Period

  • в разі помилки валідації bounds_period.end - повернути 422 ('Period end time must be within care plan period range, after period start date')

  • в разі помилки валідації bounds_period.start - повернути 422 ('Period start time must be within care plan period range')

• Якщо вказано, перевірити bounds_duration відповідно значення $.CarePlan.Period. Розразувати пов'язані дату початку як дата початку плану лікування, якщо активність була створена до того, як почався план лікування, в іншому випадку, якщо активність була створена під час виконання плану лікування - пов'язана дата початку розраховується, як дата створення активності. Пов'язана дата закінчення у зв'язку з датою початку плюс кількість розрахованих днів вказаних в bounds_duration.

  • Якщо поле comparator в bounds_duration - використати його для порівняння значення bounds_duration та періоду дії плану лікування (можливі значення >, >=, =, <=, <)

  • в разі помилки - повернути 422 ('Bounds duration must be within care plan period range')

• Якщо вказано, перевірити значення поля when є в довіднику EVENT_TIMING

  • в разі помилки - повернути 422 ('value is not allowed in enum')

• Якщо вказано, перевірити bounds_range згідно значення $.CarePlan.Period: розрахувати пов'язаниі дати початку та закінчення для bounds_range.low та bounds_range.high як описано для bounds_duration (але без поля comparator). Також, валідація low.code = high.code, high.value > low.value

  • в разі помилки валідації bounds_range.low - повернути 422 ('low must be within care plan period range, less than high, have the same code as high')

  • в разі помилки валідації bounds_range.high - повернути 422 ('high must be within care plan period range')

• якщо вказано, перевірити значення поля day_of_week, щоб була відповідність довіднику DAYS_OF_WEEK

  • в разі помилки - повернути 422 ('value is not allowed in enum')

• якщо вказано, перевірити, що time_of_day відповідає структурі ^([01][0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)(\.[0-9]+)?$

  • в разі помилки - повернути 422 ('string does not match pattern')

Перевірити значення поля scheduled_period, якщо вказано:

• Перевірити значення схеми по типу Period

  • в разі помилки - повернути помилку валідації 422

• Перевірити значення у відповідності до $.CarePlan.Period

  • в разі помилки валідації period.end - повернути 422 ('Period end time must be within care plan period range, after period start date')

  • в разі помилки валідації period.start - повернути 422 ('Period start time must be within care plan period range')

8. Розміщення

Перевірити значення поля $.detail.location, якщо вказано

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

• Перевірити, що підрозділи є активними та юридична особа підрозділів має активний статус

  • Повернути 422 ('Division is not active')

9. Виконавець

Перевірити значення поля $.detail.performer, якщо вказано

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

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

  • Повернути 422 ('Invalid employee status')

10. Добова кількість

Перевірити значення поля $.detail.daily_amount, якщо вказано.

• Перевірити, що тип активності = medication_request

  • Повернути 422 ('Field is allowed for medication request activities only') в разі, якщо тип не є medication_request

11. Не виконувати прапорець

Перевірити значення в полі $.do_not_perform

• Перевірити, що значення = false

  • в разі помилки - повернути 422 ('not allowed in enum')

12. Статус

Перевірити значення поля $.status

• Перевірити, що його значення = scheduled

  • в разі помилки - повернути 422 ('value is not allowed in enum')

Перевірити програми

Перевірити значення поля $.programs

• Перевірити, що програма існує та активна

  • якщо не знайдено або is_active==false повернути 200 з status = INVALID та rejection_reason "Program not found"

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

  • Якщо продуктом є medication - перевірити, що медикамент має бренд, який є активним учасником програми (program_medications table)

    • в разі, якщо не знайдено або is_active==false повернути 200 з status = INVALID та rejection_reason "Medication is not included in the program"

  • Якщо продуктом є service - перевірити, що сервіс є активним учасником програми

    • в разі, якщо не знайдено або is_active==false повернути 200 з status = INVALID та rejection_reason "Service is not included in the program"

  • Якшр продуктом є service_group - перевірити, що сервісна група є активним учасником програми

    • якщо не знайдено або is_active==false повернути 200 з status = INVALID та rejection_reason "Service group is not included in the program"

• Перевірити налаштування медичної програми (prm.medical_programs table):

  • якщо вказано параметр speciality_types_allowed:

    • Перевірити спеціалізацію автора в speciality_types_allowed

      • в разі помилки - повернути 200 з status = INVALID та rejection_reason “Author’s specialty doesn't allow to create activity with medical program from request”

  • якщо вказано параметр conditions_icd10_am_allowed або/і conditions_icpc2_allowed:

    • Перевірити, що пов'язаний план лікування має коди станів в полі addresses, які відповідають кодам, вказаним в conditions_icd10_am_allowed або/і conditions_icpc2_allowed (в залежності від довідника - eHealth/ICD10_AM/condition_codes або eHealth/ICPC2/condition_codes)

      • в разі помилки - повернути 200 з status = INVALID та rejection_reason “Care plan diagnosis is not allowed for the medical program“

  • Якщо є параметр providing_conditions_allowed:

    • Перевірити пов'язані плани лікування мають значення в полі terms_of_service, що включено в перелік паметрів providing_conditions_allowed

      • в разі помилки - повернути 200 з status = INVALID та rejection_reason “Care plan’s terms of service are not allowed for the medical program“

  • якщо вказано параметр patient_categories_allowed:

    • перевірити, чи patient_categories_allowed не нуль, то $.detail.reason_reference повинен містити посилання на clinical_impression з категорією пацієнтів

    • перевірити, чи patient_categories_allowed має коди в $.detail.reason_reference.[].clinical_impression.code.[].value, що відповідають кодам, вказаним в pointed in patient_categories_allowed

      • в разі помилки повернути 200 з status = INVALID та rejection_reason ("Clinical impression with patient category should be present in request for this medical program")

Якщо програма відповідає вимогам, встановити статус "VALID" у відповідності до apiary.

Сервісна логіка

1. Відобразити відповідь з результатом перевірки у відповідності до визначення, що медична програма може бути застосована в даному випадку чи ні