Table of Contents | ||||
---|---|---|---|---|
|
Специфікація
Ціль
Даний веб-сервіс розроблено для попередньої перевірки даних запиту на рецепт (post) - перевірити, чи можливо використати рецепт для вказаної програми.
Є два типи рецептів:
plan - Запит відображає намір перевірки виникнення дії без авторизації. Рецепт з типом plan не може бути відпущено та тільки надає інструкції для адміністрування ЛЗ. Від також не може бути перевірений
order - Запит відображає намір авторизації для дії. Рецепт з типом order може бути відпущений
Вхідні параметри (фільтри)
created_at
started_at
ended_at
person_id
employee_id
division_id
medication_id
medication_qty
programs
Авторизація
Перевірити валідність токену доступу
Перевірити скоупи користувача (scope = 'medication_request_request:write') на можливість виконання даної дії
в разі помилки - згенерувати відповідь 401
Перевірити запит (JSON схема)
Перевірити запит, використовуючи схему JSON.
в разі помилки повернути 422 з повідомленням ("required property %{property} was not present")
Перевірити тип рецепту
Тільки рецепти з типом (намір) order може бути перевірено.
Перевірити намір на рецепт
якщо намір для рецепту == plan - повернути 409, "Plan can't be qualified"
Логіка перевірки (перевірка можливості використання програми)
Кожна медична програма може мати її унікальні стани для відпуску рецептів. Стани можуть визначатися, як на аналізі персональної інформації, так і на списку ЛЗ, термінів, локації та їх комбінації.
На сьогодні є тільки стани для наступних програм "Dostupni liky", "Netsukrovyy diabet", "Insuliny z doplatoyu", "Insuliny bezoplatno", “Epilepsiya“, “Rozlady psykhiky ta povedinky“ і ми їх перевіряємо.
Також, можливо мати відпуск рецепту без програми.
В будь-якому випадку, для медичної програми потребується окремий блок логічної вітки.
Перевірити сумісність тільки програм, які є доступні в беклог (масиві).
Якщо статус програми невалідний, причина повинна бути збережена та повернута у відповідь.
Перевірити відповідність програмі
Деякі перевірки (нижче по тексту) повинні виконуватися для програми
якщо проходять - зберегти відповідь для програми - status = VALID
1. Перевірити відповідність INNM програмі
Застосовується до програми відповідно до medical program settings:
Ціль перевірки: Є перелік ЛЗ (які пов'язані з Innms) які можуть використовуватися за програмою. Потрібно перевірити, чи хоча б один з доступних ЛЗ (з `medication_request_allowed` == TRUE) для Innm з відповідною програмою
Перевірити відповідність innm з переліком ЛЗ для програми
якщо дані не знайдено:
додати до відповіді: status = INVALID
додати до відповіді: rejection_reason = "Innm not on the list of approved innms for program \"<medical_programs.name>\""
...
Code Block |
---|
SELECT *
FROM program_medications PM
INNER JOIN medical_programs MP
ON PM.medical_program_id=MP.id
INNER JOIN medications M
ON M.id = PM.medication_id
AND M.type = 'BRAND'
AND MP.medication_request_allowed = TRUE
INNER JOIN ingredients I
ON I.parent_id = M.id
AND I.is_primary = TRUE
AND I.medication_child_id = PM.medication_id
WHERE PM.medical_program_id = 'medical_program_id'
AND MP.is_active = TRUE
AND M.is_active = TRUE;
|
2. Перевірити відсутність таких же ЛЗ для програми
Відноситься до програм у відповідності до medical program settings:
Перевірити ціль: Може бути тільки 1 рецепт (ACTIVE, COMPLETED) на один innm для одного пацієнта у вказаний період часу.
Приклад перевірки: без перетину часу
...
EP
...
Передумови # 1
...
Результат валідації #1
...
Передумови #2
...
Результат валідації #2
...
Передумови #3
...
Результат валідації #2
...
PreQualifyMedicationRequestRequest
...
Відсутні записи MedicationRequest
...
OK
...
Створений запис в MedicationRequest
...
Не валідно
...
Рецепт відпущено (COMPLETED)
...
Не валідно
...
QualifyMedicationRequestByID
...
Відсутні записи MedicationRequest
...
Не можливо
...
Створений запис в MedicationRequest
...
OK
...
Рецепт відпущено (COMPLETED)
...
Не валідно
...
Для інформації - статуси чартів: Medication_request
Отримати `check_innm_id`
Code Block |
---|
SELECT I.innm_child_id
FROM ingredients I
WHERE I.parent_id = $.medication_id
AND I.is_primary = TRUE
|
...
Отримати рецепт з завершеним відпуском для person_id & check_innm_id
Code Block |
---|
SELECT * FROM medication_requests MR
INNER JOIN medications MED
ON MED.id = MR.medication_id
INNER JOIN ingredients I
ON I.parent_id = MED.id
AND I.innm_child_id = `check_innm_id`
AND I.is_primary = TRUE
WHERE MR.person_id == $.person_id
AND MR.status IN (ACTIVE, COMPLETED)
AND NOT( $.started_at> MR.ended_at OR $.ended_at < MR.started_at)
|
...
Перевірити наявність (IF EXIST () - що є перетином розрахованого терміну (started_at + ended_at) для еклогу зі значеннями вибраних рецептів (started_at + ended_at) з пов'язаними medication_dispense в статусі (NEW,PROCESSED)).
якщо знайдено
додати до відповіді: status = INVALID
додати до відповіді: 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!"
...
Знайти рецепт по $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) для цієї програми.
Перевірити чи є based_on в запиті
Перевірити значення care_plan_required
Code Block |
---|
SELECT medical_program_setting->>'care_plan_required'
FROM medical_programs
WHERE id = 'medical_program_id';
|
...
Якщо care_plan_required відмічено:
перевірити based_on (посилання на care_plan та її активність) в запиті
в разі не знайдено based_on:
додати до відповіді: status = INVALID
додати до відповіді: rejection_reason = "Care plan with activity on "<medical_programs.name>\" is required for for program \"<medical_programs.name>\""
4. Перевірити, що дігнози відповідають програмі
Застосовується дл програм відповідно до medical program settings:
Ціль перевірки: Необхідно перевірити чи рецепт з програмою потребує контекст (взаємодію) з вказаними діагнозами.
Якщо програма має параметр CONDITIONS_ICD10_AM_ALLOWED в medical_program_settings:
Перевірити, чи первинні діагнози зі взаємодії в контексті має код з eHealth/ICD10_AM/condition_codes dictionary
Перевірити коди діагнозів в CONDITIONS_ICD10_AM_ALLOWED
в разі помилки - повернути 200 зі статусом = INVALID та rejection_reason = “Encounter in context has no primary diagnosis allowed for the medical program“
Якщо програма має параметр CONDITIONS_ICPC2_ALLOWED в medical_program_settings:
Перевірити, чи первинні діагнози зі взаємодії в контексті має код з eHealth/ICPC2/condition_codesdictionary
Перевірити коди діагозів з CONDITIONS_ICPC2_ALLOWED
в разі помилки - повернути 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. Перевірити період
Застосовується до програм: будь-які
Ціль перевірки: Потрібно перевірити чи період рецепту не перевищив доступниму кількість днів.
Якщо рецепт має програму з MEDICATION_REQUEST_MAX_PERIOD_DAY в налаштуваннях медичної програми:
Перевірити, що період рецепту (ended_at - started_at) меньше або дорівнює налаштуванням параметру MEDICATION_REQUEST_MAX_PERIOD_DAY
в разі помилки - повернути 200 зі статусом = INVALID та rejection_reason = “Period length exceeds allowed value for the medical program“
Якщо рецепт має програму без MEDICATION_REQUEST_MAX_PERIOD_DAY в налаштуваннях програми:
Перевірити, що період рецепту (ended_at - started_at) меньше або дорівнює параметру MEDICATION_REQUEST_MAX_PERIOD_DAY чарту
в разі помилки - повернути 200 зі статусом = INVALID та rejection_reason = “Period length exceeds default maximum value“
8. Перевірити контекст
Перевірити, що "context" активна сутність (не entered-in-error) з відповідного довідника, що належить поточному пацієнту
Перевірити, що сутність в колекції $.data.context.identifier.type.coding[0].code with id == $.data.context.identifier.value that belongs to the current patient
в разі помилки - повернути код 200 зі статусом = INVALID та rejection_reason = “Encounter entity is not found for program“
Перевірити, що діагнози взаємодії не є пустими в $.encounter.diagnosis
в разі помилки - повернути код 422 ('Encounter without diagnosis can not be referenced')
9. Перевірити персону
Валідно для програм: будь-яких
Цілі перевірок: Необхідно перевірити, що персона має необхідні статуси верифікації для отримання мед препаратів.
Перевірити статус персони згідно опису в Create Medication request Request
Згенерувати структуру відповіді
...
Note |
---|
The page is not supported. The method requirements can be found here [DRAFT] PreQualify Medication Request Request [API-005-008-003-0161] |
Table of Contents | ||||
---|---|---|---|---|
|
Призначення
Даний веб-сервіс розроблено для попередньої перевірки даних запиту на рецепт (post) - перевірити, чи можливо використати рецепт для вказаної програми.
Є два типи рецептів:
plan - Запит відображає намір перевірки виникнення дії без авторизації. Рецепт з типом plan не може бути відпущено та тільки надає інструкції для адміністрування ЛЗ. Він також не може бути перевірений
order - Запит відображає намір авторизації для дії. Рецепт з типом order може бути відпущений
Специфікація
Page Properties | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Логіка
Немає даних
Передумови
Немає даних
Глобальні та конфігураційні параметри
Немає даних
Вхідні параметри
Немає
Фільтри
Немає
Структура запиту
Дивись на Apiary
Приклад:
Expand | ||
---|---|---|
| ||
|
Авторизація
Перевірити валідність токену доступу
Перевірити скоупи користувача (scope = 'medication_request_request:write') на можливість виконання даної дії
в разі помилки - згенерувати відповідь 401
Headers
Content-Type:application/json
Authorization:Bearer c2778f3064753ea70de870a53795f5c9
Перевірити запит
Перевірити запит, використовуючи схему JSON.
в разі помилки повернути 422 з повідомленням ("required property %{property} was not present")
Перевірити дані запиту
Перевірити тип рецепту
Тільки рецепти з типом (намір) order може бути перевірено.
Перевірити намір на рецепт
якщо намір для рецепту == plan - повернути 409, "Plan can't be qualified"
Логіка перевірки (перевірка можливості використання програми)
Кожна медична програма може мати її унікальні стани для відпуску рецептів. Стани можуть визначатися, як на аналізі персональної інформації, так і на списку ЛЗ, термінів, локації та їх комбінації.
На сьогодні є тільки стани для наступних програм "Dostupni liky", "Netsukrovyy diabet", "Insuliny z doplatoyu", "Insuliny bezoplatno", “Epilepsiya“, “Rozlady psykhiky ta povedinky“ і ми їх перевіряємо.
Також, можливо мати відпуск рецепту без програми.
В будь-якому випадку, для медичної програми потребується окремий блок логічної вітки.
Перевірити сумісність тільки програм, які є доступні в беклог (масиві).
Якщо статус програми невалідний, причина повинна бути збережена та повернута у відповідь.
Перевірити відповідність програмі
Деякі перевірки (нижче по тексту) повинні виконуватися для програми
якщо проходять - зберегти відповідь для програми - status = VALID
1. Перевірити відповідність INNM програмі
Застосовується до програми відповідно до medical program settings:
Ціль перевірки: Є перелік ЛЗ (які пов'язані з Innms) які можуть використовуватися за програмою. Потрібно перевірити, чи хоча б один з доступних ЛЗ (з `medication_request_allowed` == TRUE) для Innm з відповідною програмою
Перевірити відповідність innm з переліком ЛЗ для програми
якщо дані не знайдено:
додати до відповіді: status = INVALID
додати до відповіді: rejection_reason = "Innm not on the list of approved innms for program \"<medical_programs.name>\""
|
2. Перевірити відсутність таких же ЛЗ для програми
Відноситься до програм у відповідності до medical program settings:
Перевірити ціль: Може бути тільки 1 рецепт (ACTIVE, COMPLETED) на один innm для одного пацієнта у вказаний період часу.
Приклад перевірки: без перетину часу
EP | Передумови # 1 | Результат валідації #1 | Передумови #2 | Результат валідації #2 | Передумови #3 | Результат валідації #2 |
---|---|---|---|---|---|---|
PreQualifyMedicationRequestRequest | Відсутні записи MedicationRequest | OK | Створений запис в MedicationRequest | Не валідно | Рецепт відпущено (COMPLETED) | Не валідно |
QualifyMedicationRequestByID | Відсутні записи MedicationRequest | Не можливо | Створений запис в MedicationRequest | OK | Рецепт відпущено (COMPLETED) | Не валідно |
Для інформації - статуси чартів: Medication_request
Отримати `check_innm_id`
Code Block SELECT I.innm_child_id FROM ingredients I WHERE I.parent_id = $.medication_id AND I.is_primary = TRUE
Отримати рецепт з завершеним відпуском для person_id & check_innm_id
Code Block SELECT * FROM medication_requests MR INNER JOIN medications MED ON MED.id = MR.medication_id INNER JOIN ingredients I ON I.parent_id = MED.id AND I.innm_child_id = `check_innm_id` AND I.is_primary = TRUE WHERE MR.person_id == $.person_id AND MR.status IN (ACTIVE, COMPLETED) AND NOT( $.started_at> MR.ended_at OR $.ended_at < MR.started_at)
Перевірити наявність (IF EXIST () - що є перетином розрахованого терміну (started_at + ended_at) для беклогу зі значеннями вибраних рецептів (started_at + ended_at) з пов'язаними medication_dispense в статусі (NEW,PROCESSED)).
якщо знайдено
додати до відповіді: status = INVALID
додати до відповіді: 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!"
Знайти рецепт по $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) для цієї програми.
Перевірити чи є based_on в запиті
Перевірити значення care_plan_required
Code Block SELECT medical_program_setting->>'care_plan_required' FROM medical_programs WHERE id = 'medical_program_id';
Якщо care_plan_required відмічено:
перевірити based_on (посилання на care_plan та її активність) в запиті
в разі не знайдено based_on:
додати до відповіді: status = INVALID
додати до відповіді: rejection_reason = "Care plan with activity on "<medical_programs.name>\" is required for for program \"<medical_programs.name>\""
4. Перевірити, що дігнози відповідають програмі
Застосовується дл програм відповідно до medical program settings:
Ціль перевірки: Необхідно перевірити чи рецепт з програмою потребує контекст (взаємодію) з вказаними діагнозами.
Якщо програма має параметр CONDITIONS_ICD10_AM_ALLOWED в medical_program_settings:
Перевірити, чи первинні діагнози зі взаємодії в контексті має код з eHealth/ICD10_AM/condition_codes dictionary
Перевірити коди діагнозів в CONDITIONS_ICD10_AM_ALLOWED
в разі помилки - повернути 200 зі статусом = INVALID та rejection_reason = “Encounter in context has no primary diagnosis allowed for the medical program“
Якщо програма має параметр CONDITIONS_ICPC2_ALLOWED в medical_program_settings:
Перевірити, чи первинні діагнози зі взаємодії в контексті має код з eHealth/ICPC2/condition_codesdictionary
Перевірити коди діагозів з CONDITIONS_ICPC2_ALLOWED
в разі помилки - повернути 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. Перевірити період
Застосовується до програм: будь-які
Ціль перевірки: Потрібно перевірити чи період рецепту не перевищив доступниму кількість днів.
Якщо рецепт має програму з MEDICATION_REQUEST_MAX_PERIOD_DAY в налаштуваннях медичної програми:
Перевірити, що період рецепту (ended_at - started_at) меньше або дорівнює налаштуванням параметру MEDICATION_REQUEST_MAX_PERIOD_DAY
в разі помилки - повернути 200 зі статусом = INVALID та rejection_reason = “Period length exceeds allowed value for the medical program“
Якщо рецепт має програму без MEDICATION_REQUEST_MAX_PERIOD_DAY в налаштуваннях програми:
Перевірити, що період рецепту (ended_at - started_at) меньше або дорівнює параметру MEDICATION_REQUEST_MAX_PERIOD_DAY чарту
в разі помилки - повернути 200 зі статусом = INVALID та rejection_reason = “Period length exceeds default maximum value“
8. Перевірити контекст
Перевірити, що "context" активна сутність (не entered-in-error) з відповідного довідника, що належить поточному пацієнту
Перевірити, що сутність в колекції $.data.context.identifier.type.coding[0].code with id == $.data.context.identifier.value that belongs to the current patient
в разі помилки - повернути код 200 зі статусом = INVALID та rejection_reason = “Encounter entity is not found for program“
Перевірити, що діагнози взаємодії не є пустими в $.encounter.diagnosis
в разі помилки - повернути код 422 ('Encounter without diagnosis can not be referenced')
9. Перевірити персону
Валідно для програм: будь-яких
Цілі перевірок: Необхідно перевірити, що персона має необхідні статуси верифікації для отримання мед препаратів.
Перевірити статус персони згідно опису в Create Medication request Request
Параметри, які застосовуються при опрацюванні запиту
Конфігураційні параметри
Доступ до методу визначається скоупом medication_request_request:write. Дозвіл на даний скоуп визначається адміністратором Системи шляхом конфігурування скоупів в контексті клієнтів і ролей.
Довідники
Немає даних
Обробка
Немає даних
Структура відповіді
Зібрати масив для всіх програм в беклог зі статусами (VALID or INVALID) та rejection_reason
Дивись на Apiary
Приклад:
Expand | ||
---|---|---|
| ||
|
Подальша обробка
Немає
HTTP статус коди
HTTP статус код | Повідомлення | Що викликало помилку |
---|---|---|
200 | Відповідь |
|
401 | Помилка неавторизованого доступу | |
409 | Помилка | |
422 | Помилка |
|
Зворотна сумісність
Немає даних