Ціль

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

...

Purpose

This WS is designed to create Request for Medication request

There are two types of medication request:

• plan - Запит відображає намір на формування мед. препаратів без необхідності підтвердження дії. Рецепт з типом план не може бути відпущений та тільки надає інструкцію для адміністрування мед препаратів - The request represents an intention to ensure something occurs without providing an authorization for others to act. Medication request with type plan can't be dispensed and only provide the instruction to administer the medicine. 

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

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

Apiary

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

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

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

Авторизація

...

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

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

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

...

• - The request represents a request/demand and authorization for action. Medication request with type order can be dispensed

Specification

Apiary

Key points

1. Only authenticated and authorized users with appropriate scope can Create Medication Request Request (MRR)

2. Patient should be stored in hashed form according to security requirements.

Authorize

1. Verify the validity of access token

   1. in case of error - return 401 (“Invalid access token”) in case of validation fails

2. Verify that token is not expired

   1. in case of error - return 401 (“Invalid access token”)

3. Перевірити скоупи користувача Check user scopes in order to perform this action (scope = 'medication_request_request:write') на можливість виконання даної дії

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

   Якщо BLOCK

   1. return 403 (“Your scope does not allow to access this resource. Missing allowances: medication_request_request:write”) in case of invalid scope(s)

4. If BLOCK_UNVERIFIED_PARTY_USERS є true, тоді перевірити дані співробітника на свіпадіння наступним умовамis true, then check party's data match following condition: verification_status != NOT_VERIFIED або or (verification_status = NOT_VERIFIED та and updated_at <= current_date - UNVERIFIED_PARTY_PERIOD_DAYS_ALLOWED):

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

...

Validations

...

Validate container_dosage field

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

...

volume of a medication’s primary container, which is requested by a doctor or issuer of a medication request, to be dispensed to patient.

1. Validate $.container_dosage field by schemata

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

      в разі помилки повернути 422

      should be both filled

      1. in case of error return 422 error ("required property %{property} was not present")

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

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

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

...

Validate priority

1. Check by schemata if $.priority is filled with the value of MEDICATION_REQUEST_PRIORITY

   в разі помилки повернути 422

   dictionary

   1. in case of error return 422 error ("value is not allowed in enum")

...

Validate prior_prescription

1. Перевірити, що Check that $.prior_prescription це is UUID, наявний та належить персоніexists and belongs to this person:

   1. is_active = true, та та ж персонаand the same person. 

      1. в разі помилки повернути - in case of error - return 422 (message: "Prior prescription is not found")

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

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

...

Отримати employee_id з запиту

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

На існування

...

Validate employee

Validation of an employee for the possibility of creating a medication request.

1. Invoke employee_id from request

