Versions Compared

Key

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

...

Page Properties

Link

https://uaehealthapi.docs.apiary.io/#reference/public.-reimbursement/medication-request-requests/create-medication-request-request

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

Resource

/api/medication_request_requests

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

Scope

medication_request_request:write

Зазначається потрібний scopeScope для доступу

Components

ePrescription

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

Microservices

Немає даних

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

Protocol type

REST

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

Request type

POST

Тип HTTP методу, який використовується запитомзапиту API, наприклад: GET, POST | GET…, PATCH…

Sync/Async

Sync

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

Логіка

...

Технічний опис бізнес-процесу виписування рецепту в ЕСОЗ (загальний процес для усіх рецептурних ЛЗ, в т.ч. і тих, які підлягають реімбурсації)

Процеси роботи з випискою електронних рецептів

Передумови

Немає даних

Глобальні та конфігураційні параметри

...

  1. Лише автентифіковані та авторизовані користувачі з відповідним скоупом можуть створювати запит на лікування (MRR)

  2. Пацієнт повинен зберігатися в хешованому вигляді відповідно до вимог безпеки.

Вхідні параметри

НемаєATTRIBUTES - see on Apiary

Фільтри

Немає

Структура запиту

Дивись на Apiary

Приклад:

Expand
Code Block
{
  "medication_request_request": {
    "person_id": "585044f5-1272-4bca-8d41-8440eefe7d26",
    "employee_id": "d290f1ee-6c54-4b01-90e6-d701748f0851",
    "division_id": "881d6dee-dd3d-43f3-8983-922354c0e6ce",
    "created_at": "2017-08-17",
    "started_at": "2017-08-17",
    "ended_at": "2017-09-16",
    "medication_id": "1349a693-4db1-4a3f-9ac6-8c2f9e541982",
    "medication_qty": 10.34,
    "medical_program_id": "59781de0-2e64-4359-b716-bcc05a32c10f",
    "intent": "plan",
    "category": "community",
    "based_on": [
      {
        "identifier": {
          "type": {
            "coding": [
              {
                "system": "eHealth/resources",
                "code": "care_plan"
              }
            ]
          },
          "value": "9183a36b-4d45-4244-9339-63d81cd08d9c"
        }
      },
      {
        "identifier": {
          "type": {
            "coding": [
              {
                "system": "eHealth/resources",
                "code": "activity"
              }
            ]
          },
          "value": "9183a36b-4d45-4244-9339-63d81cd08d9c"
        }
      }
    ],
    "context": {
      "identifier": {
        "type": {
          "coding": [
            {
              "system": "eHealth/resources",
              "code": "encounter"
            }
          ]
        },
        "value": "9183a36b-4d45-4244-9339-63d81cd08d9c"
      }
    },
    "dosage_instruction": [
      {
        "sequence": 1,
        "text": "0.25mg PO every 6-12 hours as needed for menses from Jan 15-20, 2015.  Do not exceed more than 4mg per day",
        "additional_instruction": [
          {
            "coding": [
              {
                "system": "eHealth/SNOMED/additional_dosage_instructions",
                "code": "311504000"
              }
            ]
          }
        ],
        "patient_instruction": "0.25mg PO every 6-12 hours as needed for menses from Jan 15-20, 2015.  Do not exceed more than 4mg per day",
        "timing": {
          "event": [
            "2017-04-20T19:14:13Z"
          ],
          "repeat": {
            "bounds_duration": {
              "value": 10,
              "unit": "days",
              "system": "eHealth/ucum/units",
              "code": "d"
            },
            "count": 2,
            "count_max": 4,
            "duration": 4,
            "duration_max": 6,
            "duration_unit": "d",
            "frequency": 1,
            "frequency_max": 2,
            "period": 4,
            "period_max": 6,
            "period_unit": "d",
            "day_of_week": [
              "mon"
            ],
            "time_of_day": [
              "2017-04-20T19:14:13Z"
            ],
            "when": [
              "WAKE"
            ],
            "offset": 4
          },
          "code": {
            "coding": [
              {
                "system": "TIMING_ABBREVIATIONS",
                "code": "patient"
              }
            ]
          }
        },
        "as_needed_boolean": true,
        "site": {
          "coding": [
            {
              "system": "eHealth/SNOMED/anatomical_structure_administration_site_codes",
              "code": "344001"
            }
          ]
        },
        "route": {
          "coding": [
            {
              "system": "eHealth/SNOMED/route_codes",
              "code": "46713006"
            }
          ]
        },
        "method": {
          "coding": [
            {
              "system": "eHealth/SNOMED/administration_methods",
              "code": "419747000"
            }
          ]
        },
        "dose_and_rate": {
          "type": {
            "coding": [
              {
                "system": "eHealth/dose_and_rate",
                "code": "'ordered'"
              }
            ]
          },
          "dose_range": {
            "low": {
              "value": 0,
              "unit": "mg",
              "system": "eHealth/ucum/units",
              "code": "mg"
            },
            "high": {
              "value": 0,
              "unit": "mg",
              "system": "eHealth/ucum/units",
              "code": "mg"
            }
          },
          "rate_ratio": {
            "numerator": {
              "value": 0,
              "unit": "mg",
              "system": "eHealth/ucum/units",
              "code": "mg"
            },
            "denominator": {
              "value": 0,
              "unit": "mg",
              "system": "eHealth/ucum/units",
              "code": "mg"
            }
          }
        },
        "max_dose_per_period": {
          "numerator": {
            "value": 0,
            "unit": "mg",
            "system": "eHealth/ucum/units",
            "code": "mg"
          },
          "denominator": {
            "value": 0,
            "unit": "mg",
            "system": "eHealth/ucum/units",
            "code": "mg"
          }
        },
        "max_dose_per_administration": {
          "value": 0,
          "unit": "mg",
          "system": "eHealth/ucum/units",
          "code": "mg"
        },
        "max_dose_per_lifetime": {
          "value": 0,
          "unit": "mg",
          "system": "eHealth/ucum/units",
          "code": "mg"
        }
      }
    ],
    "priority": "routine",
    "prior_prescription": {
      "identifier": {
        "type": {
          "coding": [
            {
              "system": "eHealth/resources",
              "code": "medication_request"
            }
          ]
        },
        "value": "9183a36b-4d45-4244-9339-63d81cd08d9c"
      }
    },
    "container_dosage": {
      "system": "MEDICATION_UNIT",
      "code": "ML",
      "value": 4
    }
  }
}

