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

...

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

...

• 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

...

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:

...

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)

...

• 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

...

• 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

...

• 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.

...