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

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Required parameters are marked with "*"

Якщо інформації по відповідному параметру немає, потрібно зазначити: “API paragraph not found”.

Purpose*

This method is used to pre-qualify care plan activity in order to define whether the medical program could be applied in this particular case or not.

Specification*

Link

https://ehealthmedicaleventsapi.docs.apiary.io/#reference/care-plan/prequalify-care-plan-activity/prequalify-care-plan-activity

Resource

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

Scope

care_plan:write

Components

Care plan

Microservices

API paragraph not found

Protocol type

REST

Request type

POST

Sync/Async

Async

Public/Private/Internal

Public

Logic*

This method is used to pre-qualify care plan activity in order to define whether the medical program could be applied in this particular case or not.

Key points

  1. Activity can be prequalify by the employee who has an Approval granted by the patient on write Care plan resource

  2. Activity shouldn’t be signed with DS

Input parameters

Input parameter

Values

Type

Description

Example

patient_id

String

Unique patient identifier

7075e0e2-6b57-47fd-aff7-324806efa7e5

re_plan_id

String

Unique Care Plan identifier

7c3da506-804d-4550-8993-bf17f9ee0403

Request structure*

See on Apiary

Example:

 Response example
{
  "activity": {
    "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"
      },
      "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"
      },
      "description": "Some activity description",
      "do_not_perform": false,
      "status": "scheduled"
    }
  },
  "programs": [
    {
      "identifier": {
        "type": {
          "coding": [
            {
              "system": "eHealth/resources",
              "code": "medical_program"
            }
          ]
        },
        "value": "9183a36b-4d45-4244-9339-63d81cd08d9c"
      }
    }
  ]
}

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)

Request to process the request using a token in the headers

Headers*

Наприклад:

  • Content-Type:application/json

  • Authorization:Bearer mF_9.B5f-4.1JqM

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

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 dictionary

    • 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

  • 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.CODING.CODE>_VALIDITY_PERIOD chart parameter: difference between now() and clinical_impression.inserted_at 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")

5. Goal

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

  • Check that value matches with values in eHealth/care_plan_activity_goals dictionary

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

6. Quantity

Validate value in the field $.quantity, if submitted

  • Check $.quantity.value is not empty, is integer, greater than zero

    • Return 422 schema validation error

  • Set remaining_quantity.value = $.quantity.value

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 value

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

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

    • in 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 dictionary

    • in 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.value

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

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

    • in 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

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

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 200 with status = INVALID and rejection_reason "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 and rejection_reason "Medication is not included in the program"

    • 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 and rejection_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 and rejection_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 return 200 with status = INVALID and rejection_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 and rejection_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 parameter

        • in case of error - return 200 with status = INVALID and rejection_reason “Care plan’s terms of service are not allowed for the medical program“

    • if there is a parameter patient_categories_allowed:

      • check if patient_categories_allowed is not null then $.detail.reason_reference should contain a reference on clinical_impression with patient category

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

        • in case of error return 200 with status = INVALID with rejection_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*

  1. Render response with prequalification result in order to define whether the medical program could be applied in this particular case or not

Response structure*

See on Apiary

Example:

 Response example
{
  "meta": {
    "code": 200,
    "url": "http://example.com/resource",
    "type": "object",
    "request_id": "req-adasdoijasdojsda"
  },
  "data": [
    {
      "program_id": "59781de0-2e64-4359-b716-bcc05a32c10f",
      "program_name": "Fee-For-Service",
      "status": "INVALID",
      "rejection_reason": "Service is not included in the program"
    }
  ],
  "urgent": {
    "authentication_method_current": {
      "type": "OTP",
      "number": "+38093*****85"
    }
  }
}

 Response example
{
  "meta": {
    "code": "422",
    "url": "http://example.com/resource",
    "type": "object",
    "request_id": "req-adasdoijasdojsda"
  },
  "error": {
    "type": "unverified",
    "message": "Patient is not active"
  }
}

Post-processing processes*

API paragraph not found

HTTP status codes*

HTTP status code

Message

What caused the error

 200

 

 

 422

 

 

  • No labels