Versions Compared

Key

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

...

  1. Confidant_person is an object, not an array.

  2. It is allowed to submit confidant person when person is created.

  3. It is not allowed to submit confidant person when person is updated.

  4. Validation of confidant person is updated: age, verification status and auth methods are important.

  5. Validation of auth methods is updated: in case if person has confidant, as THIRD_PERSON in auth methods must be submitted confidant.

  6. Validation of person documents is updated: if person`s age is between no_self_registration_age and person_full_legal_capacity_age, documents that prove legal capacity can be sumbitted. In case if legal capacity is provenoven by document, person can not have confidant.

  7. Validate necessity of confidant person is added: in some cases (view on validations below) it is necessary to have confidant if person is created (in the request body) and if person is updated (in db https://e-health-ua.atlassian.net/wiki/spaces/EDDREH/pages/18048483381724729917/MPI#confidant_person_relationships#confidant_person_relationships ).

  8. Links to save documents for confidant persons are updated.

  9. When person, that is updated, must be authorized by confidant person - authentication method with type = THIRD_PERSON must be passed in authorize_with field.

...

Create person request

...

A block with information about confidant person must be transferred when the person is created.
New endpoints https://e-health-ua.atlassian.net/wiki/spaces/CSIEH/pages/1761329156118000249910 must be used to manage list of persons confidants.

...

  • Check that confidant_person.person_id exists in persons table (MPI DB) with status = active and is_active = true

    • in case of error - return 422 ('Confidant person is not found')

  • Check if confidant person itself shouldn’t be authorized by confidant - so it doesn’t correspond to following rules:

    • confidant persons age < no_self_registration_age global parameter;

    • confidant persons age between no_self_registration_age and person_full_legal_capacity_age global parameters and person does not have document with type from PERSON_LEGAL_CAPACITY_DOCUMENT_TYPES config parameter;

    • confidant persons age > person_full_legal_capacity_age global parameter and exists at least one active and approved confidant person relationship for person (using following process /wiki/spaces/CSI/pages/17667883028 Check confidant person relationship with person_id = $.person.confidant_person.person_id from request - expected :ok, :approved response)

    • confidant person has at least one confidant person in persons.confidant_person array

      • in case of error - return 422 ('Person with incorrect age or with active confidant person relationship can not be submitted as confidant')

  • Check that confidant person cumulative verification status is not in NOT_ALLOWED_CONFIDANT_PERSON_VERIFICATION_STATUSES config parameter

    • in case of error - return 422 ('Person with cumulative verification status <person.verification_status> can not be submitted as confidant')

  • Check that confidant person has active authentication method with type = OTP

    • in case of error - return 422 ('Confidant person must have active authentication method with type "OTP"')

  • Validate confidant persons documents_relationship

    • Validate document issued_at date

      • Check that issued_at <= now()

        • in case of error - return 422 ('Document issued date should be in the past')

      • Check that issued_at => person.birth_date

        • in case of error - return 422 ('Document issued date should greater than person.birth_date')

    • Validate document active_to date

      • Check that active_to > now()

        • in case error - return 422 ('Document active_to should be in future')

    • Validate document type according to DOCUMENT_RELATIONSHIP_TYPEdictionary

      • In case of error - return 422 ('value is not allowed in enum')

    • Validate document number according to regexp (as part of JSON Schema validation) 

      • BIRTH_CERTIFICATE - ^((?![ЫЪЭЁыъэё@%&$^#`~:,.*|}{?!])[A-ZА-ЯҐЇІЄ0-9№\\/()-]){2,25}$

        • In case of error - return 422 ('string does not match pattern') with the corresponding regexp

      • other document type numbers should be validated according to format varchar (255)

        • in case of error - return 422 ('expected value to have a maximum length of 255 but was <<document_number_length>>')

