| Table of Contents |
|---|
Purpose
This WS is designed to create Request fo 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
Specification
...
Project Name
...
Електронний рецепт
...
COVID-certificate
...
Project abreviation
...
ePrescription
...
SVC
...
Developer
...
API paragraph not found
...
Розробник методу API. Наприклад, Edenlab
...
Project Manager
...
API paragraph not found
...
Tech Lead
...
API paragraph not found
...
Product Owner
...
API paragraph not found
...
Вusiness analyst
...
API paragraph not found
...
Status
| Status | ||||
|---|---|---|---|---|
|
| Status | ||||
|---|---|---|---|---|
|
...
Version
...
API paragraph not found
...
1.0
...
Date of release
...
API paragraph not found
...
...
Link
...
...
Посилання на Apiary або Swagger
...
Resource
...
/api/medication_request_requests
...
Наприклад: /api/persons/create
...
Scope
...
medication_request_request:write
...
Зазначається потрібний scope
...
Components
...
ePrescription, Reimbursement
...
Зазначається перелік бізнес компонентів, які використовують цей метод, наприклад: ePrescription
...
Microservices
...
API paragraph not found
...
Перелік мікросервісів, які використовує метод API. Наприклад: Auth, ABAC
...
Protocol type
...
REST
...
Тип протоколу, який використовується запитом, наприклад: SOAP | REST
...
Request type
...
POST
...
Тип HTTP методу, який використовується запитом, наприклад: POST | GET…
...
Sync/Async
...
Sync
...
Метод є синхронним чи асинхронним?
Logic
...
Preconditions
API paragraph not found
Global and configuration parameters
API paragraph not found
Input parameters
No
Filters
No
Request structure
See on Apiary
Example:
...
| title | Request example |
|---|
...
| Table of Contents |
|---|
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
Specification
| Page Properties | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Logic
Процеси роботи з випискою електронних рецептів
Preconditions
Only authenticated and authorized users with appropriate scope can Create Medication Request Request (MRR)
Patient should be stored in hashed form according to security requirements.
Input parameters
ATTRIBUTES - see on Apiary
Request structure
See on Apiary
Example:
| Expand | ||
|---|---|---|
| ||
|
Authorize
Verify the validity of access token
Check user scope (scope = 'medication_request_request:write') in order to perform this action
In case error - generate 401 response
Headers
Content-Type:application/json
Authorization:Bearer c2778f3064753ea70de870a53795f5c9
Validate request
Validate request using JSON schema.
in case of error return 422 error with msg ("required property %{property} was not present")
Request data validation
Validate employee
...
|
Authorize
Verify the validity of access token
in case of error - return 401 (“Invalid access token”) in case of validation fails
Verify that token is not expired
in case of error - return 401 (“Invalid access token”)
Check user scopes in order to perform this action (scope = 'medication_request_request:write')
return 403 (“Your scope does not allow to access this resource. Missing allowances: medication_request_request:write”) in case of invalid scope(s)
If BLOCK_UNVERIFIED_PARTY_USERS is true, then check party's data match following condition: verification_status != NOT_VERIFIED or (verification_status = NOT_VERIFIED and updated_at <= current_date - UNVERIFIED_PARTY_PERIOD_DAYS_ALLOWED):
in case not match - return 403 ("Access denied. Party is not verified")
Headers
Content-Type:application/json
Authorization:Bearer c2778f3064753ea70de870a53795f5c9
Validate request
Validate request according to JSON Schema
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.
Validate $.container_dosage field by schemata
$.container_dosage.code and $.container_dosage.value should be both filled
in case of error return 422 error ("required property %{property} was not present")
$.container_dosage.system should be “MEDICATION_UNIT”
in case of error return 422 error ("value is not allowed in enum")
if $.container_dosage is filled then $.container_dosage.unit should be checked with the MEDICATION_UNIT dictionary by $.container_dosage.code as a key.in case of error return 422 error ("value is not allowed in enum")
Check if there is at list one record of Brand with requested primary container volume
a. if not exist - return 404 error (message: "Not found any appropriate medication with such container parameters")
Validate priority
Check by schemata if $.priority is filled with the value of MEDICATION_REQUEST_PRIORITY dictionary
in case of error return 422 error ("value is not allowed in enum")
Validate prior_prescription
Check that $.prior_prescription is UUID, exists and belongs to this person:
is_active = true, and the same person.
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.
...
Invoke employee_id from request
Validate employee
Validate that exists
in case invalid return 422 error with msg ("Employee not found")
Validate that $.employees.status == APPROVED
in case invalid return 409 error with msg ("Employee is not active")
Validate that $.employees.legal_entity_id == client_id from token
in case invalid return 422 error with msg ("Employee does not belong to legal entity from token")
Validate that $.employees.employee_type == <employee_type>
If medical program has medical_program_settings.skip_employee_validation == false (or
...
validate <employee_type>
get $.medical_programs.medical_program_setting by medical_program_id from request
...
absent), then validate <employee_type>:
validate if employee_type
...
is present in medical_program_settings
employee_types_for_create_medication_requestemployee_types_to_create_requestvariablein case invalid return 422 error with msg ("Employee type can't create medication request with medical program from request")
in case employee_type = DOCTOR
if
...
variable
skip_medication_request_employee_declaration_verifyskip_request_employee_declaration_verify = false or null/absentthen: get $.declarations by employee_id, person_id, status=ACTIVE
if not found - return 422 error "Only doctors with an active declaration with the patient can create medication request with medical program from request!"
else skip declaration verification on employee level (if true)
...
if variable
skip_medication_request_legal_entity_declaration_verifyskip_request_legal_entity_declaration_
...
verify = false or null/absent
then: get $.declarations by employee's legal_entity_id, person_id, status=ACTIVE
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!"
else skip declaration verification on legal entity level (if true)
else if both are true - skip declaration verification at all
in case employee_type = SPECIALIST
get $.employees.speciality.speciality(speciality_officio == true)
validate that speciality present
...
in $.medical_programs.medical_program_setting.speciality_types_
...
allowed variable
in case invalid return 422 error with msg ("Employee's specialty doesn't allow create medication request with medical program from request")
in case employee_type =
...
a. in case invalid return 422 error with msg ("Employee type can't create medication request with medical program from request")
...
MED_COORDINATOR
skip validation that speciality present in $.medical_programs.medical_program_setting.speciality_types_allowed variable
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
Validate division
Purpose validation: Validation Validation of the division for the possibility of creating a medication request.
Invoke Get division details
Validate division_id - division_id exists
in case invalid return 422 error with msg ("Division not found")
Validate Response $.data.status==ACTIVE
if not found - return 422 error (message: "Only employee of active divisions can create medication request!")
Division should be active and refers to current legal_entity
is_active = true
status = 'ACTIVE'
division.legal_entity_id = client_id (context)
Validate legal entity
Purpose validation: Validation Validation of the legal entity for the possibility of creating a medication request.
Get client_id from token
Validate client_id=legal_entity_id
check that legal_entity exist
in case invalid return 422 error with msg (422 Legal entity not found)
check that legal_entities.status == ACTIVE
in case
...
invalid return 422 error with msg ("Only active legal entity can provide medication request")
check legal entity type in chart parameter MEDICATION_REQUEST_REQUEST_LEGAL_ENTITY_TYPES
in case invalid return 409 error with msg (“Invalid legal entity type“)
Validate person
Purpose validation: Validation Validation of person for the possibility of creating a medication request.
Invoke Get patient by ID
...
Validate person_id
...
- mpi_id exists
in case invalid return 422 (422 Person not found)
Save temporary variables from: $.data.authentication_methods
Validate Response $.data.is_active==
...
TRUE
if not found - return 422 error (message: "Only for active MPI record can be created medication request!")
Validate person's verification status:
If MRR has based_on with valid activity, then skip this validation.
Else check patient's verification_status is not equal to NOT_VERIFIED.
in
...
case NOT_VERIFIED - return error 409, "Patient is not verified"
Validate dates
created_at - similar to assertion date in FHIR -> Actual date medication request being created
inserted_at - date when Medication request was registered in E-Health
started_at/ended_at - Treatment period. Cannot be less than MR expiration period. Defined by doctor.
dispence_valid_from - Used for dispense validation. As for now equals Created
...
at.
dispense_valid_to - Implements dispense expiration period. If MR has medical program setting with not empty parameter
medication_dispense_period_daydispense_period_day, then dispence_valid_from +medication_dispense_period_daydispense_period_day, else Dispense valid from + medication_dispense_period global parameter value.
...
Purpose validation: Must be: ended_at >= started_at >= created_at
Validate that created_at, started_at, ended_at in date format
in case invalid return 422 with msg ("expected \"%{actual}\" to be a valid ISO 8601 date")
Validate ended_at >= started_at
if invalid - return 422 error (message: "Ended date must be >= Started date!")
Validate started_
...
at >= created_at, but not greater than (created_at + MEDICATION_REQUEST_REQUEST_EXTENDED_LIMIT_STARTED_AT_DAYS)
if invalid - return 422 error (message: "
...
The start date
...
should be equal to or greater than the creation date, but the difference between them should be not exceed {{MEDICATION_REQUEST_REQUEST_EXTENDED_LIMIT_STARTED_AT_DAYS}} day(s).")
Validate started_at >= current_date()if invalid - return 422 error (message: "Started date must be >= current date!")
...
Validate created_at >= current_date() -
...
MEDICATION_REQUEST_REQUEST_DELAY_INPUT chart param
if invalid - return 422 error (message: "Create date must be >=
...
Current date - MRR delay input!")
Validate started_at regarding frequency of receiving drugs
get $.medical_programs.medical_program_setting by medical_program_id from request
...
validate
skip_mnn_in_treatment_periodskip_treatment_period variablein
...
case s
kip_mnn_in_treatment_periodskip_treatment_
...
period== FALSE (or absent)
validate request according to logic: PreQualify Medication
...
in case
skip_mnn_in_treatment_
...
periodskip_treatment_period == TRUEskip validating frequency of receiving drugs
Validate created_at regarding frequency of receiving drugs
get $.medical_programs.medical_program_setting by medical_program_id from request
validate skip_mnn_in_treatment_
...
period variable
in case skip_mnn_in_treatment_period == FALSE (or absent)
validate request according to logic: PreQualify Medication
...
in case skip_mnn_in_treatment_period == TRUE
skip validating frequency of receiving drugs
Validate period length (ended_at - started_at):
If medical program has been submitted:
validate request according to logic: PreQualify Medication request: 7. Validate period
else:
Check that medication request period less than or equal
...
to
MEDICATION_REQUEST_MAX_PERIOD_DAYrequest_max_period_dayparameter from chartsin case of error - return 409 “Period length exceeds default maximum
...
value“
Validate medication
Purpose validation: Check Check FK, status `is_active`=TRUE, type = INNM_DOSAGE
Invoke Get INNM Dosage by ID
Validate medication_id - medication_id exists
in case of error return 422 ("Medication not found")
Validate Response code == 200
if invalid - return 422 error (message: "Only medication with type `INNM_DOSAGE` can be use for created medication request!")\
Validate Response $.is_active==TRUE
if not found - return 422 error (message: "Only active innm_
...
dosage can be use for created medication request!")
Validate context
Validate "context" is present in the request
in case of error return 422 ("required property context was not present")
Validate "context" is an active (not entered-in-error) entity from corresponding dictionary, that belongs to the current patient
Validate there is an entity in collection $.data.context.identifier.type.coding[0].code with id == $.data.context.identifier.value that belongs to the current patient
in case of error 409 "{$.data.context.identifier.type.coding[*].code} not found"
Validate that entity is not in status "entered-in-error"
in case of error 409 "Entity in status "entered-in-
...
error" can not be referenced"
Validate that related episode exist
in case of error 409 "Entity without related episode can not be referenced"
Validate dosage instruction
Each non-empty attribute must be valid and reference to appropriate dictionary or object
Sequence must be unique within dosage instruction array
in case of error return (422, "Sequence must be unique")
Additional instruction must refer to a valid dictionary
$.dosage_instruction[*].additional_instruction.coding[*].system == "eHealth/SNOMED/additional_dosage_instructions"
$.dosage_instruction[*].additional_instruction.coding[*].code is a valid entry in dictionary "eHealth/SNOMED/additional_dosage_instructions"
in case of error return 409 "Incorrect additional instruction"
Site must refer to a valid dictionary
$.dosage_instruction[*].site.coding[*].system == "eHealth/SNOMED/anatomical_structure_administration_site_codes"
$.dosage_instruction[*].site.coding[*].code is a valid entry in dictionary "eHealth/SNOMED/anatomical_structure_administration_site_codes"
in case of error return 409 "Incorrect site"
Route must refer to a valid dictionary
$.dosage_instruction[*].route.coding[*].system == "eHealth/SNOMED/route_codes"
$.dosage_instruction[*].route.coding[*].code is a valid entry in dictionary "eHealth/SNOMED/route_codes"
in case of error return 409 "Incorrect route"
Method must refer to a valid dictionary
$.dosage_instruction[*].method.coding[*].system == "eHealth/SNOMED/administration_methods"
$.dosage_instruction[*].method.coding[*].code is a valid entry in dictionary "eHealth/SNOMED/administration_methods"
in case of error return 409 "Incorrect method"
Dose and rate type must refer to a valid dictionary
$.dosage_instruction[*].dose_and_rate.type.coding[*].system == "eHealth/SNOMED/dose_and_rate"
$.dosage_instruction[*].dose_and_rate.type.coding[*].code is a valid entry in dictionary "eHealth/SNOMED/dose_and_rate"
in case of error return 409 "Incorrect dose and rate type"
Validate based_on
If submitted, check field has array with two values of Reference type: one is valid Care plan resource, another - Activity resource.
Verify Care plan:
...
type: one is valid Care plan resource, another - Activity resource.
Verify Care plan:
It should belong to the same person as set in MRR
in case of error return 422 with msg ("Care plan not found")
It should be in active status
Verify submitted Activity:
It belongs to the Care plan.
in case of error return 422 with msg ("Activity not found")
It has activity.detail.kind=medication_request; activity.detail.product_reference=medication_id.
in case of error return 422 with msg ("Invalid activity kind")
It has scheduled, in_progress status.
in case of error return 422 with msg ("
...
It should be in active status
...
Care plan's period end (if exist) should be greater than current date or equal.
Verify submitted Activity:
...
It belongs to the Care plan.
in case of error return 422 with msg ("Activity not found")
...
It has activity.detail.kind=medication_request;
in case of error return 422 with msg ("Invalid activity kind")
...
activity.detail.product_reference=medication_id.
in case of error return 422 with msg ("Invalid activity product reference")
...
It has scheduled, in_progress status
...
Invalid activity status")
if it has quantity then calculate remaining quantity:
validate $.activity.details.remaining_quantity_type:
if $.activity.details.remaining_quantity_type =for_request than:
select all MRR in status NEW which based on current activity
select all MR in statuses ACTIVE based on current activity
select all MD (medication dispenses) in status PROCESSED related to the Medication requests which are in status COMPLETE, REJECTED, EXPIRED
calculate:
reserved_qty as sum of medication_qty in the filtered MRR and MR list
dispensed_qty as sum of medication_qty in the filtered MD list
current_qty as medication_qty from current MRR
calculate remaining quantity by subtracting reserved_quantity, dispensed_qty, current_qty from activity quantity
if $.activity.details.remaining_quantity_type = for_use than:
select all MRR in status NEW which based on current activity
select all MR in statuses ACTIVE, COMPLETED based on current activity
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
calculate remaining quantity by subtracting reserved quantity from activity quantity
Check remaining quantity is greater then or equal to
...
zero
in case of error return 409 "The total amount of the prescribed medication quantity exceeds quantity in care plan activity"
check that medical_program_id equal to $.activity[].program
in case of error return 422 with msg ("Medical program from activity should be equal to medical program from request")
...
Validate started_at/ended_at of Medication request Request:
...
if care plan activity has detail.scheduled_timing
...
if bounds_period.end defined then check it greater than current date or equal.
...
If it has scheduled_period:
if scheduled_period.end defined then check it greater than current date or equal.
...
.repeat.bounds_period - validate started_at/ended_at within bounds_period
if care plan activity has detail.
...
scheduled_period - validate started_at/ended_at within scheduled_period
else - validate started_at/ended_at
crossingwithin care_plan.periodin the case of started_at/ended_
...
if care plan activity has detail.scheduled_period - validate started_at/ended_at within scheduled_period
...
else - validate started_at/ended_at within care_plan.period
in the case of started_at/ended_at is not within care_plan.period return 422 with msg ("Invalid care plan period")
Validate medical program
...
at is not within care_plan.period return 422 with msg ("Invalid care plan period")
Validate medical program
Validate medical_program_id is present in the request
in case of error return 422 ("required property medical_program_id was not present")
Validate medical_program_id - medical_program_id exists
in case of error return 422 ("Medical program not found")
Validate medical_programs.medication_request_allowed parameter
check if medication_request_allowed == true
in case of error return 422 with msg ("Forbidden to create medication request for this medical program!")
Validate medical_programs.medical_program_setting parameters
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
in case of error return 422 with msg ("
...
Care plan and activity with the same medical program should be present in request")
If there is conditions_icd10_am_allowed parameter, then:
Check if primary diagnosis from the encounter in context has code from eHealth/ICD10_AM/condition_codes dictionary
Check diagnosis code in conditions_icd10_am_allowed
in case of error
...
Validate context with encounter is present in the request
...
in case of error return 422 ("Context with encounter is required as medical program is present in the request")
...
- return 422 “Encounter in context has no primary diagnosis allowed for the medical program“
If there is conditions_icpc2_allowed parameter, then:
Check if primary diagnosis from the encounter in context has code from eHealth/ICPC2/condition_codes dictionary
Check diagnosis code in conditions_icpc2_allowed
in case of error - return 422
...
Validate medical_programs.medical_program_setting parameters
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
in case of error return 422 with msg ("Care plan and activity with the same medical program should be present in request")
If there is CONDITIONS_ICD10_AM_ALLOWED parameter, then:
Check if primary diagnosis from the encounter in context has code from eHealth/ICD10_AM/condition_codes dictionary
Check diagnosis code in CONDITIONS_ICD10_AM_ALLOWED
in case of error - return 422 “Encounter in context has no primary diagnosis allowed for the medical program“
If there is CONDITIONS_ICPC2_ALLOWED parameter, then:
Check if primary diagnosis from the encounter in context has code from eHealth/ICPC2/condition_codes dictionary
Check diagnosis code in CONDITIONS_ICPC2_ALLOWED
in case of error - return 422 “Encounter in context has no primary diagnosis allowed for the medical program“
if skip_medication_request_employee_declaration_verify = false or null/absent
then: get $.declarations by employee_id, person_id, status=ACTIVE
if not found - return 422 error "Only doctors with an active declaration with the patient can create medication request!"
else skip declaration verification on employee level (if true)
if skip_medication_request_legal_entity_declaration_verify = false or null/absent
then: get $.declarations by employee's legal_entity_id, person_id, status=ACTIVE
if not found - return 422 error "Only legal entity with an active declaration with the patient can create medication request!"
else skip declaration verification on legal entity level (if true)
Validate multiplicity & medication request allowed for participants
Purpose validation: Request quantity must have multiplicity package_min_qty for linked medications. Result (Mod or % operator) must = 0 .
Also if present Medical_program - must exists medications with `medication_request_allowed`== TRUE for participants.
If `$.medical_program_id` present in payload (non null) - Check exist (IF EXIST()) medication & participant
if not exist - return 404 error (message: "Not found any medications allowed for create medication request for this medical program!")
| Code Block |
|---|
SELECT *
FROM medications MI -- 2nd level: Medication - type = INNM_DOSAGE
INNER JOIN ingredients I
ON I.medication_child_id = MI.id
AND I.is_primary =TRUE
INNER JOIN medications MED -- 3rd level: Medication - type = BRAND
ON MED.type == BRAND
AND I.parent_id = MED.id
AND MED.is_active == TRUE
INNER JOIN program_medications MP
ON MP.medical_program_id == `DOSTUPNI LIKI`
MED.id = MP.medication_id
AND MP.is_active == TRUE
AND MP.medication_request_allowed == TRUE
WHERE MI.id == $.medication_id
AND MI.type == INNM_DOSAGE
AND MI.is_active == TRUE
|
Check exist (IF EXIST()) medication & get combinations of manufacture
if not exist - return 404 error (message: "Not found any active linked medication for this innm dosage!")
| Code Block |
|---|
SELECT DISTINCT MED.package_min_qty
FROM medications MI -- 2nd level: Medication - type = INNM_DOSAGE
INNER JOIN ingredients I
ON I.medication_child_id = MI.id
AND I.is_primary =TRUE
INNER JOIN medications MED -- 3rd level: Medication - type = BRAND
ON MED.type == BRAND
AND I.parent_id = MED.id
AND MED.is_active == TRUE
WHERE MI.id == $.medication_id
AND MI.type == INNM_DOSAGE
AND MI.is_active == TRUE
|
...
Vaildate multiplicity (Mod == 0) for all elements in result (`$.medication_qty` Mod `MED.package_min_qty` == 0)
if all result of Mod operator - NOT 0 - return 409 eror (message: "The amount of medications in medication request must be divisible to package minimum quantity")
Parameters that are used when processing the request
Configuration parameters
Access to the method is defined by the scope medication_request_request:write. 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 number & verification_code for Medication request
Generate human readable number for receipt (See specs)
| Code Block |
|---|
Structure number XXXX-1234-5678-9012-345-C , where:
- XXXX - series: numbers + only some letters (A, E, H, K, M, P, T, X)
- 1234-5678-9012-345 - randomly generated numbers
- C - checksum: Should be calculated using the Damn algorithm or Verhoeff algorithm
After new Request number was generated we should check that it is unique in the DB (entity: medication_request + medication_request_request
|
Generate verification_code for MPI.person_authentication_methods == OTP or OFFLINE
| Code Block |
|---|
Structure code 1234, where:
- 1234 - randomly generated numbers
|
Create Medication request Request
set:
dispense_valid_from = created_at
dispensed_valid_to = dispensed_valid_from + dispense_period
Fill 'data' structure for Response & save in IL.medication_request_requests
Generate content for response
Generate data structure with Responce WS structure
Set IL.medication_request_requests this structure
in case if response is VALID enrich response with urgent_data:
get authetification_method by person_id and return masked number (in case if any)
...
| Code Block |
|---|
"urgent": {
"authentication_method_current": {
"type": "OTP",
"number": "+38093*****85"
}
} |
Response structure
See on Apiary
Example:
| Expand | ||
|---|---|---|
| ||
|
Post-processing processes
API paragraph not found
HTTP status codes
...
HTTP status code
...
Message
...
What caused the error
...
201
...
Response
...
...
404
...
Error
...
409
...
Error
...
422
...
Error
...
Backward compatibility
...
“Encounter in context has no primary diagnosis allowed for the medical program“.
if skip_medication_request_employee_declaration_verify = false or null/absent
then: get $.declarations by employee_id, person_id, status=ACTIVE
if not found - return 422 error "Only doctors with an active declaration with the patient can create medication request!"
else skip declaration verification on employee level (if true).
if skip_medication_request_legal_entity_declaration_verify = false or null/absent
then: get $.declarations by employee's legal_entity_id, person_id, status=ACTIVE
if not found - return 422 error "Only legal entity with an active declaration with the patient can create medication request!"
else skip declaration verification on legal entity level (if true).
If medical program has funding_source = LOCAL , then invoke validation described at PreQualify Medication request request | 11.-Check-provision-for-a-programs
Validate multiplicity & medication request allowed for participants
Perform validation as described at https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/583405343/PreQualify+Medication+Request+Request#1.-Check-INNM-complience-for-the-programs .
Perform validation as described at
PreQalify Medication Request: Check absence the same medications for the programs.
Parameters that are used when processing the request
Configuration parameters
Access to the method is defined by the scope medication_request_request:write. Permission for this scope is determined by the System administrator by configuring scopes in the context of clients and roles.
Dictionaries
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
Processing
Generate number & verification_code for Medication request
Generate human readable number for receipt (See specs)
Code Block Structure number XXXX-XXXX-XXXX-XXXX, where: - XXXX - series: numbers + some letters (A, E, H, K, M, P, T, X) - first block - always "0000" for medication requests - pattern: ^[0]{4}-[#{symbols}]{4}-[#{symbols}]{4}-[#{symbols}]{4} - example: 0000-TP42-M36M-H6TH After new Request number was generated we should check that it is unique in the DB (entity: medication_request + medication_request_request), if Request number is already reserved - generate newGenerate verification_code for MPI.person_authentication_methods == OTP or OFFLINE
Code Block Structure code 1234, where: - 1234 - randomly generated numbers
Create Medication request Request
set:
dispense_valid_from = created_at
dispensed_valid_to = dispensed_valid_from + dispense_period
Fill 'data' structure for Response & save in IL.medication_request_requests
If encounter is present in the request context then based on it - fill the IL.medication_request_requests.context_episode_id
Fill separately
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
Update based_on
If the medication request request is based on activity with quantity - set remaining_quantity for the activity which was calculated at validation Create Medication Request: Validate based_on (p. 2.d.1 )
Generate content for response
Generate data structure with Responce WS structure
Set IL.medication_request_requests this structure
in case if response is VALID enrich response with urgent_data:
get authetification_method by person_id and return masked number (in case if any)
| Code Block |
|---|
"urgent": {
"authentication_method_current": {
"type": "OTP",
"number": "+38093*****85"
}
} |
Response structure
See on Apiary
Example:
| Expand | ||
|---|---|---|
| ||
|
HTTP status codes
HTTP status code | Message | What caused the error |
|---|---|---|
201 | Response |
|
403 | Your scope does not allow to access this resource. Missing allowances: medication_request_request:write | |
409 |
| |
422 |
|
|