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 /wiki/spaces/CSI/pages/17467605147 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 legal entity
Extract client_id from token
Check legal entity status is ACTIVE
In case of error - return 409 ('client_id refers to legal entity that is not active')
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')
Check that intent specified in Device request is
order
in case of error - return 409 error ('Only device request with intent = 'order' can be dispensed')
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')
Validate related Care plan
If reference on Activity and Care Plan in device_request.based_on is present and not null:
Verify care plan Activity from $.based_on where coding.code=activity:
It has scheduled or in_progress status
in case of error - return 409 (message: "Invalid Activity status")
Verify Care plan:
Get Care Plan from $.based_on where coding.code=care_plan:
It should be in active status
in case of error - return 409 (message: "Invalid Care plan status")
Care plan's period end (if exist) should be greater than current date or equal.
in case of error - return 409 (message: “Care plan expired“)
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 the medical program has no setting skip_dispense_division_dls_verify or it is set in false/null validate:
Check $.division.dls_verify == true:
In case of error - return 409 "Division is not verified in DLS"
else if skip_dispense_division_dls_verify = true, then skip license verification for the division
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
If the medical program has no setting skip_contract_provision_verify or it is set in false/null validate:
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"
else if skip_contract_provision_verify = true, then skip provision verification for the medical program
Validate Device Definitions
skip_contract_provision_verify = true, then skip provision verification for the medical program
Find Program participants
If device_request.code specified, then:
Find program_devices related to the program, that:
are active
have 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 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 at least one classification type that is the same code as in the Device Request
in case of error - return reject_reason = “Not found any active device definition with classification type that match with code from 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”
If device_request.code_reference specified, then:
Find program_devices related to the program, that:
are active
related to the Device definition(device_request.code_reference)
have 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 Device Definition, that:
is active
in case of error - return reject_reason = "Device definition is not active"
has packaging_unit that matches to quantity.code of the Device Request
in case of error - return reject_reason = “Units of measure in the Device definition doesn't correspond to the units of measure in 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 the 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 |
|
|