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

RC_[UPD] Cancel Encounter Data Package WS

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.

Note : You have only one attempt to cancel each package via API. In case you signed and cancelled package partly and now you need to cancel more entities from this package - appeal to eHealth administrator.

 

Note: Current diagnoses on the episode will be replaced automatically with the last accurate diagnoses in case encounter was cancelled.

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 all related Device Associations within current Encounter and related to current Device are in the package and has entered_in_error status:

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

      within the same Encounter')

    2. Check that there all related Detected Issues within current Encounter and related to current Device are in the package and has entered_in_error status:

      • in case of error - return 409 error ('Can not mark in error Device related to active Detected Issues

      within the same Encounter')

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

  11. If there is Detected Issue in status entered_in_error in the package:

    1. Check if there is a Device ($.subject) 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 Detected Issue 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

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