Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

...

This WS is used to sign previously approved Person request (as part of Person creation w/o declaration process).

Specification

Apiaryhttps://uaehealthapi.docs.apiary.io/#reference/public.-medical-service-provider-integration-layer/person-requests/sign-person-request-v2

Key points

  1. Signed content must consists of JSON object with person request data and printout template.

  2. Person must re-read and sign person request print form and after that patient_signed should be changed to true.

  3. This WS will store signed copy of person request in Media Content Storage, create or update MPI records if all checks are passed.

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

...

Then person will be verified online with DRACS death acts registry via separate process: Online verification of Persons with DRACS death acts registry

DRACS birth acts registry verification

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

  1. Person is created and persons age <= no_self_auth_age and person has document with type BIRTH_CERTIFICATE (check in Request, within $.person.documents)

  2. Person is created and persons age > no_self_auth_age and person has only document with type BIRTH_CERTIFICATE (check in Request, within $.person.documents)

  3. Person is updated and persons age <= no_self_auth_age and person has document with type BIRTH_CERTIFICATE (check in Request, within $.person.documents) and following fields are updated:

    1. first_name

    2. last_name

    3. second_name

    4. birth_date

    5. document.number with type = ‘BIRTH_CERTIFICATE’

  4. Person is updated and persons age > no_self_auth_age and person has only document with type BIRTH_CERTIFICATE (check in Request, within $.person.documents) and following fields are updated:

    1. first_name

    2. last_name

    3. second_name

    4. birth_date

    5. document.number with type = ‘BIRTH_CERTIFICATE’

thenonline verification with DRACS birth acts registry needed. Set to person verification record:

  • dracs_birth_act_id = null

  • dracs_birth_verification_status = VERIFICATION_NEEDED

  • dracs_birth_verification_reason = ONLINE_TRIGGERED

  • dracs_birth_verification_comment = null

  • dracs_birth_synced_at = null

  • dracs_birth_unverified_at = null

Check existence of verification candidates for person_id with status = ‘NEW’ and entity_type = ‘dracs_birth_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 birth acts registry via separate process: DRACS birth acts synchronization for Persons

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

  • if person is created:

    • dracs_birth_act_id = null

    • dracs_birth_verification_status = VERIFICATION_NOT_NEEDED

    • dracs_birth_verification_reason = INITIAL

    • dracs_birth_verification_comment = null

    • dracs_birth_synced_at = null

    • dracs_birth_unverified_at = null

  • if person is updated – do not update dracs_birth_verification_status and dracs_birth_verification_reason for person.

DRACS name change acts registry verification

If person is created, set values in person_verifications table:

  • dracs_name_change_verification_status = VERIFICATION_NOT_NEEDED

  • dracs_name_change_verification_reason = INITIAL

If person is updated and persons dracs_name_change_verification_status = ‘VERIFICATION_NEEDED’:

Legal capacity verification

If person’s data match following rules: person has legal capacity document (from PERSON_LEGAL_CAPACITY_DOCUMENT_TYPES config parameter) with type ‘MARRIAGE_CERTIFICATE’ or ‘DIVORCE_CERTIFICATE’ (check in Request, within $.person.documents)

thenonline verification with DRACS certificates registry is needed. Set to person verification record:

  • legal_capacity_verification_status = VERIFICATION_NEEDED

  • legal_capacity_verification_reason = ONLINE_TRIGGERED

  • legal_capacity_entity_id = NULL

  • legal_capacity_entity_type = NULL

  • legal_capacity_unverified_at = NULL

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

If person’s data match following rules: person has legal capacity document (from PERSON_LEGAL_CAPACITY_DOCUMENT_TYPES config parameter) with type other than ‘MARRIAGE_CERTIFICATE’ or ‘DIVORCE_CERTIFICATE’ (check in Request, within $.person.documents)

thenpersons legal capacity is verified by default. Set to person verification record:

  • legal_capacity_verification_status = VERIFICATION_NOT_NEEDED

  • legal_capacity_verification_reason = AUTO_DATA_ABSENT

  • legal_capacity_entity_id = NULL

  • legal_capacity_entity_type = NULL

  • legal_capacity_unverified_at = NULL

