Page Comparison

...

...

...

...

...

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

  • Повернути код повернути код 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")

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

...

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

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

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

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

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

...

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

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 та employee.type=value з employee_types в configuration: ALLOWED_SERVICE_REQUEST_REQUESTER_EMPLOYEE_TYPES)

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

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

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

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

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

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

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

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

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

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

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

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

16. Перевірити, що код в існуючому сервісі або групі сервісів дозволений для використання в 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}'"

17. Якщо було вказано програму, перевірити, що вона в інуючій програмі сервісів (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")

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. Перевірити 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"

20. перевірити 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"

21. Перевірити 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"

22. Перевірити 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"

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

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

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

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

...