Purpose

This WS allows to link linking medical data of an unidentified person to a person in eHealth. Thus it helps a person who was unidentified during some period to store all its medical history.

Specification

...

Logic

1. Only authenticated and authorized

...

1. SPECIALIST,

...

1. ASSISTANT or RECEPTIONIST

...

1. employees can merge prepersons with prepersons.

2. Prepersons can be merged in EMERGENCY

...

1. or OUTPATIENT legal entities.

2. Employee can merge any active preperson to any active person.

3. To merge person with preperson only their MPI ids needed.

4. Change status should be logged in the Event manager.

...

Dictionaries

• AUTHENTICATION_METHOD

• DOCUMENT_TYPE

Request structure

Example:

{
  "master_person_id": "7c3da506-804d-4550-8993-bf17f9ee0402",
  "merge_person_id": "7c3da506-804d-4550-8993-bf17f9ee0403",
  "authorize_with": "cc949559-5dfe-420f-ac05-065e443b2cc6"
}

Authorize

1. Verify the validity of access token

...

1. • return 401 in case validation fails

2. Check user scopes in order to perform this action (scope = '

...

1. merge_request:write')

...

1. • return 403 in case invalid scope(s)

2. If BLOCK_UNVERIFIED_PARTY_USERS is true, then check party's data match following condition: verification_status != NOT_VERIFIED or (verification_status = NOT_VERIFIED and updated_at <= current_date - UNVERIFIED_PARTY_PERIOD_DAYS_ALLOWED):

   • in case not match - return 403 ("Access denied. Party is not verified")

Headers

Content-Type:application/json

Authorization:Bearer {{access_token}}

Api-key:{{secret}}

Request data validation

Validate request

Validate request using schema (TBD)

Validate legal entity

Check that legal entity is active (status = ACTIVE, SUSPENDED)

1. Extract client_id from

...

1. token

...

2. Check legal entity status (status = ACTIVE

...

1. )

   1. In case of error - return 409 (Legal entity must be ACTIVE

...

1. 1. )

Validate person

Ensure the person existsmaster_person_id is person

1. Validate master_person_id UUID

   1. In case of error - return 422

2. Find person by id in mpi.persons

   1. In case of error - return

...

1. 1. 404 ( Person not found)

2. Check person status is active

   1. In case of error - return 409 (Person is not active)

Validate preperson

Ensure the preperson existsmerge_person_id is preperson

1. Validate

...

1. merge_person_id UUID

   1. In case of error - return 422

...

1. Find preperson

...

1. by id

...

1. in mpi.

...

1. prepersons

   1. In case of error - return

...

1. 1. 404 (Preperson not found)

2. Check preperson status is active in

...

1. mpi.

...

1. prepersons

   1. In case of error - return 409 (Preperson is not active)

2. Check if exists another preperson merge requests with status NEW or APPROVED for this preperson

   1. if exists - update status

...

Validate employee

...

Extract user_id and legal_entity_id from token and find corresponding employee_id

...

Check employee status is APPROVED

1. In case of error - return 422 error (Only active employee can create preperson merge request)

If employee has division - validate it has status ACTIVE

...

1. 1. of another requests to CANCELLED

2. Check if preperson has at least one episode( status!= "entered_in_error")

   1. if no episodes - return 409 (Preperson has no episodes)

Validate authorize_with

If submitted, validate authorize_with field for a person as described on create Person request process. But for success case set it to il.merge_requests.authentication_method_current field instead.

Generate verification code

Validate person authentication method in mpi.person_authentication_methods table:

• If type is OTP or THIRD_PERSON - Generate verification code as on create patient request process.

• If type is OFFLINE - Generate uploaded URLs as on create patient request process. Set il.merge_requests.documents

In case no auth methods found (null) - return error with code 409 (Person has no auth methods)

Processing

Save object to DB

il.personmerge_requeststable

Validate person authentication method in mpi.person_authentication_methods table:

...

Generate verification code

Response structure

See on Apiary

Example:

{
  "meta": {
    "code": 201,
    "url": "https://example.com/resource",
    "type": "object",
    "request_id": "6617aeec-15e2-4d6f-b9bd-53559c358f97#17810"
  },
  "data": {
    "id": "7c3da506-804d-4550-8993-bf17f9ee0404",
    "master_person_id": "7c3da506-804d-4550-8993-bf17f9ee0402",
    "merge_person_id": "7c3da506-804d-4550-8993-bf17f9ee0403",
    "status": "NEW",
    "inserted_at": "2017-04-20T19:14:13Z",
    "inserted_by": "e1453f4c-1077-4e85-8c98-c13ffca0063e",
    "updated_at": "2017-04-20T19:14:13Z",
    "updated_by": "2922a240-63db-404e-b730-09222bfeb2dd"
  },
  "urgent": {
    "authentication_method_current": [
      {
        "type": "OTP",
        "phone_number": "+38093*****85"
      }
    ],
    "documents": [
      {
        "type": "PASSPORT",
        "url": "https://storage.ehealth.world"
      }
    ]
  }
}

HTTP status codes