Specification

Apiary

The process is initiated by any employee with necessary scopes in this legal entity and involves the transfer of a signed person with electronic digital signature.

Process is synchronous. If all validations are successfully completed, the synchronous process of creating a person starts by processing the message.

Service logic

Only authenticated and authorized user can use this service
Only APPROVED patient request can be signed
The request can be signed only by the employee who works in the same legal entity in which the request was made.

Authorize user

Verify the validity of access token
1. Return 401 in case validation fails
Check scopes in order to perform this action (scope = 'person_request:write')
1. Return 403 in case invalid scope(s)

Digital signature

Decode content that is encrypted in an electronic digital signature.
Use Digital signature WS. Method checks digital signature and returns result.
See service specification

Validate DRFO

Check that DRFO in Certificate details exists and not empty
Check that DRFO in Certificate details is equal to DRFO in Party
1. Get party.tax_id using employee_id in person payload
2. Compare DRFO in Certificate with party.tax_id
  1. Convert DRFO and TAX_ID to uppercase
  2. Compare DRFO and TAX_ID as Cyrillic letters
  3. Convert DRFO to Cyrillic and compare as Cyrillic letters
3. In case validation fails - generate 422 error

Latin to Cyrillic mapping

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

Validate request

Validate request using JSON schema (See specification)
1. In case validation fails - generate 422 error
Check patient request status
1. If status is not APPROVED, - returned error 'Incorrect status'

Validate backwards compatibility

This WS can sign only person requests that were approved by Approve person request

Check that person_request.version field is equal to 1
- in case of error - return 422 ('Person request cannot be processed by the version 1 of the service, use version 2 instead')

Check signed content

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

SELECT data
FROM patient_requests
WHERE id = {:id}

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.

Check that ID in URL exists in the system
1. Return 401 in case validation fails
Check that patient request belongs to the same legal entity as the user
1. In case of error - return 403

Check "patient_signed" flag

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")

Update patient request

Update patient request:

Change entity status in IL_DB.patient_request to SIGNED
Set updated_at - now() (Get current date-time)
Set updated_by - user_id (Extract user from token)

Create person

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

Calculate the end date of the person_aus_method and set as default

These params set only if person is creating (so after Create person request)

If person has auth_method = third_person, add in table person_auth_methods row with type = THIRD_PERSON, value = id (third_person_id), alias

Calculate term of person_authentication_method:

Start date: start_date = Current_date()

End date:

if (person.age < prm.global_parameters.no_self_auth_age) {

end_date = end_date =birth_date + prm.global_parameters.no_self_auth_age - 1d;

} else {

end_date = start_date + third_person_term;

}

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

Person_auth_methods

Name	Type	M/O	Comment

Name	Type	M/O	Comment
id	uuid	M
person_id	uuid	M
type	varchar	M	OFFLINE, OTP or THIRD_PERSON
phone_number	varchar	O
value	varchar	O	if THIRD_PERSON would be third_person_id
started_at	timestamp	O
end_at	timestamp	O
alias	varchar	O
default	boolean	O
inserted_at	timestamp	M
updated_at	timestamp	M

Submit person on verification

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

Create or 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
inserted_at = now() (for new records)
inserted_by = user uuid (for new records)

Manual NHS verification

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

Person has OFFLINE auth method
if create Person process, check Request
if update Person process, check within MPI.person_athentication_methods table
Person’s age < no_self_auth_age and has document with type BIRTH_CERTIFICATE_FOREIGN (check in Request, within $.person.documents and $.person.confidant_person[:].documents_relationship[:])
Person’s age >= no_self_auth_age and has document with type PERMANENT_RESIDENCE_PERMIT (check in Request)

then manual verification is needed. Set to person verification record:

nhs_verification_status = VERIFICATION_NEEDED
nhs_verification_reason = RULES_TRIGGERED

else manual verification is not needed. Set to person verification record:

nhs_verification_status = VERIFIED
nhs_verification_reason = RULES_PASSED
nhs_verification_comment = NULL

DRFO registry verification

Set to person verification record:

