Info |
---|
REST API method / Метод REST API (настанова) (remove the link block before publishing the document) |
...
Page Properties | ||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||
|
Purpose
Describe the purpose of the API method, add Key points (if necessary)
Logic
Description of the working algorithm of the API method and the interaction of services with each other add Service logic (if necessary)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. |
Logic
This web service allows to cancel encounter and other components of Data Package they were entered in case in error.
Configuration parameters
Description of the configuration parameters that are used when processing a request in the system
Dictionaries
Provides a list of links to dictionaries that are available in Confluence
Input parameters
Description of input parameters
Input parameter | Mandatory | Type | Description | Example | |
---|---|---|---|---|---|
1 | composition_id | M | String ($uuid) (path) | Composition object ID | 89678f60-4cdc-4fe3-ae83-e8b3ebd35c59 |
2 |
Request structure
See on API-specification (посилання на сторінку з API-специфікацією)
Description of the REST API request structure, example
Expand | ||
---|---|---|
| ||
|
Headers
Key | Value | Mandatory | Description | Example | |||||
---|---|---|---|---|---|---|---|---|---|
1 | Content-Type | application/json | M | Тип контенту | Content-Type:application/json | ||||
2 | Authorization | Bearer c2778f3064753ea70de870a53795f5c9 | M | Перевірка користувача | {{access_token}} | Authorization:Bearer c2778f3064753ea70de870a53795f5c9 | 3 |
Request data validation
Describe the process of checking the input data transmitted in the request for compliance with the given rules and restrictions set in the API
Processing
A list of processes related to receiving, changing or transmitting data according to the logic defined in the REST API
Response structure examples
Description of the REST API response structure, example
...
title | Example |
---|
...
{{access_token}} | |||||
3 | API-key | {{secret}} | API-key:{{secret}} |
Request data validation
Validate digital signature
ds.drfo == PRM.parties.tax_id where PRM.parties.id==PRM.employees.party_id where:
PRM.employees.id==$.encounter.performer.identifier.value)
OR PRM.employees.id==$.approval.granted_to.identifier.value ($.approvals.granted_resources.identifier.value==$.encounter_id AND $.approvals.access_level='write')
OR PRM.employees.employee_type==MED_ADMIN
Compare signed_content to previously created content
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 )
in case of inconsistencies return "Submitted signed content does not correspond to previously created content"
Validate diagnoses still valid
if ($.encounter.status!="entered_in_error") validate ($.conditions[?(@.verification_status=="entered_in_error")].id is not IN $.encounter.diagnoses[*].condition.identifier.value)
in case of error "The condition can not be canceled while encounter is not canceled"
Validate cancellation_reason
$.cancellation_reason.coding[*].system == "eHealth/cancellation_reasons"
Validate entities are not canceled yet (status!= "entered_in_error")
in case of error "Invalid transition"
Validate at least one entity in the request marked as "entered_in_error"
in case of error "At least one entity should have status "entered_in_error""
Validate user performs action with an episode that belong to his legal entity
ME.patient{patinet_id}.episodes{episode_id}.managing_organization==token.client_id
in case of error return 422 "Managing_organization in the episode does not correspond to user`s legal_entity"
Validate reasons (
eHealth/ICPC2/reasons
dictionary)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
Save signed_content to Media Storage
Set status `entered_in_error` for objects, submitted with status `entered_in_error`
Set cancellation_reason
Set explanatory_letter
Deactivate corresponding diagnoses in the episode in case encounter was entered_in_error
Find episode where id == encouners{encounter_id}.context.identifier.value
Find record in episodes{episode_id}.diagnoses_hstr.evidence.identifier.value==encounter_id
Set is_active = false for this record
Replace current diagnoses
Set in episodes.current_diagnoses the last record from diagnoses_history where is_active==true
Response structure examples
See on API-specification (посилання на сторінку з API-специфікацією)
See on Apiary
Expand | ||
---|---|---|
| ||
|
Expand | ||
---|---|---|
|
HTTP status codes
Response code | HTTP Status code | Message | Internal name | Description | |||||
---|---|---|---|---|---|---|---|---|---|
1 | Базові | ||||||||
2 | 202 |
|
| ||||||
3 | 401 |
| Access token validation failed | ||||||
4 | 401 | Invalid access token | |||||||
5 | 401 | Unauthorized | Помилка підтвердження | ||||||
6 | 403 | Access denied. Party is not verified | |||||||
7 | 403 |
| Invalid scope | ||||||
8 | 1000 | 404 | Composition not found | COMPOSITION_NOT_FOUND_404 | Не знайдено медичний висновок | 3 | 401 | Unauthorized | Помилка підтвердження |
4 | Специфічні | ||||||||
9 | 404 | not found |
| ||||||
10 | 409 | Employee is not performer of encounter, don't has approval or required employee type | |||||||
11 | 422 | Managing_organization in the episode does not correspond to user`s legal_entity | |||||||
12 | 422 | User is not allowed to perform actions with an episode that belongs to another legal entity | |||||||
13 | 422 |
| |||||||
14 | Специфічні | ||||||||
15 | 422 | Only for active MPI record can be created medication request! |
Post-processing processes
Description of actions performed on data after processing
Technical modules where the method is used
List of pages describing technical modules where the method is used
Page Properties Report | ||||
---|---|---|---|---|
|
...