ЕСОЗ - публічна документація

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Purpose

This WS is designed to qualify Device Request: check the ability of dispense Device Request within the Medical program.

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 /wiki/spaces/CSI/pages/17467605147 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 ???

Link

Посилання на Apiary або Swagger

Resource

Посилання на ресурс, наприклад: /api/persons/create

Scope

Scope для доступу

Components

Зазначається перелік бізнес компонентів, які використовують цей метод, наприклад: ePrescription

Microservices

Перелік мікросервісів, які використовує метод API, наприклад: Auth, ABAC

Protocol type

Тип протоколу, який використовується запитом, наприклад: SOAP | REST

Request type

Тип запиту API, наприклад: GET, POST, PATCH…

Sync/Async

Метод є синхронним чи асинхронним?

Public/Private/Internal

Потрібно зазначити тип методу за ступенем доступності

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 Device Definitions found at Validate Device Definitions step

  4. Generate response according to specification

Request structure

See on Apiary

Example:

 Request example
 

Authorize

  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)

Headers

Request data validation

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 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 422 "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

      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"

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

      • has max_daily_count is null or max_daily_count >= quantity.value/(occurence_period.end - occurence_period.start) of the Device Request

        • 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”

Processing

API paragraph not found

Response structure

See on Apiary

Example:

 Response example
 

Post-processing processes

API paragraph not found

HTTP status codes

HTTP status code

Message

What caused the error

 

 

 

 

 

 

  • No labels