Авторизація

  1. Перевірити валідність токену доступу

...

    • в разі помилки - повернути 401 (“Invalid access token”) в разі невалідних валідацій

  1. Перевірити, що токен дійсний

    • в разі помилки - повернути 401 (“Invalid access token”)

  2. Перевірити скоупи користувача (scope = 'medication_request_request:write') на можливість виконання даної дії

    • в разі помилки - надіслати у відповіді код 401

Headers

Content-Type:application/json

Authorization:Bearer c2778f3064753ea70de870a53795f5c9

...

  1. Якщо BLOCK_UNVERIFIED_PARTY_USERS є true, тоді перевірити дані співробітника на свіпадіння наступним умовам: verification_status != NOT_VERIFIED або (verification_status = NOT_VERIFIED та updated_at <= current_date - UNVERIFIED_PARTY_PERIOD_DAYS_ALLOWED):

    • в разі неспівпадіння - повернути 403 ("Access denied. Party is not verified")

Headers

Content-Type:application/json

Authorization:Bearer c2778f3064753ea70de870a53795f5c9

Перевірити запит

Перевірити запит використовуючи схему JSON. 

  1. В разі помилки повернути код 422 з повідомленням ("required property %{property} was not present")

Перевірити дані запиту

Перевірити співробітника

Ціль валідації: Перевірити співробітника на можливість створення запиту на рецепт.

...

Забрати employee_id з запиту

Перевірити співробітника

...

На існування

  1. в разі помилки повернути код 422 з повідомленням ("Employee not found")

...

Перевірити, що $.employees.status == APPROVED

  1. в разі помилки повернути код 409 з повідомленням ("Employee is not active")

...

Перевірити, що $.employees.legal_entity_id == client_id from token

  1. в разі помилки повернути код 422 з повідомленням ("Employee does not belong to legal entity from token")

Перевірити, що $.employees.employee_type == <employee_type>

якщо medical_program_id є в запиті перевірити medical_program_settings.skip_employee_validation == false (або відсутня)

перевірити <employee_type>

отримати $.medical_programs.medical_program_setting по medical_program_id з запиту

перевірити, що employee_type наявна в параметрі employee_types_for_create_medication_request

...

в разі помилки повернути код 422 з повідомленням ("Employee type can't create medication request with medical program from request") 

