ЕСОЗ - публічна документація

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Ціль

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

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

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

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

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

Apiary

Основні положення

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

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

Авторизація

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

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

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

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

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

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

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

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

Перевірки

Перевірка поля container_dosage

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

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

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

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

    2. $.container_dosage.system повинен бути “MEDICATION_UNIT”

      1. в разі помилки повернути 422 ("value is not allowed in enum")

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

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

    1. в разі помилки повернути 422 ("value is not allowed in enum")

Перевірити prior_prescription

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

    1. is_active = true, та та ж персона. 

      1. в разі помилки повернути - 422 (message: "Prior prescription is 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. якщо medical_program_id є в запиті перевірити medical_program_settings.skip_employee_validation == false (або відсутня), то перевірити <employee_type>:

      • перевірити, що employee_type вказано в змінній medical_program_settings.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. якщо змінна skip_medication_request_employee_declaration_verify = false або null/absent

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

              1. якщо не знайдено - повернути помилку 422  "Only doctors with an active declaration with the patient can create medication request with medical program from request!"

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

          2. якщо змінна skip_medication_request_legal_entity_declaration_verify = false або null/absent

            1. то: get $.declarations по employee's legal_entity_id, person_id, status=ACTIVE

              1. якщо не знайдено - повернути помилку 422 "Only legal entity with an active declaration with the patient can create medication request with medical program from request!"

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

          3. якщо обидва true - пропустити верифікацію декларації взагалі

        3. в разі employee_type = SPECIALIST

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

          2. перевірити, що спеціалізація вказана для змінної $.medical_programs.medical_program_setting.speciality_types_allowed 

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

        4. якщо employee_type = MED_COORDINATOR

          1. пропустити валідації, що спеціалізація присутня в змінній $.medical_programs.medical_program_setting.speciality_types_allowed 

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

    3. перевірити тип юридичної особи згідно з чарт параметрами MEDICATION_REQUEST_REQUEST_LEGAL_ENTITY_TYPES

      1. в разі помилки повернути код 409 з повідомленням (“Invalid legal entity type“)

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

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

  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 - Вказує на дату закінчення строку відпуску. Якщо MR має вказані налаштування по програмі з заповненим параметром medication_dispense_period_day, то dispence_valid_from + medication_dispense_period_day, в іншому випадку відпуск валідний з + 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. Перевірити context.identifier.type.coding[0].code = encounter

      1. в разі помилки повернути код 422 ("value is not allowed in enum")

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

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

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

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

    4. Діагнози взаємодії заповнені в $.encounter.diagnosis

      1. в разі помилки повернути код 422 ("Encounter without diagnosis 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 

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

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

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

  3. Перевірити 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. Перевірити параметри 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. Якщо програма має funding_source = LOCAL , викликати валідації як описано для https://e-health-ua.atlassian.net/wiki/spaces/EPRx/pages/16981065737/PreQualify+Medication+request+request+modified+EN#11.-Check-provision-for-a-programs

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

  1. Виконати перевірки як описано для https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/583405343/PreQualify+Medication+request+EN#1.-Check-INNM-complience-for-the-programs.

  2. Виконати перевірки як описано

PreQalify Medication Request: Check absence the same medications for the programs.

Сервісна логіка

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

  1. Згенерувати читабельний номер для рецепту (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

  2. Згенерувати 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

    1. якщо взаємодія наявна в контексті запита на основі якого створений рецепт - заповнити IL.medication_request_requests.context_episode_id

  3. Заповнити окремо

    1. data_employee_id,
      data_intent,
      data_based_on_care_plan_id,
      data_based_on_activity_id,
      data_context_id,
      data_patient_id,
      data_legal_entity_id

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

  • Згенерувати структуру даних з структури відповіді WS

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

  • в разі валідності відповіді VALID збагатити відповідь даними з urgent_data:

    • отримати authetification_method по person_id та повернути замаскований номер (а разі будь якого)

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

  • No labels

ЕСОЗ - публічна документація