Versions Compared

Key

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

Required parameters are marked with "*"

...

Purpose*

API paragraph not found

Specification*

...

Project Name

...

COVID-certificate

...

Project abreviation

...

SVC

...

Developer

...

Розробник методу API. Наприклад, Edenlab

...

Project Manager

...

@Єлизавета Гессен-Дармштадська

...

Tech Lead

...

@Іоанн Воїнов

...

Product Owner

...

@Нікодім Святогорцев

...

Вusiness analyst

...

@Пантелеймон Нікомедійський

...

Status

Status
colourGreen
titleAPPROVED

...

Version

...

1.0

...

Date of release

...

Purpose

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

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

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

Specification

Page Properties

Link

https://ehealthmedicaleventsapimedicaleventsmisapi.docs.apiary.io/#reference/medical-events/encounter-data-package/cancel-encounter-package

Resource

/api/patients/{{id}}/encounter_package

Scope

encounter:write

Components

Зазначається перелік бізнес компонентів, які використовують цей метод, наприклад: ePrescriptionEpisode of Care

Microservices

Перелік мікросервісів, які використовує метод API. Наприклад: Auth, ABACAPI paragraph not found

Protocol type

Тип протоколу, який використовується запитом, наприклад: SOAP | REST

Request type

PATCH

Sync/Async

Async

Метод є синхронним чи асинхронним?

Public/Private/Internal

Public

Logic

...

This web service allows to cancel encounter and other components of Data Package they were entered in case in error.

Request structure

...

See on Apiary

Example:

Expand
titleRequest example
Code Block
{
  "signed_data": "ew0KICAicGVyaW9kIjogew0KIC..."
}

Authorize

...

Request to process the request using a token in the headers

  • Verify the validity of access token

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

  • Verify token is not expired

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

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

    • Return 403 in case invalid scope(s)

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

Headers

Наприклад:

  • Content-Type:application/json

  • Authorization:Bearer mF_9.B5f-4.1JqM

Validate request*

API paragraph not found

Request data validation*

API paragraph not found

Processing*

API paragraph not found

...

  • {{access_token}}

  • API-key:{{secret}}

Request data validation

  1. Validate digital signature

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

      1. PRM.employees.id==$.encounter.performer.identifier.value)

      2. OR PRM.employees.id==$.approval.granted_to.identifier.value ($.approvals.granted_resources.identifier.value==$.encounter_id AND $.approvals.access_level='write')

      3. OR PRM.employees.employee_type==MED_ADMIN

  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. Validate user performs action with an episode that belong to his legal entity

    1. ME.patient{patinet_id}.episodes{episode_id}.managing_organization==token.client_id

      1. in case of error return 422 "Managing_organization in the episode does not correspond to user`s legal_entity"

  9. If entity is device_dispense:

    1. Check that status != “entered_in_error” and status != “completed”

      1. in case of error - return 409 error ('Device dispense in status <status> cannot be marked in error')

  10. Validate reasons (eHealth/ICPC2/reasons dictionary)

    1. is case is_active = false return error 422 “value is not allowed in enum

Validate legal entity

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

    • ME.episode.managing_organization==token.client_id

      • in case of error return 409 "User is not allowed to perform actions with an episode that belongs to another 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 .recorded_by.identifier.value is in the list of APPROVED employees)

    • OR check that user has an employee which has 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 has MED_ADMIN employee type

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

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

Response structure

See on Apiary

Example:

Expand
titleResponse example
Code Block
{
  "data": {
    "status": "pending",
    "eta": "2018-08-02T10:45:16.000Z",
    "links": [
      {
        "entity": "job",
        "href": "/Jobs/NBXk9EyErUZv1RhXgyvgg"
      }
    ]
  },
  "meta": {
    "code": 202,
    "url": "http://example.com/resource",
    "type": "object",
    "request_id": "req-adasdoijasdojsda"
  }
}

Expand
titleResponse example
Code Block
{
  "meta": {
    "code": 404,
    "url": "http://example.com/resource",
    "type": "object",
    "request_id": "req-adasdoijasdojsda"
  },
  "error": {
    "type": "NOT_FOUND",
    "message": "Patient not found"
  }
}

Post-processing processes

...

API paragraph not found

HTTP status codes

...

HTTP status code

Message

What caused the error

 202

 

 

 404

401

 

Access token validation failed

403

 

Invalid scope

404

 not found