2. Validate employee

   1. Validate that exists

      1. in case invalid return 422 error with msg ("Employee not found")

   2. Перевірити, що Validate that $.employees.status == APPROVED

      1. в разі помилки повернути код 409 з повідомленням in case invalid return 409 error with msg ("Employee is not active")

   3. Перевірити, що Validate that $.employees.legal_entity_id == client_id from token

      1. в разі помилки повернути код 422 з повідомленням in case invalid return 422 error with msg ("Employee does not belong to legal entity from token")

   4. якщо If medical _program_id є в запиті перевірити medicalprogram is present and has medical_program_settings .with skip_employee_validation == false (або відсутняor absent), то перевірити then validate <employee_type>:

      перевірити, що

      1. validate if employee_type

      вказано в змінній medical

      1. is present in medical_program_settings.employee_types_for_create_medication_request

       в разі помилки повернути код 422 з повідомленням

      1. variable

         1. in case invalid return 422 error with msg ("Employee type can't create medication request with medical program from request") 

      в разі

      1. 1. in case employee_type = DOCTOR

      якщо змінна 

      1. 1. 1. if variable skip_medication_request_employee_declaration_verify

       

      1. 1. 1. = false

      або

      1. 1. 1. or null/absent

      то

      1. 1. 1. 1. then:

       отримати

      1. 1. 1. 1.  get $.declarations

      по

      1. 1. 1. 1. by employee_id, person_id, status=ACTIVE

      якщо не знайдено - повернути помилку 422  якщо змінна 

      1. 1. 1. 1. 1. if not found - return 422 error  "Only doctors with an active declaration with the patient can create medication request with medical program from request!"

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

   1. 1. 1. 1. else skip declaration verification on employee level (if true)

         2. if variable skip_medication_request_legal_entity_declaration_verify = false

   або

   1. 1. 1. or null/absent

   то

   1. 1. 1. 1. then: get $.declarations

   по

   1. 1. 1. 1. by employee's legal_entity_id, person_id, status=ACTIVE

   якщо не знайдено - повернути помилку 422 

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

   в разі

   1. 1. 1. 1. 1. if not found - return 422 error "Only legal entity with an active declaration with the patient can create medication request with medical program from request!"

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

   1. 1. 1. 1. else skip declaration verification on legal entity level (if true)

         2. else if both are true - skip declaration verification at all

      2. in case employee_type = SPECIALIST

   отримати

   1. 1. 1. get $.employees.speciality.speciality(speciality_officio == true)

   перевірити, що спеціалізація вказана для змінної

   1. 1. 1. validate that speciality present in $.medical_programs.medical_program_setting.speciality_types_allowed

    в разі неуспішної перевірки - помилка 422 з повідомленням

   1. 1. 1.  variable

            1. in case invalid return 422 error with msg ("Employee's specialty doesn't allow create medication request with medical program from request")

     

   1. 1. 1. 1.  

   якщо

   1. 1. in case employee_type = MED_COORDINATOR

   пропустити валідації, що спеціалізація присутня в змінній

   1. 1. 1. skip validation that speciality present in $.medical_programs.medical_program_setting.speciality_types_allowed

    якщо medical

   1. 1. 1.  variable

   8. If medical program has medical_program_settings with medical_program_settings.skip_employee_validation == true або відсутня true or there is no medical_program_id в запиті, будь-який користувач, який має скоуп може створити запит на рецепт

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

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

1. Отримати 

   1. in the request, any user who has a scope can create medication request

Validate division

Validation of the division for the possibility of creating a medication request.

1. Invoke Get division details

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

   в разі помилки направити код 422 з повідомленням 

   exists

   1. in case invalid return 422 error with msg ("Division not found")

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

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

4. Підрозділ повинен бути активним або посилатися на поточну Division should be active and refers to current legal_entity

   1. is_active = true

   2. status = 'ACTIVE'

   3. division.legal_entity_id = client_id (context)

Перевірити юридичну особу

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

...

Отримати client_id з токену

...

Validate legal entity

Validation of the legal entity for the possibility of creating a medication request.

1. Get client_id from token

