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

[DRAFT] [UPD] Verify approval [API-007-011-001-0479]

REST API method / Метод REST API (настанова) (remove the link block before publishing the document)

Properties of a REST API method document

Document type

Метод REST API

Document title

[DRAFT] [UPD] Verify approval [API-007-011-001-0479]

Guideline ID

GUI-0011

Author

@

Document version

1

Document status

DRAFT

Date of creation

ХХ.ХХ.ХХХХ (дата фінальної версії документа – RC або PROD)

Date of update

ХХ.ХХ.ХХХХ (дата зміни версії)

Method API ID

API-007-011-001-0479

Microservices (namespace)

ME

Component

Compositions_ME

Component ID

COM-007-011

Link на API-специфікацію

https://ehealthmisapi1.docs.apiary.io/#reference/public.-medical-service-provider-integration-layer/manage-client-configuration/get-client-details

Resource

{{host}}//api.ehealth.gov.ua/api/patients/id/encounter_package

Scope

 

Protocol type

REST

Request type

 

Sync/Async

 

Public/Private

 

Purpose

Key items

user PATCH /api/patients/{id}/approvals/{id} with the verification code received from the patient

Logic

  1. If approval has resource != (care_plan & terms_of_service = ‘INPATIENT’ for care_plan&granted_to.employees.legal_entity_id = care_plans.managing_organization):

    1. If authentication_method_current.type = OTP

      1. system checks verification code via otp_verification service PATCH /verifications/:phone_number/actions/complete

      2. if verification code matches - change is_verified to true

      3. If not - return error

      4. if resource from granted_to = employee AND access_level=read:

        1. Check if there are items Medical Events filtration by Forbidden groups#Medical-events-to-filter for entities from granted_resource and\or from reason included to the forbidden groups

          1. if there are active items from forbidden group

            1. create approval on each forbidden_group block whose elements appear entities from granted_resource and\or from reason

            2. set is_verified = true

            3. set reason = id of the approval which was verified

            4. set created_by - the same user as for approval, which is verified

            5. set granted_to - the same employee as for approval, which is verified

            6. set granted_by - the same patient as for approval, which is verified

  2. If there are some some values in approval.forbidden_groups - create approval for each forbidden group mentioned in the list

    1. set is_verified = true

    2. set reason = id of the approval which was verified

    3. set created_by - the same user as for approval, which is verified

    4. set granted_to - the same employee as for approval, which is verified

    5. set granted_by - the same patient as for approval, which is verified

  3. If authentication_method_current.type = offline or null OR approval with resource = care_plan where terms_of_service = ‘INPATIENT’ for care_plan&granted_to.employees.legal_entity_id = care_plans.managing_organization::

    1. change is_verified to true

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

    • If found - set for existing approvals:

      • updated_at = now()

      • updated_by = current user

      • expired_at = now()

Configuration parameters

N/A

Dictionaries

N/A

Input parameters

Input parameter

Mandatory

Type

Description

Example

Input parameter

Mandatory

Type

Description

Example

1

 

 

 

 

 

2

 

 

 

 

 

Request structure

See on API-specification

Headers

https://e-health-ua.atlassian.net/wiki/spaces/ESOZ/pages/18415648793

Request data validation

Authorize

  1. Verify the validity of access token

  2. Check user scope approval:create in order to perform this action

Validate confidant person relationship

Get value of THIRD_PERSON_CONFIDANT_PERSON_RELATIONSHIP_CHECK config parameter, if it is set to true:

  • If authorize_with in approval exists, not empty and contains auth method with type = THIRD_PERSON - validate that person from value is an approved confidant for a person from request – exists active and approved confidant person relationship between person from request and person_id from authentication method value (using following logic: Check confidant person relationship with person_id = person from approval and confidant_person_id = value from auth method - expected :ok, :approved response)

    • in case of error - return 422 ('Cannot be verified by method with not approved confidant person relationship')

Processing

N/A

Response structure examples

See on API-specification

HTTP status codes

Response code

HTTP Status code

Message

Internal name

Description

Response code

HTTP Status code

Message

Internal name

Description

1

Базові

2

 

422

Cannot be verified by method with not approved confidant person relationship

 

 

3

Специфічні

4

 

 

 

 

 

Post-processing processes

N/A

Technical modules where the method is used

 

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