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

(RC-1 MRIN) PreQualify Service Request

Owned by Гліб Ущенко (Unlicensed)
Apr 02, 2021
5 min read

Requirements

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

Apiary

  1. PreQualify Service Request

Validations

Authorization

  • Verify the validity of access token

    • Return (401, 'unauthorized') in case of validation fails

  • Verify that token is not expired

    • in case of error - return (401, 'unauthorized')

  • Check user scopes in order to perform this action (scope = 'service_request:write')

    1. Return (403, 'invalid scopes') in case of invalid scope(s)

Validate request using JSON Schema

Return 422 with the list of validation errors in case validation fails

Validate legal entity

  • Check legal entity type: it has to be in me_allowed_transactions_le_types config parameter, has status = active 

    • in case of error return 409 "Action is not allowed for the legal entity"

Validate service request

  1. Validate that service request ID is unique

    1. $.id must be unique

      1. in case of error return 409 - "Service request with such id already exists"

  2. Requisition is a common identifier for the group of service requests and it must matches with one of the patient's episode of care number

    1. $.requisition must match with patient's episode of care number

      1. in case of error return 409 - "Incorrect requisition number"

  3. Service request category must refer to a valid dictionary

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

      1. in case of error return 409 "Incorrect service request category"

  4. Procedure code must refer to a valid dictionary

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

      1. in case of error return 409 "Incorrect procedure code"

  5. Patient must be active

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

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

    3. $.patient.identifier.value refer to active MPI (is_active == true and status == 'active')

  6. Context must be an active encounter

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

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

    3. $.context.identifier.value refer to existing encounter (status == 'finished')

  7. Occurence is a valid date-time in the future

    1. $.occurrenceDateTime 

      1. $.occurrence_date_time - ISO date must be greater current date-time

    2. $.occurrencePeriod.start

      1. $.occurrence_period.start - ISO date must be greater than current date-time

      2. $.occurrence_period.end - ISO date must be greater than current date-time and greater than $.occurrencePeriod.start

  8. Authored On is a valid date-time in the past

    1. $.authored_on - ISO date must be less than current date-time

  9. Requester_employee must be active employee within current legal entity

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

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

    3. $.requester_employee.identifier.value refer to active employee within current legal entity (employee.status == approved and employee.is_active == true and employee.legal_entity_id == token.client_id)

  10. Requester_legal_enity must be current legal enity

  11. Performer type must refer to a valid dictionary

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

      1. in case of error return 409 "Incorrect service request category"

  12. Supporting info must refer to a valid medical events object (Episode of Care) within specified patient. 

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

      1. in case of error return 409 "Incorrect supporting info"

  13. Reason reference must refer to a valid medical events object (Observation, Condition) within specified patient. 

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

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

      1. in case of error return 409 "Incorrect reason reference"

  14. Permitted Episode of care must refer to a valid medical events object (Episode of Care) within specified patient. 

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

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

      1. in case of error return 409 "Incorrect reason reference"

  15. Validate code is an existing service or service group that is allowed to be used in service_request

    1. in case not found or is_active == false return 422 "Service(Service group) not found"

    2. if request_allowed==false return 422 "Service request is not allowed for this service(service_group)"

    3. in case based_on passed in request

      1. If service_requests.code.identifier.value is service, validate $based_on[].activity.code.identifier.value = service_requests.code.identifier.value

        1. in case error return 422, "Service in activity differs from service in service request"

      2. If service_requests.code.identifier.value is service_group, validate $based_on[].activity.code.identifier.value = service_requests.code.identifier.value

        1. in case error return 422, "Service group in care plan activity differ from service group in service request"

      3. if service_requests.code.identifier.value is service/service group, validate $based_on[].activity.code.identifier.value is service/service group

        1. in case error return 422, "Activity referes to '#{service/service group}' but service request refers to '#{service group/service}'"

  16. Validate service category is equal to service request category in case service was defined as a code (not a service_group)

    1. Select category from PRM.services where id = $.code.identifier.value

      1. if PRM.services.category!=$.category OR PRM.services.category is not NULL  return 422 "Service category does not match with service request category"

  17. For each program validate it is an existing service program (type=service)

    1. in case not found or is_active==false write result in Data collection according to apiary

    2. in case type!= service write result in Data collection according to apiary - "Invalid program type"

    3. check if medical_programs.medical_program_settings.care_plan_required == true then the request should contain a based_on with care plan and activity that contains the same medical program

      1. in case of error return 422 with msg ("Care plan and activity with the same program should be present in request")

      2. check that program equal to $.activity[].program

        1. in case of error return 422 with msg ("Program from activity should be equal to program from request")

  18. For each program validate that service(or service_group) is an active member of the program

    1. Select request_allowed, is_active from PRM.program_services where service_id(or group_id) == $.signed_content.code.identifier.value and program_id=$.program.identifier.value

      1. if not found or is_active==false write result in Data collection according to apiary - "Service is not included in the program"

      2. if request_allowed==false write result in Data collection according to apiary -  "Service request is not allowed for this service(service_group) in this programm"

  19. For each program validate that doctor is allowed to create service request with the program for the current patient

    1. $.requester has an active declaration with the patient OR

    2. $.requester works in the same MSP with doctor that has an active declaration with the patient AND doctors employee_type== DOCTOR

      1. in case of error write result in Data collection according to apiary - "User is not allowed to create service request with the program for the patient"

  20. Validate based_on

    1. If submitted, check field has array with two values of Reference type: one is valid Care plan resource, another - Activity resource.

      1. in case of error return 422 with msg ("expected a minimum of %{min} items but got %{actual}")

    2. Verify Care plan:

      1. It should belong to the same person as set in service request

        1. in case of error return 422 with msg ("Care plan with such id is not found")

      2. It should be in active status

        1. in case of error return 422 with msg ("Care plan is not active")

      3. Care plan's period end (if exist) should be greater than current date or equal.

    3. Verify submitted Activity:

      1. It belongs to the Care plan.

        1. in case of error return 422 with msg ("Activity with such id is not found")

      2. It has activity.detail.kind=service_request; activity.detail.product_reference=service_request.code[].value.

        1. in case of error return 422 with msg ("Invalid activity kind")

      3. It has scheduled, in_progress status

        1. in case of error return 422 with msg ("Invalid activity status")

    4. Verify activity period: 

      1. If it has scheduled_timing:

        1. if bounds_period.end defined then check it greater than current date or equal.

      2. If it has scheduled_period:

        1. if scheduled_period.end defined then check it greater than current date or equal.

ELSE, if program meets the requirements write status "Valid" according to apiary.

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