Purpose

This job designed for initial and further regular synchronization of Persons with the DRFO registry. In addition, it can work on a schedule to make synchronization of updated Persons via Person Request whose DRFO data hasn’t been updated online due to technical reasons.

Key points

1. Job can modify Person data in MPI: tax_id and no_tax_id fields. But, these fields does not update if person is female with age > 16, so FindRegistrationDRFO service does not call for it.

2. Job gets DRFO records using strict Person data, such as last name, first name etc. (w/o any assumptions and data modifications)

3. It is assumed that DRFO record is unique within RNOKPP. So if such record does not exists in drfo_data table (MIMIR db) it will be created, if exists - updated.

4. The result of the job changes verification status and reason according to received result from DRFO registry. Also, if success the DRFO data is saved and linked to the Person.

5. Verification status of another Persons/Parties associated with updated DRFO data may be changed too.

Configuration

Data flow

Scheduller starts according to DRFO_PERSON_SYNCHRONIZATION_SCHEDULE cron parameter and gets number of entries pointed at PERSONS_SYNCHRONIZATION_BATCH_SIZE chart parameter. After, it creates an oban job that selects Persons which match to some filter parameters. For each the job receives Person data on input and returns the result of reconciliation with the DRFO registry to output (details in “Step description” section below):

• if RNOKPP is found and matches to the person’s tax_id or passport/national_id number - set verification status to VERIFIED along with verification reason AUTO. Also, update no_tax_id to “false” (if it has not set to “false” yet) for tax ID returned in RNOKPP; update no_tax_id to “true” (if it has not set to “true” yet) for passport/national_id number returned in RNOKPP. The DRFO data is saved and linked to the Person.

• if RNOKPP is found and doesn’t match to the person’s tax_id or passport/national_id number.
  For passport/national_id number - set verification status to NOT_VERIFIED along with verification reason AUTO if any document with such number does not exist in person documents; if any document with such number exists - set verification status to VERIFIED along with verification reason AUTO. Update no_tax_id to true (if it has not set to true yet) and tax_id to null (if it is not null).
  For tax_id returned in RNOKPP - just update person’s tax_id to RNOKPP value, set verification status to VERIFIED along with verification reason AUTO and update no_tax_id to false (if it has not set yet). DRFO data is saved and linked to the Person;

• if person identified as deceased - the verification status sets to VERIFICATION_NEEDED and verification reason to POTENTIALLY_DECEASED. Update no_tax_id and tax_id to null because DRFO does not return RNOKPP in this case and we don’t know what it really was.
  DRFO data is not saved and not linked to the Person;

• if person identified as having closed RNOKPP - the verification status sets to NOT_VERIFIED along with verification reason AUTO. Update no_tax_id and tax_id to null because DRFO does not return RNOKPP in this case and we don’t know what it really was.
  DRFO data is not saved and not linked to the Person;

• if RNOKPP is not found for the person - set verification status to NOT_VERIFIED for adults and VERIFIED for underaged person (configured in no_self_auth_age global parameter, equal 14 at the moment); verification reason set to AUTO. Update no_tax_id, tax_id and drfo_data_id to null.
  DRFO data is not saved and not linked to the Person;

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

UML

...

Step description

Step 1. Get list of Persons

Get list of Persons with status=active and is_active=true who meets the following criteria (using logical AND):

...

• drfo_verification_status = VERIFICATION_NEEDED and drfo_verification_reason = ONLINE_TRIGGERED(should be at the top of the list)

Step 2. Call InfoRNOKPPDRFO

Check person’s RNOKPP - invoke RPC call with third-party service https://e-health-ua.atlassian.net/wiki/spaces/RNOKPP/pages/17271128443/DRFO+Trembita+methods_ph2_EN#Info%D0%A0N%D0%9E%D0%9APPDRFO using following request params:

...

• drfo_verification_status = IN_REVIEW

• drfo_verification_reason = AUTO

• drfo_unverified_at = null (if not null)

Step 3. Create or update drfo_data

If RNOKPP check in Step 2 was successful and RESULT=0 returned. Get record from mimir.drfo_data table by rnokpp:

...

Step 4. Update Person

Invoke the Step If person_verifications.drfo_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 DRFO performed)

...

Step 4.1. Update another Persons

Invoke the Step If person_verifications.drfo_data_verification_status is not IN_REVIEW

...

• drfo_data_id = null

• drfo_data_result = null

• drfo_synced_at = null

• drfo_verification_status = VERIFICATION_NEEDED

• drfo_verification_reason = ONLINE_TRIGGERED

• drfo_unverified_at = null (if not null)

Step 4.2. Update Parties

Invoke the Step if party_verifications.drfo_verification_status is not IN_REVIEW

...

• drfo_data_id = null

• drfo_data_result = null

• drfo_synced_at = null

• drfo_verification_status = VERIFICATION_NEEDED

• drfo_verification_reason = ONLINE_TRIGGERED

• drfo_unverified_at = null (if not null)

Step 2.1. Update Person

Invoke the Step If person_verifications.drfo_data_verification_status still IN_REVIEW

...

