ЕСОЗ - публічна документація
RC_REHAB_Prequalify Care Plan Activity+
- 1 Purpose
- 2 Specification
- 3 Logic
- 3.1 Key points
- 4 Global and configurable parameters
- 5 Input parameters
- 6 Filters
- 7 Dictionaries
- 8 Request structure
- 9 Authorize
- 10 Headers
- 11 Request data validation
- 11.1 Validate legal entity
- 11.2 Validate Care plan
- 11.3 Validate Patient
- 11.4 Validate User
- 11.5 Validate activity
- 11.5.1 Validate care plan identifier
- 11.5.2 Validate activity author
- 11.5.3 Validate activity detail
- 11.6 Validate programs
- 12 Processing
- 13 Response structure
- 14 Post-processing processes
- 15 HTTP status codes
Purpose
This WS allows prequalifying care plan activity in order to define whether the medical program could be applied in this particular case or not.
Процеси роботи з планом лікування (care plan) | Створення первинного призначення плану лікування
Specification
Link | |
Resource | /api/patients/{{patient_id}}/care_plans/{{care_plan_id}}/activities/prequalify |
Scope | care_plan:write |
Components | Care plan |
Microservices | me/api-medical-events me/event-consumer me/kafka-consumer il/api(rpc) |
Protocol type | REST |
Request type | POST |
Sync/Async | Sync |
Public/Private/Internal | Public |
Logic
Render response with prequalification result in order to define whether the medical program could be applied in this particular case or not.
Key points
Activity can be prequalified by the employee who has Approval granted by the patient on write Care plan resource
Activity shouldn’t be signed with DS
Global and configurable parameters
Care Plan dictionaries and configurable parameters_UA | Конфігураційні параметри
Medical Events Dictionaries and configurations | ME_ALLOWED_TRANSACTIONS_LE_TYPES
Input parameters
Input parameter | Values | Type | Description | Example |
---|---|---|---|---|
patient_id |
| String | Unique patient identifier. Required |
|
care_plan_id |
| String | Unique Care Plan identifier. Required |
|
Filters
No
Dictionaries
eHealth/care_plan_activity_outcomes
eHealth/ICPC2/condition_codes
eHealth/ICD10_AM/condition_codes
eHealth/care_plan_activity_goals
eHealth/care_plan_activity_cancel_reasons
eHealth/care_plan_activity_complete_reasons
eHealth/ucum/units
MEDICATION_UNIT
DAYS_OF_WEEK
EVENT_TIMING
SPECIALITY_TYPES_ALLOWED
PROVIDING_CONDITIONS_ALLOWED
INNM_DOSAGE
Request structure
See on Apiary
Example:
Authorize
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)
Headers
Наприклад:
Content-Type:application/json
Authorization:Bearer {{access_token}}
API-key:{{mis_client_secret}}
Request data validation
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's verification_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 ('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
Return 422 ('value is not allowed in enum')
2. Product
Validate value in the field $.detail.product_reference, required
If $detail.kind=medication_request:
Check the value is valid reference on medication resource.
Return 422 ('Cannot refer to service for kind = medication_request')
Check medication:
is active
in case of error - return 422 ('Medication should be active')
type is INNM_DOSAGE
in case of error - return 422 ('Medication does not exist')
Check there is no duplicated activities (status=scheduled, in_progress) with the same medication in the Care plan
Return 422 (“Another activity with status ‘scheduled' or ‘in_progress' already exists in the current Care plan”)
If $.detail.kind=service_request:
Check that value is a reference on service or service_group
Return 422 ('Cannot refer to medication for kind = service_request')
Check service or service_group is active
Return 422 ('<Service/Service group> should be active')
Check there is no activities (status=scheduled, in_progress) with the same service or service_group 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_codes
dictionaryin case of error - return 422 ('value is not allowed in enum')
4. 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 ('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 clinical impression is valid based on clinical_impression.code.coding.code and CLINICAL_IMPRESSION_PATIENT_CATEGORIES_<CODE.VALUE>_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 ("Clinical impression with patient category exceeds validity period")
Check that clinical impression is based on active rule engine rule (exists record in rule_engine_rules collection with is_active=true, code.code=clinical_impression.code.coding.code, code.system=clinical_impression.code.coding.system)
if true - check that clinical impression still corresponds to configured rule
in case of error - return 422 (“Clinical impression with patient category does not correspond to rule engine rule“)
if false - skip rule validation
5. Goal
Validate value in the field $.detail.goal, if submitted
Check that value matches with values in
eHealth/care_plan_activity_goals
dictionaryin case of error - return 422 ('value is not allowed in enum')
6. Quantity
Validate value in the field $.detail.quantity, if submitted
Check $.detail.quantity.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 is other than medication_request:
Check the $.detail.quantity.system field is not present.
Return 422 ('System field of quantity object is not allowed for kind other than medication_request')
Check the $.detail.quantity.code field is not present.
Return 422 ('Code field of quantity object is not allowed for kind other than medication_request')
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>')
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 type
in 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 inEVENT_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 inDAYS_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')
Validate value in scheduled_period, if submitted:
Validate value with schema of the Period type
in case of error - return 422 schema validation error
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')
Validate value in the field $.detail.daily_amount, if submitted.
Check activity kind is medication_request
Return 422 ('Field is allowed for medication request activities only') in case kind is not medication_request
Validate $.detail.daily_amount.system, $.detail.daily_amount.code fields and their values in the object $.detail.daily_amount
If $.detail.kind=medication_request:
Check (by schemata) the $.detail.daily_amount.system field’s value is MEDICATION_UNIT.
Return 422 ('value is not allowed in enum')
Check the $.detail.daily_amount.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 daily_amount object should be equal to denumerator_unit of one of medication’s innms')
If $.detail.kind is other than medication_request:
Check the $.detail.daily_amount.system field is not present.
Return 422 ('System field of daily_amount object is not allowed for kind other than medication_request')
Check the $.detail.daily_amount.code field is not present.
Return 422 ('Code field of daily_amount object is not allowed for kind other than medication_request')
11. Do not perform flag
Validate value in the field $.do_not_perform
Check it is
false
in 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"
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 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
addresses
field 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_service
field 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.[].code that 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 program meets the requirements write status "VALID" according to apiary.
Processing
See Logic
Response structure
See on Apiary
Example:
Post-processing processes
API paragraph not found
HTTP status codes
HTTP status code | Message | What caused the error |
---|---|---|
200 |
| Programs validation error |
401 | Invalid access token |
|
403 |
|
|
409 |
| Validation error |
422 |
| Validation error |
ЕСОЗ - публічна документація