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

1. Only authenticated and authorized users with appropriate scope can invoke Qualify Device Request

2. 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.

3. 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.

4. Any Medical program can have separate block of branching logic configured at medical program settings by NHS administrator.

5. Сompatibility is checked only for programs which are available in payload (array).

6. 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.

7. Allowed for existing and active Device Requests

8. Also medical program provision is checked for the division of the pharmacy.

Specification

Apiary

Specification

Input parameters

Request structure

See on Apiary

Authorization

1. Verify the validity of access token

   • in case of error - return 401 (“Invalid access token”) in case of validation fails

2. Verify that token is not expired

   • in case of error - return 401 (“Invalid access token”)

3. 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:

1. Verify care plan Activity from $.based_on where coding.code=activity:

   1. It has scheduled or in_progress status

      1. in case of error - return 409 (message: "Invalid Activity status")

2. Verify Care plan:

   1. Get Activity from $.based_on where coding.code=activity

   2. Get Care plan from activity.care_plan

   3. Get Care Plan from $.based_on where coding.code=care_plan:

      1. It should be in active status

         1. in case of error - return 409 (message: "Invalid Care plan status")

      2. Care plan's period end (if exist) should be greater than current date or equal.

         1. 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 request

  • Find all device dispenses related to the same device request ($.based_on)

  • Check that there are no records in status IN_PROGRESS where inserted_at + config device_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"

• 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

    1. 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

    1. 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

    1. 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

kip_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 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

1. If general error found at Validate division section, that doesn’t depend on medical program, then return corresponding error code with error message

2. If general validation passed, then collect array for all programs in payload with status for each (VALID or INVALID) and rejection_reason

3. For each program return a list of appropriate program participants found at Validate Device Definitions step

4. Generate response according to specification

Response structure

See on Apiary

HTTP status codes