ЕСОЗ - публічна документація
[DRAFT] Qualify Service request by ID [API-007-010-001-0316]
Сторінка знаходиться в процесі розробки. Інформація на ній може бути застарілою.
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
- 9.1 Authorize
- 9.2 Validate request
- 10 Response structure examples
- 11 HTTP status codes
- 12 Post-processing processes
- 13 Technical modules where the method is used
Properties of a REST API method document
Document type | Метод REST API |
---|---|
Document title | [DRAFT] Qualify Service request by ID [API-007-010-001-0316] |
Guideline ID | GUI-0011 |
Author | @ |
Document version | 1 |
Document status | DRAFT |
Date of creation | ХХ.ХХ.ХХХХ (дата фінальної версії документа – RC або PROD) |
Date of update | ХХ.ХХ.ХХХХ (дата зміни версії) |
Method API ID | PI-007-010-001-0316 |
Microservices (namespace) | ME |
Component | Service request |
Component ID | COM-007-010 |
Link на API-специфікацію | https://medicaleventsmisapi.docs.apiary.io/#reference/service-requests/manage-service-requests |
Resource | {{host}}/api/service_requests/{{service_request_id}}/actions/qualify |
Scope | service_request:use |
Protocol type | REST |
Request type | POST |
Sync/Async | Sync |
Public/Private | Public |
Purpose
This method checks the possibility of using the direction according to the program.
Logic
https://e-health-ua.atlassian.net/wiki/x/CwPGIg
Configuration parameters
N/A
Dictionaries
N/A
Input parameters
Input parameter | Mandatory | Type | Description | Example | |
---|---|---|---|---|---|
1 | service_request_id |
| String | Unique service request identifier |
|
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, 'unauthorized') in case of validation fails
Verify that token is not expired
in case of error - return (401, 'unauthorized')
Check user scopes in order to perform this action (scope = 'service_request:write')
Return (403, 'invalid scopes') in case of invalid scope(s)Processing
Validate request using JSON Schema
Return 422 with the list of validation errors in case validation fails
Validate request
legal entity(client_id)
Check legal_entity.type in me_allowed_transactions_le_types config parameter and legal_entity.status = ACTIVE
in case of error return 409 "Action is not allowed for the legal entity"
service request
validate SR.program_processing_status in (new,In Queue,In Progress)
in case error return 409, “service request has wrong status“
validate SR.status = Active
in case error return 409, “service request has wrong status“
If SR.based_on is present:
Verify submitted Activity:
It has scheduled, in_progress status
in case of error return 409, "Invalid activity status")
if quantity was set, then validate remaining_quantity greater then zero:
in case of error return 409, "The number of available services according to the care plan activity has been exhausted"
Verify Care plan:
It should be in active status
in case of error return 409, "Care plan is not active"
Care plan's period end (if exist) should be greater than current date or equal.
in case of error return 409, “Care plan expired“
Validate remaining quantity of services is still available:
If SR has quantity:
Validate remaining_quantity within SR is greater then zero
in case of error return 409 (The number of available services according to the service request has been exhausted)
If SR has no quantity, but it is based on activity with quantity:
Validate remaining_quantity within Activity is greater then zero
in case of error return 409 (The number of available services according to the care plan activity has been exhausted)
program
For each program validate it is an existing service program with type=service
in case not found or is_active==false write result in Data collection according to apiary
in case type!= service write result in Data collection according to apiary - "Invalid program type"
For each program validate that service(or service_group) is an active member of the program
Select is_active from PRM.program_services where service_id(or group_id) == $.signed_content.code.identifier.value and program_id=$.program.identifier.value
if not found or is_active==false write result in Data collection according to apiary - "Service is not included in the program"
Response structure examples
See on API-specification
Prepare & return response data structure
For each program in array prepare response
If it is any or some errors from validations return “NOT VALID“ with error msg
HTTP status codes
Response code | HTTP Status code | Message | Internal name | Description | |
---|---|---|---|---|---|
1 | Базові | ||||
2 |
| 401 | invalid scopes |
|
|
3 |
| 401 | Unauthorized |
| Помилка підтвердження |
4 |
| 409 | Action is not allowed for the legal entit |
|
|
5 |
| 409 | Care plan is not active |
|
|
6 |
| 409 | Care plan expired |
|
|
7 |
| 409 | Invalid activity status |
|
|
8 |
| 409 | service request has wrong statu |
|
|
9 |
| 409 | The number of available services according to the service request has been exhausted |
|
|
10 | Специфічні | ||||
11 |
| 422 | Only for active MPI record can be created medication request! |
|
|
Post-processing processes
N/A
Technical modules where the method is used
List of pages describing technical modules where the method is used
ЕСОЗ - публічна документація