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

...

Value

...

Description

...

Example

...

DRFO_PERSON_SYNCHRONIZATION_SCHEDULE

...

Cron parameter, represents start time of the DRFO data synchronization

...

"0 1 * * *"

...

DRFO_PERSON_VALIDATION_PERIOD_DAYS

...

Represents period in days when the existing saved DRFO data should be validated in DRFO registry if it still valid.

...

"180"

...

PERSONS_SYNCHRONIZATION_BATCH_SIZE

...

Amount of Person records performed by job at once

...

"100"

Data flow

Scheduler 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

...

Source:

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

• mpi.person_verifications.drfo_synced_at <= current_date - DRFO_PERSON_VALIDATION_PERIOD_DAYS OR drfo_synced_at is null

• has tax_id or (hasn’t tax_id and age > no_self_auth_age)

• exclude persons who has drfo_verification_status = IN_REVIEW and drfo_verification_reason = AUTO (such status means they has already being processed by the job at the moment)

Order selected records in descending way by:

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

...

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

Scheduler 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

...

Source:

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

• mpi.person_verifications.drfo_synced_at <= current_date - DRFO_PERSON_VALIDATION_PERIOD_DAYS OR drfo_synced_at is null

• has tax_id or (hasn’t tax_id and age > no_self_auth_age)

• exclude persons who has drfo_verification_status IN(IN_REVIEW, VERIFICATION_NOT_NEEDED) and drfo_verification_reason = AUTO (such status means they has already being processed by the job at the moment, or person is inactive and shouldn’t be verified with drfo)

Order selected records in descending way by:

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

• RNOKPP = mpi.persons.tax_id if exists, else - mpi.person_documents.number. For document number: get document with the latest issued_at, but exclude those with an expiration_date that is less than the current date, and type should be in (“PASSPORT”, “NATIONAL_ID”).

  • if RNOKPP not defined OR RNOKPP format doesn't match pattern (^(?![ЫЪЭЁ])[А-ЯҐЇІЄ]{2}[0-9]{6}$|^[0-9]{9}$|^[0-9]{10}$) - InfoRNOKPPDRFO shouldn't be called:

    • If person is FEMALE with age > 16, then set person_verification for it:

      • drfo_data_id = null

      • drfo_data_result = null

      • drfo_synced_at = current datetime

      • drfo_verification_status = NOT_VERIFIED

      • drfo_verification_reason depends on conditions:

        • if RNOKPP not defined - TAX_ID_AND_PASSPORT_DOCUMENT_ABSENT

        • if RNOKPP format doesn't match pattern - INVALID_RNOKPP_FORMAT

      • drfo_unverified_at = current datetime

    • else - Step 5. Call FindRegistrationDRFOQuery should be initialized.

• last_name = mpi.persons.last_name

• first_name = mpi.persons.first_name

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

• date_birth = mpi.persons.birth_date

...

• drfo_verification_status = IN_REVIEW

• drfo_verification_reason = AUTO

• drfo_unverified_at = null (if not null)

Step 3. Create or update drfo_data

...

Step 4.1. Update another Persons

...

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

...

• document.series_number = mpi.person_documents.number. Get number of document with the latest issued_at with types: “PASSPORT”, “NATIONAL_ID”, “BIRTH_CERTIFICATE”, “BIRTH_CERTIFICATE_FOREIGN”, “PERMANENT_RESIDENCE_PERMIT”, “TEMPORARY_CERTIFICATE”. If one of these documents was used in Step 2, then chose another one at this Step. Documents with type “PASSPORT” or “NATIONAL_ID” are priority.

• 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

...

• 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

...

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

...

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

...