ЕСОЗ - публічна документація
[DRAFT] Cancel Diagnostic Report Package [API-007-003-001-0239]
Сторінка знаходиться в процесі розробки. Інформація на ній може бути застарілою.
https://e-health-ua.atlassian.net/wiki/spaces/EN/pages/17591304241 (remove the link block before publishing the document)
- 1 Properties of a REST API method document
- 2 Purpose
- 3 Logic
- 4 Configuration parameters
- 5 Dictionaries
- 6 Input parameters
- 7 Request structure
- 8 Headers
- 9 Request data validation
- 10 Authorize
- 10.1 Validate legal entity
- 10.2 Validate patient
- 10.3 Validate User
- 11 Processing
- 12 Response structure examples
- 13 HTTP status codes
- 14 Post-processing processes
- 15 Technical modules where the method is used
Properties of a REST API method document
Document type | Метод REST API |
---|---|
Document title | [DRAFT] Cancel Diagnostic Report Package [API-007-003-001-0239] |
Guideline ID | GUI-0011 |
Author | @ |
Document version | 1 |
Document status | DRAFT |
Date of creation | ХХ.ХХ.ХХХХ (дата фінальної версії документа – RC або PROD) |
Date of update | ХХ.ХХ.ХХХХ (дата зміни версії) |
Method API ID | API-007-003-001-0239 |
Microservices (namespace) | ME |
Component | Diagnostic Report Data Package |
Component ID | COM-007-003 |
Link на API-специфікацію | |
Resource | {{host}}/api/patients/{{id}}/diagnostic_report_package |
Scope | diagnostic_report:cancel |
Protocol type | REST |
Request type | PATCH |
Sync/Async | Async |
Public/Private | Public |
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
N/A
Dictionaries
N/A
Input parameters
Input parameter | Mandatory | Type | Description | Example | |
---|---|---|---|---|---|
1 |
|
|
|
|
|
2 |
|
|
|
|
|
Request structure
See on API-specification
Headers
Request data validation
Authorize
Request to process the request using a token in the headers
Verify the validity of access token
Return 401 in case validation fails
Verify token is not expired
in case error return 401
Check user scopes in order to perform this action (scope = 'diagnostic_report:cancel')
Return 403 in case invalid scope(s)
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
HTTP status codes
Response code | HTTP Status code | Message | Internal name | Description | |
---|---|---|---|---|---|
1 | Базові | ||||
2 |
| 202 |
|
|
|
3 |
| 403 | Access denied. Party is not verified |
|
|
4 |
| 403 | Invalid scopes |
|
|
5 |
| 403 | User is not allowed to perform actions with an enity that belongs to another legal entity |
|
|
6 |
| 404 | Patient not found |
|
|
7 |
| 409 |
| Validation failed |
|
8 |
| 409 | Employee is not performer of diagnostic report, don't has approval or required employee type |
|
|
9 | Специфічні | ||||
10 |
|
|
|
|
|
Post-processing processes
N/A
Technical modules where the method is used
ЕСОЗ - публічна документація