Versions Compared

Key

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

Purpose

...

Page Properties
idAPI_Specification

Link

https://uaehealthapi.docs.apiary.io/#reference/internal.-portal-and-reports/employee-requests/approve-or-reject-employee-request

Посилання на Apiary або Swagger

Resource

/employee_requests/{{id}}/actions/{{action}}

Посилання на ресурс, наприклад: /api/persons/create

Scope

employee_request:update

Scope для доступу

Components

Employees

Зазначається перелік бізнес компонентів, які використовують цей метод, наприклад: ePrescription

Microservices

il/api

Перелік мікросервісів, які використовує метод API, наприклад: Auth, ABAC

Protocol type

REST

Тип протоколу, який використовується запитом, наприклад: SOAP | REST

Request type

POST

Тип запиту API, наприклад: GET, POST, PATCH…

Sync/Async

Sync

Метод є синхронним чи асинхронним?

Public/Private/Internal

Internal

Потрібно зазначити тип методу за ступенем доступності

Logic

...

Sample Request
Code Block
languagexml
curl -X POST -H 'Content-Type: application/json' -H 'Authorization:Bearer YW5WcFkyVnFkV2xqWldwMWFXTmxDZzpjY1hwWTR0cWRZbGVjNHAxYUdsMXVJ' 'http://ehealth.nebo15.com/employee_requests/d290f1ee-6c54-4b01-90e6-d701748f0851/actions/approve'

Input parameters

Input parameter

Values

Type

Description

Example

id

String

Required

d290f1ee-6c54-4b01-90e6-d701748f0851

action

  • APPROVE

  • REJECT

String

Required

APPROVE

Authorize

  1. Verify the validity of access token

  2. Check user scope employee_request:update in order to perform this action

    1. In case error - return 401 error

Headers

Наприклад:

Content-Type:application/json

...

  1. Search party_id by tax_id (tax_id or passport_number) and birth_date for deduplication Party

    1. If found, update object party - Update party WS

    2. If not found, - Create object party 

  2. Update Party.  See specification

    1. The following fields can't be changed:

      1. tax_id (tax_id or passport_number) 

      2. birth_date

    2. If doctor object in ER is null, don't update party.eductions/party.qualifications/party.specialities/party.science_degree. Otherwise update those objects.

    3. if about_myself/working_experience is null or empty string - don't update correspondent fields in parties.

  3. Create party WS. See specification

    1. create related entity party-user in PRM 

  4. Chech employee_id in request

    1. if employee_id is exist in request, Update employee.

    2. if  employee_id is not exist, Create employee.

  5. Update employee. See specification

    1. The following fields can't be changed:

      1. employee_type

      2. legal_entity_id

      3. start_date

    2. if employee_type = 'DOCTOR', 'SPECIALIST' or 'ASSISTANT' update doctor object

    3. if one of next fields were changed:

      1. first_name

      2. second_name

      3. last_name
        find contracts with contractor_owner_id=$owner_id and status='VERIFIED'. Set ops.contracts.is_suspended=true

  6. Create new employee. See specification

    1. If (employee_type = OWNER || employee_type = PHARMACY_OWNER) : deactivate all other records with the employee_type = OWNER
      or employee_type = PHARMACY_OWNER for the legal_entity,
      where new owner is creating:

...

In case new OWNER was added find contracts with contractor_owner_id=$old_owner_id and status='VERIFIED'.

Set ops.contracts.is_suspended=true

...

Role is assigned according to employee_type

See service logic

See service specification

Sample Request

...

Send email with successful registration using WS - Send Message (TBD)

Temporarily use Postmark

Submit party on verification

Create or update existing record in party_verifications table for a party according to logic in sections below. Also, set:

  • updated_at = now()

  • updated_by = user uuid

  • inserted_at = now() (for new records)

  • inserted_by = user uuid (for new records)

DRFO registry verification

Set to party verification record as ready for online verification with DRFO registry:

  • drfo_data_id = NULL

  • drfo_data_result = NULL

  • drfo_synced_at = NULL

  • drfo_verification_status = VERIFICATION_NEEDED

  • drfo_verification_reason = ONLINE_TRIGGERED

Then party will be verified online with DRFO registry via separate process: DRFO data synchronization for Parties_EN

DRACS death acts registry verification

Set to party verification record as ready for online verification with DRACS death acts registry:

  • dracs_death_verification_status = VERIFICATION_NEEDED

  • dracs_death_verification_reason = ONLINE_TRIGGERED

  • dracs_death_online_status = READY

Then party will be verified online with DRACS death acts registry via separate process: Online verification of Parties with DRACS death acts registry_EN

Calculate cumulative verification status

Calculate parties cumulative verification status based on parties verification status in each stream: DRFO registry verification, DRACS death acts registry verification according to logic described at Party verification status model_EN | Cumulative verification status

  • Set calculated status to parties.verification_status field

  • Create StatusChangeEvent for each active employee related to a party in event manager with new verification status if it was changed

Response structure

Example:

...