...

Purpose

Describe the purpose of the API method, add Key points (if necessary)

Logic

Description of the working algorithm of the API method and the interaction of services with each other add Service logic (if necessary)

Configuration parameters

Description of the configuration parameters that are used when processing a request in the system

Dictionaries

Provides a list of links to dictionaries that are available in Confluence

Input parameters

Description of input This WS is designed to complete person documents uploading proccess through person information system (PIS).

Key points

1. This method is used only by PIS.

2. This method checks list of documents that needs to be uploaded for person and urls. In case all person documents were be uploaded - persons nhs verification status is updated.

3. Person is obtained from user that performs method.

Logic

Service logic

1. Get list of person documents that must be uploaded to media content storage (for each type of documents, if couple of rules worked - only one file is expected):

   1. Call /wiki/spaces/PCAB/pages/17415995422 , send person_id = person.id and confidant_person_id = applicant_person_id (from token)
      in case if method returns “ok”:

      1. Check for documents with name confidant_person.{confidant_person_id}.documents_relationship.[:].{type}

   2. If one of persons document has type = ‘BIRTH_CERTIFICATE_FOREIGN’ and there is no same document in {person.confidant_person.[:].documents_relationship.[:]} and persons age < no_self_auth_age global parameter value then

      1. Check for document with name person.BIRTH_CERTIFICATE_FOREIGN

   3. If one of persons document has type = ‘PERMANENT_RESIDENCE_PERMIT’ and persons age >= no_self_auth_age global parameter value then

      1. Check for document with name person.PERMANENT_RESIDENCE_PERMIT

   4. If persons authentication method = ‘OFFLINE’ or ‘THIRD_PERSON’ authentication method = ‘OFFLINE’

      1. Check for documents with name person.{documents.[:].type} or third_person.{third_person.documents.[:].type}

   5. If person.unzr field is not empty and first 8 digits of unzr != persons birth_date

      1. Check for document with name person.unzr

   6. If persons age is greater then no_self_registration_age global parameter, but less then person_full_legal_capacity_age global parameter
      and one of persons documents has type from PIS_PERSON_LEGAL_CAPACITY_DOCUMENT_TYPESconfig parameter then

      1. Get type of document that has been found
         AND check for documents with name person.{type}

2. Check existence of each document in existing media content storages for person:

   1. persons

   2. person_requests

   3. authentication_method_requests

3. Generate signed urls for each document that must be uploaded but does not exist in persons media content storage.

4. If all expected person documents exist in persons media content storage and persons nhs_verification_status = ‘NOT_VERIFIED’ and nhs_verification_reason = ‘DOCUMENTS_TRIGGERED’, update persons nhs verification status according to logic described https://e-health-ua.atlassian.net/wiki/spaces/DRACS/pages/17249206422

5. Render a response according to specification.

Configuration parameters

N/A

Dictionaries

N/A

Input parameters

Request structure

See on API-specification (посилання на сторінку з API-специфікацією)Description of the REST API request structure, example

...

...

...

Headers

...

Headers

...

Request data validation

...

Example

...

Content-Type

...

application/json

...

M

...

Тип контенту

...

Content-Type:application/json

...

Authorization

...

Bearer c2778f3064753ea70de870a53795f5c9

...

M

...

Перевірка користувача

...

Authorization:Bearer c2778f3064753ea70de870a53795f5c9

...

Request data validation

Describe the process of checking the input data transmitted in the request for compliance with the given rules and restrictions set in the API

Processing

A list of processes related to receiving, changing or transmitting data according to the logic defined in the REST API

Response structure examples

...

Authorization

• Verify the validity of the access token

  • in case of error - return 401 (“Invalid access token”)

• Verify that token is not expired

  • in case of error - return 401 (“Invalid access token”)

• Check user scopes in order to perform this action (scope = 'person_documents:write_pis')

  • in case of invalid scope(s) - return 403 (“Your scope does not allow to access this resource. Missing allowances: person_documents:write_pis”)

Validate person

• Get person_id from user

• Check person exists in mpi database and is active (status = ‘active’ and is_active=true)

  • in case of error - return 404 ('Person does not exist or is not active')

Processing

N/A

Response structure examples

See on API-specification

HTTP status codes

Post-processing processes

Description of actions performed on data after processing

Technical modules where the method is used

List of pages describing technical N/A

Technical modules where the method is used

...