If person does not have legal capacity document (from PERSON_LEGAL_CAPACITY_DOCUMENT_TYPES config parameter), legal capacity verification is not needed. Set to person verification record:

  • legal_capacity_verification_status = VERIFICATION_NOT_NEEDED

  • legal_capacity_verification_reason = AUTO_DATA_ABSENT

  • legal_capacity_entity_id = NULL

  • legal_capacity_entity_type = NULL

  • legal_capacity_unverified_at = NULL

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, DRACS birth acts registry verification, DRACS name change acts registry verification according to logic described at https://e-health-ua.atlassian.net/wiki/spaces/DRACS2/pages/17859870885/UPD+Person+verification+status+model#Cumulative-verification-status:

...

  • Call Create confidant person relationship, set values:

    • confidant_person_id = person.confidant_person.person_id

    • person_id = id of created person

    • verification_status = “VERIFICATION_NEEDED”

    • verification_reason based on relationship document:

      • if confidant_person.relationship_documents contains document with type BIRTH_CERTIFICATE, set verification_reason = “ONLINE_TRIGGERED”

      • if confidant_person.relationship_documents does not contain document with type BIRTH_CERTIFICATE, set verification_reason = “MANUAL_CREATED_BY_DOCTOR”

    • confidant_person_relationship_documents = person.confidant_person.documents_relationship

    In case if persons age < person_full_legal_capacity_age global parameter:

    • calculate relationship_expiration_date - date when person becomes person_full_legal_capacity_age years old

    • check if $.active_to <= relationship_expiration_date

      • if true - set active_to = $.active_to

      • if false or $.active_to = null - set active_to = relationship_expiration_date

In case if person is updated (person.id exists in person_data for person request) and at least one of submitted person document types exist in PERSON_LEGAL_CAPACITY_DOCUMENT_TYPES config parameter and legal_capacity_verification_status = VERIFIED or VERIFICATION_NOT_NEEDED according to Legal capacity verification - deactivate all existing confidant person relationships for person:

  • Deactivate all records in IL | confidant_person_relationship_requests table where person_id = person.id and status = NEW, set values:

    • status = CANCELLED

    • updated_at = now()

    • updated_by = user_id (from token)

  • Deactivate all records in MPI | confidant_person_relationships table where person_id = person.id and is_active = true. Set:

    • active_to = now()

    • updated_at = now()

    • updated_by = user_id (from token)

  • For each relationship from previous step - deactivate person authentication methods with type = THIRD_PERSON and value = confidant_person_relationships.confidant_person_id, set values:

    • ended_at = now()

    • updated_at = now()

    • updated_by = user_id (from token)

In case if person is updated (person.id exists in person_data for person request), and person has active Confidant person relationships with relationship document with type='BIRTH_CERTIFICATE' and following person fields are updated:

  • first_name

  • last_name

  • second_name

  • birth_date

Update found active Confidant person relationships as those that need online verification with DRACS birth acts registry, set values:

  • verification_status = “VERIFICATION_NEEDED”

  • verification_reason = “ONLINE_TRIGGERED”

  • updated_at = now()

  • updated_by = user_id

Check existance of verification candidates for updated confidant_person_relationship_id with status = ‘NEW’ and entity_type = ‘dracs_birth_act' in confidant_person_relationship_verification_candidates table, if found - deactivate them, set:

  • status = ‘DEACTIVATED’

  • status_reason = ‘PERSON_UPDATED’

  • updated_at = now()

In case if person is updated (person.id exists in person_data for person request), and person exists in the system as confidant person in active confidant person relationship with relationship document with type='BIRTH_CERTIFICATE' and following person fields are updated:

  • first_name

  • last_name

  • second_name

  • birth_date

  • tax_id

Update found active Confidant person relationships as those that need online verification with DRACS birth acts registry, set values:

  • verification_status = “VERIFICATION_NEEDED”

  • verification_reason = “ONLINE_TRIGGERED”

  • updated_at = now()

  • updated_by = user_id

Check existance of verification candidates for updated confidant_person_relationship_id with status = ‘NEW’ and entity_type = ‘dracs_birth_act' in confidant_person_relationship_verification_candidates table, if found - deactivate them, set:

  • status = ‘DEACTIVATED’

  • status_reason = ‘CONFIDANT_PERSON_UPDATED’

  • updated_at = now()