REST API method / Метод REST API (настанова) (remove the link block before publishing the document)
Properties of a REST API method document
Purpose
This method is designed to create reimbursement report which is based on Medication request and Medication dispense data.
Logic
The access and ability to create and get the report have
MSP (OWNER)
PHARMACY (PHARMACY_OWNER)
To get the report the creator must input requested period (date_from_request, date_to_request, date_from_dispense, date_to based on date of dispense or request). In response will be received the json with data.
OWNER will receive info only about Medication Requests which were made by his legal_entity and corresponding Medication Dispenses.
PHARMACY_OWNER is allowed to view only info related to Medication Dispenses which were made by his PHARMACY and corresponding Medication Requests.
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 c2778f3064753ea70de870a53795f5c9 | M | Перевірка користувача | Authorization:Bearer c2778f3064753ea70de870a53795f5c9 |
3 |
Request data validation
Get legal entity from token
Extract legal_entity_id (client_id) from token
Get Party from token
Extract party_user (user_id) from token.
Validate FK
Validate
legal_entity_id - legal_entity_id exists (for MSP and PHARMACY)
In case error - return 422 error:
{:error, [{%{ description: "Legal entity not found", params: [], rule: :invalid }, "$.legal_entity_id"}]}
Validate
party_id - party_id exists
{:error, [{%{ description: "Party not found", params: [], rule: :invalid }, "$.party_id"}]}
Validate
legal_enity type - type [MSP, PHARMACY]
In case of error - show 403 error ('Legal_entity type is not allowed to get the report')
Validate statuses
Legal entity should be active in order to create report
is_active = true
status = 'ACTIVE'
in case of error show 403 error ('Legal entity is not active')
Party should refer to active employee in current legal_entity
employees.is_active = true
employees.status = 'APPROVED'
employees.legal_entity_id = client_id (context)
in case of error show 403 error ('Employee is not active')
Validate input dates
There is 4 available dates for the filtering: by dispense or/and by request. At least one pair of those dates must be not empty.
In case of error show 422 error with message must be shown (date_from_request: "At least one of input dates must be not empty")
Validate input date_from and date_to
if date_from_request is not null then: date_from_request<=date_to_request and date_to_request must be filled
in case of error - return 422 error:
{:error, [{%{ description: "Input dates are not valid", params: [], rule: :invalid }, "$.date_from_request"}]}
if date_from_dispense is not null then: date_from_dispense<=date_to_dispense and date_to_dispense must be filled
in case of error - return 422 error:
{:error, [{%{ description: "Input dates are not valid", params: [], rule: :invalid }, "$.date_from_dispense"}]}
Input dates filter the field:
date_from_request/date_to_request comparing to field medication_requests.created_at
date_from_dispense/date_to_dispense comparing to field medication_dispenses.dispensed_at
If there is no data available for the requested period of time in response must be sent empty json, no error is shown.
Processing
A list of processes related to receiving, changing or transmitting data according to the logic defined in the REST API
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 | 1000 | 200 | Response |
| 200 |
3 | 401 |
| Access token validation failed | 401 | |
4 | 403 |
|
| 403 | |
5 | 422 |
| Validation failed | 422 | |
6 | Специфічні | ||||
7 | 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