2. Validate client_id=legal_entity_id

   1. перевірити, що юридична особа існує

      в разі помилки повернути код 422 з повідомленням

      check that legal_entity exist

      1. in case invalid return 422 error with msg (422 Legal entity not found)

   2. перевірити, що check that legal_entities.status == ACTIVE

      1. в разі помилки повернути код 422 з повідомленням in case invalid return 422 error with msg ("Only active legal entity can provide medication request")

   3. перевірити тип юридичної особи згідно з чарт параметрами check legal entity type in chart parameter MEDICATION_REQUEST_REQUEST_LEGAL_ENTITY_TYPES

      1. в разі помилки повернути код 409 з повідомленням in case invalid return 409 error with msg (“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

         в разі skip

Validate person

Validation of person for the possibility of creating a medication request.

Invoke validation described at PreQualify Medication Request: Check person

Validate dates

1. created_at - similar to assertion date in FHIR -> Actual date medication request being created

2. inserted_at - date when Medication request was registered in E-Health

3. started_at/ended_at - Treatment period. Cannot be less than MR expiration period. Defined by doctor.

4. dispense_valid_from - Used for dispense validation. As for now equals Created at.

5. dispense_valid_to -  Implements dispense expiration period. If MR has medical program setting with not empty parameter medication_dispense_period_day, then dispense_valid_from + medication_dispense_period_day, else Dispense valid from + medication_dispense_period global parameter value.

Purpose validation:  Must be: ended_at >= started_at >= created_at

1. Validate that created_at, started_at, ended_at in date format

   1. in case invalid return 422 with msg ("expected \"%{actual}\" to be a valid ISO 8601 date")

2. Validate ended_at >= started_at

   1. if invalid - return 422 error  (message: "The end date should be equal to or greater than the start date.")

3. Validate started_at >= created_at, but not greater than (created_at + MEDICATION_REQUEST_REQUEST_EXTENDED_LIMIT_STARTED_AT_DAYS)

   1. if invalid - return 422 error  (message: "The start date should be equal to or greater than the creation date, but the difference beetwen them should be not exceed {{MEDICATION_REQUEST_REQUEST_EXTENDED_LIMIT_STARTED_AT_DAYS}} day(s).")

4. Validate started_at >= current_date()

   1. if invalid - return 422 error  (message: "Started date must be >= current date!")

5. Validate created_at >= current_date() - MEDICATION_REQUEST_REQUEST_DELAY_INPUT chart param

   1. if invalid - return 422 error  (message: "Create date must be >= Current date - MRR delay input!")

6. Validate started_at regarding frequency of receiving drugs

   1. get $.medical_programs.medical_program_setting by medical_program_id from request

      отримати

      1. validate skip_mnn_in_treatment_period variable

         1. in case skip_mnn_in_treatment_period == FALSE (or absent)

            1. перевірити запит на відповідністьvalidate request according to logic: PreQualify Medication request#2.Checkabsencethesamemedicationsfortheprograms

            в разі skip

            1. request: 2. Check absence the same medications for the programs

         2. in case skip_mnn_in_treatment_period == TRUE

            1. пропустити перевірку періодичності отримання препаратів

   Перевірити created_at у відповідності до періодичності отримання препаратів

   1. 1. 1. 1. skip validating frequency of receiving drugs

7. Validate created_at regarding frequency of receiving drugs

   1. get $.medical_programs.medical_program_setting по by medical_program_id з запиту

      перевірити параметр skip

      from request

      1. validate skip_mnn_in_treatment_period 

         в разі skip

         period variable

         1. in case skip_mnn_in_treatment_period == FALSE (або відсутня)

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

            or absent)

            1. validate request according to logic: PreQualify Medication request#2.Checkabsencethesamemedicationsfortheprograms

            в разі skip

            1. request: 2. Check absence the same medications for the programs

         2. in case skip_mnn_in_treatment_period == TRUE

            1. пропустити перевірку періодичності отримання препаратів

   Перевірити тривалість періоду

   1. 1. 1. 1. skip validating frequency of receiving drugs

8. Validate period length (ended_at - started_at):

   1. Якщо медична программа була вказана:

      перевірити запит на відповідність логіки

      If medical program has been submitted:

      1. validate request according to logic: PreQualify Medication request: 7. Validate period

   2. в іншому випадку:

      Перевірити, що період рецепту меньше або дорівнює MEDICATION

      else:

      1. Check that medication request period less than or equal to MEDICATION_REQUEST_MAX_PERIOD_DAY параментру з чартів

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

         parameter from charts

         1. in case of error - return 409 “Period length exceeds default maximum value“ 

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

...

Validate medication

Check FK, status `is_active`=TRUE, type = INNM_DOSAGE

1. Отримати Invoke Get INNM Dosage by ID

2. Перевірити, що medicationValidate medication_id - medication_id існує

   в разі помилки повернути код

   exists

   1. in case of error return 422 ("Medication not found")