...

якщо employee_type = DOCTOR

  1. отримати $.declarations by employee_id, person_id, status=ACTIVE або перевірити параметр MEDICATION_REQUEST_DECLARATION_VERIFY (який дозволяє створити запит на рецепт для будь-якого лікаря в LE де персона має декларацію)

    1. якщо не знайдено - повернути код 422 (повідомлення: "Employee must have an active declaration with the patient to create medication request!")

...

якщо employee_type = SPECIALIST

  1. отримати $.employees.speciality.speciality(speciality_officio == true)

  2. перевірити, що вказана спеціальність in$.medical_programs.medical_program_setting.speciality_types_allowed variable

    1. в разі помилки повернути код 422 з повідомленням ("Employee's specialty doesn't allow create medication request with medical program from request") 

якщо employee_type = <XXX>

...

Перевірте поле container_dosage

$.container_dosage - об'єм основного контейнера ліків, який вимагається лікарем або видачею запиту на ліки для видачі пацієнту.

  1. Перевірте поле $.container_dosage за допомогою схем

    1. $.container_dosage.code і $.container_dosage.value мають бути заповнені

      1. у разі помилки повертає помилку 422 ("необхідна властивість %{property} відсутня")

    2. $.container_dosage.system має бути «MEDICATION_UNIT»

      1. у разі помилки повертає помилку 422 ("значення не допускається в enum")

    3. якщо $.container_dosage заповнено, то $.container_dosage.unit слід перевірити за допомогою словника MEDICATION_UNIT за допомогою $.container_dosage.code як ключа.

      1. у разі помилки повертає помилку 422 ("значення не допускається в enum")

Перевірити пріоритет

  1. Перевірте за схемами, чи $.priority заповнено значенням словника MEDICATION_REQUEST_PRIORITY

    1. у разі помилки повертає помилку 422 ("значення не допускається в enum")

Перевірити prior_prescription

  1. Переконайтеся, що $.prior_prescription є UUID, існує та належить цій особі:

    1. is_active = true, і та сама особа.

      1. у разі помилки - повернути 422 (повідомлення: "Попередній рецепт не знайдено")

Перевірити співробітника

Ціль валідації: Перевірити співробітника на можливість створення запиту на рецепт.

Перевірити підрозділ

Ціль валідації: Перевірити підрозділ на можливість створення запиту на рецепт.

...

Отримати Get division details

...

Перевірити division_id - division_id існує

  • а разі помилки направити код 422 з повідомленням ("Division not found")

...

  1. Забрати employee_id з запиту

  2. Перевірити співробітника

    1. На існування

      1. в разі помилки повернути код 422 з повідомленням ("Employee not found")

    2. Перевірити, що $.employees.status == APPROVED

      1. в разі помилки повернути код 409 з повідомленням ("Employee is not active")

    3. Перевірити, що $.employees.legal_entity_id == client_id from token

      1. в разі помилки повернути код 422 з повідомленням ("Employee does not belong to legal entity from token")

    4. Перевірити, що $.employees.employee_type == <employee_type>

      1. якщо medical_program_id є в запиті перевірити medical_program_settings.skip_employee_validation == false (або відсутня)

        1. перевірити <employee_type>

          1. отримати $.medical_programs.medical_program_setting по medical_program_id з запиту

            1. перевірити, що employee_type наявна в параметрі employee_types_for_create_medication_request

              1. в разі помилки повернути код 422 з повідомленням ("Employee type can't create medication request with medical program from request") 

...

якщо medical_program_settings.skip_employee_validation == true або відсутня medical_program_id в запиті, будь-який користувач, який має скоуп може створити запит на рецепт

              1. якщо employee_type = DOCTOR

                1. отримати $.declarations by employee_id, person_id, status=ACTIVE або перевірити параметр MEDICATION_REQUEST_DECLARATION_VERIFY (який дозволяє створити запит на рецепт для будь-якого лікаря в LE де персона має декларацію)

                  1. якщо не знайдено - повернути

