PreQualify Medication Request Request_UA

Призначення

Даний веб-сервіс розроблено для попередньої перевірки даних запиту на рецепт (post) - перевірити, чи можливо використати рецепт для вказаної програми.

Є два типи рецептів:

• plan - Запит відображає намір перевірки виникнення дії без авторизації. Рецепт з типом plan не може бути відпущено та тільки надає інструкції для адміністрування ЛЗ. Він також не може бути перевірений

• order - Запит відображає намір авторизації для дії. Рецепт з типом order може бути відпущений

Специфікація

Логіка

Немає даних

Передумови

Немає даних

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

Немає даних

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

Немає

Фільтри

Немає

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

Дивись на Apiary

Приклад:

Авторизація

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

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

   1. в разі помилки - згенерувати відповідь 401

Headers

Content-Type:application/json

Authorization:Bearer c2778f3064753ea70de870a53795f5c9

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

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

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

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

Перевірити тип рецепту

Тільки рецепти з типом (намір) order може бути перевірено.

1. Перевірити намір на рецепт

   1. якщо намір для рецепту == plan - повернути 409, "Plan can't be qualified"

Логіка перевірки (перевірка можливості використання програми)

• Кожна медична програма може мати її унікальні стани для відпуску рецептів. Стани можуть визначатися, як на аналізі персональної інформації, так і на списку ЛЗ, термінів, локації та їх комбінації.

• На сьогодні є тільки стани для наступних програм "Dostupni liky", "Netsukrovyy diabet", "Insuliny z doplatoyu", "Insuliny bezoplatno", “Epilepsiya“, “Rozlady psykhiky ta povedinky“ і ми їх перевіряємо.

• Також, можливо мати відпуск рецепту без програми.

• В будь-якому випадку, для медичної програми потребується окремий блок логічної вітки.

• Перевірити сумісність тільки програм, які є доступні в беклог (масиві).

• Якщо статус програми невалідний, причина повинна бути збережена та повернута у відповідь.

Перевірити відповідність програмі

Деякі перевірки (нижче по тексту) повинні виконуватися для програми

1. якщо проходять - зберегти відповідь для програми - status = VALID

1. Перевірити відповідність INNM програмі

Застосовується до програми відповідно до medical program settings:

