Overview

This web service allows to cancel encounter and other components of Data Package such as conditions, observations, allergy_intolerances and immunizations in case they were entered in error.

Specification

Apiary

Authorization

Validate token

• Verify the validity of access token

  • Return 401 in case validation fails

• Verify token is not expired

  • in case error return 401 

• 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")

• 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")

Validate scopes

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

  1. Return 403 in case invalid scope(s)

Validate legal entity

• Validate episode belongs to the legal entity where the current user works

  • ME.encounter.episode.managing_organization==token.client_id

    • in case of error return 422 "Managing_organization does not correspond to user`s legal_entity"

Validate patient

• Validate patient is active

  •  ME.patient.status=="active"

    • in case of error return "Patient is not active"

Validate User

• Extract user_id from token

• Get list of APPROVED employees with this user_id in current Legal Entity

• Check that for user one of the conditions is TRUE:

  • user has an employee that specified as author of the encounter ($.encounter.performer.identifier.value is in the list of APPROVED employees)

  • OR check that user has an employee of DOCTOR or SPECIALIST type, which has an approval granted by the patient with access_level:write for this encounter resource ($.approvals.granted_resources.identifier.value==$.encounter._id AND $.approvals.granted_to.identifier.value==PRM.employees.id AND $.approvals.access_level='write')

  • OR user has an employee which has MED_ADMIN employee type

  • otherwise, return error 409  "Employee is not performer of encounter, don't has approval or required employee type"

Request validation

1. Validate digital signature 

   1. ds.drfo == PRM.parties.tax_id where (PRM.parties.id==PRM.employees.party_id)

2. Compare signed_content to previously created content

   1. select encounter, select * from observations, conditions, immunizations, allergy_intolerances where context.identifier.value=encounter_id and compare to signed_content (do not include statuses to comparation, cancellation_reason and  explanatory_letter )

      1. in case of inconsistencies return "Submitted signed content does not correspond to previously created content"

3. Validate diagnoses still valid

   1. if ($.encounter.status!="entered_in_error") validate ($.conditions[?(@.verification_status=="entered_in_error")].id is not IN $.encounter.diagnoses[*].condition.identifier.value)

      1. in case of error "The condition can not be canceled while encounter is not canceled" 

4. Validate cancellation_reason

   1. $.cancellation_reason.coding[*].system == "eHealth/cancellation_reasons"

5. Validate status_reason if present

   1. $.status_reason.code is a value from the dictionary that is referenced in $.status_reason.coding[*].system

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

6. Validate entities are not canceled yet (status!= "entered_in_error")

   1. in case of error "Invalid transition"

7. Validate at least one entity in the request marked as "entered_in_error"

   1. in case of error "At least one entity should have status "entered_in_error"

8. If there is Device Dispense in status entered_in_error in the package:

   1. Check that status of the Device Dispense in DB != “completed”

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

9. If there is Device in status entered_in_error in the package:

   1. Check that there is also related Device Association in status entered_in_error in the package:

      1. in case of error - return 409 error ('Can not mark in error Device related to active Device Association')

10. If there is Device Association in status entered_in_error in the package:

    1. Check if there is a Device in DB that references the same encounter. If there is:

       1. Check that this Device is present in the package in status entered_in_error

          1. in case of error - return 409 error ('Can not mark in error Device Association related to Device, that is not marked in error' )

Request processing

1. Save signed_content to Media Storage

2. Set status `entered_in_error` for objects, submitted with status `entered_in_error`

3. Set cancellation_reason

4. Set explanatory_letter 

5. Deactivate corresponding diagnoses in the episode in case encounter was entered_in_error

   1. Find episode where id == encouners{encounter_id}.context.identifier.value

   2. Find record in episodes{episode_id}.diagnoses_hstr.evidence.identifier.value==encounter_id

   3. Set is_active = false for this record

6. Replace current diagnoses 

   1. Set in episodes.current_diagnoses the last record from diagnoses_history where is_active==true