| Note |
|---|
Сторінка знаходиться в процесі розробки. Інформація на ній може бути застарілою. |
| Info |
|---|
/wiki/spaces/EN/pages/17591304241 (remove the link block before publishing the document) |
| Table of Contents |
|---|
Properties of a REST API method document
...
| id | page_properties_method_REST API |
|---|
...
Document type
...
Метод REST API
...
Document title
...
[Document status] REST API [Назва методу] [ID методу]
...
Guideline ID
...
GUI-0011
...
Author
...
@
...
Document version
...
1
...
Document status
...
DRAFT
...
Date of creation
...
ХХ.ХХ.ХХХХ (дата фінальної версії документа – RC або PROD)
...
Date of update
...
ХХ.ХХ.ХХХХ (дата зміни версії)
...
Method API ID
...
API-005-008-002-0155
...
Microservices (namespace)
...
IL
...
Component
...
ePrescription
...
Component ID
...
COM-005-008
...
Link на API-специфікацію
...
...
Resource
...
{{host}}/api/medication_requests/{{id}}
...
Scope
...
medication_request:details
...
Protocol type
...
REST
...
Request type
...
GET
...
Sync/Async
...
Sync
...
Public/Private
...
Public
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)
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
...
composition_id
...
M
...
String ($uuid) (path)
...
Composition object ID
...
89678f60-4cdc-4fe3-ae83-e8b3ebd35c59
...
Request structure
See on API-specification (посилання на сторінку з API-специфікацією)
Description of the REST API request structure, example
...
| title | Example |
|---|
...
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
See on API-specification (посилання на сторінку з API-специфікацією)
Description of the REST API response structure, example
| Expand | ||
|---|---|---|
| ||
| Note | ||
Сторінка знаходиться в процесі розробки. Інформація на ній може бути застарілою. |
| Info |
|---|
/wiki/spaces/EN/pages/17591304241 (remove the link block before publishing the document) |
| Table of Contents |
|---|
Properties of a REST API method document
| Page Properties | ||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||
|
Purpose
This WS is designed to return Medication request detail.
Search Medication Request possible in 2 options: by `medication_request.id` OR `medication_request.request_number`.
According to requirements:
A user of MSP, PRIMARY_CARE, OUTPATIENT (DOCTOR, SPECIALIST, etc) can see all Medication request from the user's legal entity.
A user of MSP, PRIMARY_CARE (DOCTOR, etc) can see all the Medication requests of the patients whom he has an active declaration with by yourself a doctor (employee_id).
Users of PHARMACY can see all Medication requests (without limitations).
Users of MSP, PRIMARY_CARE, OUTPATIENT (DOCTOR, SPECIALIST, etc) can see all Medication requests based on the approval of the care plan that is contained in the Medication request.
Logic
Verify the validity of access token
Return 401 in case validation fails
Check user scopes in order to perform this action (scope = 'medication_request:details')
Return 403 in case invalid scope(s)
Get `client_type` from `mithril.clients`
Get `my_party_id` from `$.context.user_id`
Get list from `prm.employees` for this `party_id` & `$.context.legal_entity_id`
Search Medication requests by filters:
Code Block SELECT * FROM medication_request MR INNER JOIN employees E ON E.party_id = my_party_id AND (E.id = $.employee_id OR $.employee_id IS NULL) AND (E.legal_entity_id == $.context.legal_entity_id OR $.context.legal_entity_id IS NULL) LEFT JOIN declarations D ON D.Employee_id = E.id AND E.status = ACTIVE AND D.status = ACTIVE AND MR.person_id = D.person_id WHERE (MR.id = $.id OR MR.request_number = $.id) AND MR.employee_id == E.id AND MR.is_active = TRUE
Logic WS for medication requests based on care plan
Get party_id from $.context.user_id
Get list from $.prm.employees for this party_id
Get care_plan_id from $.medication_requests.based_on_care_plan_id
Check $.approvals for user's employees (granted_to) on care_plan_id (granted_resources) and $.medication_requests.person_id (granted_by)
Search Medication requests by filters: based_on_care_plan_id, person_id.
Code Block SELECT * FROM medication_request MR WHERE (MR.id = $.id OR MR.request_number = $.id) AND MR.based_on_care_plan_id = $.id AND MR.person_id = $.id AND MR.is_active = TRUE
Logic WS for `client_type` = PHARMACY
Search Medication request by $.id:
Code Block SELECT * FROM medication_request MR WHERE (MR.id = $.id OR MR.request_number = $.id) AND MR.is_active = TRUE
Configuration parameters
N/A
Dictionaries
N/A
Input parameters
Input parameter | Mandatory | Type | Description | Example | |
|---|---|---|---|---|---|
| 1 | id |
| String | Medication Request identifier OR request_number. Required. | 48416485-cc98-46c4-8bba-e321de9e1ecd |
| 2 |
Request structure
See on API-specification
| Expand | ||
|---|---|---|
| ||
|
Request data validation
Search Medication Request
Search record by `$.id` in column `medication_request.id`
If not found - Search record by `$.id` in column `medication_request.request_number`
If not found - Return 404 in case "Not found"
Validate FK
Read data from `ops.medication_requests` by `id`
Validate legal_entity_id - legal_entity_id exists
Return 422 in case validation fails (422 EView)
Validate employee_id - employee_id exists
Return 422 in case validation fails (422 EView)
Validate division_id - division_id exists
Return 422 in case validation fails (422 EView)
Validate medical_program_id - medical_program_id exists
Return 422 in case validation fails (422 EView)
Validate all medication_id - medication_id exists
Return 422 in case validation fails (422 EView)
Validate person_id - mpi_id exists
Return 422 in case validation fails (422 EView)
Processing
N/A
Response structure examples
Return object with response structure from WS Sign Medication request Request.
Calculate medication remaining quantity:
Select all Medication Dispenses in status PROCESSED related to the Medication Request
Sum medication_qty in the filtered Medication Dispenses as dispensed_qty
Calculate medication_remaining_qty = medication_qty - dispensed_qty
Return medication_remaining_qty in the response
See on API-specification
| Expand | |||||
|---|---|---|---|---|---|
| |||||
|
HTTP status codes
Response code | HTTP Status code | Message | Internal name | Description | |
|---|---|---|---|---|---|
| 1 | Базові | ||||
| 2 | |||||
1000
404
Composition not found
COMPOSITION_NOT_FOUND_404
200 | Response |
| ||
| 3 | 401 |
Unauthorized
Invalid access token |
| ||
| 4 | 403 | Invalid scope |
| ||
| 5 | 422 |
Validation fails |
| ||||
| 6 | Специфічні | ||||
| 7 | |||||
Post-processing processes
Description of actions performed on data after processing
Technical modules where the method is used
List of pages describing technical N/A
Technical modules where the method is used
| Page Properties Report | ||||
|---|---|---|---|---|
|
...