ЕСОЗ - публічна документація

Create Care Plan Activity

Owned by Oleg Brizhatiy
Last updated: Oct 31, 2024 by Oksana Demchenko
20 min read

Purpose

This WS allows to add activity to the specified Care plan.

Процеси роботи з планом лікування (care plan) | Створення первинного призначення плану лікування

Specification

Link

https://medicaleventsmisapi.docs.apiary.io/#reference/care-plan/create-care-plan-activity/create-care-plan-activity

Resource

/api/patients/{{patient_id}}/care_plans/{{care_plan_id}}/activities

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

Async

Public/Private/Internal

Public

 

Logic

This method adds activity to an existing patient's Care Plan. Method receives signed message (pkcs7) that consists of signed content, digital signature and signer public key. All signature fields will be validated (including signer certificate authority). Service will store signed copy of Care Plan activity in Media Content Storage if all checks is passed.

It can be processed in both sync and async methods depends on Server decision.

Key points

  1. One request can add only one activity to the Care plan

  2. Activity can be added by the employee who has Approval granted by the patient on write Care plan resource

  3. Activity adds in async way. The result of the activity addition job should be link on the created activity (look at Get Care plan activity by ID).

  4. Activity should be signed with DS. Signed content stores in the media storage.

Global and configurable parameters

Care Plan dictionaries and configurable parameters_UA | Конфігураційні параметри

https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/583402009/Medical+Events+Dictionaries+and+configurations#ME_ALLOWED_TRANSACTIONS_LE_TYPES

Input parameters

Input parameter

Values

Type

Description

Example

Input parameter

Values

Type

Description

Example

patient_id

 

String

MPI identifier of the person.

Required

7c3da506-804d-4550-8993-bf17f9ee0402

care_plan_id

 

String

Unique Care Plan identifier.

Required

7c3da506-804d-4550-8993-bf17f9ee0403

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

eHealth/activity_remaining_quantity_types

Request structure

See on Apiary

Example:

{ "signed_data": "ew0KICAicGVyaW9kIjogew0KIC..." }

 

