ЕСОЗ - публічна документація

RC_(GraphQL) Update Person UNZR verification status (DMS)

Owned by Anna Popelysheva (SoE eHealth)
Last updated: Oct 01, 2024
2 min read

Purpose

This WS allows to submit person on repeat verification to UNZR stream using Admin panel immediately without awaiting it’s data update or verification schedule.

Key points

  1. This graphQl method is used in Administration panel only

  2. Only authenticated and authorized NHS employee with appropriate scope can verify persons.

  3. It is allowed to set VERIFICATION_NEEDED status only

  4. Person could have any previous verification status to be changed on VERIFICATION_NEEDED by the mutation. That is, no status transitions there.

Specification

"Updates UNZR verification status for a single `Person` by NHS using its globally unique ID." updatePersonUnzrVerificationStatus( input: UpdatePersonUnzrVerificationStatusInput! ): UpdatePersonUnzrVerificationStatusPayload
""" Input for `updatePersonUnzrVerificationStatus` mutation. """ input UpdatePersonUnzrVerificationStatusInput { "Person unique identifier." personId: ID! "Person verification status" unzrVerificationStatus: PersonVerificationStatus! "Person UNZR verification reason" unzrVerificationReason: PersonUnzrVerificationReason! } """ Return type for `updatePersonUnzrVerificationStatus` mutation. In order to verify person user must have a scope `person:verify`. """ type UpdatePersonUnzrVerificationStatusPayload { "Payload for person." person: Person }

Authorization

  • Verify the validity of access token

    • in case of error - 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:verify')

    • return 403 (“Your scope does not allow to access this resource. Missing allowances: person:verify”) in case of invalid scope(s)

Validate legal entity

  • Extract client_id from token.

  • Check client scopes in order to perform this action (scope = 'person:verify')

    • in case of error - return 403 (“Your scope does not allow to access this resource. Missing allowances: person:verify”)

  • Check legal entity status (status = ACTIVE) and is_active=true

    • In case of error - return 409 ('client_id refers to legal entity that is not active')

Validate request

Validate input of the mutation for the following fields:

1. Person

Validate value in the field personId, identifier (ID), required

  • Check it is submitted

    • in case of error - return 422 ('required property <property name> was not present')

  • Check person exists in the DB

    • in case of error - return 404 ('Person not found')

  • Validate person has status=active and is_active=true

    • in case of error - return 409 ('Person is not active')

2. Verification status

Validate value in the field unzrVerificationStatus, enum, required

  • Check it is submitted

    • in case of error - return 422 ('required property <property name> was not present')

  • Check value is VERIFICATION_NEEDED according to PERSON_VERIFICATION_STATUSES dictionary.

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

3. Verification reason

Validate value in the field unzrVerificationReason, enum, required

  • Check it is submitted

    • in case of error - return 422 ('required property <property name> was not present')

  • Check value is MANUAL according to PERSON_VERIFICATION_STATUS_REASONS dictionary.

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

Service logic

  1. Set fields in person_verifications table (mpi database) for a $.personId :

    1. unzr_verification_status = $.unzrVerificationStatus

    2. unzr_verification_reason = $.unzrVerificationReason

    3. updated_by = user_id (from token)

    4. updated_at = current timestamp

    5. unzr_data_id = null

    6. unzr_data_status = null

    7. unzr_synced_at = null

    8. unzr_unverified_at = null

  2. Recalculate cumulative verification status according to logic described at https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/17702781134/Person+verification+data+model#Cumulative-verification-status

  3. Create StatusChangeEvent in event manager with the cumulative verification status if such was changed

ЕСОЗ - публічна документація