Purpose

...

Logic

...

Preconditions

Person request must be approved.

Input parameters

Filters

No

Dictionaries

...

Request structure

Example:

...

Content-Type:application/json

Authorization:Bearer c2778f3064753ea70de870a53795f5c9{{access_token}}

api-key:uXhEczJ56adsfh3Ri9SUkc4en{{secret}}

mds_drfo:2534157686{{secret}}

Request data validation

Validate DRFO

...

%{"A" => "А", "B" => "В", "C" => "С", "E" => "Е", "H" => "Н", "I" => "І", "K" => "К", "M" => "М", "O" => "О", "P" => "Р", "T" => "Т", "X" => "Х"}

Validate request

1. Validate request using JSON schema (See specification)

   1. In case validation fails - generate 422 error.

2. Check patient request status

   1. If status is not APPROVED, - returned error 'Incorrect status'.

Check signed content

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

...

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

Check legal entity id

Patient request can be signed by any employee with necessary scopes in equal legal_entity_id.

...

• If "patient_signed" is not present in request, return 422 ("required property patient_signed was not present")

• If "patient_signed"=false in request, return 422 ("value is not allowed in enum")

Processing

Update patient request

Update patient request:

1. Change entity status in IL_DB.patient_request to SIGNED

2. Set updated_at - now() (Get current date-time)

3. Set updated_by - user_id (Extract user from token)

Create person

After singed patient request create new person on DB.mpi.

...

Also to table person_auth_methods add this method as default(field `default` = TRUE) - it's for all auth_method.type

Check if Person should be sent for verification

Please note, (GraphQL) Update person refers to this validation.

if person’s data match any of the following rules:

validate all Rules 01-05

1. Person has OFFLINE auth method
   if create Person process, check Request
   if update Person process, check within MPI.person_athentication_methods table

2. Person's age >= no_self_auth_age and no_tax_id = true (check in Request)

3. Person's age >= no_self_auth_age and Person’s tax_id is invalid (i.e. not match with birth date or gender or invalid checksum) (check in Request)

4. Person’s age < no_self_auth_age and has document with type BIRTH_CERTIFICATE_FOREIGN (check in Request)

5. Person’s age >= no_self_auth_age and has document with type PERMANENT_RESIDENCE_PERMIT (check in Request)

then

manual verification is needed

• Set MPI.persons.verification_status = VERIFICATION_NEEDED and

• Set MPI.persons.verification_reason = RULES_TRIGGERED and

• Create StateChangeEvent in event manager with new verification status

else

person will be verified with Registers

• Set MPI.persons.verification_status = VERIFICATION_NEEDED and

• Set MPI.persons.verification_reason = RULES_PASSED and

• Set MPI.persons.verification_comment = NULL and

• Create StateChangeEvent in event manager with new verification status

Response structure

Example:

{
  "meta": {
    "code": 200,
    "url": "https://example.com/resource",
    "type": "object",
    "request_id": "req-adasdoijasdojsda"
  },
  "data": {
    "person_id": "b075f148-7f93-4fc2-b2ec-2d81b19a9b7b",
    "updated_at": "2017-03-02T00:00:00.000Z",
    "status": "SIGNED",
    "id": "74a6fae6-4207-4e03-a136-f2e70c6b0c02",
    "inserted_at": "2017-07-06T16:54:05.161571Z"
  }
}

Post-processing processes

API paragraph not found

HTTP status codes

Backward compatibility

...