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

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

Version 1 Next »

Ціль

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

  • No labels