drfo_data_id = NULL
drfo_data_result = NULL
drfo_synced_at = NULL
drfo_verification_status = VERIFICATION_NEEDED
drfo_verification_reason = ONLINE_TRIGGERED

Then person will be verified online with DRFO registry via separate process: ARCHIVE_DRFO data synchronization for Persons (CSI-2823)

DRACS death acts registry verification

Set to person verification record as ready for online verification with DRACS death acts registry:

dracs_death_verification_status = VERIFICATION_NEEDED
dracs_death_verification_reason = ONLINE_TRIGGERED
dracs_death_online_status = READY

If person is updated, check existance of verification candidates for person_id with status = ‘NEW’ and entity_type = ‘dracs_death_act' in person_verification_candidates table, if found - deactivate them, set:

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

Then person will be verified online with DRACS death acts registry via separate process: https://e-health-ua.atlassian.net/wiki/spaces/DRACS/pages/17249763472

MVS passport registry verification

If person’s data match following rules: person has document with type ‘PASSPORT’ or ‘NATIONAL_ID’ (check in Request, within $.person.documents)

then online verification with MVS passports registry needed. Set to person verification record:

mvs_passport_data_id = NULL
mvs_passport_data_status = NULL
mvs_passport_synced_at = NULL
mvs_passport_verification_status = VERIFICATION_NEEDED
mvs_passport_verification_reason = ONLINE_TRIGGERED

Then person will be verified online with MVS passports registry via separate process: https://e-health-ua.atlassian.net/wiki/spaces/EDDR/pages/18050908162

If person’s data does not match rules from above – online verification with MVS passports registry is not needed. Set to person verification record:

mvs_passport_data_id = NULL
mvs_passport_data_status = NULL
mvs_passport_synced_at = NULL
mvs_passport_verification_status = VERIFICATION_NOT_NEEDED
mvs_passport_verification_reason = AUTO_DATA_ABSENT

DMS passport registry verification

If person’s data match following rules: person has document with type ‘PASSPORT’ or ‘NATIONAL_ID’ (check in Request, within $.person.documents)

then online verification with DMS passports registry needed. Set to person verification record:

dms_passport_data_id = NULL
dms_passport_data_status = NULL
dms_passport_synced_at = NULL
dms_passport_verification_status = VERIFICATION_NEEDED
dms_passport_verification_reason = ONLINE_TRIGGERED

Then person will be verified online with DMS passports registry via separate process: https://e-health-ua.atlassian.net/wiki/spaces/EDDR/pages/18050711556

If person’s data does not match rules from above – online verification with DMS passports registry is not needed. Set to person verification record:

dms_passport_data_id = NULL
dms_passport_data_status = NULL
dms_passport_synced_at = NULL
dms_passport_verification_status = VERIFICATION_NOT_NEEDED
dms_passport_verification_reason = AUTO_DATA_ABSENT

UNZR registry verification

If person’s data match following rules: ‘unzr’ is submitted and is not null (check in Request, within $.person.unzr)

then online verification with UNZR registry needed. Set to person verification record:

unzr_data_id = NULL
unzr_data_status = NULL
unzr_synced_at = NULL
unzr_verification_status = VERIFICATION_NEEDED
unzr_verification_reason = ONLINE_TRIGGERED

Then person will be verified online with UNZR registry via separate process: https://e-health-ua.atlassian.net/wiki/spaces/EDDR/pages/18050351106

If person’s data does not match rules from above – online verification with UNZR registry is not needed. Set to person verification record:

unzr_data_id = NULL
unzr_data_status = NULL
unzr_synced_at = NULL
unzr_verification_status = VERIFICATION_NOT_NEEDED
unzr_verification_reason = AUTO

Calculate cumulative verification status

Calculate persons cumulative verification status based on persons verification status in each stream: Manual NHS verification, DRFO registry verification, DRACS death acts registry verification, MVS passport registry verification, DMS passport registry verification, UNZR registry verification according to logic described at Person verification status model_EN | Cumulative verification status :

Set calculated status to persons.verification_status field
Create StatusChangeEvent in event manager with new verification status if it was changed

E-Health

RC_IL.Sign person request (DMS)