...

                  1. код 422 (повідомлення: "

...

Перевірити юридичну особу

Ціль перевірки: Перевірити юридичну особу на можливість створенна запиту на рецепт.

  1. Отримати client_id з токену

  2. Перевірити client_id=legal_entity_id

    1. перевірити, що юридична особа існує

      1. в разі помилки повернути код 422 з повідомленням (422 Legal entity not found)

    2. перевірити, що legal_entities.status == ACTIVE

      1. в разі помилки повернути код 422 з повідомленням ("Only active legal entity can provide medication request")

Перевірити персону

...

                  1. Employee must have an active declaration with the patient to create medication request!")

...

Підрозділ повинен бути активним або посилатися на поточну legal_entity

  • is_active = true

  • status = 'ACTIVE'

  • division.legal_entity_id = client_id (context)

              1. якщо employee_type = SPECIALIST

                1. отримати $.employees.speciality.speciality(speciality_officio == true)

                2. перевірити, що вказана спеціальність in$.medical_programs.medical_program_setting.speciality_types_allowed variable

                  1. в разі помилки повернути код 422 з повідомленням ("Employee's specialty doesn't allow create medication request with medical program from request") 

              2. у випадку, якщо Employee_type = MED_COORDINATOR

                і. пропустити перевірку спеціальності в змінній $.medical_programs.medical_program_setting.speciality_types_allowed

      1. якщо medical_program_settings.skip_employee_validation == true або відсутня medical_program_id в запиті, будь-який користувач, який має скоуп може створити запит на рецепт

Перевірити підрозділ

Ціль валідації: Перевірити підрозділ на можливість створення запиту на рецепт.

  1. Отримати Get

...

  1. division details

  2. Перевірити division_id

...

  1. -

...

  1. division_id

...

  1. існує

...

    • а разі помилки

...

    • направити код 422 з повідомленням ("Division not found

...

    • ")

  1. Перевірити

...

  1. Response $.data.

...

  1. status==

...

  1. ACTIVE

    1. якщо не знайдено - повернути

...

    1. код 422 (повідомлення: "Only

...

    1. employee of active

...

    1. divisions can

...

    1. create medication request!")

...

Первірити статус верифікації персони:

  1. Якщо MRR має based_on з валідною активністю, пропустити перевірку.

  2. В іншому випадку перевірити, що verification_status не рівний NOT_VERIFIED.

    1. в разі NOT_VERIFIED - повернути помилку 409, "Patient is not verified"

Перевірити дати

  1. created_at - схожа з датою погодженя FHIR -> Актуальній даті створення запиту на рецепт

  2. inserted_at - дата, коли запит на рецепт був створений в E-Health

  3. started_at/ended_at - Період лікування. Не може бути меньше ніж дата закінчення MR. Визначається лікарем.

  4. dispence_valid_from - Використовується для перевірки відпуску. Аналогічно для дат створення.

  5. dispense_valid_to - Відпуск валідний з + medication_dispense_period значення параметру. Вказує на дату закінчення строку відпуску.

Ціль валідації:  Повинна бути: ended_at >= started_at >= created_at

...

Перевірити, що created_at, started_at, ended_at в форматі дати

  • в разі помилки повернути код 422 в повідомленні ("expected \"%{actual}\" to be a valid ISO 8601 date")

...

Перевірити ended_at >= started_at

  1. якщо помилка - повернути код 422  (повідомлення: "Ended date must be >= Started date!")

...

Перевірити started_at` >= created_at

  1. якщо помилка - повернути код 422  (повідомлення: "Started date must be >= Created date!")

...

Перевірити started_at >= current_date()

  1. якщо помилка - повернути код 422  (повідомлення: "Started date must be >= current date!")

...

Перевірити created_at >= current_date() - mrr_delay_input

  1. якщо помилка - повернути код  422  (повідомлення: "Create date must be = current date!")

...

Перевірити started_at у відповідності до частоти отримання препаратів

  1. отримати $.medical_programs.medical_program_setting по medical_program_id з запиту

    1. перевірити параметр skip_mnn_in_treatment_period

      1. в разі skip_mnn_in_treatment_period == FALSE (or absent)

        1. перевірити запит на відповідність: PreQualify Medication request#2.Checkabsencethesamemedicationsfortheprograms

      2. в разі skip_mnn_in_treatment_period == TRUE

        1. пропустити перевірку періодичності отримання препаратів

  1. Підрозділ повинен бути активним або посилатися на поточну legal_entity

    • is_active = true

    • status = 'ACTIVE'

    • division.legal_entity_id = client_id (context)

Перевірити юридичну особу

Ціль перевірки: Перевірити юридичну особу на можливість створенна запиту на рецепт.

  1. Отримати client_id з токену

  2. Перевірити client_id=legal_entity_id

    1. перевірити, що юридична особа існує

      1. в разі помилки повернути код 422 з повідомленням (422 Legal entity not found)

    2. перевірити, що legal_entities.status == ACTIVE

      1. в разі помилки повернути код 422 з повідомленням ("Only active legal entity can provide medication request")

Перевірити персону

Ціль перевірки: Перевірити персону на можливість створення запиту на рецепт.

  1. Отримати Get patient by ID

  2. Перевірити, що person_id - mpi_id існують

    • в разі помилки повернути код 422 (422 Person not found)

  3. Зберегти перемінні параметри з: $.data.authentication_methods

  4. Перевірити відповідь $.data.is_active==TRUE 

    1. якщо не знайдено - повернути помилку з кодом 422 (повідомлення: "Only for active MPI record can be created medication request!")

  5. Первірити статус верифікації персони:

    1. Якщо MRR має based_on з валідною активністю, пропустити перевірку.

    2. В іншому випадку перевірити, що verification_status не рівний NOT_VERIFIED.

      1. в разі NOT_VERIFIED - повернути помилку 409, "Patient is not verified"

Перевірити дати

  1. created_at - схожа з датою погодженя FHIR -> Актуальній даті створення запиту на рецепт

  2. inserted_at - дата, коли запит на рецепт був створений в E-Health

  3. started_at/ended_at - Період лікування. Не може бути меньше ніж дата закінчення MR. Визначається лікарем.

  4. dispence_valid_from - Використовується для перевірки відпуску. Аналогічно для дат створення.

  5. dispense_valid_to - Відпуск валідний з + medication_dispense_period значення параметру. Вказує на дату закінчення строку відпуску.

Ціль валідації:  Повинна бути: ended_at >= started_at >= created_at

  1. Перевірити, що created_at, started_at, ended_at в форматі дати

    • в разі помилки повернути код 422 в повідомленні ("expected \"%{actual}\" to be a valid ISO 8601 date")

  2. Перевірити ended_at >= started_at

    1. якщо помилка - повернути код 422  (повідомлення: "Ended date must be >= Started date!")

  3. Перевірити started_at` >= created_at

    1. якщо помилка - повернути код 422  (повідомлення: "Started date must be >= Created date!")

  4. Перевірити started_at >= current_date()

    1. якщо помилка - повернути код 422  (повідомлення: "Started date must be >= current date!")

  5. Перевірити created_at >= current_date() - mrr_delay_input

    1. якщо помилка - повернути код  422  (повідомлення: "Create date must be = current date!")

  6. Перевірити started_at у відповідності до частоти отримання препаратів

    1. отримати $.medical_programs.medical_program_setting по medical_program_id з запиту

      1. перевірити параметр skip_mnn_in_treatment_period

        1. в разі skip_mnn_in_treatment_period == FALSE (or absent)

          1. перевірити запит на відповідність: PreQualify Medication request#2.Checkabsencethesamemedicationsfortheprograms

        2. в разі skip_mnn_in_treatment_period == TRUE

          1. пропустити перевірку періодичності отримання препаратів

  7. Перевірити created_at у відповідності до періодичності отримання препаратів

    1. отримати $.medical_programs.medical_program_setting по medical_program_id з запиту

      1. перевірити параметр skip_mnn_in_treatment_period 

        1. в разі skip_mnn_in_treatment_period == FALSE (або відсутня)

          1. перевірити запит у відповідності до логіки: PreQualify Medication request#2.Checkabsencethesamemedicationsfortheprograms

        2. в разі skip_mnn_in_treatment_period == TRUE

          1. пропустити перевірку періодичності отримання препаратів

  8. Перевірити тривалість періоду (ended_at - started_at):

    1. Якщо медична программа була вказана:

      1. перевірити запит на відповідність логіки: PreQualify Medication request: 7. Validate period

    2. в іншому випадку:

      1. Перевірити, що період рецепту меньше або дорівнює MEDICATION_REQUEST_MAX_PERIOD_DAY параментру з чартів

        1. в разі помилки - повернути код 409 “Period length exceeds default maximum value“ 

Перевірити препарат

Ціль валідації: Перевірити FK, status `is_active`=TRUE, type = INNM_DOSAGE

  1. Отримати Get INNM Dosage by ID

  2. Перевірити, що medication_id - medication_id існує

    1. в разі помилки повернути код 422 ("Medication not found")

  3. Перевірити код відповіді == 200

    1. в разі помилки - повернути код 422 (повідомлення: "Only medication with type `INNM_DOSAGE` can be use for created medication request!")\

  4. Перевірити відповідь $.is_active==TRUE

    1. якщо не знайдено - повернути код 422 (повідомлення: "Only active innm_dosage can be use for created medication request!")

Перевірити контекст

  1. Перевірити наявність "context"

    1. у разу помилки повернути код 422 “required property context was not present“

  2. Перевірити "context" це активна сутність (не entered-in-error) з відповідного довідника, який належить поточному пацієнту

    1. Перевірити на наявність в колекції сутності $.data.context.identifier.type.coding[0].code з id == $.data.context.identifier.value , який належить поточному пацієнту

      1. в разі помилки повернути код 409 "{$.data.context.identifier.type.coding[*].code} not found"

    2. Перевірити, що сутність не в статусі "entered-in-error"

      1. в разі помилки повернути код 409 "Entity in status "entered-in-error" can not be referenced"

Перевірити інструкцію дозування

Кожний не порожній атрибут повинен бути валідним та посилатися на відповідний довідник або об'єкт

  1. Послідовність повинна бути унікальна включаючи масив інстркцій дозування

    1. в разі помилки повернути код (422, "Sequence must be unique")

  2. Додаткова інструкція повинна посилатися на валідний довідник

    1. $.dosage_instruction[*].additional_instruction.coding[*].system == "eHealth/SNOMED/additional_dosage_instructions"

    2. $.dosage_instruction[*].additional_instruction.coding[*].code це валдіне значення в довіднику "eHealth/SNOMED/additional_dosage_instructions"

      1. в разі помилки повернути код 409 "Incorrect additional instruction"

  3. Місце має посилатися на валдіний довідник

    1. $.dosage_instruction[*].site.coding[*].system == "eHealth/SNOMED/anatomical_structure_administration_site_codes"

    2. $.dosage_instruction[*].site.coding[*].code це валідне місце в довіднику "eHealth/SNOMED/anatomical_structure_administration_site_codes"

      1. в разі помилки повернути код 409 "Incorrect site"

  4. Шлях повинен посилатися на валідний довідник

    1. $.dosage_instruction[*].route.coding[*].system == "eHealth/SNOMED/route_codes"

    2. $.dosage_instruction[*].route.coding[*].code це валідне місце в довіднику  "eHealth/SNOMED/route_codes"

      1. в разі помилки повернути код 409 "Incorrect route"

  5. Метод повинен посилатися на валідний довідник

    1. $.dosage_instruction[*].method.coding[*].system == "eHealth/SNOMED/administration_methods"

    2. $.dosage_instruction[*].method.coding[*].code це валідне місце в довіднику "eHealth/SNOMED/administration_methods"

      1. в разі помилки повернути код 409 "Incorrect method"

  6. Дозування та тип дозування повинні посилатися на валідний довідник

    1. $.dosage_instruction[*].dose_and_rate.type.coding[*].system == "eHealth/SNOMED/dose_and_rate"

    2. $.dosage_instruction[*].dose_and_rate.type.coding[*].code це валідне місце в довіднику "eHealth/SNOMED/dose_and_rate"

      1. в разі помилки повернути код 409 "Incorrect dose and rate type"

Перевірити based_on

Якщо вказано, перевірити, що поле є масивом з двома значеннями типу Reference: одна - це валідний ресурс плану лікування, інший - ресурс активності.

  1. Перевірити План лікування:

    1. Від повинен належати тій же персоні, що і набір в MRR

      1. в разі помилки повернути код 422 з повідомленням ("Care plan not found")

    2. Від повинен бути в статусі active

  2. Перевірити вказану активність:

    1. Вона відповідає Плану лікування.

      1. в разі помилки повернути код 422 з повідомленням ("Activity not found")

    2. Вона має activity.detail.kind=medication_request; activity.detail.product_reference=medication_id.

      1. в разі помилки повернути код 422 з повідомленням ("Invalid activity kind")

    3. Вона має статус scheduled, in_progress

...

    1. status

      1. у випадку помилки повернути 422 з повідомленням ("Invalid activity status")

  1. Якщо вона має quantity порахувати remaining quantity:

    1. вибрати всі MRR в статусі NEW які створені на основі даної активності

    2. вибрати всі MR в статусах ACTIVE, COMPLETED які створені на основі даної активності

    3. порахувати зарезервовану на сьогодні кількість, як суму medication_qty у профільтрованому MRR  та MR списку, включаючи medication_qty з поточного MRR

    4. порахувати вказану кількість шляхом віднімання зарезервованої кількості з кількості активностей

    5. Перевірити remaining quantity більше або дорівнює 0 

      1. в разі помилки повернути код 409 "The total amount of the prescribed medication quantity exceeds quantity in care plan activity"

    1. перевірити, що medical_program_id дорівнює $.activity[].program

      1. в разі помилки повернути код 422 з повідомленням ("Medical program from activity should be equal to medical program from request")

  2. Перевірити started_at/ended_at для запиту рецепту: 

    1. Якщо активність плану лікування має detail.scheduled_timing.repeat.bounds_period - перевірити started_at/ended_at включаючи bounds_period

    2. Якщо план активності має detail.scheduled_period - перевірити started_at/ended_at включаючи scheduled_period

    3. в іншому випадку - перевірити started_at/ended_at включаючи care_plan.period

      1. у випадку якщо started_at/ended_at не в межах care_plan.period повернути код 422 з повідомленням ("Invalid care plan period")

Перевірити медичну програму

  1. Перевірити наявність medical_program_id

    1. у разі помилки повернути код 422 (“required property medical_program_id was not present“)

  2. Перевірити, що medical_program_id - medical_program_id існує

    1. в разі помилки повернути код 422 ("Medical program not found")

  3. Перевірити контекст на наявність взаємодії в запиті

    1. в разі помилки повернути 422 ("Context with encounter is required as medical program is present in the request")

    2. Перевірити, що діагнози взаємодії не є пустими в $.encounter.diagnosis

      1. в разі помилки - повернути код 422 ('Encounter without diagnosis can not be referenced')

  4. Перевірити параметри medical_programs.medical_program_setting

    1. перевірити, що care_plan_required == true тоді запит повинен містити based_on на план лікування і активність, що містять ту ж програму

      1. в разі помилки повернути код 422 з повідомленням ("Care plan and activity with the same medical program should be present in request")

    2. Якщо вказано параметр CONDITIONS_ICD10_AM_ALLOWED, то:

      1. Перевірити що первинні діагнози зі взаємодії в контексті має код з довідника eHealth/ICD10_AM/condition_codes 

        1. Перевірити, що код діагнозу з CONDITIONS_ICD10_AM_ALLOWED

          1. в разі помилки - повернути 422 “Encounter in context has no primary diagnosis allowed for the medical program“

    3. Якщо вказано параметр CONDITIONS_ICPC2_ALLOWED, то:

      1. Перевірити що первинні діагнози зі взаємодії в контексті має код з довідника eHealth/ICPC2/condition_codes 

        1. Перевірити

...

        1. , що код діагнозу з CONDITIONS_ICPC2_ALLOWED

          1. в разі помилки - повернути 422 “Encounter in context has no primary diagnosis allowed for the medical program“

    1. якщо skip_medication_request_employee_declaration_verify = false або null/absent

      1. потім: отримати $.declarations за Employee_id, person_id, status=ACTIVE

        1. якщо не знайдено - повертає помилку 422 "Тільки лікарі з активною декларацією з пацієнтом можуть створювати запит на ліки!

      2. інакше пропустити перевірку декларації на рівні співробітника (if true).

    2. якщо skip_medication_request_legal_entity_declaration_verify = false або null/absent

      1. потім: отримати $.declarations за legal_entity_id співробітника, person_id, status=ACTIVE

        1. якщо не знайдено - повертає помилку 422 "Тільки юридична особа з активною декларацією з пацієнтом може створювати заявку на ліки!"

      2. інакше пропустити перевірку декларації на рівні юридичної особи (якщо правда).

    3. Якщо медична програма має funding_source = LOCAL, викличте перевірку, описану в PreQualify Medication request request | 11.-Check-provision-for-a-programs

Перевірити множинність та запит на рецепт дозволений учасникам

Ціль валідації:  Запит кількості повинен містити множинність package_min_qty for пов'язаних препаратів. Результат (Mod або % знак) повинен = 0 . 
Також, якщо вказана Medical_program - повинні міститися мед препарати, які `medication_request_allowed`== TRUE для учасників.

  1. Якщо `$.medical_program_id` відображена у додатковому навантажені (non null) - Перевірити наявність (IF EXIST()) medication & participant 

    1. якщо не існують - повернути код помилки 404 (повідомлення: "Not found any medications allowed for create medication request for this medical program!")

      Code Block
      SELECT *
      FROM medications MI											-- 2nd level: Medication - type = INNM_DOSAGE
      	INNER JOIN ingredients I
      		ON I.medication_child_id = MI.id
      			AND I.is_primary =TRUE
          INNER JOIN medications MED                              -- 3rd level: Medication - type = BRAND
              ON MED.type == BRAND
                  AND I.parent_id = MED.id
      			AND MED.is_active == TRUE
      	INNER JOIN program_medications MP
      		ON MP.medical_program_id == `DOSTUPNI LIKI`
      			MED.id = MP.medication_id
                  AND MP.is_active == TRUE
                  AND MP.medication_request_allowed == TRUE
      WHERE MI.id == $.medication_id
      	AND MI.type == INNM_DOSAGE
      	AND MI.is_active == TRUE
      

    2. Перевірити, що існує (IF EXIST()) медпрепарат & та отримати комбінацію виробніків

      1. якщо не існує - повернути код помилки 404 (повідомлення: "Not found any active linked medication for this innm dosage!")

        Code Block
        SELECT DISTINCT MED.package_min_qty
        FROM medications MI											-- 2nd level: Medication - type = INNM_DOSAGE
        	INNER JOIN ingredients I
        		ON I.medication_child_id = MI.id
        			AND I.is_primary =TRUE
            INNER JOIN medications MED                              -- 3rd level: Medication - type = BRAND
                ON MED.type == BRAND
                    AND I.parent_id = MED.id
        			AND MED.is_active == TRUE
        WHERE MI.id == $.medication_id
        	AND MI.type == INNM_DOSAGE
        	AND MI.is_active == TRUE
        

        2. Перевірити множинність (Mod == 0) для всіх елементів в результаті (`$.medication_qty` Mod `MED.package_min_qty` == 0)

а.якщо всі результати для знаку Mod  - NOT 0 - повернути код помилки 409 (повідомлення: "The amount of medications in medication request must be divisible to package minimum quantity") 

Параметри, які застосовуються при опрацюванні запиту

Конфігураційні параметри

Наприклад: Доступ до методу визначається скоупом covidmedication_request_certificaterequest:get write. Дозвіл на даний скоуп визначається адміністратором Системи шляхом конфігурування скоупів в контексті клієнтів і ролей.

Довідники

Потрібно вказати довідники, які використовує метод APIНемає даних

Обробка

Згенерувати номер та verification_code для рецепту

  • Згенерувати номер для рецепту (See specs)

    Code Block
    Structure number XXXX-1234-5678-9012-345-C , where:
    - XXXX - series: numbers + only some letters (A, E, H, K, M, P, T, X)
    - 1234-5678-9012-345 - randomly generated numbers
    - C - checksum: Should be calculated using the Damn algorithm or Verhoeff algorithm
    After new Request number was generated we should check that it is unique in the DB (entity: medication_request + medication_request_request
    
    • Згенерувати verification_code для MPI.person_authentication_methods == OTP або OFFLINE

      Code Block
      Structure code 1234, where:
      - 1234 - randomly generated numbers 
      

Згенерувати рецепт

  1. Встановити:

    1. dispense_valid_from = created_at

    2. dispensed_valid_to = dispensed_valid_from + dispense_period

  2. Заповнити структуру 'data' для відповіді & зберегти в IL.medication_request_requests

Згенерувати наповнення для відповіді

  • Згенерувати структуру даних відповіді для веб-сервісу

    • Встановити структуру для IL.medication_request_requests 

  • якщо відповідь VALID доповнити відповідь urgent_data:

    • отримати authetification_method по person_id та повернути зашифрований номер (в будь-якому випадку)

Code Block
"urgent": {
    "authentication_method_current": {
      "type": "OTP",
      "number": "+38093*****85"
    }
  }

 

Структура відповіді

Дивись на Apiary

...

Подальша обробка

Немає

HTTP статус коди

HTTP статус код

Повідомлення

Що викликало помилку

 201

 Відповідь 

Відповідь

 

401

Перевірку scope не пройдено

409

Помилка валідації

 422

 Only active employee with type DOCTOR can create medication request!

Помилка валідації

Зворотна сумісність

Немає даних

...