3. Перевірити код відповіді Validate Response code == 200

   1. в разі помилки - повернути код 422 (повідомленняif invalid - return 422 error (message: "Only medication with type `INNM_DOSAGE` can be use for created medication request!")\

4. Перевірити відповідь $Validate Response $.is_active==TRUE

   1. якщо не знайдено - повернути код 422 (повідомленняif not found - return 422 error (message: "Only active innm_dosage can dosage can be use for created medication request!")

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

...

Validate context

1. Validate "context" в запиті

   у разу помилки повернути код 422 “required

   is present in the request

   1. in case of error return 422 ("required property context was not present“present")

2. Перевірити Validate "context" це активна сутність (не is an active (not entered-in-error) з відповідного довідника, який належить поточному пацієнту

   Перевірити

   encounter, that belongs to the current patient

   1. Validate context.identifier.type.coding[0].code = encounter

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

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

      в разі помилки повернути код

      that belongs to the current patient

      1.  in case of error 422 "Entity not found"

   3. Перевірити, що сутність не в статусі Validate that entity is not in status "entered-in-error"

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

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

      1. в разі помилки повернути код in case of error return 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

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

...

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

...

Validate dosage instruction

Each non-empty attribute must be valid and reference to appropriate dictionary or object

Invoke validation described at Preqalify Medication Request: Validate dosage instructions

Validate based_on

If submitted, invoke validation described at PreQalify Medication Request: Check Care Plan and Activity

Validate medical program

1. Validate medical_program_id is present in the request

   1. in case of error return 422 ("required property medical_program_id was not present")

2. Validate medical_program_id - medical_program_id exists

   1. in case of error return 422 ("Medical program not found")

3. Validate medical_programs.medical_program_setting parameters

   1. check if care_plan_required == true then the request should contain a based_on with care plan and activity that contains the same medical program

      1. in case of error return 422 with msg ("Care plan and activity with the same medical program should be present in request")

   2. If there is conditions_icd10_am_allowed parameter, then:

      1. Check if primary diagnosis from the encounter in context has code from eHealth/ICD10_AM/condition_codes dictionary

         1. Check diagnosis code in conditions_icd10_am_allowed

            1. in case of error - return 422 “Encounter in context has no primary diagnosis allowed for the medical program“

   3. If there is conditions_icpc2_allowed parameter, then:

      1. Check if primary diagnosis from the encounter in context has code from eHealth/ICPC2/condition_codes dictionary

         1. Check diagnosis code in conditions_icpc2_allowed

            1. in case of error - return 422 “Encounter in context has no primary diagnosis allowed for the medical program“

4. If medical program has funding_source = LOCAL , then invoke validation described at https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/583405343/PreQualify+Medication+Request+Request#11.-Check-provision-for-a-programs

Validate multiplicity & medication request allowed for participants

1. Perform validation as described at PreQalify Medication Request: Check INNM complience for the programs. If MRR has no program, then following script used in this validation to define list of medications (BRANDs):

SELECT m0.id, m2.id, m2.package_qty, m2.package_min_qty
FROM medications AS m0
         INNER JOIN ingredients AS i1 ON i1.medication_child_id = {$.medication_id}
         INNER JOIN medications AS m2 ON i1.parent_id = m2.id
WHERE (i1.is_primary = TRUE)
  AND (m0.id = {$.medication_id})
  AND (m0.type = 'INNM_DOSAGE')
  AND (m0.is_active = TRUE)
  AND (m2.is_active = TRUE)

1. Perform validation as described at

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

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

...

Service Logic

Generate number & verification_code

...

for Medication request

1. Generate human readable number for receipt (See specs)

   Code Block
   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. Згенерувати verificationGenerate verification_code для for MPI.person_authentication_methods == OTP або or OFFLINE

   Code Block
   Structure code 1234, where: - 1234 - randomly generated numbers

Створити запит на рецепт

1. встановити

Create Medication request Request

1. set:

   1. dispense_valid_from = created_at

   2. dispensed_valid_to = dispensed_valid_from + dispense_period

2. Заповнити структуру Fill 'data' для відповіді & зберегти в ILstructure for Response & save in IL.medication_request_requests

   1. якщо взаємодія наявна в контексті запита на основі якого створений рецепт - заповнити If encounter is present in the request context then based on it - fill the IL.medication_request_requests.context_episode_id

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

   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

...

Generate content for response

• Generate data structure with Responce WS structure

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

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

  • requests this structure

• in case if response is VALID enrich response with urgent_data:

  • отримати get authetification_method по by person_id та повернути замаскований номер (а разі будь якогоand return masked number (in case if any)

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

...