• Properties of a REST API method document

• Purpose

  • Key points

• Logic

• Preconditions

• Configuration parameters

• Dictionaries

• Input parameters

• Request structure

• Headers

• Request data validation

  • Authorize

  • Validate digital signature

    • Validate Medication dispense

    • Validate User

    • Validate Care plan and Activity

    • Validate signed content

    • Validate transition

      • Validate division

    • Validate related Medication request

• Processing

• Response structure examples

• HTTP status codes

• Post-processing processes

• Technical modules where the method is used

Properties of a REST API method document

Purpose

This method is designed to process previously created Medication dispense

Key points

1. Only authenticated and authorized users of a legal entity who has created Medication dispense can process Medication dispense

2. Medication dispense can be processed only from ‘NEW' status.

3. The process should be signed with DS. So, all the Medication dispense data should be submitted.

4. Invoke Get Medication dispense details by Pharmacy User to obtain previously created Medication dispense. In order to process dispense payment_id (optional) and payment_amount (optional, if medical program has funding sourse != NHS) should be added.

Logic

1. Save signed content to media storage

2. Update Medication dispense data in OPS DB:

   1. set status  =  ‘PROCESSED’

   2. updated_by = user_id

   3. updated_at = now()

3. Update related Medication request data in OPS DB:

   1. set status  =  ‘COMPLETED’

   2. updated_by = user_id

   3. updated_at = now()

4. Write changes to event manager (Medication dispense and Medication request)

5. Сhange Care plan activity (If related medication request has reference on Care plan, then corresponding care plan activity should be changed after Medication dispense processed):

   1. Set activity status to in_progress if previous activity status was scheduled 

   2. Check the MD identifier in outcome_reference attribute of the activity:

      1. if not found:

         1. Add reference on the medication dispense resource to the outcome_reference attribute .

         2. If quantity in the activity was set - validate $.activity.details.remaining_quantity_type:

            1. if $.activity.details.remaining_quantity_type =for_request than:

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

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

               3. select all MD (medication dispenses) in status PROCESSED related to the Medication requests which are in status COMPLETED, REJECTED, EXPIRED

               4. calculate:

                  1. reserved_qty as sum of medication_qty in the filtered MRR  and MR list

                  2. dispensed_qty as sum of medication_qty in the filtered MD list

               5. calculate and update remaining quantity by subtracting reserved_quantity and dispensed_qty from activity quantity

            2. if $.activity.details.remaining_quantity_type = for_use than:

               1. select all MD in status PROCESSED related to MR which based on care plan and current activity

               2. calculate dispensed quantity in the current activity as sum of medication_qty in the filtered MD list

               3. calculate remaining quantity by subtracting dispensed quantity from activity quantity

               4. update remaining_quantity value in the activity with calculated value

      2. If found, then skip updating activity (it means that activity has been already updated by event from current MD processing).

Preconditions

If skip_medication_dispense_sign=false, MD should be created

Configuration parameters

N/A

Dictionaries

• MEDICATION_REQUEST_BLOCK_REASON

• MEDICATION_REQUEST_INTENT

• MEDICATION_REQUEST_CATEGORY

• MEDICATION_REQUEST_PRIORITY

• eHealth/SNOMED/additional_dosage_instructions

• eHealth/SNOMED/anatomical_structure_administration_site_codes

• eHealth/SNOMED/route_codes

• eHealth/SNOMED/administration_methods

• eHealth/SNOMED/dose_and_rate

• eHealth/ICD10_AM/condition_codes

• eHealth/ICPC2/condition_codes

• ADDRESS_TYPE

• SETTLEMENT_TYPE

• STREET_TYPE

• PHONE_TYPE

• DIVISION_TYPE

• POSITION

• MEDICATION_FORM

• MEDICATION_UNIT

• eHealth/clinical_impression_patient_categories

• LICENSE_TYPE

• FUNDING_SOURCE

• MR_BLANK_TYPES

• MEDICATION_REQUEST_REJECT_REASON

Input parameters

Request structure

See on API-specification

Headers

Headers

Request data validation

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 scopes in order to perform this action (scope = 'medication_dispense:process')

   • return 403 (“Your scope does not allow to access this resource. Missing allowances: medication_dispense:process”) in case of invalid scope(s)

Validate digital signature

• Validate request is signed

  • in case of error - return 400 (“document must be signed by 1 signer but contains 0 signatures”)

• Validate that DS is valid and not expired

• Validate that DS belongs to the user

  • Check that DRFO from DS and party.tax_id matches

    • in case of error - return 422 (“Does not match the signer drfo“)

  • Check that Last Name from DS and party.last_name matches

    • in case of error - return 422 (“Does not match the signer last name“).

Validate Medication dispense

• Get Medication dispense identifier from the URL

  • Check Medication dispense exists in DB (OPS)

    • Return 404 ('not_found') in case of error

  • Check Medication dispense belongs to legal entity

    • Return 404 ('not_found') in case of error

Validate User

• Extract user_id from token

  • Return 404 ('not_found') in case employee didn’t create medication dispense

Validate Care plan and Activity

It is needed to check if medication request with a program allowed to be created for specified care plan and activity.

If based_on submitted, check field has array with two values of Reference type: one is valid Care plan resource, another - Activity resource.

