Table of Contents

Purpose

This WS is used to compete Person request to update the person details according to his id, which was previously found using person_id from access token.

Specification

Apiary

Key points

This WS should be used only for completing person requests for updating existing person in the system.
Only person request created in PIS should be completed by this WS.
Prior completing - scan copies for person documents may be uploaded to media content storage.

Authorization

Verify the validity of access token
- Return (401, 'Invalid access token') in case of validation fails
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_request:write_pis')
- Return (403, 'Your scope does not allow to access this resource. Missing allowances: person_request:write_pis') in case of invalid scope(s)
Check that token contains person_id
- in case of error - return (401, 'Invalid access token')

Validate person

Get person_id from token (x-person-id header)
Validate person status is active (status = ‘active' & is_active = 'true’)
- in case of error - return 404 ('Person is not found')

Validate confidant person and relationship

If person is not legally capable - system must ensure that its details are updated by confidant person and there is registered and verified their relationship

...

If equals - check that person must not be authorized by confidant person, so it doesn’t correspond to following rules:
- persons age < no_self_registration_age global parameter;
- persons age between no_self_registration_age and person_full_legal_capacity_age global parameters and person does not have document with type from PIS_PERSON_LEGAL_CAPACITY_DOCUMENT_TYPES config parameter or person has document with type from PIS_PERSON_LEGAL_CAPACITY_DOCUMENT_TYPES config parameter and legal_capacity_verification_status <> VERIFIED or VERIFICATION_NOT_NEEDED;
- persons age > person_full_legal_capacity_age global parameter and exists at least one active and approved confidant person relationship for person (using following process /wiki/spaces/PCAB/pages/17415995422 with person_id = person from request - expected :ok, :approved response)
- In case of error - return 409 (‘Request must be authorized by confidant person’)
If not equal - validate relationship with following steps:
- Check that there is registered relationship between person_id and applicant_person_id(MPI.confidant_person_relationships)
- Check that relationship is VERIFIED
  - In case of error - return 409 (‘Can’t confirm relationship’)
- Check that applicant_person_id exists (status = 'active' & is_active = 'true') and has verification_status any but NOT_VERIFIED
  - In case of error - return 409 (‘Confidant person not found or is not verified’)

Validate request

Validate encoded and decoded request according to JSON Schema

...

in case of error - return 404('Person request not found')

Validate status transition

Only person request in NEW status and PIS can be completed.

Check that person request for URL has status = NEW and channel = PiS
- in case of error - return 409 ('Invalid transition')

Validate signed content

Check $.signed_content field is a valid base64 string
- in case of error - return 422 ('Not a base64 string')
Check $.signed_content_encoding field value equals to 'base64'
- in case of error - return 422 ('value is not allowed in enum')
Check that $.signed_content field contains digital signature
- in case of error - return 400 ('Invalid signature')
Check digital signature of $.signed_content is valid
- in case of error - return 400 with digital signature validation error message
Check that decoded signed content equals with previously saved in person_requests table for person request (except for $.patient_signed field)
- in case of error - return 422 ('Signed content does not match the previously created content')
Check that drfo field in digital signature equals to person that completes request, based on applicant_person_id field from token
- if applicant_person_id = person_id from token - compare with person from request
  - if value equals to tax_id regexp (^[0-9]{10}$), field contains tax_id, use tax_id field from person request to compare;
  - if value equals to national_id number regexp (^[0-9]{9}$), field contains national_id number, use documents.number field with documents.type = 'NATIONAL_ID' to compare;
  - if value contains at least one letter, perform reverse transliteration of field using existing algorithm (described here), then check that value equals to passport number regexp (^((?![ЫЪЭЁ])([А-ЯҐЇІЄ])){2}[0-9]{6}$), in case equals, field contains passport number, use documents.number field with documents.type = 'PASSPORT' to compare;
- if applicant_person_id != person_id from token - compare with confidant person in MPI database
  - if drfo value equals to tax_id regexp (^[0-9]{10}$), field contains tax_id, compare with persons.tax_id;
  - if drfo value equals to national_id number regexp (^[0-9]{9}$), field contains national_id number, compare with document.number with type = 'NATIONAL_ID'
  - if drfo value contains at least one letter, perform reverse transliteration of field using existing algorithm (described here), then check that value equals to passport number regexp (^((?![ЫЪЭЁ])([А-ЯҐЇІЄ])){2}[0-9]{6}$), in case equals, field contains passport number, compare with documents.number with type 'PASSPORT'
    - in case of error - return 409 ('Unable to authenticate signer.')

Validate patient_signed flag

Person request must be signed only after person has read the print form.

...

Check that patient_signed field exists in decoded person request
- in case of error - return 422 ('required property patient_signed was not present')
Check that patient_signed = true in decoded person request
- in case of error - return 422 ('value is not allowed in enum')

Check uploaded documents

Get list of document types that must be uploaded to media content storage in documents field of person request.

