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
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 patient status is active (status = ‘active' & is_active = 'true’)
in case of error - return 404 ('Person 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;
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/CSI/pages/17667883028 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
andapplicant_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 butNOT_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 stringin 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 signaturein case of error - return 400 ('Invalid signature')
Check digital signature of
$.signed_content
is validin 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 onapplicant_person_id
field from tokenif
applicant_person_id
= person_id from token - compare with person from requestif value equals to tax_id regexp (
^[0-9]{10}$
), field contains tax_id, usetax_id
field from person request to compare;if value equals to national_id number regexp (
^[0-9]{9}$
), field contains national_id number, usedocuments.number
field withdocuments.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, usedocuments.number
field withdocuments.type = 'PASSPORT'
to compare;
if
applicant_person_id
!= person_id from token - compare with confidant person in MPI databaseif drfo value equals to tax_id regexp (
^[0-9]{10}$
), field contains tax_id, compare withpersons.tax_id
;if drfo value equals to national_id number regexp (
^[0-9]{9}$
), field contains national_id number, compare withdocument.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 withdocuments.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 requestin case of error - return 422 ('required property patient_signed was not present')
Check that
patient_signed
= true in decoded person requestin 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
tableperson_phones
tableperson_addresses
tableperson_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
Manual NHS verification
Submit person on Manual NHS verification according to following logic: https://e-health-ua.atlassian.net/wiki/spaces/EDDR/pages/18050613264/Sign+person+request+v2#Manual-NHS-verification
DRFO registry verification
Submit person on DRFO registry verification according to following logic: https://e-health-ua.atlassian.net/wiki/spaces/EDDR/pages/18050613264/Sign+person+request+v2#DRFO-registry-verification
DRACS death acts registry verification
Submit person on DRACS death acts registry verification according to following logic: https://e-health-ua.atlassian.net/wiki/spaces/EDDR/pages/18050613264/Sign+person+request+v2#DRACS-death-acts-registry-verification
MVS passport registry verification
Submit person on MVS passport registry verification according to following logic: https://e-health-ua.atlassian.net/wiki/spaces/EDDR/pages/18050613264/Sign+person+request+v2#MVS-passport-registry-verification
DMS passport registry verification
Submit person on DMS passport registry verification according to following logic: https://e-health-ua.atlassian.net/wiki/spaces/EDDR/pages/18050613264/Sign+person+request+v2#DMS-passport-registry-verification
UNZR registry verification
Submit person on UNZR registry verification according to following logic: https://e-health-ua.atlassian.net/wiki/spaces/EDDR/pages/18050613264/Sign+person+request+v2#UNZR-registry-verification
Calculate cumulative verification status
Calculate cumulative person verification status according to following logic: https://e-health-ua.atlassian.net/wiki/spaces/EDDR/pages/18050613264/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 - deactivate all existing confidant person relationships for person:
Deactivate all records in https://e-health-ua.atlassian.net/wiki/spaces/CSI/pages/17613422609/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 https://e-health-ua.atlassian.net/wiki/spaces/EDDR/pages/18048483381/MPI#confidant_person_relationships table where person_id =
person.id
and is_active = true, set values:active_to = now()
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/EDDR/pages/18048483381/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)
Render a response
Render a response according to specification.