• If RNOKPP check in Step 2 returned RESULT that is not 0:

  • drfo_data_id = null

  • drfo_data_result = value according to DRFO_RESULT dictionary (negative for InfoRNOKPPDRFO service)

  • drfo_synced_at = current datetime

  • drfo_verification_status = NOT_VERIFIED

  • drfo_verification_reason = AUTO

  • drfo_unverified_at = current datetime

• If RNOKPP check in Step 2 was not successful (error):

  • rollback to previous drfo_verification_status and drfo_verification_reason (that was before IN_REVIEW set in Step 2)

Step 5. Call FindRegistrationDRFOQuery

Invoke the Step If person_verifications.drfo_data_verification_status still IN_REVIEW

...

• document.series_number = mpi.person_documents.number. Get number of document with the latest issued_at. If one of these documents was used in Step 2, then chose another one at this Step

• person.last_name = mpi.persons.last_name

• person.first_name = mpi.persons.first_name

• person.middle_name = mpi.persons.second_name (skip if empty)

• person.date_birth = mpi.persons.birth_date

Step 6. Create Job

At this step an oban job creates. It awaits a response on application returned in Step 5 and includes steps described below.

Step 7. Call FindRegistrationDRFOAnswer

Invoke the Step If person_verifications.drfo_data_verification_status still IN_REVIEW

Invoke RPC call with third-party service https://e-health-ua.atlassian.net/wiki/spaces/RNOKPP/pages/17271128443/DRFO+Trembita+methods_ph2_EN#FindRegistrationDRFOAnswer in a loop while getting error = 1002 (application in process). The FindRegistrationDRFOAnswer uses applicationNumber and applicationDate as parameters (were returned in Step 5.)

Step 8. Create or update drfo_data

If valid RNOKPP was found: application with Info.RNOKPP and Info.result=0 returned in Step 7. Get record from mimit.drfo_data table by rnokpp:

...

Step 9. Update Person

Invoke the Step If person_verifications.drfo_data_verification_status still IN_REVIEW

...

• drfo_data_id = mimir.drfo_data.id

• drfo_data_result = 20. The value according to DRFO_RESULT dictionary.

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

• drfo_verification_reason = AUTO

• drfo_verification_status:

  • set VERIFIED for rnokpp as tax ID or passport number (if non-expired document with such number exists in person documents) returned

  • set NOT_VERIFIED for rnokpp as passport number returned if non-expired document with such number not exists in person documents

• drfo_unverified_at:

  • if drfo_verification_status = VERIFIED then set to null (if not null)

  • if drfo_verification_status = NOT_VERIFIED then set to current datetime

Step 9.1. Update another Persons

The same logic as described in Step 4.1.

Step 9.2. Update Parties

The same logic as described in Step 4.2.

Step 10. Update Person

Invoke the Step If person_verifications.drfo_data_verification_status still IN_REVIEW

If person was identified as potentially deceased in DRFO registry (RNOKPP not received): application with Info.result = 5 returned in Step 7 - update Person record in MPI db, without relation to drfo_data. Update following person’s data:

• no_tax_id = null (if it is not null)

• tax_id = null (if it is not null)

Update person_verifications record by person_id:

• drfo_data_id = null (if it is not null)

• drfo_data_result = 25. The value according to DRFO_RESULT dictionary.

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

• drfo_verification_status = NOT_VERIFIED

• drfo_verification_reason = AUTO

• drfo_unverified_at = current datetime

• dracs_death_verification_status = VERIFICATION_NEEDED

• dracs_death_verification_reason = ONLINE_TRIGGERED

• dracs_death_online_status = READY

Step 11. Update Person

Invoke the Step If person_verifications.drfo_data_verification_status still IN_REVIEW

If person identified as having closed RNOKPP in DRFO registry (RNOKPP not received): application with Info.result = 6 returned in Step 7 - update Person record in MPI db, without relation to drfo_data. Update following person’s data:

• no_tax_id = null (if it is not null)

• tax_id = null (if it is not null)

Update person_verifications record by person_id:

• drfo_data_id = null (if it is not null)

• drfo_data_result = 26. The value according to DRFO_RESULT dictionary.

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

• drfo_verification_status = NOT_VERIFIED

• drfo_verification_reason = AUTO

• drfo_unverified_at = current datetime

Step 12. Update Person

Invoke the Step If person_verifications.drfo_data_verification_status still IN_REVIEW

...

• drfo_data_id = null (if it is not null)

• drfo_data_result = 21 or 22. The value according to DRFO_RESULT dictionary depending on the returned result

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

• drfo_verification_reason = AUTO

• drfo_verification_status:

  • set NOT_VERIFIED if person age > no_self_auth_age

  • set VERIFIED if person age < no_self_auth_age

• drfo_unverified_at:

  • if drfo_verification_status = VERIFIED then set to null (if not null)

  • if drfo_verification_status = NOT_VERIFIED then set to current datetime

Step 13. Technical error returned

If technical error: application with Info.result in (4,3), error in (1000, 1004), timeout, etc. returned in Step 7 - the Person is considered unprocessed.

...

• rollback to previous drfo_verification_status and drfo_verification_reason (that was before IN_REVIEW set in Step 2)

Log info

To find details about synchronization of specific person in the Elastic you can use following filters:

...