Create Medication request Request_UA

Призначення

Даний веб-сервіс розроблений для створення запиту на рецепт

Є два види запиту на рецепт:

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

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

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

Логіка

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

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

Передумови

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

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

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

ATTRIBUTES - see on Apiary

Фільтри

Немає

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

Дивись на Apiary

Приклад:

Авторизація

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

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

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

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

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

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

4. Якщо 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")

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

Перевірте поле 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 (повідомлення: "Попередній рецепт не знайдено")

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

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

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") 

                  2. якщо 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!")

                  3. якщо 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") 

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

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

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

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

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

1. Отримати Get division details

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

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

3. Перевірити Response $.data.status==ACTIVE

   1. якщо не знайдено - повернути код 422 (повідомлення: "Only employee of active divisions can create medication request!")

4. Підрозділ повинен бути активним або посилатися на поточну 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 status

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

3. Якщо вона має 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")

4. Перевірити 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. Перевірити, що код діагнозу з CONDITIONS_ICPC2_ALLOWED

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

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

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

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

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

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

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

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

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

   6. Якщо медична програма має 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!")

      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!")

         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)

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

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

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

Довідники

Немає даних

Обробка

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

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

  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

    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 та повернути зашифрований номер (в будь-якому випадку)

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

Дивись на Apiary

Приклад:

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

Немає

HTTP статус коди

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

Немає даних