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

PreQualify Service Request_UA

Owned by Dmytro Omelchenko (SoE eHealth)
Last updated: May 23, 2022 by Nataliia Burdeina (NHSU partner, Edenlab)
4 min read

Вимоги

  1. Створення направлення

Apiary

  1. PreQualify Service Request

Валідації

Авторизація

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

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

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

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

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

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

Перевірити запит використовуючи JSON Schema

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

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

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

    • в разі помилки повернути код 409 "Action is not allowed for the legal entity"

Перевірити запит на сервіс

  1. Перевірити ID запиту на сервіс на унікальність

    1. $.id повинен бути унікальним

      • в разі помилки повернути код 409 - "Service request with such id already exists"

  2. Реквізити - це загальний ідентифікатор для групи запитів на сервіс та повинен співпадати з одним з епізодів пацієнта по номеру лікування

    1. $.requisition повинен співпадати з одним з епізодів пацієнта по номеру лікування

      1. в разі помилки повернути код 409 - "Incorrect requisition number"

  3. Категорія запитів на сервіси повинні посилатися на валідний довідник

    1. $.category.coding[*].system  == "eHealth/SNOMED/service_request_categories" 

      1. в разі помилки повернути код 409 "Incorrect service request category"

  4. Код процедури повинен посилатися на валідний довідник

    1. $.code.coding[*].system  == "eHealth/SNOMED/procedure_codes" 

      1. в разі помилки повернути код 409 "Incorrect procedure code"

  5. Пацієнт має бути активним

    1. $.patient.identifier.type.coding[*].system == "eHealth/resources"

    2. $.patient.identifier.type.coding[*].code == "patient"

    3. $.patient.identifier.value посилатися на активний MPI (is_active == true та status == 'active')

    4. в разі patients.preperson == true

      1. перевірити PREPERSON_SERVICE_REQUEST_ALLOWED_CATEGORIES (дані з довідника: eHealth/SNOMED/service_request_categories) конфігурація відповідна дозволеним категорія преперсон

        1. в разі помилки повернути код 422 (Category of service request is not allowed for prepersons)

  6. Контекст повинен бути активним візитом

    1. $.context.identifier.type.coding[*].system == "eHealth/resources"

    2. $.context.identifier.type.coding[*].code == "encounter"

    3. $.context.identifier.value посилатися на існуючий візит (status == 'finished')

  7. Створення є валідна дата-час в майбутньому

    1. $.occurrenceDateTime 

      1. $.occurrence_date_time - ISO дата повинна бути більше поточної дати-часу

    2. $.occurrencePeriod.start

      1. $.occurrence_period.start - ISO дата повинна бути більше поточної дати-часу

      2. $.occurrence_period.end - ISO дата повинна бути більше поточної дати-часу та більше ніж $.occurrencePeriod.start

    3. в разі based_on не вказано в запиті

      1. якщо активність плану лікування має detail.scheduled_timing.repeat.bounds_period - перевірити спвіпадіння по періоду bounds_period

      2. якщо активність плану лікування має detail.scheduled_period - перевірити спвіпадіння по періоду scheduled_period

      3. в інщому випадку - перевірити спвіпадіння по періоду care_plan.period

  8. Authored On це валідна дата-час в минулому

    1. $.authored_on - ISO дата повинна бути меньше ніж поточна дата-час

  9. Requester_employee повинен бути активний співробітник з поточною юридичної особою

    1. $.requester_employee.identifier.type.coding[*].system == "eHealth/resources"

    2. $.requester_employee.identifier.type.coding[*].code == "employee"

    3. $.requester_employee.identifier.value посилається на активного співробітника з поточною юридичною особою (employee.status == approved та employee.is_active == true та employee.legal_entity_id == token.client_id)

  10. Requester_legal_enity повинна бути поточна юридична особа

  11. Тип виконавця повинен посилатися на валідний довідник

    1. $.performer_type.coding[*].system  == "eHealth/SNOMED/service_request_performer_roles" 

      1. в разі помилки повернути код 409 "Incorrect service request category"

  12. Супроводжуюча інформація повинна посилатися на валідний об'єкт медичної події (Episode of Care) з вказанням конкретного пацієнта. 

    1. $.supporting_info.identifier.type.coding[*].system == "eHealth/resources"

      1. в разі помилки повернути код 409 "Incorrect supporting info"

  13. Посилання на причину повинна посилатися на валідний об'єкт медичної події (Observation, Condition) з вказанням конкретного пацієнта. 

    1. $.reason_reference.identifier.type.coding[*].system == "eHealth/resources"

    2. $.reason_reference.identifier.type.coding[*].code in ("condition", "observation")

      1. в разі помилки повернути код 409 "Incorrect reason reference"

  14. Дозволений Епізод лікування (Episode of care) повинен посилатися на валідний об'єкт медичної події (Episode of Care) з вказанням конкретного пацієнта. 

    1. $.permitted_episodes.identifier.type.coding[*].system == "eHealth/resources"

    2. $.permitted_episodes.identifier.type.coding[*].code == "episode_of_care"

      1. в разі помилки повернути код 409 "Incorrect reason reference"

  15. Перевірити, що код в існуючому сервісі або групі сервісів дозволений для використання в service_request

    1. в разі, якщо не знайдено або is_active == false повернути код 422 "Service(Service group) not found"

    2. if request_allowed==false повернути код 422 "Service request is not allowed for this service(service_group)"

    3. в разі based_on передано в запиті

      1. якщо service_requests.code.identifier.value це сервіс, перевірити $based_on[].activity.code.identifier.value = service_requests.code.identifier.value

        1. в разі помилки повернути код 422, "Service in activity differs from service in service request"

      2. Якщо service_requests.code.identifier.value це service_group, перевірити $based_on[].activity.code.identifier.value = service_requests.code.identifier.value

        1. в разі помилки повернути код 422, "Service group in care plan activity differ from service group in service request"

      3. якщо service_requests.code.identifier.value це сервіс/група сервісів, перевірити $based_on[].activity.code.identifier.value is service/service group

        1. в разі помилки повернути код 422, "Activity referes to '#{service/service group}' but service request refers to '#{service group/service}'"

  16. Перевірити категорію сервісу на відповідність категорії запиту сервісу в разі, якщо сервіс було визначено як код (не service_group)

    1. Вибрати категорію з PRM.services де id = $.code.identifier.value

      1. якщо PRM.services.category!=$.category OR PRM.services.category не NULL  повернути код 422 "Service category does not match with service request category"

  17. Для кожної програми перевірити, що вона в існуючій програмі сервісів (type=service)

    1. в разі, якщо не знайдено або is_active==false записати результат в колекції даних у відповідності до apiary

    2. в разі, якщо type!= service записати результат в колекції даних у відповідності до apiary - "Invalid program type"

    3. перевірити, що medical_programs.medical_program_settings.care_plan_required == true тоді запит повинен мати based_on з планом лікування та активністю з тою ж програмою

      1. в разі помилки повернути код 422 з повідомленням ("Care plan and activity with the same program should be present in request")

      2. перевірити, що программа відповідє $.activity[].program

        1. в разі помилки повернути код 422 з повідомленням ("Program from activity should be equal to program from request")

  18. Для кожної програми перевірити, що сервіс (або service_group) діючий учасник програми

    1. Вибрати request_allowed, is_active з PRM.program_services де service_id(or group_id) == $.signed_content.code.identifier.value та program_id=$.program.identifier.value

      1. якщо не знайдено або is_active==false записати результат в колекції даних у відповідності до apiary - "Service is not included in the program"

      2. якщо request_allowed==false записати результат в колекції даних у відповідності до apiary -  "Service request is not allowed for this service(service_group) in this programm"

  19. Для кожної програми перевірити, що лікар може створювати запит на сервіс з програмою для поточного пацієнта

    1. $.requester має активну декларацію з OR пацієнта

    2. $.requester works в тій же MSP з лікарем, який має активну декларацію з пацієнтом та для лікаря employee_type== DOCTOR

      1. в разі помилки записати результат в колекції даних у відповідності до apiary - "User is not allowed to create service request with the program for the patient"

  20. Перевірити based_on

    1. якщо вказано, перевірити, що поле є масивом з двома значеннями типу Reference: одна - це валідний ресурс плану лікування, інший - ресурс активності.

      1. в разі помилки повернути код 422 з повідомленням ("expected a minimum of %{min} items but got %{actual}")

    2. Перевірити План лікування:

      1. Вона повинна належати тому ж пацієнту як набір в запиті сервісів

        1. в разі помилки повернути код 422 з повідомленням ("Care plan with such id is not found")

      2. Він повинен бути активним

        1. в разі помилки повернути код 422 з повідомленням ("Care plan is not active")

      3. Дата закінчення періоду плану лікування (якщо заповнено) повинна бути більна ніж поточна дата або більше.

    3. Перевірити вказану активність:

      1. Вона відповідає Плану лікування.

        1. в разі помилки повернути код 422 з повідомленням ("Activity with such id is not found")

      2. Вона має activity.detail.kind=service_request; activity.detail.product_reference=service_request.code[].value.

        1. в разі помилки повернути код 422 з повідомленням ("Invalid activity kind")

      3. Вона має статус scheduled, in_progress 

        1. в разі помилки повернути код 422 з повідомленням ("Invalid activity status")

      4. якщо вказана кількість, то перевірити, що remaining_quantity більше нуля:

        1. в разі помилки повернути код 422, "The number of available services according to the care plan activity has been exhausted"

    4. Перевірити період активності: 

      1. На наявність scheduled_timing:

        1. якщо bounds_period.end відрізняється, то перевірити, що від більше поточної дати або дорівнює.

      2. На наявність scheduled_period:

        1. якщо scheduled_period.endвідрізняється, то перевірити, що від більше поточної дати або дорівнює.

  21. Якщо пацієнт це person - перевірити статус верифікації:

    1. Якщо SR має based_on з валідною активністю, то пропустити перевірку.

    2. Перевірити, що verification_status пацієнта не дорівнює NOT_VERIFIED.

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

В противному випадку, якщо програма відповідає вимогам - записати "Valid" у відповідності до apiary.

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