Page Comparison

Purpose

This WS is designed to mark in error previously created Device request in case it was entered in error.

Specification

Apiaryhttps://medicaleventsmisapi.docs.apiary.io/#reference/device-requests/mark-in-error-device-request/mark-in-error-device-request

Authorization

1. Verify the validity of access token

   • in case of error - return 401 (“Invalid access token”) in case of validation fails

2. Verify that token is not expired

   • in case of error - return 401 (“Invalid access token”)

3. Check user scopes in order to perform this action (scope = 'device_request:mark_in_error')

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

4. If BLOCK_UNVERIFIED_PARTY_USERS is true, then check party's data match following condition: verification_status != NOT_VERIFIED or (verification_status = NOT_VERIFIED and updated_at > current_date - UNVERIFIED_PARTY_PERIOD_DAYS_ALLOWED):

   • in case not match - return 403 ("Access denied. Party is not verified")

5. If BLOCK_DECEASED_PARTY_USERS is true, check that party is not deceased (party_verification record does not equal to: dracs_death_verification_status = VERIFIED and dracs_death_verification_reason = MANUAL_CONFIRMED):

   • in case of error - return 403 ("Access denied. Party is deceased")

Validations

Validate request

...

1. Validate request is signed

   1. in case of error - return 400 (“Invalid signed content”)

2. Check DS is valid and not expired

3. Validate that DS belongs to the user

   1. Check that DRFO from DS and party.tax_id matches

      1. in case of error - return 422 (“Does not match the signer drfo“)

Validate user

Marking in error a Device Request is allowed for a user if he has one of the following active and approved employee that:

• is an Employee from legal entity where Device Request is created

  • in case of error - return 409 ("Only an employee from legal entity where device request is created can mark it in error")

Validate transition

1. Get current device request status

   1. Check that status != “entered_in_error”

      1. in case of error - return 409 error ('Device request in status entered_in_error cannot be marked in error')

For more information look at [UPD] Device request status model.

Validate status reason

1. Validate $.status_reason.code is a value from device_request_mark_in_error_reasons dictionary

   1. in case of error - return 422 ("value is not allowed in enum")

...

1. Save signed content to media storage

2. Update device request status to entered-in-error (update also updated_at, updated_by)

3. Get person's authentication_method of MPI

4. If authentication_method == OTP or THIRD_PERSON (with OTP),:

   1. Check if sms notifications are enabled:

      1. if device_request has a program specified

         1. check that the specified program has setting request_notification_disabled set in false or the setting is absent, else

      2. if device_request has no program specified

         1. check config parameter DEVICE_REQUESTS_SMS_ENABLED is set in true

5. Generate text SMS with template MARK_IN_ERROR_DEVICE_REQUEST_SMS_TEMPLATE and send it

6. Save internal information to corresponding DB

7. Send StatusChangeEvent to the Event Manager