Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents
maxLevel3
minLevel1
maxLevel3

Purpose

This WS is designed to verify 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 OR patient.

...

Specification

Page Properties


Link

https://medicaleventsmisapi.docs.apiary.io/#reference/approvals/verify-approval/verify-approval

Resource

/api/patients/{{patiend_id}}/approvals/{{id}}

Scope

approval:create

Components

Approvals

Microservices

API paragraph not found

Protocol type

REST

Request type

PATCH

Sync/Async

Async

Public/Private/Internal

Public



Input parameters

Input parameter

Values

Type

Description

Example

patiend_id


String

mpi_id. Required

aff00bf6-68bf-4b49-b66d-f031d48922b3

id


String

approval_id. Required

aff00bf6-68bf-4b49-b66d-f031d48922b3

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 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

  3. 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 for existing approvals:

      • updated_at = now()

      • updated_by = current user

      • expired_at = now()

Request structure

See on Apiary

...

  1. Verify the validity of access token

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

Headers

Наприклад:

  • Content-Type:application/json

  • Authorization:Bearer d368a4b0-4a0e-457a-b267-32359fa6288f

Logic

...

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 status to active

  3. If not - return error

...

  1. change status to active

HTTP status codes

Page Properties


HTTP status code

Message

What caused the error

 200

 Response