If list is empty - skip validation
If list is not empty - check that documents were uploaded, using Media Content Storage
- in case of error - return 409 ('Documents <<document_types_to_upload>> is not uploaded') with types of documents that must be uploaded to media content storage

Service logic

Save signed person request in Media content storage

After person request is successfully signed, save signed person request to Media content storage.

Get name for bucket from MEDIA_STORAGE_PERSON_REQUEST_BUCKET config parameter, save person request to /person_requests/person_request_id folder with signed_content filename.

Update person request

Update person request, set values:

status = SIGNED
updated_by = user_id from token
updated_at = now()
patient_signed = true
person_id = person_id from token

Update pending declaration requests

Search for active declaration requests in IL.declaration_requests table with following search parameters:

...

status = CANCELLED
status_reason = request_cancelled
updated_at = now()
updated_by = user_id from token

Update person

Update existing person (from person_id from token) in MPI database.

...

persons table
person_phones table
person_addresses table
person_documents table

Submit person on verification

Update existing record in person_verifications table for a person according to logic in sections below. Also, set:

updated_at = now()
updated_by = user uuid

Calculate cumulative verification status

Calculate cumulative person verifiation status according to following logic: https://e-health-ua.atlassian.net/wiki/spaces/DRACS2/pages/17858101317/UPD+Sign+person+request+v2#Calculate-cumulative-verification-status

Update relationship between confidant person and updated person

In case if at least one of submitted person document types exist in PERSON_LEGAL_CAPACITY_DOCUMENT_TYPES config parameter and legal_capacity_verification_status = VERIFIED or VERIFICATION_NOT_NEEDED according to Legal capacity verification - deactivate all existing confidant person relationships for person:

Deactivate all records in IL.confidant_person_relationship_requests table where person_id = person.id and status = NEW, set values:
- status = CANCELLED
- updated_at = now()
- updated_by = user_id (from token)
Deactivate all records in MPI.confidant_person_relationship table where person_id = person.id and is_active = true, set values:
- is_active = false
- updated_at = now()
- updated_by = user_id (from token)
For each relationship from previous step - deactivate person authentication methods in https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/724729917/MPI#person_authentication_methods table with type = THIRD_PERSON and value = confidant_person_relationships.confidant_person_id, set values:
- is_active = false
- ended_at = now()
- updated_at = now()
- updated_by = user_id (from token)

In case if person has active Confidant person relationships with relationship document with type='BIRTH_CERTIFICATE' and following person fields are updated:

first_name
last_name
second_name
birth_date

Update found active Confidant person relationships as those that need online verification with DRACS birth acts registry, set values:

verification_status = “VERIFICATION_NEEDED”
verification_reason = “ONLINE_TRIGGERED”
updated_at = now()
updated_by = user_id

Check existance of verification candidates for updated confidant_person_relationship_id with status = ‘NEW’ and entity_type = ‘dracs_birth_act' in confidant_person_relationship_verification_candidates table, if found - deactivate them, set:

status = ‘DEACTIVATED’
status_reason = ‘PERSON_UPDATED’
updated_at = now()

In case if person exists in the system as confidant person in active confidant person relationship with relationship document with type='BIRTH_CERTIFICATE' and following person fields are updated:

first_name
last_name
second_name
birth_date
tax_id

Update found active Confidant person relationships as those that need online verification with DRACS birth acts registry, set values:

verification_status = “VERIFICATION_NEEDED”
verification_reason = “ONLINE_TRIGGERED”
updated_at = now()
updated_by = user_id

Check existance of verification candidates for updated confidant_person_relationship_id with status = ‘NEW’ and entity_type = ‘dracs_birth_act' in confidant_person_relationship_verification_candidates table, if found - deactivate them, set:

status = ‘DEACTIVATED’
status_reason = ‘CONFIDANT_PERSON_UPDATED’
updated_at = now()

Render a response

Render a response according to specification.

Versions Compared

Old Version 1

New Version 2

Key

Purpose

Specification

Key points

Authorization

Validate person

Validate confidant person and relationship

Validate request

Validate status transition

Validate signed content

Validate patient_signed flag

Check uploaded documents

Service logic

Save signed person request in Media content storage

Update person request

Update pending declaration requests

Update person

Submit person on verification

Manual NHS verification

DRFO registry verification

DRACS death acts registry verification

DRACS birth acts registry verification

DRACS name change acts registry verification

Legal capacity verification

Calculate cumulative verification status

Update relationship between confidant person and updated person

Render a response

Page Comparison

Versions Compared

Old Version 1

New Version 2

Key

Purpose

Specification

Key points

Authorization

Validate person

Validate confidant person and relationship

Validate request

Validate status transition

Validate signed content

Validate patient_signed flag

Check uploaded documents

Service logic

Save signed person request in Media content storage

Update person request

Update pending declaration requests

Update person

Submit person on verification

Manual NHS verification

DRFO registry verification

DRACS death acts registry verification

DRACS birth acts registry verification

DRACS name change acts registry verification

Legal capacity verification

Calculate cumulative verification status

Update relationship between confidant person and updated person

Render a response