Ціль перевірки:  Є перелік ЛЗ (які пов'язані з Innms) які можуть використовуватися за програмою. Потрібно перевірити, чи хоча б один з доступних ЛЗ (з `medication_request_allowed` == TRUE)  для Innm з відповідною програмою

1. Перевірити відповідність innm з переліком ЛЗ для програми

   1.  

   2. якщо дані не знайдено:

      1. додати до відповіді: status = INVALID

      2. додати до відповіді: rejection_reason = "Innm not on the list of approved innms for program \"<medical_programs.name>\""

2. Перевірити відсутність таких же ЛЗ для програми

Відноситься до програм у відповідності до medical program settings:

Перевірити ціль:  Може бути тільки 1 рецепт (ACTIVE, COMPLETED)  на один innm для одного пацієнта у вказаний період часу.

Приклад перевірки: без перетину часу

1. Для інформації - статуси чартів: Medication_request

2. Отримати `check_innm_id`

   SELECT I.innm_child_id FROM ingredients I WHERE I.parent_id = $.medication_id AND I.is_primary = TRUE

    

3. Отримати рецепт з завершеним відпуском для person_id & check_innm_id

4.  

    

5. Перевірити наявність (IF EXIST ()  - що є перетином  розрахованого терміну (started_at + ended_at) для беклогу зі значеннями вибраних рецептів (started_at + ended_at) з пов'язаними medication_dispense в статусі (NEW,PROCESSED)).  

   1. якщо знайдено  

      1. додати до відповіді: status = INVALID

      2. додати до відповіді: rejection_reason = "It can be only 1 active/ completed medication request request or medication request per one innm for the same patient at the same period of time!"

6. Знайти рецепт по $innm_dosge, $medical_program_id, $person_id and max(end_date). В разі наявності рецепту з ended_at>=current_date тоді наступний може бути виконано в

   • якщо (ended_at - started_at) => mrr_standart_duration то
     NEW created_at >= ended at - max_mrr_renew_days>=current_day

     • в разі помилки повернути помилку 422 ('It's to early to create new medication request for such innm_dosage and medical_program_id')

   • якщо (ended_at - started_at) < mrr_standart_duration то
     NEW created_at >= ended_at - min_mrr_renew_days>=current_day

     • в разі помилки повернути помилку 422 ('It's to early to create new medication request for such innm_dosage and medical_program_id')

3. Перевірити що план лікування є обов'язковим для програми

Застосовується дл програм відповідно до medical program settings:

Перевірити ціль:  Потрібно перевірити, якщо рецепт з програмою потребує план лікування (з `care_plan_required` == TRUE) для цієї програми.

1. Перевірити чи є based_on в запиті

   1. Перевірити значення care_plan_required

       

   2. Якщо care_plan_required відмічено:

      1. перевірити based_on (посилання на care_plan та її активність) в запиті

         1. в разі не знайдено based_on:

            1. додати до відповіді: status = INVALID

            2. додати до відповіді: rejection_reason = "Care plan with activity on "<medical_programs.name>\" is required for for program \"<medical_programs.name>\""

4. Перевірити, що дігнози відповідають програмі

Застосовується дл програм відповідно до medical program settings:

Ціль перевірки: Необхідно перевірити чи рецепт з програмою потребує контекст (взаємодію) з вказаними діагнозами. 

1. Якщо програма має параметр CONDITIONS_ICD10_AM_ALLOWED в medical_program_settings:

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

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

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

2. Якщо програма має параметр CONDITIONS_ICPC2_ALLOWED в medical_program_settings:

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

      1. Перевірити коди діагозів з CONDITIONS_ICPC2_ALLOWED

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

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

Застосовується до програм: будь-які

Ціль перевірки: Необхідно перевірити, чи рецепт з програмою дозволяється створювати вказаним співробітником.

Перевірити employee_id як описано в Create Medication request Request

6. Перевіри ти план лікування та активність

Застосовується до програм: будь-які

Ціль перевірки: Необхідно перевірити, чи рецепт з програмою дозволяється створювати для вказаної програми та активності.

Перевірити based_on як описано в Create Medication request Request

7. Перевірити період

Застосовується до програм: будь-які

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

1. Якщо рецепт має програму з MEDICATION_REQUEST_MAX_PERIOD_DAY в налаштуваннях медичної програми:

   1. Перевірити, що період рецепту (ended_at - started_at) меньше або дорівнює налаштуванням параметру MEDICATION_REQUEST_MAX_PERIOD_DAY

      1. в разі помилки - повернути 200 зі статусом = INVALID та rejection_reason = “Period length exceeds allowed value for the medical program“ 

2. Якщо рецепт має програму без MEDICATION_REQUEST_MAX_PERIOD_DAY в налаштуваннях програми:

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

      1. в разі помилки - повернути 200 зі статусом = INVALID та rejection_reason = “Period length exceeds default maximum value“ 

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

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

   1. Перевірити, що сутність в колекції $.data.context.identifier.type.coding[0].code with id == $.data.context.identifier.value that belongs to the current patient

      1.  в разі помилки - повернути код 200 зі статусом = INVALID та rejection_reason = “Encounter entity is not found for program“

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

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

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

Валідно для програм: будь-яких

Цілі перевірок: Необхідно перевірити, що персона має необхідні статуси верифікації для отримання мед препаратів.

Перевірити статус персони згідно опису в Create Medication request Request

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

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

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

Довідники

Немає даних

Обробка

Немає даних

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

Зібрати масив для всіх програм в беклог зі статусами (VALID or INVALID) та rejection_reason

Дивись на Apiary

Приклад:

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

Немає

HTTP статус коди

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

Немає даних