| Table of Contents | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Purpose
This WS is designed to Pre-qualify data of Device Request (post) - check whether it's possible to create Device request with specified parameters and within the particular Medical program.
Key points
Only authenticated and authorized users with appropriate scope can invoke Prequalify Device Request
This method simply returns the result of data validation within each submitted medical program, but not creates any entities in the system.
Each Medical program may have its unique conditions for the Device Request. It can be based on analysis of personal info, device definition list, terms, locations and combinations of them.
Any Medical program can have separate block of branching logic configured at medical program settings by NHS administrator.
Сompatibility is checked only for programs which are available in payload (array).
Successful invocation of the method returns decision for each program if it is valid or not to create Device request with submitted combination of parameters in the payload. If program is invalid, the reason must be returned in the response.
It is not allowed for prepersons, because dispense with program is forbidden for them
Specification
Authorization
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 and client scopes in order to perform this action (scope = 'device_request:write')
return 403 (“Your scope does not allow to access this resource. Missing allowances: device_request:write”) in case of invalid scope(s)
Validate legal entity
Extract client_id from token
Check legal entity status (status = ACTIVE)
In case of error - return 409 ('client_id refers to legal entity that is not active')
Check legal entity type in ME_ALLOWED_TRANSACTIONS_LE_TYPES config parameter
in case of error - return 409 ('client_id refers to legal entity with type that is not allowed to create medical events transactions')
Validate Patient
...
Get Patient identifier from the URL
...
Check it exists in persons table (MPI)
Return 404 ('not found') in case of error
...
Validate person status is active
in case of error - return 409 ('Patient is not active')
...
in case NOT_VERIFIED - return error 409 ("Patient is not verified")
Validate request
Validate request using schema. Return 422 with the list of validation errors in case validation fails. In addition, check following:
Validate Device request
Invoke common validations of root attributes first that are independent of medical programs.
1. Validate requester
Validate value in the field $.requester, Reference on employee resource, required.
...
Extract user_id from token. Check that requester belongs to one of the user’s employee.
in case of error - return 422 ('User is not allowed to create device request for the requester')
...
Check requester is an active and approved employee.
in case of error - return 422 ('Invalid employee status')
...
| Table of Contents |
|---|
Purpose
This WS allows to prequalify care plan activity in order to define whether the medical program could be applied in this particular case or not.
Key points
Activity can be prequalify by the employee who has an Approval granted by the patient on write Care plan resource
Activity shouldn’t be signed with DS
Specification
Authorization
Verify the validity of access token
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 = 'care_plan:write')
Return (403, 'Your scope does not allow to access this resource. Missing allowances: care_plan:write') in case of invalid scope(s)
Validate legal entity
Extract client_id from token
Check legal entity status is ACTIVE
In case of error - return 409 ('client_id refers to legal entity that is not active')
Check legal entity type in ME_ALLOWED_TRANSACTIONS_LE_TYPES config parameter
in case of error - return 409 ('client_id refers to legal entity with type that is not allowed to create medical events transactions')
Validate Care plan
Get Care plan identifier from the URL
Check Care plan:
belongs to patient (from url)
in case of error - return 422 ('Care plan with such id is not found')
is not in final status
in case of error - return 422 ('Invalid care plan status')
Care plan’s period.end >= current date.
in case of error - return 422 ('Care Plan end date is expired')
Validate Patient
Get person_id from URL
Validate patient status is active
in case of error - return 409 ('Person is not active')
If patient is a person - validate patient'sverification_status is not equal to NOT_VERIFIED.
in case NOT_VERIFIED - return error 409, "Patient is not verified"
Validate User
Extract user_id from token.
Check user has an active and approved employee from legal entity (token) that:
has an active Approval granted by the Patient on write the Care plan resource (care plan id from URL)
Return 403 ('Access denied') in case employee has no Approval on write
Check user's employee is from the same legal entity (token) as managing_organisation from the care_plan:
Return 422 ('User is not allowed to create care plan activity for this care plan') in case employee’s legal_entity do not match managing_organisation of related care_plan
Validate activity
Activity should be validated. User fills following fields in the activity:
Validate care plan identifier
As care plan identifier should be contained in signed content, $.care_plan required in the request body.
Check value matches with care plan identifier from URL
in case of error - return 409 ('Care Plan from url does not match to Care Plan ID specified in body')
Validate activity author
Validate value in the field $.author, required
Check employee belongs to the user and legal entity (from token)
Employee is:
an employee who has active Approval on write the Care plan
belongs to user
in case of error - return 422 ('
Check that requester is the same employee as encounter performer ($.requester == encounter.performer)
- in case of error - return 422 ('Requester doesn’t match with encounter performer
User is not allowed to create care plan activity for the employee')
Validate activity detail
1. Kind
Validate value in the field $.detail.kind, required
Check value in enum: medication_request, service_request, device_request
Return 422 ('value is not allowed in enum')
2.
...
Validate values in the field $.based_on (Reference), array, optional.
...
Check that $.based_on contains only one reference
in case of error - return 422 ('Only one reference is allowed in based_on')
...
Validate that referenced resource is one of the following (activity):
in case of error - return 422 ("Referenced resource in based_on is not allowed")
Check that resource exists and belongs to the patient ($.subject)
Product
Check there is one of the required $.detail.product_[x] field is set: product_reference or product_codeable_concept.
Return 422 ('Only one of the parameters must be present') in case more then one submitted
If $detail.kind=medication_request:
Check $.detail.product_reference field is submittedand has Reference type
in case it isn’t submitted - return 422 ('can't be blank')
in case of wrong type - return 422 ('type mismatch')
Check the value is valid reference on medication resource.
Return 422 ('Cannot refer to <resource> for kind = medication_request')
Check medication:
Validate that entity status is “SCHEDULED” or “IN_PROGRESS“is active
in case of error - return 422 ('
Medication should be active')
If Activity resource referenced:
- Check that value is in allowed active values from
device_request_intentdictionary.type is INNM_DOSAGE
in case of error - return 422 (
Check that activity.kind == 'device_request'
in case of error - return 422 ("Invalid Activity kind (based_on)")
Validate that referenced activity has the same product_codeable_concept or product_reference as current device request
Check that $.code == (referenced) activity.detail.codeable_concept OR
Check that $.code_reference == (referenced) activity.detail.product_reference
in case of error - return 422 ("Type in based_on activity doesn’t match with type in prescribed device request")
Validate that referenced activity has the same program as current device request
Check that $.program == (referenced) activity.detail.program OR is missing on both sides
in case of error - return 422 ("Program in based_on activity doesn’t match with program in prescribed device request")
Check that units of measure is the same
Check that $.quantity.code == activity.detail.quantity.code:
in case of error return 422 ("The quantity units must not differ from the quantity units in the activity")
Check that prescribed quantity does not exceed remaining quantity
select all device requests based on current activity and calculate previously reserved quantity as sum of DR.quantity.value.
calculate reserved at the moment quantity as sum of previously reserved quantity and quantity from current DR
calculate remaining quantity by subtracting reserved at the moment quantity from activity's quantity
Check that remaining quantity is greater then or equal to zero
in case of error return 422 "The number of available devices according to the care plan activity has been exhausted"
3. Validate intent
Validate value in the field $.intent, string, required.
'Medication does not exist')
If $.detail.kind=service_request:
Check $.detail.product_reference field is submitted and has Reference type
in case it isn’t submitted - return 422 ('can't be blank')
in case of wrong type - return 422 ('type mismatch')
Check that value is a reference on service or service_group
Return 422 ('Cannot refer to <resource> for kind = service_request')
Check service or service_group is active
Return 422 ('<Service/Service group> should be active')
If $.detail.kind=device_request:
Validate product_reference:
Check there value is valid Reference on device_definition resource
Return 422 ('Cannot refer to <resource> for kind = device_request')
Check the device_definition is active
Return 422 ('Device definition is not active')
Validate product_codeable_concept:
Check that value matches with active values in
device_definition_classification_typedictionary.Return 422 ('value is not allowed in enum')
Check there is no another activities (status=scheduled, in_progress) with the same product_reference or product_codeable_concept in the Care plan
Return 422 (“Another activity with status ‘scheduled' or ‘in_progress' already exists in the current Care plan“)
3. Reason code
Validate value in the field $.detail.reason_code, if submitted
Check that value matches with values in
eHealth/ICD10_AM/condition_codesdictionaryin case of error - return 422 ('value is not allowed in enum')
4.
...
One and only one of $.code (CodeableConcept) and $.code_reference (Reference) must be provided
...
Check that $.code or $.code_reference provided in request
in case of error - return 422 ('One of $.code and $.code_reference is required')
...
Reason reference
Validate value in the field $.detail.reason_reference, if submitted
Check that value is an array with references of condition, observation, diagnostic report, clinical impression types.
in case of error - return 422 ('Only one of $.code and $.code_reference is allowed')
If $.code provided:
- Check that value is in allowed active values from
device_definition_classification_typedictionary.value is not allowed in enum')
Check that each reference:
is valid ME
belongs to the patient ($.subject)
in case of error - return 422 ('
<medical event type> with such ID is not
found')
If $.detail.reason_reference=clinical_impression:
Check that
device_definitions.is_active = trueclinical impression is valid based on clinical_impression.code.coding.code and CLINICAL_IMPRESSION_PATIENT_CATEGORIES_<CODE.CODING.CODE>_VALIDITY_PERIOD chart parameter: difference between now() and $.clinical_impression.effective_date_time OR $.clinical_impression.effective_period.end date must be less than a value in chart parameter (pointed in config for a corresponding care plan category) for clinical impression code
in case of error - return 422 ('No active device_definitions with the same type')
...
"Clinical impression with patient category exceeds validity period")
5. Goal
Validate value in the field $.code_reference, Reference on device_definitions resource
...
detail.goal, if submitted
Check that value matches with values in
eHealth/care_plan_activity_goalsdictionaryin case of error - return 422 ('Device definition not foundvalue is not allowed in enum')
...
6.
...
Quantity
Validate value in the field $.detail.quantity, SimpleQuantity type, required.if submitted
Check that $.detail.quantity.system is
device_unitdictionary, requiredin case of error - return 422 ('value is not allowed in enum')
Check that $.quantity.code comply with $.quantity.system, required
in case of error - return 422 ('value is not allowed in enum')
Check that $.quantity.value is integer, required
in case of error - return 422 ('Value should be an integer')
6. Validate encounter
Validate value in the field $.encounter, Reference on encounter resource, required
Validate that entity is not in status "entered_in_error"
in case of error - return 422 ("Entity in status "entered_in_error" can not be referenced")
Validate diagnosis in the encounter is not empty
in case of error - return 422 ("Encounter without diagnosis can not be referenced")
Check that encounter belongs to the patient ($.subject)
in case of error - return 422 ('Encounter with such id is not found')
Check that encounter created in the same legal entity as the requester
in case of error - return 422 ('Encounter was not created at the requester’s legal entity ')
7. Validate authored on
Validate value in the field $.authored_on, datetime type, required
Check current date >= authored_on >= (current date - DEVICE_REQUEST_DELAY_INPUT)
in case of error - return 422 “Authored on date must be in range of <current date> and <current date - DEVICE_REQUEST_DELAY_INPUT>”
Check authored_on comply with the encounter period
check $.authored_on >= $.encounter.period.start and $.authored_on <= $.encounter.period.end
in case of error - return 422 ('Authored on date must be in between of Encounter period start and end')
8. Validate occurrence
Validate value in the field $.occurrence_period, Period type, required.
Check ($.authored_on + DEVICE_REQUEST_EXTENDED_LIMIT_START_DAYS) >= $.occurrence_period.start >= $.authored_on
in case of error - return 422 error ('Start date must be greater than or equal to <authored_on> date, but less than or equal to <authoredOn + DEVICE_REQUEST_EXTENDED_LIMIT_START_DAYS> date')
Check $occurrence_period.end >= $.occurrence_period.start
in case of error - return 422 error ('Occurrence end date must be greater than or equal to start date')
In case based_on passed in request and activity referenced - check that this occurrence period matches with care plan occurrence period:
Get care plan that relates to referenced activity
if care plan activity has detail.scheduled_timing.repeat.bounds_period - validate occurrence within bounds_period
if care plan activity has detail.scheduled_period - validate occurrence within scheduled_period
else - validate occurrence within care_plan.period
in case of error - return 422 error ('Occurrence period of device request must be in range of care plan occurrence period')
9. Validate reason
Validate value in the field $.reason, optional.
Check that reason is an array with References on (condition, diagnostic_report, observation) resource
in case of error - return 422 ('value is not allowed in enum')
Check that each {resource} belongs to the patient ($.subject)
in case of error - return 422 ('{resource} with such id is not found')
Check that status of each {resource} is not "entered_in_error" (for condition verification status should be used)
in case of error - return 422 ("{resource} in status "entered_in_error" can not be referenced")
10. Validate Package unit and quantity
Check there is at least one Device Definition:
which classification_type attribute is equal to $.code, that:
is active
has packaging_unit that matches to $.quantity.code of the Device Request
in case of error - return 422 “Not found any active Device Definition with the same units of measure as pointed in the quantity of the Device Request”
which package quantity compliant with prescribed quantity
Find all active device definitions with the same classification_type (device_definition.classification_type = device_request.code)
Check that there is at least one device definition where remainder of division device_request.quantity / device_definition.packaging_count equal to zero
i. in case there is no such definitions - return 422 “The amount of devices in device request must be divisible to device package quantity“
11. 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:
...
Check the program exists and is active
in case of error - return reject_reason = “Medical program not found”
...
Check the program is of type DEVICE
in case of error - return reject_reason = “Invalid program type”
...
Check request_allowed = true for the program
in case of error - return reject_reason = “It is not allowed to create Device requests for the program”
...
Check there is at least one appropriate participant for a program:
Find program_devices, that:
is active
has device_request_allowed=true
its validity period (start_date and end_date) includes current date
has max_daily_count is null or max_daily_count >= $.quantity.value/(occurence_period.end - occurence_period.start+1)
relates to the Device Definition found at the Validate Device definition step
in case not found - return reject_reason = “No appropriate participants found for this medical program“
Make validation according to medical program settings:
If skip_employee_validation = false (null/absent), then $.requester should be validated:
...
in case is not found - return reject_reason = “Employee type of the requester doesn't allow to create Device Request with the medical program”
...
In case employee type of the requester is SPECIALIST, then additional validations may be performed:
If speciality_types_allowed is set, then check if it contains speciality of the requester (speciality_officio=true):
in case is not found - return reject_reason = "Employee's specialty of the requester doesn't allow to create Device Request with the medical program"
...
In case employee type of the requester is DOCTOR, then additional validations may be performed:
if skip_request_employee_declaration_verify = false (null/absent), then get declaration by employee_id of the requester, person_id and status=ACTIVE
in case is not found - return reject_reason = "Only doctors with an active declaration with the patient can create Device Request with the medical program"
if skip_request_legal_entity_declaration_verify = false (null/absent), then get declaration by requester's legal_entity_id, person_id and status=ACTIVE
in case is not found - return reject_reason = "Only legal entity with an active declaration with the patient can create Device Request with the medical program"
...
If conditions_icd10_am_allowed is set and $.encounter has primary diagnosis code from the eHealth/ICD10_AM/condition_codes dictionary, then check this code is in the conditions_icd10_am_allowed parameter
in case is not found - return reject_reason = "Encounter in the request has no primary diagnosis allowed for the medical program”
...
If conditions_icpc2_allowed is set and $.encounter has primary diagnosis code from the eHealth/ICD10_AM/condition_codes dictionary, then check this code is in the conditions_icpc2_allowed parameter
in case is not found - return reject_reason = "Encounter in the request has no primary diagnosis allowed for the medical program”
...
If skip_treatment_period = false (null/absent), then:
Get all active/completed Device Requests with $.code or $.code_reference (depending on attribute provided in request), $.medical_program_id, $person_id
If such was found, get the Device Request with the latest occurrence_period.end date and check:
its occurrence_period.end less then $.occurrence_period.start from the request
in case of error - return reject_reason = ”It can be only one active / completed Device Request for the same code and patient at the same period of time”
if its occurrence_period.end greater than or equal to current date, then in addition check:
If occurrence_period of found Device Request is greater than or equal to DEVICE_REQUEST_STANDARD_DURATION, then $.authored_on from the request should be greater then (occurrence_period.ended at - DEVICE_REQUEST_MAX_RENEW_DAYS) of the found Device Request
else $.authored_on from the request should be greater then (occurrence_period.ended at - DEVICE_REQUEST_MIN_RENEW_DAYS)
in case of error - return reject_reason = “It's to early to create new Device Request for such code and medical program”
...
If request_max_period_day is set, then check if it is not exceeded by the number of days in the $.occurrence_period of the request
if exceeded - return reject_reason = “Occurrence period length exceeds allowed value for the medical program“
...
if there is parameter device_request_allowed_code_types, then check values in the array:
if it includes
CLASSIFICATION_TYPE- it is allowed to pass $.code in the requestif it includes
DEVICE_DEFINITION- it is allowed to pass $.code_reference in the requestin case of a mismatch between the filled field and the config values - return 422 ("<Device definition/Device classification type> is not allowed to set for this medical program").
...
If care_plan_required = true, then:
Reference to activity in $.based_on is required
in case of error - return reject_reason = “Care plan activity in based_on is required according to medical program settings”
12. Validate priority
Validate value in the field $.priority, string, optional.
Check that value is in allowed active values from
device_request_prioritydictionary.in case of error - return 422 ('value is not allowed in enum')
13. Validate supporting info
Validate values in the field $.supporting_info, array, optional. Validate each value with the following rules:
Validate that referenced resource is one of the following (diagnostic_report, observation, condition, procedure, encounter, episode, device, device_association)
in case of error - return 422 ("Referenced resource in supporting_info is not allowed")
Validate that entity is not in status "entered_in_error"
in case of error - return 422 ("Entity in status "entered_in_error" can not be referenced")
Check that resource belongs to the patient ($.subject)
in case of error - return 422 ('Referenced resource not found')
14. Validate performer
Validate value in the field $.performer, Reference, optional.
Validate that referenced resource is legal_entity and record with such id exists (is_active = true):
in case of error - return 422 ("Legal entity referenced as performer not found")
Validate that entity status is "ACTIVE" or “SUSPENDED“
in case of error - return 422 ("Legal entity referenced as performer is in invalid status")
15. Validate parameter
Validate values in the field $.parameter, array, optional. Validate each value with the following rules:
Check that value from $.parameter.code is in allowed active values from
device_propertiesdictionary.in case of error - return 422 ('value is not allowed in enum')
Check $.parameter.value[x] is one of the following:
value_codeable_concept,value_quantity,value_boolean,value_range,value_stringin case of value[x] is missing - return 422 ('value must be provided')
in case of more than one value[x] provided - return 422 ('only one value is allowed')
in case of value[x] is provided with incorrect type - return 422 ('value type <type> is not allowed')
Service logic
Generate structure for response
...
If general error found at Validate device request section, that doesn’t depend on medical program, then return corresponding error code with error message
...
If general validation passed, then collect array for all programs in payload with status for each (VALID or INVALID) and rejection_reason
...
value is not empty, is fractional, greater than zero
Return 422 schema validation error
Validate $.detail.quantity.system, $.detail.quantity.code and their values in the object $.detail.quantity
If $.detail.kind=medication_request:
Check (by schemata) the $.detail.quantity.system field’s value is MEDICATION_UNIT.
Return 422 ('value is not allowed in enum')
Check the $.detail.quantity.code field’s value equals to dosage.denumerator_unit of one of INNMs of a INNM_DOSAGE where innms with is_primary = true
Return 422 ('Code field of quantity object should be equal to denumerator_unit of one of medication’s innms')
If $.detail.kind=service_request:
Check that $.detail.quantity.system field’s value is SERVICE_UNIT, if submitted.
Return 422 ('value is not allowed in enum')
If care plan category is class_23, class_24 or class_25:
Check $.detail.quantity.system and $.detail.quantity.code are set, $.detail.quantity.code = MINUTE
Return 422 ('Code field of quantity object should be in MINUTE for care plan’s category <category code>')
if $.detail.kind=device_request:
Check $.detail.quantity.value is not empty, is integer, greater than zero
Return 422 schema validation error
Check the $.detail.quantity.system is
device_unitdictionary.Return 422 ('value is not allowed in enum')
Check that $.detail.quantity.code matches to active values from $.detail.quantity.system.
Return 422 ('value is not allowed in enum')
Validate Device Definitions in case $.detail.product_codeable_concept and $.detail.program was set:
Find all active Device Definitions with packaging_unit that matches to $.detail.quantity.code
For retrieved Device Definitions define minimum value of packaging_count as min_packaging_count
Check the remainder of division $.detail.quantity.value / min_packaging_count that is equal to zero
Return 422 ('Not found any appropriate Device Definition with the same units of measure and minimum packaging count that is multiple of Activity quantity')
Validate Device Definition in case $.detail.product_reference was set:
Get Device Definition in the $.detail.product_reference (depends on what was set)
Check it has packaging_unit that matches to $.quantity.code of the Activity
Return 422 ('Device Definition must have the same units of measure as pointed in the quantity of the Activity')
Check the remainder of division $.detail.quantity.value / device_definition.packaging_count is equal to zero
Return 422 ('The amount of devices in device request must be divisible to device package quantity')
7. Scheduled
If submitted, validate there is one of the $.detail.scheduled_[x] field: scheduled_timing, scheduled_period or scheduled_string.
Return 422 ('Only one of the parameters must be present') in case more then one submitted
Validate value in scheduled_timing, if submitted:
Validate value with schema of Timing typein case of error - return 422 schema validation error
If submitted, check values of the event within $.CarePlan.Period valuein case of error - return 422 ('event is not within care plan period range')
If submitted, check bounds_period within $.CarePlan.Period valuein case of bounds_period.end validation error - return 422 ('Period end time must be within care plan period range, after period start date')in case of bounds_period.start validation error - return 422 ('Period start time must be within care plan period range')
If submitted, check bounds_duration within $.CarePlan.Period value. Calculate bounds start date as care plan period start date if activity creates before care plan has started, else if activity creates during care plan performing - bound start date calculates as activity creation date. Bounds end date as bounds start date plus count of days specified in bounds_duration.If comparator field in bounds_duration - use it to compare bounds_duration value and care plan duration (possible values >, >=, =, <=, <)in case of error - return 422 ('Bounds duration must be within care plan period range')
If submitted, check when field values are in EVENT_TIMING dictionaryin case of error - return 422 ('value is not allowed in enum')
If submitted, check bounds_range within $.CarePlan.Period value: calculate bounds start - end date for bounds_range.low and bounds_range.high as described for bounds_duration (but w/o comparator field). Also, validate low.code = high.code, high.value > low.valuein case bounds_range.low validation error - return 422 ('low must be within care plan period range, less than high, have the same code as high')in case bounds_range.high validation error - return 422 ('high must be within care plan period range')
if submitted, check day_of_week field values are in DAYS_OF_WEEK dictionaryin case of error - return 422 ('value is not allowed in enum')
if submitted, check time_of_day match regex ^([01][0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)(\.[0-9]+)?$in case of error - return 422 ('string does not match pattern')
As this method always requires medical programs on its input, so scheduled_period required also:
Validate value with schema of the Period type
in case of error - return 422 schema validation error
Validate $.scheduled_period.end is present:
in case it isn’t submitted - return 422 ('can't be blank')
Check values within $.CarePlan.Period
in case period.end validation error - return 422 ('Period end time must be within care plan period range, after period start date')
in case period.start validation error - return 422 ('Period start time must be within care plan period range')
8. Location
Validate value in the field $.detail.location, if submitted
Check the value is valid reference on division resource
Check the division is active and division’s legal entity has active status
Return 422 ('Division is not active')
9. Performer
Validate value in the field $.detail.performer, if submitted
Check the value is valid reference o employee resource
Check employee is active and approved
Return 422 ('Invalid employee status')
10. Daily amount
If submitted, check $.detail.daily_amount has the same code and system as quantity field.
Return 422 ('Units of daily_amount field should be equal to units of quantity field')
11. Do not perform flag
Validate value in the field $.do_not_perform
Check it is
falsein case of error - return 422 ('not allowed in enum')
12. Status
Validate value in the field $.status
Check it has value = scheduled
in case of error - return 422 ('value is not allowed in enum')
Validate programs
Validate value in the field $.programs
Сheck program exists and active
in case not found or is_active==false return 422 'Program not found'
Validate product is program participant:
If product is medication - validate:
that medication has brand that is an active member of the program (program_medications table)
in case not found or is_active==false return 200 with
status= INVALID andrejection_reason"Medication is not included in the program"
that care_plan_activity_allowed for program medication == true
in case ==false return 422 "Forbidden to create care plan activity for this medication!"
If product is service - validate that service is an active member of the program
in case not found or is_active==false return 200 with
status= INVALID andrejection_reason"Service is not included in the program"
if product is service_group - validate that service group is an active member of the program
in case not found or is_active==false return 200 with
status= INVALID andrejection_reason"Service group is not included in the program"
If product is code from
device_definition_classification_typedictionary (product_codeable_concept was set) or product is device_definition (product_reference was set):Find all active program devices with care_plan_activity_allowed == true and period (start_date and end_date) that includes current date, and related to the Device Definitions that has successfully passed Quantity and Product validations before
in case not found return 422 ('No appropriate participants found for this medical program')
For retrieved program devices define maximum value of max_daily_count as max_of_max_daily_count.
Check max_of_max_daily_count >= $.quantity.value/($.detail.scheduled_period.end - $.detail.scheduled_period.start + 1). Count scheduled_period length in days, without taking into account time
in case of error return 422 ('Activity quantity exceeds the allowed maximum daily count of defined program devices for the treatment period')
Validate medical program settings (prm.medical_programs table):
if there is a parameter speciality_types_allowed:
Check author’s speciality is present in speciality_types_allowed
in case of error - return return 200 with
status= INVALID andrejection_reason“Author’s specialty doesn't allow to create activity with medical program from request”
if there is a parameter conditions_icd10_am_allowed or/and conditions_icpc2_allowed:
Check related Care plan has condition codes in
addressesfield that correspond to codes pointed in conditions_icd10_am_allowed or/and conditions_icpc2_allowed (depending on dictionary - eHealth/ICD10_AM/condition_codes or eHealth/ICPC2/condition_codes)in case of error - return 200 with
status= INVALID andrejection_reason“Care plan diagnosis is not allowed for the medical program“
If there is a parameter providing_conditions_allowed:
Check related Care plan has a value in
terms_of_servicefield that is included in the list of providing_conditions_allowed parameterin case of error - return 200 with
status= INVALID andrejection_reason“Care plan’s terms of service are not allowed for the medical program“
if there is a parameter patient_categories_allowed:
check that patient_categories_allowed has codes in $.detail.reason_reference.[].clinical_impression.code.[].codethat correspond to codes pointed in patient_categories_allowed
in case of error return 200 with
status= INVALID withrejection_reason("Clinical impression with patient category should be present in request for this medical program")
if there is parameter device_request_allowed_code_types and activity kind=device_request, then check values in the array of values:
if it includes
CLASSIFICATION_TYPE- it is allowed to set $.detail.product_codeable_concept in the activityif it includes
DEVICE_DEFINITION- it is allowed to set $.detail.product_reference in the activityin case of a mismatch between the filled field and the config values - return 422 ("<Device definition/Device classification type> is not allowed to set for this medical program").
If program meets the requirements write status "VALID" according to apiary.
Service logic
Render response with prequalification result in order to define whether the medical program could be applied in this particular case or not