Versions Compared

Old Version 1

changes.mady.by.user Dmytro Omelchenko (SoE eHealth)

Saved on

compared with

New Version Current

changes.mady.by.user Yuliia Mazur (UA SoE eHealth)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

...

...

...

...

...

...

Table of Contents
maxLevel7
minLevel1

...

Вимоги

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

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

  1. Create Service Request

Валідації

Авторизація

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

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

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

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

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

    • Повернути код 403 (

    403,

    • '

    invalid

    • Invalid scopes') в разі невалідних скоупів

  • Якщо BLOCK_UNVERIFIED_PARTY_USERS є true, тоді перевірити дані співробітника на свіпадіння наступним умовам: verification_status != NOT_VERIFIED або (verification_status = NOT_VERIFIED та updated_at <= current_date - UNVERIFIED_PARTY_PERIOD_DAYS_ALLOWED):

    • в разі неспівпадіння - повернути 403 ("Access denied. Party is not verified")

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

Декодувати контент, який є закодований в електронному підпису.
Використати веб-сервіс по електронному підпису. Метод перевіряє електронний підпис та повертає результат.
Див специфікацію сервісу specification

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

  2. Перевірити, що той, хто надіслав запит на сервіс це поточний користувач

2.1. Отримати метадані токену

...

2.2. Визначити party_id пов'язаний з цим user_id

Code Block
SELECT pu.party_id
FROM party_users pu
WHERE pu.user_id = :user_id;

2.3. Визначити employees пов'язаного з даним party_id в поточному MSP

Code Block
SELECT e.id
FROM employees e
WHERE e.party_id = :party_id
AND e.legal_entity_id = :client_id;

2.4 Переконатися, що $.requester.identifier.value відповідає співробітнику користувача

  1. Перевірити, що DS відповідає особі, яка направила запит на візит

3.1. Визначити party_id пов'язаного з requester ($.requester.identifier.value)

Code Block
SELECT p.tax_id
FROM employees e, parties p
WHERE e.party_id = p.id
AND e.id = :requester;

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

...

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

  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"

    2. в разі, якщо сервіс бути вказаний як код (не група сервісів) перевірити service_request.category=service.category from $code.identifier.value

      1. в разі помилки повернути код 422, "Category mismatch"

    3. якщо категорія в (hospitalization, transfer_of_care), не перевіряти service_request.category=service.category from $code.identifier.value

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

    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. якщо category = transfer_of_care, пацієнт може бути персоною та преперсоною

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

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

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

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

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

    4. якщо category = transfer_of_care,

      1. перевірити encounter.hospitalization.Discharge_Disposition='transfer_general', в разі помилки повернути код 422, "Context is not valid for service request with type $type"

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

    1. $.occurrenceDateTime 

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

    2. $.occurrencePeriod.start

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

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

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

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

  8. 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 and employee.is_active == true та employee.legal_entity_id == token.client_id

...

    1. та employee.type=

...

    1. value з employee_types в configuration: ALLOWED_SERVICE_REQUEST_REQUESTER_EMPLOYEE_TYPES)

  2. Той, хто направив запит є одним з поточних співробітників користувача

    1. в разі помилки повернути код 422 "User is not allowed to create service request for the employee"

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

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

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

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

  5. Посилання на причину повинна посилатися на валідний об'єкт медичної події (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"

  6. Дозволений Епізод лікування (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"

  7. Перевірити, що дозволений епізод не вказаний для категорії "laboratory_procedure"

    1. в разі помилки повернути код 422 "Permitted episodes are not allowed for laboratory category of service request"

  8. Перевірити, що expiration_date в майбутньому

    1. в разі помилки повернути код 422 "Expiration date can not be in past"

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

    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}'"

  10. Якщо було вказано програму, перевірити, що вона в інуючій програмі сервісів (type=service)

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

    2. у випадку type!= service повернути код 422 "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")

  11. Для кожної програми перевірити, що сервіс (або 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"

  12. Перевірити performer

    1. якщо category = transfer_of_care,

      1. виконавець направлений, в разі помилки вказати код 422, "performer is mandatory for category `transfer_of_care`"

      2. виконавець є діючим LE зі status=Active та is_Active=true, в разі помилки повернути код 422, "performer is not active legal entity"

  13. перевірити LocationReference

    1. якщо category = transfer_of_care,

      1. LocationReference це діючий підрозділ з типом (CLINIC, LICENSED_UNIT,AMBULANT_CLINIC,FAP) та status=Active та is_active=true, в разі помилки повернути код 422, "LocationReference is not an active division"

      2. LocationReference division.legal_entity_id=Performer, в разі помилки повернути код 422, "Division does not belong to performer legal entity"

  14. Перевірити PerformerType

    1. якщо category = hospitalization

      1. PerformerType направлено, в разі помилки повернути код 422, "PerformerType is mandatory for category hospitalization"

      2. PerformerType це код з dictionary.SPECIALITY_TYPE та відповідає конфігураційному файлу 'SERVICE_REQUEST_HOSPITALIZATION_SPECIALITY_TYPES', в разі помилки повернути код 422, "PerformerType=$PerformerType is forbidden for category hospitalization"

  15. Перевірити 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. Якщо activity.program вказана то $.service_request.program з таким же значенням повинен бути в запиті

        1. в разі помилки повернути код 409 з повідомленням ('Program from activity should be present in request')

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

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

  16. Перевірити статус верифікації пацієнта:

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

    2. В іншому випадку, перевірити, що статус пацієнта verification_status не рівняється NOT_VERIFIED.

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

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

  1. Згенерувати номер (див Human readable requisition number) на основі encounter id

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

  3. Зберегти дати до відповідної колекції в DB

  4. Зберегти посилання до підписного контенту в сховищі запитів на сервіс

  5. Якщо була вказана програма, змінити program_processing_status на New

Відправити SMS повідомлення

Якщо за-замовчування метод автентифікації пацієнта визначено як Determination of a default authentication method and return person's active auth_methods OTP або third_person.OTP, відправити SMS пацієнтом з номером.

З метою оптимізації коштів, тільки одна смс повинна бути направлена по одному візиту. Тому смс направляються тільки для першого запиту на сервіс в рамках вказаного візиту

  1. Знайти запити на сервіс по номеру

    1. якщо є тільки один запит на сервіс з таким номером - не відправляти sms

    2. якщо не знайдено - відправити sms пацієнту