ЕСОЗ - публічна документація
RC__Qualify Device Request by ID
- 1 Purpose
- 2 Key points
- 3 Specification
- 4 Specification
- 5 Input parameters
- 6 Request structure
- 7 Authorization
- 8 Validate Device request
- 9 Check for existing Device dispenses
- 10 Validate request
- 10.1 Validate location
- 10.2 Validate Medical programs
- 10.2.1 Validate program
- 10.2.2 Validate medical program provision
- 10.2.3 Validate Device Definitions
- 11 Service logic
- 12 Response structure
- 13 HTTP status codes
Purpose
This WS is designed to qualify Device Request: check the ability of dispense Device Request within the Medical program. This method is used to qualify (possibility to use device definition for the program) Device request by Id . Fields descriptions are listed in request Example view.
Key points
Only authenticated and authorized users with appropriate scope can invoke Qualify Device Request
This method returns for existing Device Request the result of data validation within each submitted medical program, but not creates any entities in the system.
Each Medical program may have its unique conditions for the Device Dispense. They can be based on analysis of personal info, device definition list, terms, locations and combinations of them.
Any Medical program can have separate block of branching logic configured at medical program settings by NHS administrator.
Сompatibility is checked only for programs which are available in payload (array).
Successful invocation of the method returns decision for each program if it is valid or not to create Device dispense with submitted combination of parameters in the payload. If program is invalid, the reason must be returned in the response.
Allowed for existing and active Device Requests
Also medical program provision is checked for the division of the pharmacy.
Specification
Specification
Link | Посилання на Apiary або Swagger | |
Resource | /api/device_requests/{{device_request_id}}/actions/qualify | Посилання на ресурс, наприклад: /api/persons/create |
Scope | device_request:read | Scope для доступу |
Components | Devices | Зазначається перелік бізнес компонентів, які використовують цей метод, наприклад: ePrescription |
Microservices |
| Перелік мікросервісів, які використовує метод API, наприклад: Auth, ABAC |
Protocol type | REST | Тип протоколу, який використовується запитом, наприклад: SOAP | REST |
Request type | POST | Тип запиту API, наприклад: GET, POST, PATCH… |
Sync/Async | Sync | Метод є синхронним чи асинхронним? |
Public/Private/Internal | Public | Потрібно зазначити тип методу за ступенем доступності |
Input parameters
Input parameter | Values | Type | Description | Example |
---|---|---|---|---|
device_request_id |
| String |
|
|
Request structure
See on Apiary
Authorization
Verify the validity of access token
in case of error - return 401 (“Invalid access token”) in case of validation fails
Verify that token is not expired
in case of error - return 401 (“Invalid access token”)
Check user and client scopes in order to perform this action (scope = 'device_request:read')
return 403 (“Your scope does not allow to access this resource. Missing allowances: device_request:read”) in case of invalid scope(s)
Validate Device request
Get Device request identifier from URL and check:
it exists in DB and has ACTIVE status
in case of error - return 404 ('Device request not found')
has a program
in case of error - return 409 ('Device request without a program cannot be qualified')
has dispense_valid_to that is greater or equal to current date
in case of error - return 409 ('Device request is expired for dispense')
Check for existing Device dispenses
Check that there is no other
IN_PROGRESS
device dispenses based on the same device requestFind all device dispenses related to the same device request ($.based_on)
Check that there are no records in status
IN_PROGRESS
whereinserted_at
+ configdevice_dispense_ttl
>= current date-time()in case of error - return 409 "Other active device dispense already exist."
Validate request
Validate request using schema. Return 422 with the list of validation errors in case validation fails. In addition, check following:
Validate location
Validate value in the field $.location, Reference on division resource, required.
Check that division exists
in case of error - return 409 ("Division not found")
Check that division is active
in case of error - return 409 ("Division is not active")
Validate division belongs to user's legal entity (client_id from token)
in case of error - return 409 ("Division does not belong to user's legal entity")
If chart parameter DEVICE_DISPENSE_DIVISION_DLS_VERIFY is on, then validate division is DLS verified (dls_verified=true)
in case of error - return 409 "Division is not verified in DLS"
Validate Medical programs
If all checks below in the text passed for the program - save the response for this program with status = VALID; if not passed - save response with status = INVALID and corresponding reject_reason. Response for such validations should be returned with code 200.
Validate each medical program in the $.programs array:
Validate program
Check the program exists, is of type DEVICE, and is active
in case of error - return reject_reason = “Medical program not found”
Check dispense_allowed = true for the program
in case of error - return reject_reason = “It is not allowed to create Device dispenses for the program”
Validate medical program provision
Check $.division participates in submitted program. Validate Provision for the medical program:
Medical program in the request has funding_source = NHS
In case of error - return reject_reason = "Program was configured incorrectly - incorrect source of funding"
Provision exist and active, relates to the $.location and to the actual reimbursement contract: contract.start_date <= current_date <= contract.end_date, is_active = true, status = VERIFIED, contracts.type==reimbursement, contracts.contractor_legal_entity_id=token.client_id, contracts.medical_program_id==$.medical_program_id
in case of error - return reject_reason = "Medical program provision is not related to any actual contract for the current date"
Сontract is_suspended = false
in case of error - return reject_reason="Contract with number <contract_number> is suspended"
Validate Device Definitions
Check there is at least one appropriate Device Definition for a program:
Find program_devices related to the program, that:
is active
has validity period (start_date and end_date) within current date
in case not found - return reject_reason = “No appropriate participants found for this medical program“
For found program_devices check there at least one appropriate Device Definition, that:
is active
has the same code as in the Device Request
has packaging_unit that matches to quantity.code of the Device Request
in case of error - return reject_reason = “Not found any active Device Definition with the same units of measure as pointed in the quantity of the Device Request”
has a remainder of the division ($.device_request.quantity.value/device_definition.packaging_count) that is equal to 0
in case of error - return reject_reason = “The quantity in the Device Request must be divisible to packaging_count of at least one related Device Definition”
Service logic
Generate structure for response
If general error found at Validate division section, that doesn’t depend on medical program, then return corresponding error code with error message
If general validation passed, then collect array for all programs in payload with status for each (VALID or INVALID) and rejection_reason
For each program return a list of appropriate program participants found at Validate Device Definitions step
Generate response according to specification
Response structure
See on Apiary
HTTP status codes
HTTP status code | Message | What caused the error |
---|---|---|
200 |
|
|
422 |
|
|
ЕСОЗ - публічна документація