Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

...

Page Properties
idAPI_Specification

Link

https://ehealthmedicaleventsapi.docs.apiary.io/#reference/device-requests/prequalify-device-request/prequalify-device-request

Посилання на Apiary або Swagger

Resource

/api/patients/{{patient_id}}/device_requests/prequalify

Посилання на ресурс, наприклад: /api/persons/create

Scope

device_request:write

Scope для доступу

Components

Devices

Зазначається перелік бізнес компонентів, які використовують цей метод, наприклад: ePrescription

Microservices

Перелік мікросервісів, які використовує метод API, наприклад: Auth, ABAC

Protocol type

REST

Тип протоколу, який використовується запитом, наприклад: SOAP | REST

Request type

POST

Тип запиту API, наприклад: GET, POST, PATCH…

Sync/Async

Sync

Метод є синхронним чи асинхронним?

Public/Private/Internal

Public

Потрібно зазначити тип методу за ступенем доступності

Logic

Generate structure for response

  1. If general error found at Validate device request section, that doesn’t depend on medical program, then return corresponding error code with error message

  2. If general validation passed, then collect array for all programs in payload with status for each (VALID or INVALID) and rejection_reason

  3. Generate response according to specification

Input parameters

Input parameter

Values

Type

Description

Example

patient_id

String

Unique patient identifier

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

Request structure

See on Apiary

...

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

  • Validate person'sverification_status is not equal to NOT_VERIFIED.

    • in case NOT_VERIFIED - return error 409 ("Patient is not verified")

  • Validate person is not a preperson

    • in case of error return 409 ('Forbidden to create device request for a preperson')

Validate request

Validate request using schema. Return 422 with the list of validation errors in case validation fails. In addition, check following:

...

Validate each medical program in the $.programs array:

  • Check the program exists , is of type DEVICE, 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)

      • 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 /wiki/spaces/CSI/pages/17467605147:

    • If skip_employee_validation = false (null/absent), then $.requester should be validated:

      • If employee_types_to_create_request parameteris set, then check if it contains employee type of the requester

        • 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, $.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_DAY) of the found Device Request

          • else $.authored_on from the request should be greater then (occurrence_period.ended at - DEVICE_REQUEST_MIN_RENEW_DAY)

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

...