Authorize

  1. Verify the validity of access token

    • Return (401, 'Invalid access token') in case of validation fails

  2. Verify that token is not expired

    • in case of error - return (401, 'Invalid access token')

  3. Check user scopes in order to perform this action (scope = '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)

  4. 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 {{access_token}}
API-key:{{mis_client_secret}}

Request data validation

Validate legal entity

  1. Extract client_id from token

  2. Check legal entity status is ACTIVE

    1. In case of error - return 409 ('client_id refers to legal entity that is not active')

  3. Check legal entity type in ME_ALLOWED_TRANSACTIONS_LE_TYPES config parameter

    1. 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

  1. Get Care plan identifier from the URL

  2. Check Care plan:

    1. belongs to patient (from url)

      1. in case of error - return 422 ('Care plan with such id is not found')

    2. is not in final status

      1. in case of error - return 422 ('Invalid care plan status')

    3. Care plan’s period.end >= current date.

      1. in case of error - return 422 ('Care Plan end date is expired')

Validate Patient

  1. Get person_id from URL

  2. Validate patient status is active

    1. in case of error - return 409 ('Person is not active')

  3. If patient is a person - validate patient's verification_status is not equal to NOT_VERIFIED.

    1. in case NOT_VERIFIED - return error 409, "Patient is not verified"

Validate User

  1. Extract user_id from token.

  2. Check user has an active and approved employee from legal entity (token) that:

    1. has an active Approval granted by the Patient on write the Care plan resource (care plan id from URL)

      1. Return 403 ('Access denied') in case employee has no Approval on write

  3. Check user's employee is from the same legal entity (token) as managing_organisation from the care_plan:

    1. 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 Digital Sign

  1. Validate request is signed

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

  2. Check DS is valid and not expired

  3. Validate that DS belongs to the author of the activity

    1. Check that DRFO from DS and user's party.tax_id matches

      1. in case of error - return 409 (“Signer DRFO doesn't match with requester tax_id“)

Validate activity

Activity should be validated. User fills following fields in the activity:

Validate activity identifier

Validate value in the field $.id, required

  1. Check it is unique within Care plan and has UUID format

    1. Return 422 ("Activity with such id already exists")

Validate care plan identifier

As care plan identifier should be contained in signed content, $.care_plan required in the request body.

  1. Check value matches with care plan identifier from URL

    1. 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

  1. Check employee belongs to the user and legal entity (from token)

  2. Employee is:

    1. an employee who has active Approval on write the Care plan

    2. belongs to user

      1. in case of error - return 422 ('User is not allowed to create care plan activity for the employee')

  3. Check employee_type is value from list of employee_types in configuration: ACTIVITY_AUTHOR_EMPLOYEE_TYPES_ALLOWED

    • in case of error - return 422 ('Invalid employee type')

Validate activity detail

1. Kind

Validate value in the field $.detail.kind, required

  1. Check value in enum: medication_request, service_request

    1. Return 422 ('value is not allowed in enum')

2. 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

  1. If $detail.kind=medication_request:

    1. 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')

    2. Check the value is valid reference on medication resource.

      1. Return 422 ('Cannot refer to <resource>for kind = medication_request')

    3. Check medication:

      1. is active

        1. in case of error - return 422 ('Medication should be active')

    4. type is INNM_DOSAGE

      1. in case of error - return 422 ('Medication does not exist')

    5. Check there is no duplicated activities (status=scheduled, in_progress) with the same medication in the Care plan

      1. Return 422 (“Another activity with status ‘scheduled' or ‘in_progress' already exists in the current Care plan”)

  2. If $.detail.kind=service_request:

    1. 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')

    2. Check that value is a reference on service or service_group

      1. Return 422 ('Cannot refer to <resource> for kind = service_request')

    3. Check service or service_group is active

      1. Return 422 ('<Service/Service group> should be active')

  3. If $.detail.kind=device_request:

    • Validate product_reference:

      • Check there is no activities (status=scheduled, in_progress) with the same service or service_group in the Care plan

      • 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_type dictionary.

        • Return 422 ('value is not allowed in enum')

    Check there is no another activities (status=scheduled, in_progress) in the Care plan with the same product_reference or product_codeable_concept, and program = $.detail.program (including the equality of program absence/null value)

    • Return 422 (“Another activity with status ‘scheduled' or ‘in_progress' already exists in the current Care plan within current program value“)

3. Reason code

Validate value in the field $.detail.reason_code, if submitted

  1. Check that value matches with values in eHealth/ICD10_AM/condition_codes dictionary

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

4. Reason reference

Validate value in the field $.detail.reason_reference, if submitted

  1. Check that value is an array with references of condition, observation, diagnostic report or clinical impression types.

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

  2. Check that each reference:

    1. is valid ME

    2. belongs to the patient ($.subject)

      1. in case of error - return 422 ('<medical event type> with such ID is not found')

  3. If $.detail.reason_reference=clinical_impression:

    1. 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

      1. in case of error - return 422 ("Clinical impression with patient category exceeds validity period")

    2. 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)

      1. if true - check that clinical impression still corresponds to configured rule

        1. in case of error - return 422 (“Clinical impression with patient category does not correspond to rule engine rule“)

      2. if false - skip rule validation

5. Goal

Validate value in the field $.detail.goal, if submitted

  1. Check that value matches with values in eHealth/care_plan_activity_goals dictionary

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

6. Quantity

Validate value in the field $.detail.quantity, if submitted

  • Check it is submitted if $.detail.kind=device_request and $.detail.program is set

    • Return 422 ('required property quantity was not present')

  1. Check $.detail.quantity.value is not empty, is fractional, greater than zero

    1. Return 422 schema validation error

Validate $.detail.quantity.system, $.detail.quantity.code fields and their values in the object $.detail.quantity

  1. If $.detail.kind=medication_request:

    1. Check (by schemata) the $.detail.quantity.system field’s value is MEDICATION_UNIT.

      1. Return 422 ('value is not allowed in enum')

    2. 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

      1. Return 422 ('Code field of quantity object should be equal to denumerator_unit of one of medication’s innms')

  2. If $.detail.kind is other than medication_request:

    1. Check the $.detail.quantity.system field is not present.

      1. Return 422 ('System field of quantity object is not allowed for kind other than medication_request')

    2. Check the $.detail.quantity.code field is not present.

      1. Return 422 ('Code field of quantity object is not allowed for kind other than medication_request')

  3. If $.detail.kind=service_request:

    1. Check that $.detail.quantity.system field’s value is SERVICE_UNIT, if submitted.

      1. Return 422 ('value is not allowed in enum')

    2. If care plan category is class_23, class_24 or class_25:

      1. Check $.detail.quantity.system and $.detail.quantity.code are set, $.detail.quantity.code = MINUTE

        1. Return 422 ('Code field of quantity object should be in MINUTE for care plan’s category <category code>')

  4. 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_unit dictionary.

      • 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

      • Check that there is at least one device definition where the remainder of division $.detail.quantity.value/packaging_count is equal to zero

        • Return 422 ('Not found any appropriate Device Definition')

    • 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')

  5. Set remaining_quantity.value = $.detail.quantity.value, and use for remaining_quantity.system, remaining_quantity.code, remaining_quantity.unit fields, which were specified in $.detail.quantity object.

7. Scheduled

  1. If submitted, validate there is one of the $.detail.scheduled_[x] field: scheduled_timing, scheduled_period or scheduled_string.

    1. Return 422 ('Only one of the parameters must be present') in case more then one submitted

Validate value in scheduled_timing, if submitted:

  1. Validate value with schema of Timing type

    1. in case of error - return 422 schema validation error

  2. If submitted, check values of the event within $.CarePlan.Period value

    1. in case of error - return 422 ('event is not within care plan period range')

  3. If submitted, check bounds_period within $.CarePlan.Period value

    1. in case of bounds_period.end validation error - return 422 ('Period end time must be within care plan period range, after period start date')

    2. in case of bounds_period.start validation error - return 422 ('Period start time must be within care plan period range')

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

    1. If comparator field in bounds_duration - use it to compare bounds_duration value and care plan duration (possible values >, >=, =, <=, <)

    2. in case of error - return 422 ('Bounds duration must be within care plan period range')

  5. If submitted, check when field values are in EVENT_TIMING dictionary

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

  6. 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.value

    1. in 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')

    2. in case bounds_range.high validation error - return 422 ('high must be within care plan period range')

  7. if submitted, check day_of_week field values are in DAYS_OF_WEEK dictionary

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

  8. 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]+)?$

    1. in case of error - return 422 ('string does not match pattern')

