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

RC_Create approval_v2_EN

Purpose

  1. This WS is designed to create approval on entity, which aggregate other entities (episode_of_care, diagnostic_report, care_plan), OR forbidden group OR diagnoses group, OR on service_request including it’s permitted_resources OR on cancel for encounter and procedure.

  2. Approvals are processed in the async way

  3. Only authenticated and authorized employees with appropriate scope can create approval.

Specification

  1. API Create Approval

Authorize

  1. Verify the validity of access token

    1. in case of error - return 401 (“Invalid access token”) in case of validation fails

  2. Verify that token is not expired

    1. in case of error - return 401 (“Invalid access token”)

  3. Check user scopes in order to perform this action (scope = 'approval:create ')

    1. return 403 (“Your scope does not allow to access this resource. Missing allowances: approval:create ”) in case of invalid scope(s)

Validate request

Validate user

  1. Granted_to.employee_id should be active

    1. in case of error - return 422 “Should be active“

  2. Check if employee from the same legal entity as user:

    1. client_id from token should be linked with employee_id from granted_to object.

      1. in case of error - return 422 “Employee <employee_id> doesn't belong to your legal entity“

Validate resources or block of resources

  1. Approvals are processed in the async way

Validate resources

  1. if episode_of_care is presented in request as the code of resource

    1. Check episode_of_care in the request exists and is in active or closed status in DB

      1. in case of error return - 422 (Episode is canceled)

  2. if diagnostic_report is presented in request as the code of resource

    1. Check diagnostic_report block in the request exists and is in final status in DB

      1. in case of error return - 422 (Diagnostic report in \"entered_in_error\" status can not be referenced or Diagnostic report with such id is not found)

  3. if care_plan is presented in request as the code of resource

    1. Check care_plan in the request exists in DB

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

    2. Check there no other objects in request

      1. in case of error return - 422 (Approval for care plan can not contain other entities)

  4. if encounter  is presented in request as the code of resource

    1. Check encounter in the request exists in DB

      1. in case of error return - 422 (not found)

  5. if procedure is presented in request as the code of resource

    1. Check procedure in the request exists in DB

      1. in case of error return - 422 (not found)

Validate service_request

  1. If service_request block is presented in request

    1. Get Service_request details (only in active status)

    2. use Response.permitted_resources as resources for approval(could be episode or diagnostic_report).

Validate forbidden_group

  1. if forbidden_group block is presented in request

    1. Check forbidden group in the request exists and is_active in DB

      1. in case of error return - 404 (not found)

Validate diagnoses_group

  1. if diagnoses_group block is presented in request

    1. Check diagnoses_group in the request exists and is_active in DB

      1. in case of error return - 404 (not found)

Validate patient

  1. if patient block is presented in request

    1. Get patient_id from URL:

      1. Check person_id from the request equal to the patient_id from URL

        1. in case of error return - 404 (“Approval for one patient can not be created in another patient’s context”)

      2. exists and is_active in DB

        1. in case of error return - 404 (Person is not found)

Validate block child_resource

  1. if child_resource is not empty:

    1. validate that access_level == read

      1. in case of error return - 422 ("$.access_level. value is not allowed in enum")

    2. check that $.child_resource.identifier.value context is equal to $.resource.identifier.value

      1. in case of error return - 422 (Child resource context id is not equal to granted resource id)

    3. validate that service_requests / forbidden_groups / diagnoses_group / patients are not filled

      1. in case of error return - 422 (schema does not allow additional properties)

    4. validate that resources max items = 1

      1. in case of error return - 422 ($.resources.expected a maximum of 1 items but got 2)

Validate person authentication_method

  1. Check patient_id:

    1. if belongs to person, then GET auth_method from MPI using {patient_id}

      1. If it's OTP:

        1. send SMS to the auth_phone via otpч_verification service POST /verifications

        2. save approval to DB

        3. save authentication_method_current.type and number to DB

        4. return authentication_method_current.type = OTP

      2. If it is offline

        1. save approval to DB

        2. save authentication_method_current.type and number to DB

        3. return  authentication_method_current.type = offline

      3.  if it is null:

        1. return error 409 (Person does not have active authentication method)

    2. if belongs to preperson:

      1. save approval to DB

      2. set approval status = active

      3. set approval urgent = null 

Validate access_level

  1. Validate that access_level correspond to granted_resources:

    1. In case error return 422 ("Resource types [\"$.granted_resources[].code\"] not allowed to use write access_level")

block

granted_resources

access_level

access to

reason

block

granted_resources

access_level

access to

reason

resources

episode_of_care

read

Reading all the data of specified in approval episode

null

diagnostic_report

read

Reading all the data of specified in approval diagnostic report

null

diagnostic_report

write

Canceling diagnostic report package

care_plan

read

Reading all the data of specified in approval care plan

null

care_plan

write

Creating activities for care plan, cancelling medication requests or recalling/cancelling service requests based on care plan

encounter

write

Canceling encounter data package

null

procedure

write

Canceling procedure

null

child_resources

diagnostic_report

read

Reading all the data of specified in context for diagnostic_report

null

encounter

Reading all the data of specified in context for encounter

null

condition

Reading all the data of specified in context for condition

null

observation

Reading all the data of specified in context for observation

null

activity

Reading all the data of specified in context for activity

null

clinical_impression

Reading all the data of specified in context for clinical_impression

null

allergy_intolerance

Reading all the data of specified in context for allergy_intolerance

null

immunization

Reading all the data of specified in context for immunization

null

device

Reading all the data of specified in context for device

null

risk_assessment

Reading all the data of specified in context for risk_assessment

null

procedure

Reading all the data of specified in context for procedure

null

service_request

episode_of_care

read

Reading data from granted_resources in approval service request

service_request

diagnostic_report

read

forbidden_group

forbidden_group

read

Reading all the medical events with items (codes/services/service_groups) of specified in approval forbidden groups 

null

diagnoses_group

episode_of_care array

read

Reading all data of episodes with current_diagnoses.codes that specified in approval diagnoses group 

null

patient_id

patient_id

read

Reading all the data of specified patient

null

Validate authorize_with

The patient can pass the id of his auth_method which he wants to confirm the approval. The necessary auth method can be found by making Get person's auth methods

  1. validate auth_method.id is UUID

    1. in case error return 422

  2. search auth method in MPI.person_authentication_method

    1. in case error return 422, "such authentication method doesn't exist"

  3. search auth method of this patient where  MPI.person_authentication_method.person_id = $.patient.id

    1. in case error return 422, "such authentication method does not belong to this person"

  4. validate if auth_method.type = NA

    1. error return 422, "Сannot be confirmed by a method with type= NA. Use a different method."

  5. validate that this method is active ( authentication_method.ended_at > now() and is_active = true)

This field is optional and set in new field authorize_with and save type and phone_number in approvals.urgent.authentication_method_current.

If approval doesn't have this field, then choose that method which is returned from mpi as person's default method.

Cancel existing approvals

Search if there exists active and not expired approvals with current patient_id, for the same granted_resources, granted_to and access_level as in request.

  • If found - set their status to terminated. Also, set updated_at and updated_by to current user.

Additional logic

  1. All the approvals in status "new" should be deleted 12 hours after creation - env. configuration parameter

  2. All approvals with diagnoses_group has its own expires_at config parameter - env. configuration parameter

  3. All approvals with forbidden_group has its own expires_at config parameter - env. configuration parameter

  4. All approvals with care_plan has its own expires_at config parameter - env. configuration parameter

  5. All approvals with patient has its own expires_at config parameter - env. configuration parameter

  6. Approvals with child_resources will be created ON entity which is context of this child_resources

  7. For approvals on child_resource with resource and on service_request:

    1. set child resource to block reason

    2. set service_request to block reason

  8. Approvals with child_resources will be created ON entity which is context of this child_resources

  9. For approvals on child_resource with resource and on service_request:

    1. set child resource to block reason

    2. set service_request to block reason

  10. Check if for granted_resource and\or for reason there are forbidden groups:

    1. if there are items from forbidden group

      1. check type of authentication_method for patient

        1. If type = 'OTP' send SMS (Код <code> для доступу до даних про ВІЛ/РПП eHealth )

    2. if there NO forbidden group items and diagnoses_group block is presented in request

      1. if diagnoses_group type is ICD10:

        1. check type of authentication_method for patient

          1. If type = 'OTP' send SMS (Код <code>: доступ на групу діагнозів {diagnoses_group_code} eHealth )

      2. if diagnoses_group type is ICPC2:

        1. check type of authentication_method for patient

          1. If type = 'OTP' send SMS (Код <code> доступ на групу діагнозів {diagnoses_group_code} eHealth )

    3. else if there NO forbidden group items

      1. check type of authentication_method for patient

        1. If type = 'OTP' send SMS (Код авторизації дій в системі eHealth: <code>')

 

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