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

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

« Previous Version 6 Next »

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

Apiary

Ціль

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

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

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

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

Авторизація

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

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

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

Перевірити запит (JSON schema)

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

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

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

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

  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 = <XXX>

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

      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. перевірити запит на відповідність: /wiki/spaces/MRIN/pages/2041217051

        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. перевірити запит у відповідності до логіки: /wiki/spaces/MRIN/pages/2041217051

        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 

    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. Перевірити контекст на наявність взаємодії в запиті

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

  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“

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

Ціль валідації:  Запит кількості повинен містити множинність 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)

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

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

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

 

  • No labels

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