Validate value in scheduled_period. Required if medical program is set.

  1. Validate value with schema of the Period type

    1. in case of error - return 422 schema validation error

  2. Validate $.scheduled_period.end is present:

    • in case it isn’t submitted - return 422 ('can't be blank')

  3. Check values within $.CarePlan.Period

    1. in case period.end validation error - return 422 ('Period end time must be within care plan period range, after period start date')

    2. 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

  1. Check the value is valid reference on division resource

  2. Check the division is active and division’s legal entity has active status

    1. Return 422 ('Division is not active')

9. Performer

Validate value in the field $.detail.performer, if submitted

  1. Check the value is valid reference o employee resource

  2. Check employee is active and approved

    1. Return 422 ('Invalid employee status')

10. Daily amount

  1. If submitted, check $.detail.daily_amount has the same code and system as quantity field.

    1. Return 422 ('Units of daily_amount field should be equal to units of quantity field')

  2. Validate value in the field $.detail.daily_amount, if submitted.

  3. Check activity kind is medication_request

    1. Return 422 ('Field is allowed for medication request activities only') in case kind is not medication_request

  4. Validate $.detail.daily_amount.system, $.detail.daily_amount.code fields and their values in the object $.detail.daily_amount

  5. If $.detail.kind=medication_request:

    1. Check (by schemata) the $.detail.daily_amount.system field’s value is MEDICATION_UNIT.

      1. Return 422 ('value is not allowed in enum')

    2. 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

      1. Return 422 ('Code field of daily_amount object should be equal to denumerator_unit of one of medication’s innms')

  6. If $.detail.kind is other than medication_request:

    1. Check the $.detail.daily_amount.system field is not present.

      1. Return 422 ('System field of daily_amount object is not allowed for kind other than medication_request')

    2. Check the $.detail.daily_amount.code field is not present.

      1. Return 422 ('Code field of daily_amount object is not allowed for kind other than medication_request')

11. Medical program

Validate field exists for kind = medication_request

  1. If $.detail.kind=medication_request, check that $.program is submitted

    1. in case of error - return 422 ("Medical program must be submitted for kind = medication_request")

Validate value in the field $.program, if submitted

  1. Сheck program exists and active

    1. in case not found or is_active==false return 404 "Program not found"

  2. Validate product is program participant:

    1. If product is medication - validate:

      1. that medication has brand that is an active member of the program (program_medications table) or medication itself is an active member of the program

        1. in case not found or is_active==false return 422 "Medication is not included in the program"

      2. that care_plan_activity_allowed for program medication == true

        1. in case ==false return 422 "Forbidden to create care plan activity for this medication!"

    2. If product is service - validate that service is an active member of the program

      1. in case not found or is_active==false return 422 "Service is not included in the program"

    3. if product is service_group - validate that service group is an active member of the program

      1. in case not found or is_active==false return 422 "Service group is not included in the program"

    4. If product is code from device_definition_classification_type dictionary (product_codeable_concept was set) or product is device_definition (product_reference was set):

      • Find all program devices with:

        • is_active=true

        • care_plan_activity_allowed = true

        • period (start_date and end_date) that includes current date

        • 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

        • 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')

  3. Validate medical program settings (prm.medical_programs table):

    1. if there is a parameter SPECIALITY_TYPES_ALLOWED:

      1. Check author’s speciality is present in SPECIALITY_TYPES_ALLOWED

        1. in case of error - return 422 “Author’s specialty doesn't allow to create activity with medical program from request”

    2. if there is a parameter CONDITIONS_ICD10_AM_ALLOWED or/and CONDITIONS_ICPC2_ALLOWED:

      1. 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)

        1. in case of error - return 422 “Care plan diagnosis is not allowed for the medical program“

    3. If there is a parameter PROVIDING_CONDITIONS_ALLOWED:

      1. Check related Care plan has a value in terms_of_service field that is included in the list of PROVIDING_CONDITIONS_ALLOWED parameter

        1. in case of error - return 422 “Care plan’s terms of service are not allowed for the medical program“

    4. if there is a parameter patient_categories_allowed:

      1. check that patient_categories_allowed has codes in $.detail.reason_reference.[].clinical_impression.code.[].code that correspond to codes pointed in patient_categories_allowed

        1. in case of error - return 422 "Clinical impression with patient category should be present in request for this medical program".

    5. 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 activity

      • if it includes DEVICE_DEFINITION - it is allowed to set $.detail.product_reference in the activity

        • in 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").

