Purpose

This WS merges a person with a preperson after the merge request has been signed by employee

Specification

Logic

1. Only authenticated and authorized SPECIALIST employees can use this WS.

2. Usage of this WS allowed in EMERGENCY or OUTPATIENT legal entities.

3. Employee should sign merge request to link person with preperson.

4. Only request APPROVED by person can be signed.

5. The request can be signed only by employee who made the request.

6. Create objects in DB should be done in one transaction.

7. Status change of the merge request and preperson should be logged in the Event manager.

8. Succesfull merge does not create record in MPI.persons table for preperson, but deactivates record in MPI.prepersons and linked document in patient collection (mongo)

9. Data from the field data_to_be_signed used as request data for sign method.

Input parameters

Request structure

See on Apiary

Example:

{
  "signed_content": "U2lnbmVkIGNvbnRlbnQgTVVTVCBjb25zaXN0cyBvZiBKU09OIG9iamVjdCB3aXRoIG1lcmdlIHJlcXVlc3QgZGF0YSBhbmQgcHJpbnRvdXQgdGVtcGxhdGUuIE9iamVjdCB0aGF0IG5lZWQgdG8gYmUgc2lnbmVkIGlzIHJldHVybmVkIGJ5IEFwcHJvdmUgbWVyZ2UgcmVxdWVzdCBtZXRob2QsIEpTT04uUGF0aDogJC5kYXRhLiBQZXJzb24gbXVzdCByZS1yZWFkIGFuZCBzaWduIG1lcmdlIHJlcXVlc3QgcHJpbnQgZm9ybSBhbmQgYWZ0ZXIgdGhhdCBwYXRpZW50X3NpZ25lZCBzaG91bGQgYmUgY2hhbmdlZCB0byBUUlVFLg==",
  "signed_content_encoding": "base64"
}

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 = 'merge_request:sign')

   1. Return 403 in case invalid scope(s)

3. Check the employee has created this merge request. Thus select inserted_by from il.merge_requests of this merge request and compare it with user_id from the token.

4. Check that client_id from the token maches with il.merge_requests.legal_entity_id

   1. If not match - return 422 error (User doesn’t belong to legal entity where the merge request was created)

Headers

Наприклад:

Content-Type:application/json

Authorization:Bearer c2778f3064753ea70de870a53795f5c9

api-key:uXhEczJ56adsfh3Ri9SUkc4en

Request data validation

Validate digital signature

Validate digital sign as described on sign patient request process

Check signed content

• Check decoded signed content with previously created on IL.db.

SELECT data
FROM merge_requests
WHERE id = {:id}

In case if they are not equal - generate 422 error (message: "Signed content does not match the previously created content")

• Generate data for sign and compare it with information from il.merge_requests.data

In case if they are not equal - generate 422 error (message: "Created content has been changed")

Validate schema

Validate request using schema (TBD)

Validate merge request

1. Validate merge request id exists in DB

   1. In case of error - return 404

2. Check merge request status is APPROVED

   1. In case of error - return 422 (Incorrect status to sign merge request)

Check signed content

1. Get previously request data from il.merge_requests.data.

2. Compare it with request data_ to_be_signed field.

   1. In case they are not equal - return 422 error (Signed content does not match the previously created content)

3. Check patient_signed = true. It means that person signed printout content.

   1. In case of error - return 422 error (Patient must sign merge request form).

Validate legal entity

Validate legal entity as on create merge request process.

Validate person

Validate person as on create merge request process.

Validate preperson

Validate preperson as on create merge request process, but w/o searching pending merge requests and episodes.

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

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

Processing

Save signed merge request to media storage

1. Get url for merge request upload.

1. Upload signed merge request to media storage.

Create object in DB

mpi.merged_pairs table

Update object in DB

1. il.merge_requests table

2. mpi.prepersons table

3. patients collection (mongo, separate job)

Response structure

See on Apiary

Example:

{
  "meta": {
    "code": 200,
    "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": "SIGNED",
    "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"
  }
}

Post-processing processes

API paragraph not found

HTTP status codes