REST API method / Метод REST API (настанова) (remove the link block before publishing the document)
Properties of a REST API method document
Purpose
This web service allows to cancel diagnostic report and observations, crated as a part of Diagnostic Report Data Package, 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.
Logic
Відкликання діагностичного звіту
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
Headers
Key | Value | Mandatory | Description | Example | |
---|---|---|---|---|---|
1 | Content-Type | application/json | M | Тип контенту | Content-Type:application/json |
2 | Authorization | Bearer {{access_token}} | Authorization:Bearer {{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==$.diagnostic_report.reported_by.identifier.value))
Compare signed_content to previously created content
select encounter, select * from observations where diagnostic_report.identifier.value=$.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 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 legal entity
Validate diagnostic_report belongs to the legal entity where the current user works
$.diagnostic_report.managing_organization==token.client_id
in case of error return 403 "User is not allowed to perform actions with an enity 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 diagnostic report ($.diagnostic_report.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 diagnostic_report resource ($.approvals.granted_resources.identifier.value==$.diagnostic_report._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 diagnostic report, don't has approval or required employee type"
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")
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
Response structure examples
See on API-specification (посилання на сторінку з API-специфікацією)
Description of the REST API response structure, example
HTTP status codes
Response code | HTTP Status code | Message | Internal name | Description | |
---|---|---|---|---|---|
1 | Базові | ||||
2 | 202 |
|
| ||
3 | 401 | Unauthorized | Помилка підтвердження | ||
4 | 403 | Access denied. Party is not verified | |||
5 | 403 | Invalid scopes |
| ||
6 | 403 | User is not allowed to perform actions with an enity that belongs to another legal entity | |||
7 | 1000 | 404 | Composition not found | COMPOSITION_NOT_FOUND_404 | Не знайдено медичний висновок |
8 | 404 | Patient not found |
| ||
9 | 409 |
| Validation failed | ||
10 | 409 | Employee is not performer of diagnostic report, don't has approval or required employee type | |||
11 | Специфічні | ||||
12 | 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