12. Do not perform flag

Validate value in the field $.do_not_perform

  1. Check it is false

    1. in case of error - return 422 ('not allowed in enum')

13. Status

Validate value in the field $.status

  1. Check it has value = scheduled

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

 

Processing

  1. Save signed content to media storage

  2. Save data to care_plan_activities collection in DB according to Care plan data model

    1. for kind = medication_request

      1. add unit (and its value) field into quantity, daily_amount, objects based on system, code out of MEDICATION_UNIT or SERVICE_UNIT dictionary.

      2. add system, code, unit fields into remaining_quantity based on quantity object

  3. Save link from media storage to the $.signed_content_links field in care plan activities collection

  4. If Care plan has status = new:

    1. Set care plan status = active

    2. Check if patient has another active or/and new Care plans with such condition code in the addresses field and the same terms of service:

      1. If such Care plans found - set these Care plans statuses to TERMINATED (related activities doesn`t change their status)

  5. Set $.details.remaining_quantity_type:

    1. If $.details.kind = medication_request or device_request, then check $.details.quantity:

      1. if $.details.quantity = null then set $.details.remaining_quantity_type = null

      2. if $.details.quantity is not null then:

        1. set $.details.remaining_quantity_type = for_request

    2. If $.details.kind = service_request check $.details.quantity:

      1. if $.details.quantity = null then set $.details.remaining_quantity_type = null

      2. if $.details.quantity is not null then check $.details.quantity.code:

        1. if $.details.quantity.code is not null then set $.details.remaining_quantity_type = for_request

        2. if $.details.quantity.code = null then set $.details.remaining_quantity_type = for_use

  6. Create job and return it’s id.

 

Response structure

See on Apiary

Example:

{ "data": { "id": "75a5d991-0bf7-476f-b3cf-bec73f044b2e", "author": { "identifier": { "type": { "coding": [ { "system": "eHealth/resources", "code": "employee" } ] }, "value": "9183a36b-4d45-4244-9339-63d81cd08d9c" } }, "care_plan": { "identifier": { "type": { "coding": [ { "system": "eHealth/resources", "code": "care_plan" } ] }, "value": "9183a36b-4d45-4244-9339-63d81cd08d9c" } }, "detail": { "kind": "service_request", "product_reference": { "identifier": { "type": { "coding": [ { "system": "eHealth/resources", "code": "service" } ], "text": "" }, "value": "97d57238-ffbe-4335-92ea-28d4de117ea3" } }, "reason_code": [ { "coding": [ { "system": "eHealth/ICD10_AM/condition_codes", "code": "X85" } ] } ], "reason_reference": [ { "identifier": { "type": { "coding": [ { "system": "eHealth/resources", "code": "condition" } ] }, "value": "9183a36b-4d45-4244-9339-63d81cd08d9c" } } ], "goal": [ { "coding": [ { "system": "eHealth/care_plan_activity_goals", "code": "diabetes_treatment" } ] } ], "quantity": { "value": 13, "system": "MEDICATION_UNIT", "code": "MG", "unit": "мг" }, "scheduled_timing": { "event": [ "2018-08-02T10:45:16Z" ], "repeat": { "bounds_duration": { "value": 10, "comparator": ">", "unit": "доба", "system": "eHealth/ucum/units", "code": "day" }, "count": 10, "count_max": 20, "duration": 15, "duration_max": 25, "duration_unit": "day", "frequency": 1, "frequency_max": 4, "period": 1, "period_max": 3, "period_unit": "day", "day_of_week": [ "mon" ], "time_of_day": [ "16:00:00" ], "when": [ "WAKE" ], "offset": 20 }, "code": { "coding": [ { "system": "TIMING_ABBREVIATION", "code": "Q4H" } ] } }, "location": { "identifier": { "type": { "coding": [ { "system": "eHealth/resources", "code": "division" } ] }, "value": "9183a36b-4d45-4244-9339-63d81cd08d9c" } }, "performer": { "identifier": { "type": { "coding": [ { "system": "eHealth/resources", "code": "employee" } ] }, "value": "9183a36b-4d45-4244-9339-63d81cd08d9c" } }, "daily_amount": { "value": 13.5, "system": "MEDICATION_UNIT", "code": "MG", "unit": "мг" }, "description": "Some activity description", "do_not_perform": false, "program": { "identifier": { "type": { "coding": [ { "system": "eHealth/resources", "code": "medical_program" } ] }, "value": "9183a36b-4d45-4244-9339-63d81cd08d9c" } }, "status": "completed", "status_reason": { "coding": [ { "system": "eHealth/care_plan_activity_cancel_reasons", "code": "some code" } ] }, "remaining_quantity": { "value": 12, "system": "MEDICATION_UNIT", "code": "MG", "unit": "мг" } }, "outcome_reference": [ { "identifier": { "type": { "coding": [ { "system": "eHealth/resources", "code": "encounter" } ] }, "value": "9183a36b-4d45-4244-9339-63d81cd08d9c" } } ], "outcome_codeable_concept": [ { "coding": [ { "system": "eHealth/care_plan_activity_outcomes", "code": "some code" } ] } ] }, "meta": { "code": 201, "url": "http://example.com/resource", "type": "object", "request_id": "req-adasdoijasdojsda" } }

 

{ "data": { "status": "pending", "eta": "2018-08-02T10:45:16.000Z", "links": [ { "entity": "job", "href": "/Jobs/NBXk9EyErUZv1RhXgyvgg" } ] }, "meta": { "code": 202, "url": "http://example.com/resource", "type": "object", "request_id": "req-adasdoijasdojsda" } }

HTTP status codes

HTTP status code

Message

What caused the error

HTTP status code

Message

What caused the error

201

Response

 Sync. Use payload from response

202

Response

 Async: default method. use Get job details to get processing result. Response payload will be returned in the job details

401

Invalid access token

  • validation fails

  • token is expired

403

  • Your scope does not allow to access this resource. Missing allowances: care_plan:write

  • Access denied

  • invalid scope(s)

409

  • client_id refers to legal entity that is not active

  • client_id refers to legal entity with type that is not allowed to create medical events transactions

  • Person is not active

  • Patient is not verified

  • Signer DRFO doesn't match with requester tax_id

  • Care Plan from url does not match to Care Plan ID specified in body

 

422

  • document must be signed by 1 signer but contains 0 signatures

  • Medical program must be submitted for kind = medication_request

  • Activity with such id already exists

  • Care plan with such id is not found

  • Invalid care plan status

  • Care Plan end date is expired

  • User is not allowed to create care plan activity for the employee

  • Value is not allowed in enum

  • Cannot refer to service for kind = medication_request

  • Medication should be active

  • Medication does not exist

  • Another activity with status ‘scheduled' or ‘in_progress' already exists in the current Care plan

  • Cannot refer to medication for kind = service_request

  • <Service/Service group> should be active

  • Another activity with status ‘scheduled' or ‘in_progress' already exists in the current Care plan

  • <medical event type> with such ID is not found

  • Clinical impression with patient category does not correspond to rule engine rule

  • Code field of quantity object should be equal to denumerator_unit of one of medication’s innms

  • System field of quantity object is not allowed for kind other than medication_request

  • Code field of quantity object is not allowed for kind other than medication_request

  • Only one of the parameters must be present

  • Event is not within care plan period range

  • Period end time must be within care plan period range, after period start date

  • Period start time must be within care plan period range

  • Bounds duration must be within care plan period range

  • Low must be within care plan period range, less than high, have the same code as high

  • High must be within care plan period range

  • String does not match pattern

  • Division is not active

  • Invalid employee status

  • Field is allowed for medication request activities only

  • Code field of daily_amount object should be equal to denumerator_unit of one of medication’s innms

  • System field of daily_amount object is not allowed for kind other than medication_request

  • Code field of daily_amount object is not allowed for kind other than medication_request

  • Program not found

  • Forbidden to create care plan activity for this medication!

  • Clinical impression with patient category exceeds validity period

  • Medication is not included in the program

  • Service is not included in the program

  • Service group is not included in the program

  • Author’s specialty doesn't allow to create activity with medical program from request

  • Care plan diagnosis is not allowed for the medical program

  • Care plan’s terms of service are not allowed for the medical program

  • Clinical impression with patient category should be present in request for this medical program

  • User is not allowed to create care plan activity for this care plan

  • Code field of quantity object should be in MINUTE for care plan’s category <category code>

  • Units of daily_amount field should be equal to units of quantity field

Validation error

 

 

ЕСОЗ - публічна документація