Purpose

This job is designed for initial and further regular synchronization of Person's UNZR with the EIS MVS registry in order to check if this number is valid or not.

Configuration

Data flow

Scheduller starts according to UNZR_PERSON_SYNCHRONIZATION_SCHEDULE cron parameter. It creates oban job that selects UNZR_PERSONS_SYNCHRONIZATION_BATCH_SIZE Persons that match to some filter parameters. For each the job receives Person data on input and returns the result of reconciliation with the MVS registry to output (details in “Step description” section below):

• if UNZR is found - set verification status to VERIFIED along with verification reason AUTO. The unzr_data is saved and linked to the Person.

• if UNZR is not found for the person - set verification status to NOT_VERIFIED and verification reason is set to AUTO. The unzr_data is not saved and not linked to the Person;

• if person has no UNZR - set verification status to VERIFICATION_NOT_NEEDED and verification reason to INITIAL. Sync isn't performed, unzr_data is not saved and not linked to the Person;

• if UNZR is incorrect - set verification status to NOT_VERIFIED and verification reason to INITIAL. In this case UNZR value will be cleared, sync isn't performed.

• if technical error received - the verification status and reason doesn’t change. The unzr_data is not saved, Person is not updated;

Step description

Step 1. Get list of Persons

Get the list of active Persons (status=active, is_active=true) who meet the following criteria (using logical AND):

• mpi.person_verifications.unzr_synced_at <= current_date - UNZR_PERSON_VALIDATION_PERIOD_DAYS OR unzr_synced_at is null

• exclude persons who has unzr_verification_status = IN_REVIEW, NOT_VERIFIED, VERIFICATION_NOT_NEEDED

Order selected records in descending way by:

• unzr_verification_status = VERIFICATION_NEEDED and unzr_verification_reason = ONLINE_TRIGGERED or MANUAL (should be at the top of the list)

Update person_verifications record by person_id:

• unzr_verification_status = IN_REVIEW

• unzr_verification_reason = AUTO

Step 1.1 Update Person

Invoke the Step If person_verifications.unzr_verification_status still IN_REVIEW

Make data pre-estimation for a synchronization:

1. If a person has no UNZR (persons.unzr is empty), then update person_verifications record by person_id:

   • unzr_data_id = null

   • unzr_data_status = null

   • unzr_synced_at = null

   • unzr_verification_status = VERIFICATION_NOT_NEEDED

   • unzr_verification_reason = INITIAL

   • unzr_unverified_at = null

2. If the person has UNZR, but it does not match a regex ^[0-9]{8}-[0-9]{5}$, then:

   1. Update person_verifications record by person_id:

      1. unzr_data_id = null

      2. unzr_data_status = null

      3. unzr_synced_at = null

      4. unzr_verification_status = NOT_VERIFIED

      5. unzr_verification_reason = INITIAL

      6. unzr_unverified_at = current datetime

   2. Update persons record by id:

      • unzr = null

Step 2. Call checkunzr

Check person’s UNZR - invoke RPC call with third-party “checkunzr“ service https://e-health-ua.atlassian.net/wiki/spaces/EDDR/pages/18052513879/MVS+Trembita+methods#checkunzr using the following request params:

• unzr - mpi.persons.unzr

• family_name = mpi.persons.last_name

• given_name = mpi.persons.first_name

• patronymic_name = mpi.persons.second_name (skip if empty)

• date_birth = mpi.persons.birth_date

Step 3. Create or update unzr_data

If Step 2 was successful and Status = 1 returned. Get record from mimir.unzr_data table by unzr:

• if not found - create a record.

• if found - updated the record.

Step 4. Update Person

Invoke the Step If person_verifications.unzr_verification_status still IN_REVIEW (because if changed to VERIFICATION_NEEDED+ONLINE_TRIGGERED, then its mean that person record has been changed while current sync with MVS performed)

After MVS record was stored in Step 3 - update persons record in MPI db:

Update person_verifications record by person_id:

• unzr_data_id = mimir.unzr_data.id

• unzr_data_status = 1

• unzr_synced_at = date and time when synchronization has been performed (current datetime)

• unzr_verification_status = VERIFIED

• unzr_verification_reason = AUTO

• unzr_unverified_at = null

Step 4.1. Update another Persons

Invoke the Step If person_verifications.unzr_verification_status is not IN_REVIEW

If unzr_data has been changed at Step 3 and another active Persons linked to it (have the same unzr_data_id in person_verifications table), then compare person’s data with uznr_data: last_name, first_name, middle_name and date_birth. If these data are different, then update person_verification data for these persons:

• unzr_data_id = null

• unzr_data_status = null

• unzr_synced_at = null

• unzr_verification_status = VERIFICATION_NEEDED

• unzr_verification_reason = ONLINE_TRIGGERED

• unzr_unverified_at = null

Step 5. Update Person

Invoke the Step If person_verifications.unzr_verification_status still IN_REVIEW

If person’s UNZR hasn’t been found in the MVS register at Step 2 and we’ve received Status = 0, then:

1. Update persons record:

• unzr = null (if it is not null)

1. Update person_verifications record by person_id:

• unzr_data_id = null

• unzr_data_status = 0. The value according to the Status field in checkunzr response.

• unzr_synced_at = date and time when synchronization has been performed (current datetime)

• unzr_verification_status = NOT_VERIFIED

• unzr_verification_reason = AUTO

• unzr_unverified_at = current datetime

Step 6. Technical error returned

If technical error: checkunzr response with Status = -1, -2, internal error, timeout, etc. returned from Step 2 - the Person is considered unprocessed.

If person_verifications.unzr_verification_status still IN_REVIEW:

• rollback to the previous unzr_verification_status and unzr_verification_reason (that was before IN_REVIEW set in Step 2)