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

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. Відобразити відповідь з результатом перевірки у відповідності до визначення, що медична програма може бути застосована в даному випадку чи ні

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