Purpose

This WS is designed to create Request for Medication request

There are two types of medication request:

...

Purpose

This WS is designed to create Request for Medication request

There are two types of medication request:

• plan - The request represents an intention to ensure something occurs without providing an authorization for others to act. Medication request with type plan can't be dispensed and only provide the instruction to administer the medicine. 

• order - The request represents a request/demand and authorization for action. Medication request with type order can be dispensed

Key points

1. Only authenticated and authorized users with appropriate scope can Create Medication Request Request (MRR)

2. Patient should be stored in hashed form according to security requirements.

Specification

...

Project Name

...

Електронний рецепт

...

COVID-certificate

...

Project abreviation

...

ePrescription

...

SVC

...

Developer

...

Edenlab

...

Розробник методу API. Наприклад, Edenlab

...

Project Manager

...

Mari Hulko (Unlicensed)

...

Tech Lead

...

Mynchenko Andrii (SoE eHealth)

...

Product Owner

...

Igor Kostyria

...

Вusiness analyst

...

Iryna Lishtaba (SoE eHealth) Oleksandr Zhuk (SoE eHealth) Oksana Demchenko

...

Status

...

Version

...

API paragraph not found

...

1.0

...

Date of release

...

PROD 30 Jul 2022

...

22 Jun 2022

• administer the medicine. 

• order - The request represents a request/demand and authorization for action. Medication request with type order can be dispensed

Key points

1. Only authenticated and authorized users with appropriate scope can Create Medication Request Request (MRR)

2. Patient should be stored in hashed form according to security requirements.

Specification

Logic

API paragraph not found

...

1. Validate request according to JSON Schema

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

Request data validation

Validate container_dosage field

$.container_dosage - volume of a medication’s primary container, which is requested by a doctor or issuer of a medication request, to be dispensed to patient.

1. Validate $.container_dosage field by schemata

   1. $.container_dosage.code and $.container_dosage.value should be both filled

      1. in case of error return 422 error ("required property %{property} was not present")

   2. $.container_dosage.system should be “MEDICATION_UNIT”

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

   3. if $.container_dosage is filled then $.container_dosage.unit should be checked with the MEDICATION_UNIT dictionary by $.container_dosage.code as a key.

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

Validate priority

1. Check by schemata if $.priority is filled with the value of MEDICATION_REQUEST_PRIORITY dictionary

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

Validate prior_prescription

1. Check that $.prior_prescription is UUID, exists and belongs to this person:

   1. is_active = true, and the same person. 

      1. in case of error - return 422 (message: "Prior prescription is not found")

Validate employee

Validation of an employee for the possibility of creating a medication request.

1. Invoke employee_id from request

2. Validate employee

   1. Validate that exists

      1. in case invalid return 422 error with msg ("Employee not found")

   2. Validate that $.employees.status == APPROVED

      1. in case invalid return 409 error with msg ("Employee is not active")

   3. Validate that $.employees.legal_entity_id == client_id from token

      1. in case invalid return 422 error with msg ("Employee does not belong to legal entity from token")

   4. If medical program has medical_program_settings.skip_employee_validation == false (or absent), then validate <employee_type>:

      1. validate if employee_type is present in medical_program_settings.employee_types_for_create_medication_request variable

         1. in case invalid return 422 error with msg ("Employee type can't create medication request with medical program from request") 

         2. in case employee_type = DOCTOR

            1. if variable skip_medication_request_employee_declaration_verify = false or null/absent

               1. then: get $.declarations by employee_id, person_id, status=ACTIVE

                  1. if not found - return 422 error  "Only doctors with an active declaration with the patient can create medication request with medical program from request!"

               2. else skip declaration verification on employee level (if true)

            2. if variable skip_medication_request_legal_entity_declaration_verify = false or null/absent

               1. then: get $.declarations by employee's legal_entity_id, person_id, status=ACTIVE

                  1. if not found - return 422 error "Only legal entity with an active declaration with the patient can create medication request with medical program from request!"

               2. else skip declaration verification on legal entity level (if true)

            3. else if both are true - skip declaration verification at all

         3. in case employee_type = SPECIALIST

            1. get $.employees.speciality.speciality(speciality_officio == true)

            2. validate that speciality present in $.medical_programs.medical_program_setting.speciality_types_allowed variable

               1. in case invalid return 422 error with msg ("Employee's specialty doesn't allow create medication request with medical program from request") 

   5. If medical program has medical_program_settings with medical_program_settings.skip_employee_validation == true any user who has a scope can create medication request

...

1. Validate medical_program_id is present in the request

   1. in case of error return 422 ("required property medical_program_id was not present")

2. Validate medical_program_id - medical_program_id exists

   1. in case of error return 422 ("Medical program not found")

3. Validate medical_programs.medical_program_setting parameters

   1. check if care_plan_required == true then the request should contain a based_on with care plan and activity that contains the same medical program

      1. in case of error return 422 with msg ("Care plan and activity with the same medical program should be present in request")

   2. If there is conditions_icd10_am_allowed parameter, then:

      1. Check if primary diagnosis from the encounter in context has code from eHealth/ICD10_AM/condition_codes dictionary

         1. Check diagnosis code in conditions_icd10_am_allowed

            1. in case of error - return 422 “Encounter in context has no primary diagnosis allowed for the medical program“

   3. If there is conditions_icpc2_allowed parameter, then:

      1. Check if primary diagnosis from the encounter in context has code from eHealth/ICPC2/condition_codes dictionary

         1. Check diagnosis code in conditions_icpc2_allowed

            1. in case of error - return 422 “Encounter in context has no primary diagnosis allowed for the medical program“

4. If medical program has funding_source = LOCAL , then invoke validation described at PreQualify Medication request request | 11.-Check-provision-for-a-programs

...

1. set:

   1. dispense_valid_from = created_at

   2. dispensed_valid_to = dispensed_valid_from + dispense_period

2. Fill 'data' structure for Response & save in IL.medication_request_requests

   1. If encounter is present in the request context then based on it - fill the IL.medication_request_requests.context_episode_id

3. Fill separately

   1. data_employee_id,
      data_intent,
      data_based_on_care_plan_id,
      data_based_on_activity_id,
      data_context_id,
      data_patient_id,
      data_legal_entity_id

Generate content for response

...