...

  1. Validate block confidant person. If $.person.confidant_person is not null:

    • Generate URLs with type confidant_person.{confidant_person.person_id}.documents_relationship.[:].{type}

  2. Validate block of person documents. If one of the documents has document.type = BIRTH_CERTIFICATE_FOREIGN and there is no same document in {$.person_request.person.confidant_person.[:].documents_relationship.[:]}

    and persons age < no_self_auth_age global parameter then

    1. Generate URL with type person.BIRTH_CERTIFICATE_FOREIGN

  3. Validate block of person documents. If one of the documents has document.type = PERMANENT_RESIDENCE_PERMIT and persons age >= no_self_auth_age global parameter then

    1. Generate URL with type person.PERMANENT_RESIDENCE_PERMIT

  4. Validate block of authentication methods. If authentication method type = OFFLINE

    1. Generate URLs with type person.{$.person.documents.[:].type} for each persons document

  5. Validate persons unzr. If $.person.unzr is not empty and first 8 digits of $.person.unzr != $.person.birth_date

    1. Generate URL with type person.unzr

Invoke Media Content Storage to generate upload URL for each document obtained by executing logic above and save documents to DB.

...

  • Check that $.person.id is a valid uuid

    • in case error - return 422 ('string does not match pattern') with uuid regexp

  • Check that person exists in persons table (MPI DB) with status = active and is_active = true 

    • in case error - return 404 ('Person does not exist.’)

  • Check that amount of changes of person data in request is acceptable (person is not updated too much). Compare updated person data with data from person request using existing deduplication model https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/583402355/Deduplication+process+NEW#Variables-calculation-for-each-pair - check that resulted comparison score is greater that PERSON_ONLINE_DEDUPLICATION_UPDATE_SCORE config parameter

    • in case of error - return 409 ('Such person can't be updated. Deduplication update score is lower than system value (less changes should be made)')

...

Validate client

Validate as on Create person request process

Validate tax id

  • If updated persons tax_id is not null - check that $.person.tax_id equals to updated persons tax_id

    • in case of error - return 422 ('tax_id can't be updated')

  • Validate as on Create person request process

Validate no_tax_id flag

Validate as on Create person request process

Validate patient_signed flag

Validate as on Create person request process

Validate process_disclosure_data_consent flag

Validate as on Create person request process

Validate person addresses

Validate as on Create person request process

Validate person documents

...

  • Check that $.authorize_with with auth_method.type = 'THIRD_PERSON' is submitted for person that must be authorized by confidant person using following logic:

    1. persons age < no_self_registration_age global parameter;

    2. persons age between no_self_registration_age and person_full_legal_capacity_age global parameters and person does not have document with type from PERSON_LEGAL_CAPACITY_DOCUMENT_TYPES config parameter;

    3. persons age > person_full_legal_capacity_age global parameter and exists at least one active and approved confidant person relationship for person (using following process /wiki/spaces/CSI/pages/17667883028 Check confidant person relationship with person_id = person from request - expected :ok, :approved response)

      1. in case of error - return 422 ('Authentication method with type THIRD_PERSON must be submitted for this person')

  • Check that $.authorize_with is a valid uuid

    1. in case error - return 422 ('string does not match pattern') with uuid regexp

  • Check that auth method exists in MPI database, person_authentication_methods table, belongs to person from request, stored in $.person.id, is active (ended_at > now() or ended_at is null and is_active = true), and type != NA, additionally for auth method with type = ‘THIRD_PERSON’ - check that person from value is an approved confidant for a $.person.id from request – exists active and approved confidant person relationship between person from request and person_id from authentication method value (using following logic: /wiki/spaces/CSI/pages/17667883028 Check confidant person relationship with person_id = person from request and confidant_person_id = value from auth method - expected :ok, :approved response)

    1. in case error - return 409 ('Authentication method doesn't belong to person.')

...

If person request doesn't have this field, then choose that method which is returned from mpi as using following process Determination of a default authentication method and return person's active auth_methods .

Determine authentication method current for request

  • If $.authorize_with is not null - set its value as authentication method current for request

  • If $.authorize_with is null -set default auth method as authentication method current for request - use function in mpi that return default auth method

    • Check that persons default auth method != NA

      • in case of error - return 409 ('Person does not have active auth methods.')

...