1. Verify Care plan:

   1. It should belong to the same person as set in MRR

      1. in case of error return 422 with msg ("Care plan not found")

   2. It should be in active status

2. Verify submitted Activity:

   1. It belongs to the Care plan.

      1. in case of error return 422 with msg ("Activity not found")

   2. It has activity.detail.kind=medication_request; activity.detail.product_reference=medication_id.

      1. in case of error return 422 with msg ("Invalid activity kind")

   3. It has scheduled, in_progress status

      1. in case of error return 422 with msg ("Invalid activity status")

   4. 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"

   5. check that medical_program_id equal to $.activity[].program

      1. in case of error return 422 with msg ("Medical program from activity should be equal to medical program from request")

3. Validate started_at/ended_at of Medication request Request: 

   1. if care plan activity has detail.scheduled_timing.repeat.bounds_period - validate started_at/ended_at within bounds_period

   2. if care plan activity has detail.scheduled_period - validate started_at/ended_at within scheduled_period

   3. else - validate started_at/ended_at within care_plan.period

      1. in the case of started_at/ended_at is not within care_plan.period return 422 with msg  ("Invalid care plan period")

Validate signed content

1. Check that signed content is equal to online generated dispense with ids in DB

   1. Do not compare:

      • payment_amount field

      • payment_id field

      • medication_request/legal_entity object

      • medication_request/division object

      • medication_request/employee object

      • medication_request/person/id field

      • medication_request/rejected_at field

      • medication_request/rejected_by field

        • in case error return 422 ("Signed content does not match to previously created dispense")

Validate transition

• Get status of Medication dispense by $.id in OPS DB. Check that Medication dispense is in status ‘NEW’

  • in case of error - return 409 ("Can't update medication dispense status from {status} to PROCESSED")

For more information look at [Transferred] Medication dispense status model

Validate payment_amount

1. In case if medical program has funding sourse == NHS check that payment_amount is submitted and greater or equal to 0

   1. in case of error - return 422 ("expected the value to be >= 0")

Validate division

1. 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 "Invalid division dls status"

   else if skip_dispense_division_dls_verify = true, then skip license verification for the division

Validate related Medication request

1. Medication request should be active in order to process medication dispense

   1. is_active = true

   2. status = 'ACTIVE'

      1. In case error - return 409 ("Medication request is not active")

2. Medication request should not be blocked in order to process medication dispense

   1. is_blocked <> true

      1. In case of error - return 409 ("Medication request is blocked")

3. Check that Medication request not blocked

   1. medication_requests.blocked_to <= now() (datetime) or NULL

      1. in case of error - return 409 error ('Medication request is blocked')

4. Medication request should be up to date

   1. medication_request.dispense_valid_from ≤ now OR medication_request.dispense_valid_to ≥ now

      1. In case of error - return 409 ("Invalid dispense period")

5. Checking the status of the legal entity where the medication request was issued

   1. status in ('ACTIVE', 'CLOSED', 'REORGANIZED')

      1. In case of error - return 422 ("value is not allowed in enum")

Check if related medication request has reference on the Care plan - based_on attribute filled. If it has, validate following:

1. Care plan is not in final status.

   1. In case of error - return 409 error (Care plan is not active)

2. If end_date Care plan is present then it should be less than or equal than todays date

   1. In case of error - return 409 ("Care plan expired")

3. Corresponding Care plan activity is not in final status.

   1. In case of error - return 409 error (Care plan activity should be scheduled or in_progress)

Processing

1. Save signed content to media storage

2. Update Medication dispense data in OPS DB:

   1. set status  =  ‘PROCESSED’

   2. updated_by = user_id

   3. updated_at = now()

3. Update related Medication request data in OPS DB (if total medication_dispense quantity = medication_request.medication_qty):

   1. set status  =  ‘COMPLETED’

   2. updated_by = user_id

   3. updated_at = now()

4. Write changes to event manager (Medication dispense and Medication request)

5. Сhange Care plan activity (If related medication request has reference on Care plan, then corresponding care plan activity should be changed after Medication dispense processed):

   1. Set activity status to in_progress if previous activity status was scheduled 

   2. Check the MD identifier in outcome_reference attribute of the activity:

      1. if not found:

         1. Add reference on the medication dispense resource to the outcome_reference attribute.

         2. If quantity in the activity was set - validate $.activity.details.remaining_quantity_type:

            1. if $.activity.details.remaining_quantity_type =for_request than:

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

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

               3. select all MD (medication dispenses) in status PROCESSED related to the Medication requests which are in status COMPLETE, REJECTED, EXPIRED

               4. calculate:

                  1. reserved_qty as sum of medication_qty in the filtered MRR  and MR list

                  2. dispensed_qty as sum of medication_qty in the filtered MD list

               5. calculate and update remaining quantity by subtracting reserved_quantity and dispensed_qty from activity quantity

            2. if $.activity.details.remaining_quantity_type = for_use than:

               1. select all MD in status PROCESSED related to MR which based on care plan and current activity

               2. calculate dispensed quantity in the current activity as sum of medication_qty in the filtered MD list

               3. calculate remaining quantity by subtracting dispensed quantity from activity quantity

               4. update remaining_quantity value in the activity with calculated value

      2. If found, then skip updating activity (it means that activity has been already updated by event from current MD processing).

Response structure examples

See on API-specification

HTTP status codes

Post-processing processes

N/A

Technical modules where the method is used