Purpose

This WS is designed to qualify Medication request (post) - check the ability of using Medication request within the Medication program.

Specification

Logic

API paragraph not found

Preconditions

API paragraph not found

Global and configurable parameters

No

Input parameters

Filters

No

Request structure

See on Apiary

Example:

{
  "division_id": "2848a935-5fd7-48ba-b235-a9b5d475c647",
  "programs": [
    {
      "id": "59781de0-2e64-4359-b716-bcc05a32c10f"
    }
  ]
}

Authorize

1. Verify the validity of access token

2. Check user scope (scope = 'medication_request:details') in order to perform this action

   1. In case error - generate 401 response

Headers

Content-Type:application/json

Authorization:Bearer c2778f3064753ea70de870a53795f5c9

Validate request

Validate request using JSON schema 

Request data validation

Validate FK

1. Validate id - medication_request_id exists

   1. Return  404 in case (not found medication request in DB with this ID)

2. Validate [programs.id] - medical programs id  exists

   • Return 422 in case validation fails (422 EView - not found medical program in DB with this ID)

Get Medication Request 

Invoke Get Medication request by ID 

Validation status

1. For info - status charts: Medication_request

2. Check Medication Request `status` = ACTIVE

   1. if invalid - return 409 error (message: "Invalid status Medication request for qualify action!")'

Validate related Care plan

If medication_request.based_on is present and not null:

1. Verify Care plan:

   1. It should be in active status

      1. in case of error - return 409 (message: "Care plan is not active")

   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“)

2. Verify care plan Activity:

   1. It has scheduled, in_progress status

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

   2. If it has quantity then calculate remaining quantity:

      1. select all MRR in status NEW which based on current activity

      2. select all MR in statuses ACTIVE, COMPLETED based on current activity

      3. calculate reserved at the moment medication quantity as sum of medication_qty in the filtered MRR  and MR list, including medication_qty from current MRR

      4. calculate remaining quantity by subtracting reserved quantity from activity quantity

      5. Check remaining quantity is greater then or equal to zero

         1. in case of error return 409 "The total amount of the prescribed medication quantity exceeds quantity in care plan activity"

Validate division

If division_id submitted:

1. Validate division is active

   1. in case of error - return 409 ("Division is not active")

2. Validate division belongs to user's legal entity

   1. in case of error - return 409 ("Division does not belong to user's legal entity")

3. If chart parameter DISPENSE_DIVISION_DLS_VERIFY is on, then validate division is DLS verified (dls_verified=true)

   1. in case of error - return 409 "Division is not verified in DLS"

4. If chart parameter MEDICAL_PROGRAM_PROVISION_VERIFY, then check division provide each submitted program. For each medical program provision validate:

   1. it is exist and active:

      1. in case of error - return 409 ("Division is not provide the medical program")

   2. it relate to the actual reimbursement contract: contract.start_date <= current_date <= contract.end_date, is_active = true, status = VERIFIED.

      1. in case of error - return 409 ("Medical program provision is not actual for the current date")

Logic for qualify (analyze compliance with programs)

• Each Medical program may have its unique conditions for the medication dispense. It can be based on analysis of personal info, medications list, terms, locations and combinations of them.

• For now there are only conditions for the following programs "Dostupni liky", "Netsukrovyy diabet", "Insuliny z doplatoyu", "Insuliny bezoplatno" and we check them.

• Also, it is possible to have the medication dispense without any Medical program.

• However for any Medical program we need a separate block of branching logic.

• Check compatibility only for programs which are available in payload (array)

• If program status is invalid, the reason must be saved and returned in response

Check compliance for programs

1. Validate 2 checks (below in the text) for programs

   1. if passed - save status this program for response = VALID

Check INNM_dosage compliance for the programs

Applies to the following programs:

1. Dostupni liky

2. Netsukrovyy diabet

3. Insuliny z doplatoyu

4. Insuliny bezoplatno

5. Epilepsiya

6. Rozlady psykhiky ta povedinky

Validation purpose:  There is a list of medications (which links to innm_dosage) which can be used for the program. It must be check whether there is at least one available medication for the innm_dosage for the particular program.

1. Get info from Medication request  by id in payload, set temp variable object `_MR`

2. Validate the compatibility of innm with the medication program list 

   1. if data is not found:

      1. add to response: status = INVALID

      2. add to response: rejection_reason = "Innm not on the list of approved innms for program '#{program.name}"

IF EXISTS
    (SELECT * FROM program_medications MP
        INNER JOIN medications M
            ON M.id = MP.medication_id
                AND M.type =  BRANDS
        INNER JOIN ingredients I
            ON I.parend_id = M.id
                AND I.is_primary = TRUE
                AND I.medication_child_id = _MR.medication_id
    WHERE MP.medical_program_id == $.id
        AND MP.is_active == TRUE
        AND M.is_active == TRUE)

Check absence a same medication for the programs

Applies to the following programs:

1. Dostupni liky

2. Netsukrovyy diabet

3. Insuliny z doplatoyu

4. Insuliny bezoplatno

5. Epilepsiya

6. Rozlady psykhiky ta povedinky

