Versions Compared

Key

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

Purpose

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

Specification

Apiary

Key points

...

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

...

https://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.

...

  1. Confidant_person is an object, not an array, so user must use responses from https://e-health-ua.atlassian.net/wiki/spaces/CSIEH/pages/17613226064 or 18000740387 or https://e-health-ua.atlassian.net/wiki/spaces/CSIEH/pages/1761342267617999298891

  2. In case if document that prove legal capacity is set: deactivates all person records in IL | confidant https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/724271171/IL#confidant_person_relationship_requests and MPI | confidant https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/724729917/MPI#confidant_person_relationships tables.

  3. In case if person is created and confidant is submitted: creates relationship in MPI | confidant https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/724729917/MPI#confidant_person_relationships and saves documents that prove relationship to MPI | confidantprove relationship to https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/724729917/MPI#confidant_person_relationship_documents .

Authorization

  • Verify the validity of access token

    • Return (401, 'Invalid access token') in case of validation fails

  • Verify that token is not expired

    • in case of error - return (401, 'Invalid access token')

  • Check user scopes in order to perform this action (scope = 'person_request:write')

    • Return (403, 'Your scope does not allow to access this resource. Missing allowances: person_request:write') in case of invalid scope(s)

...

This WS can sign only person requests that were approved by https://e-health-ua.atlassian.net/wiki/spaces/CSIEH/pages/1761342267617999298891

  • Check that person_request.version field is equal to 2

    • in case of error - return 422 ('Person request cannot be processed by the version 2 of the service, use version 1 instead')

  • Check that channel equals to MIS

    • in case of error - return 422 ('Only person request with MIS channel can be signed.')

...

...

Then person will be verified online with DRFO registry via separate process: /wiki/spaces/RNOKPP/pages/17158275099 DRFO data synchronization for Persons | Data flow

DRACS death acts registry verification

...

Then person will be verified online with DRACS death acts registry via separate process: Online verification of Persons with DRACS death acts registry: https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/17629643174

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: https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/18201837580

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/DRACS2EH/pages/1814400205218231492689

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/DRACS2EH/pages/17859870885/UPD+Person+verification+status+model#Cumulative-verification-status18254790685:

  • Set calculated status to persons.verification_status field

  • Create StatusChangeEvent in event manager with new verification status if it was changed

...

In case if person is created and person.confidant_person.person_id exists in person_data for person request - create confidant person relationship between person and confidant person:

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

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