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 method is used to create an episode of care.
Logic
This method is used to create an episode of care.
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 Apiary
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{{access_token}} | ||
3 | API-key | {{secret}} | API-key:{{secret}} |
Request data validation
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
Validate patient status
Medical_data status for this patient must be in "active" status
in case of error return 409 - "Patient is not active"
Validate episode id is unique
$.id is unique
in case of error return 422 - "Episode with such id already exists"
Validate that episode number is unique$.number is uniquein case of error return 409 - "Episode with such number already exists. Episode number must be unique"
Validate request according to JSON Schema LINK
in case of error return 422
Validate type
according to legal entity type: Medical Events Dictionaries and configurations#legal_entity_episode_types
in case of error return 409 "Episode type <type> is forbidden for your legal entity type"
according to employee type: Medical Events Dictionaries and configurations#employee_episode_types
in case of error return 409 "Episode type <type> is forbidden for your employee type"
Validate status= "active"- resolved by JSON schemaValidate managing_organization
Only one item is allowed in coding array
in case of error return 422 "Only one item is allowed in "coding" array "
$.managing_organization.identifier.type.coding.[0].code = "legal_entity"
in case of error return 422 "Only legal_entity could be submitted as a managing_organization"
$.managing_organization.identifier.value = token.client_id
in case of error return 422 "Managing_organization does not correspond to user`s legal_entity"
$.managing_organization.identifier.type.coding.[0].system = "eHealth/resources"
in case of error return 422 "Submitted system is not allowed for this field"
Validate period
$.period.start <= current_date
in case of error return 422 - "Start date of episode must be in past"
$.period.end is absent
in case of error return 422 - "End date of episode could not be submitted on creation"
Validate care_manager
$.care_manager.identifier.type.coding.[0].code = "employee"
in case of error return 422 "Only employee could be submitted as a care_manager"
$.care_manager.identifier.type.coding.[0].system = "eHealth/resources"
in case of error return 422 "Submitted system is not allowed for this field"
PRM.employee.type = value from list of employee_types in configuration:
ALLOWED_EPISODE_CARE_MANAGER_EMPLOYEE_TYPESin case of error return 409 "Employee submitted as a care_manager is not in the list of allowed employee types"
PRM.employee.status= "active"
in case of error return 409 "Employee submitted as a care_manager is not active"
PRM.employee.legal_entity = token.client_id
in case of error return 409 "User can create an episode only for the doctor that works for the same legal_entity"
$.care_manager.identifier.value belongs to one of the user’s employee
in case of error return 422 "Employee is not care manager of episode"
Error example:
|
Processing
Set episodes.care_manager.display_value = ((PRM.parties.first_name + PRM.parties.second_name + PRM.parties.last_name) where PRM.parties.id == PRM.employees.party_id) where PRM.employees.id== $.care_manager.identifier.value
Set episodes.managing_organization.display_value = PRM.legal_entities.public_name where ( PRM.legal_entities.id == $.managing_organization.identifier.value)
Create a record in status_hstr
Response structure examples
See on Apiary
See on API-specification (посилання на сторінку з API-специфікацією)
Description of the REST API response structure, example
Expand | ||
---|---|---|
| ||
|
Expand | ||
---|---|---|
| ||
|
HTTP status codes
Response code | HTTP Status code | Message | Internal name | Description | |||||
---|---|---|---|---|---|---|---|---|---|
1 | Базові | ||||||||
2 | 202 | Response |
| ||||||
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 | Patient not found |
| ||||||
10 | 409 | Episode type <type> is forbidden for your legal entity type | |||||||
11 | 409 | Employee submitted as a care_manager is not in the list of allowed employee types | |||||||
12 | 409 | Employee submitted as a care_manager is not active | |||||||
13 | 409 | Patient is not active | |||||||
14 | 409 |
| Validation failed | ||||||
15 | 409 | User can create an episode only for the doctor that works for the same legal_entity | |||||||
16 | 422 | Episode with such id already exists | |||||||
17 | 422 | Employee is not care manager of episode | |||||||
18 | 422 | End date of episode could not be submitted on creation | |||||||
19 | 422 | Managing_organization does not correspond to user`s legal_entity | |||||||
20 | 422 | Only one item is allowed in "coding" array | |||||||
21 | 422 | Only legal_entity could be submitted as a managing_organization | |||||||
22 | 422 | Only employee could be submitted as a care_manager | |||||||
23 | 422 |
| Validation failed | ||||||
24 | 422 | Submitted system is not allowed for this field | |||||||
25 | 422 | Submitted system is not allowed for this field | |||||||
26 | 422 | Start date of episode must be in past | |||||||
27 | Специфічні | ||||||||
28 | 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 | ||||
---|---|---|---|---|
|
...