Validation purpose: It could be done several dispenses for one medication request per one innm for one patient until sum(medication_dispenses.medication_qty) < medication_request.medication_qty

Example validation: without crossing time

1. For info - status charts: Medication Request Status Chart & Medication Dispense Status Chart

2. Get `check_innm_id`

   SELECT I.innm_child_id
       FROM ingredients I
   WHERE I.parent_id = _MR.medication_id 
       AND I.is_primary = TRUE
   

3. Get Medication requests with their linked completed Medication dispense by person_id & innm_id

   SELECT * FROM medication_requests MR    INNER JOIN medication_dispense MD        ON MD.medication_request_id = MR.id             AND MD.status IN (PROCESSED)    INNER JOIN ingredients I        ON I.parent_id = MR.medication_id           -- type = INNM_DOSAGE            AND I.innm_child_id = `check_innm_id`            AND I.is_primary = TRUE    WHERE MR.person_id == _MR.person_id        AND MR.status IN (ACTIVE, COMPLETED)        AND NOT($.started_at> MR.ended_at OR $.ended_at < MR.started_at)

4. Validate medication request_id

   1. for medication_dispense.medication_request_id !== $.id

      1. Validate exist (IF EXIST ()  - that is any crossing  calculating term (started_at + ended_at) for payload with terms selecting Medication requests with linked Medication dispense (started_at + ended_at)).  

      2. if found 

         1. get $.medical_programs.medical_program_setting by medical_program_id from request

            1. validate skip_mnn_in_treatment_period variable

               1. in case skip_mnn_in_treatment_period == FALSE (or absent) 

                  1. validate request according to logic:

                     1. add to response: status = INVALID

                     2. add to response: rejection_reason = "For the patient at the same term there can be only 1 dispensed medication request per one and the same innm!"

               2. in case skip_mnn_in_treatment_period == TRUE

                  1. skip validating frequency of receiving drugs

   2. for medication_dispense.medication_request_id = $.id

      1. Validate medication request qty: sum(medication_dispenses.medication_qty) >= medication_request.medication_qty 

      2. if found

         1. add to response: status = INVALID

         2. add to response: rejection_reason = "Sum of dispense's medication quantity can not be more then medication_request.medication_qty"

Parameters that are used when processing the request

Configuration parameters

Access to the method is defined by the scope medication_request:details. Permission for this scope is determined by the System administrator by configuring scopes in the context of clients and roles.

Dictionaries

API paragraph not found

Processing

Generate structure for response

• Collect response array for all programs in payload with status for each (VALID or INVALID) and rejection_reason

• For all VALID programs - Get linked medications (type = BRAND) with reimbursement info 

• Show only active program medications based on start_date and end (start_date must be earlier or equal to current date or empty, end_date must be greater or equal to current date or empty)

  SELECT *
  FROM program_medications pm
      INNER JOIN ingredients i ON (i.parent_id = pm.medication_id
                                   AND i.medication_child_id = :medication_request_medication_id
                                   AND i.is_primary = TRUE)
      INNER JOIN medications m ON (m.id = pm.medication_id)
  WHERE pm.medical_program_id = $.id
        AND pm.is_active = TRUE
        AND m.is_active = TRUE
        AND (pm.start_date <= now() OR pm.start_date IS NULL)
        AND (pm.end_date >= now() OR pm.end_date IS NULL)
  

Prepare & return response data structure

1. Fill response WS data structure

2. Validate response using JSON schemas

   1. Return 422 with list of validation errors in case validation fails (422 EView)

Response structure

See on Apiary

Example:

{
  "meta": {
    "code": 200,
    "url": "https://example.com/resource",
    "type": "object",
    "request_id": "req-adasdoijasdojsda"
  },
  "data": [
    {
      "program_id": "59781de0-2e64-4359-b716-bcc05a32c10f",
      "program_name": "Програма \"Доступні ліки\"",
      "status": "INVALID",
      "rejection_reason": "Innm not on the list of approved innms for program 'DOSTUPNI LIKI' !",
      "participants": [
        {
          "id": "0f2fbf93-3041-4c0d-a3cf-ff558c861df8",
          "medication_id": "59781de0-2e64-4359-b716-bcc05a32c10f",
          "medication_name": "Амлодипін-КВ",
          "form": "PILL",
          "manufacturer": {
            "name": "ПАТ \"Київський вітамінний завод\"",
            "country": "UA"
          },
          "reimbursement_amount": 15,
          "wholesale_price": 25.14,
          "consumer_price": 34.03,
          "reimbursement_daily_dosage": 1.4438,
          "estimated_payment_amount": 5.15,
          "container_dosage": {
            "numerator_unit": "PILL",
            "numerator_value": 1,
            "denumerator_unit": "PILL",
            "denumerator_value": 1
          },
          "package_min_qty": 20,
          "package_qty": 20,
          "start_date": "2019-01-01",
          "end_date": "2019-06-30",
          "registry_number": "REG-1111"
        }
      ]
    }
  ]
}

Post-processing processes

No

HTTP status codes

Backward compatibility

API paragraph not found