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

RC_Rx_Create Medication Dispense (modified - UA)

Ціль

Даний метод був створений для створення бронювання (холд) на лікарський засіб для попередження декількох відпусків по одному рецепту. Даний холд триває деякий час (конфігураційний праметр MEDICATION_DISPENSE_EXPIRATION) після цього переходить в статус EXPIRED 

  1. Відпуск ЛЗ можливий тільки по рецепту та протягом періоду вказаного у рецепті (dispense_valid_from, dispense_valid_to)

  2. Dispense details - декілька ЛЗ різних виробників з тією ж діючою речовиною можуть бути відпущені за один раз. Загальний medication_qty повинен бути менше або дорівнювати кількості ЛЗ, вказаних в рецепті

  3. Якщо пацієнт бажає розділити відпуск рецепту на декілька частин, то можливо створити та обробити відпуск рецепту з вказаною кількістю лікарського засобу.

Status Charts (reimbursement)

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

Apiary

Логіка веб-сервісу

Авторизація користувача

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

    1. Повернути 401 в разі неуспішної валідації

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

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

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

Перевірка схеми

  1. Перевірити запит на відповідність схемі JSON

    • Повернути 422 зі списком помилок валідації в разі їх неуспішності (422 EView)

Перевірити ЛЗ по програмі

В разі відпуску ЛЗ пацієнту, вказані medical program, program medication id повинні надатися клієнтом або бути розраховані системою

В разі наявності program medication id в запиті:

  1. Перевірити, що дані id ЛЗ по програмі пов'язані до вказаної медичної програми

    1. в разі помилки - повернути 422 (Invalid program medication id)

Розрахувати program medication id якщвін о відснутній в запиті:

  1. Отримати program_medication_id пов'язаний до медичної програми та ЛЗ

    1. в разі помилки - повернути 422 (There are no active program medications for this program and medication)

Отримати юридичну особу з токену

  1. Отримати legal_entity_id (client_id) з токену

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

  1. Отримати party_user (user_id) з токену.

Перевірити FK

  1. Перевірити 

legal_entity_id - legal_entity_id існує

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

{:error, [{%{ description: "Legal entity not found", params: [], rule: :invalid }, "$.legal_entity_id"}]}

 

  1. Перевірити 

medication_request_id - medication_request_id існує

{:error, [{%{ description: "Medication request not found", params: [], rule: :invalid }, "$.medication_request_id"}]}
  1. Перевірити 

party_id - party_id існує

{:error, [{%{ description: "Party not found", params: [], rule: :invalid }, "$.party_id"}]}
  1. Перевірити 

division_id - division_id існує

  1. Перевірити 

medical_program_id - medical_program_id існує

5.1 Перевірити, що є contract в PRM.contracts який відповідає наступним вимогам:

Якщо відпуск рецепту має програму, для якої вказано наступні налаштування skip_contract_provision_verify = true, то пропустити валідацію договору.

Перевірити, що є contract в PRM.contracts який відповідає наступним вимогам:

  1. contracts.type==reimbursement

  2. contracts.status==VERIFIED

  3. Дати договору: start_date <= current_date & end_date >= current_date

  4. contracts.contractor_legal_entity_id=token.client_id

  5. $division_id in contract_divisions

  6. contracts.medical_program_id==$.medical_program_id

  7. сontracts.is_suspended ==false

В разі помилки 409 - "Program cannot be used - no active contract exists"

 

Перевірити всі medication_id (brand_id) - brand_id існують

Перевірити код

  1. Перевірити, що code в запиті рівний коду в medication_request (або обидва пусті)

    1. в разі code наявний в рецепті - він повинен відповідати коду в medication_request

      1. Повернути 401 в разі, якщо код не відповідає (message = "Incorrect code")

    2. в разі code відсутній в запиті - перевірити, що код в medication_request є NULL

      1. Повернути 401 в разі, якщо код в medication_request не NULL (повідомлення = "Missing or Invalid code")

Перевірити пов'язаний план лікування

Якщо (medication_request.based_on наявний і не пусто) ТА medication_program відсутня:

  1. Перевірити план лікування:

    1. Він повинен бути в статусі active 

      1. в разі помилки - повернути 409 (повідомлення: "Invalid care plan status")

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

      1. в разі помилки - повернути 409 (повідомлення: “Care plan expired“)

  2. Перевірити активність плану лікування:

    1. Має статус scheduled, in_progress 

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

Перевірити відділення

Якщо вказано division_id:

  1. Перевірити, що відділення активні

    1. в разі помилки - повернути 409 ("Division is not active")

  2. Перевірити, що відділення належить до юридичної особи користувача

    1. в разі помилки - повернути 409 ("Division does not belong to user's legal entity")

  3. Якщо параметр чарту DISPENSE_DIVISION_DLS_VERIFY включено, то перевірити відділення в списку ДЛС (dls_verified=true)

    1. в разі помилки - повернути 409 "Invalid division dls status"

  4. Якщо параметр чарту вказано MEDICAL_PROGRAM_PROVISION_VERIFY, перевірити, що відділення надає послуги по програмам. Для кожного відділення по програмі перевірити:

    1. Якщо для програми не вказано skip_contract_provision_verify або дорівнює false/null: 

      1. що він існує та активний:

        1. в разі помилки - повернути статус =INVALID for a program, rejection_reason= "Division does not provide the medical program"

      2. що він пов'язаний до дійсного договору реімбурсації: contract.start_date <= current_date <= contract.end_date, is_active = true, status = VERIFIED.

        1. в разі помилки - повернути статус=INVALID для програми, rejection_reason="Medical program provision is not related to any actual contract for the current date"

      3. в іншому випадку, якщо skip_contract_provision_verify = true, то пропустити перевірку відділень для медичної програми

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

Важливо: Дана перевірка повинна бути виконана тільки якщо medical_program наявна в запиті

  1. Перевірити, що рецепт валідний та доступний для відпуску

    1. Викликати Qualify method

    2. Використати medication_requests.medical_program_id як програму для перевірки

    3. Перевірити, що program_medication_id в запиті на перевірку

Відпуск просрочено

Рецепт просрочено для відпуску в разі $.data[?(@.program_id=medication_requests.medical_program_id)].status = 'INVALID' or program_medication_id відсутній у відповіді

В разі помилки - повернути код 409 (повідомлення = "Medication request can not be dispensed. Invoke qualify medication request API to get detailed info")

Відпуск дозволено

Рецепт дозволено для відпуску у випадку $.data[?(@.program_id=medication_requests.medical_program_id)].status = 'VALID' та program_medication_id наявна у відповіді

Перевірити статуси

  1. Юридична особа повинен бути активний для відпуску ЛЗ

    • is_active = true

    • status = 'ACTIVE'

    • тип в pharmacy_allowed_transactions_le_types

    • mis_verified = `VERIFIED`

  2. Рецепт поинен бути активним для відпуску ЛЗ

    • is_active = true

    • status = 'ACTIVE'

    • started_at <= current_date() and ended_at >= current_date()

  3. Паті повинен посилатися на активного співробітника в поточному legal_entity

    • employees.is_active = true

    • employees.status = 'APPROVED'

    • employees.legal_entity_id = client_id (context)

  4. Медична програма повинна бути активна для можливості відпуску ЛЗ по даній програмі та дорівнювати програмі в рецепті

    • is_active = true

    • request.medical_program_id = medication_requests.medical_program_id

      • в разі помилки повернути код 409 (`Medical program in dispense doesn't match the one in medication request`)

  5. ЛЗ (brand) повинен бути активним

    1. medications.is_active = true

    2. medications.type = 'BRAND'

    3. ingredients.medication_child_id = medication_request.medication_id and ingredients.is_primary = true

    4. medication_id існує в program_medications (is_active = true)

Перевірити ліцензію відділення

Відділення повинно мати активну ліценцію аптеки для можливості відпуску ЛЗ

  1. Перевірити параметри відділень

    1. division.dls_verified повинні бути дійсні

      1. в будь-якому випадку - повернути помилку 409 ('Invalid division dls status')

Перевірити період відпуску

  1. Перевірити, що дата відпуску в періоді, вказаному в рецепті

    • dispense_valid_from <= current_date()

    • dispense_valid_to >= current_date()

Перевірити інші відпуски ЛЗ

  1. Перевірити всі пов'язані відпуски ЛЗ

  • просумувати medication_qty всіх пов'язаних відпусків ЛЗ < medication_request.medication_qty

  • статус відпуску ЛЗ в ('NEW', 'PROCESSED')

В разі помилки - повернути помилку 403 (повідомлення = "No more medication dispense could be done with this medication request")

Перевірити кількість ЛЗ

  1. Отримати параметр multi_medication_dispense_allowed з налаштувань програми:

    1. якщо дорівнює true - перевірити, що запитана кількість ЛЗ менше або дорівнює кількості ЛЗ в Рецепті

      1. sum(:medication_qty) <= medication_request.medication_qty

        1. в разі помилки - повернути 422 "Dispensed medication quantity must be lower or equal to medication quantity in Medication Request. Available quantity is #{available_qty}"

    2. якщо дорівнює false (absent) - перевірити, що запитана кілкість ЛЗ дорівнює кількості в рецепті

      1. medication_qty = medication_request.medication_qty 

        1. в разі помилки - повернути 422 "Dispensed medication quantity must be equal to medication quantity in Medication Request"

Перевірити кратність ЛЗ

  1. Перевірити, що запитана кількість ЛЗ в відпуску для ЛЗ кратно package_min_qty для цієї medications.id

    •  Mod($medication_qty, medications.package_min_qty) = 0

В разі помилки (якщо хоча б один з ЛЗ не проходить перевірку) - повернути помилку 422

Перевірити суму знижки на ліки

Примітка: Є два різні правила перевірки в залежності від пакету ліків та мінімальної кількості

Якщо мінімальна кількість дорівню кількості пакету - не повинно бути ніякої знижки при розрахунку. 

Перевірка 1: Мінімальна кількість пакету дорівнює кількості пакету

  1. Перевірити, що зареєстрована ціна зі знижкою дорівнює допустимому розміру по договору реімбурсації для запитаної кількості ЛЗ (спосіб розрахунку дозволеної кількості для договору реімбурсації нижче)

Перевірка 2: Мінімальна кількість пакету НЕ дорівнює кількості пакету

  1. Перевірити, що запитана ціна зі знижкою менше або дорівнює допустимій кількості по договору реімбурсації (включаючи відхилення) для запитаної кількості ЛЗ (спосіб розрахунку дозволеної кількості для договору реімбурсації нижче)

  • 1 > = discount_amount/ (((reimbursement_amount/package_qty)*medication_qty)) >= 1 - deviation

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

Отримати розмір відшкодування за ЛЗ

Існує два способи розрахунку розміру відшкодування за договором реімбурсації:

  • FIXED - рівень ремібурсації визначений для package_qty без розрахунків 

  • EXTERNAL - рівень ремібурсації або кількість повинен бути розрахований по виклику API

Важливо: Тільки спосіб FIXED дозволено на першому етапі

  1. Отримати кількість відпуску для medication_id відповідно до medical_program_id

    1. Визначити спосіб розрахунку (FIXEDEXTERNAL)

    2. Розрахувати кількість відпуску для запитаної кількості ЛЗ:

      1. Отримати reimbursement_amount з program_medications.reimbursement.reimbursement_amount (для упаковки)

      2. На основі цього,  package_min_qty та запитаний розмір medication_qty та дозволений ромір відпуску ((reimbursement_amount/package_qty)*medication_qty)

Логіка сервісу

  1. Отримати skip_medication_dispense_sign з налаштувань медичної програми.

2. Якщо skip_medication_dispense_sign = false або відсутня:

2.1. Перевірити payment_id, payment_amount не присутній в запиті.

  • В разі наявності - повернути 422 зі шляхом: $.<field_name>  та додати повідомлення "schema does not allow additional properties"

      2.2. Додати запис до таблиці medication_dispenses:

Параметр

Ресурс

Опис

Параметр

Ресурс

Опис

id

UUID

Генерується автоматично

payment_id

NULL

NULL для записів

status

Const: NEW

NEW skip_medication_dispense_sign = false

Див: Status Charts (reimbursement)

is_active

Const: TRUE

завжди TRUE для нових записів

inserted_at

Timestamp: now()

Отримати поточні дату та час

inserted_by

Token: user_id

Отримати користувача з токену

updated_at

Timestamp: now()

Отримати поточні дату та час

updated_by

Token: user_id

Отримати користувача з токену

   2.3. Додати записи до таблиці medication_dispense_details:

Пареметр

Ресурс

Опис

Пареметр

Ресурс

Опис

id

UUID

Генерується автоматично

medication_dispense_id

FK: medication_dispense

 

reimbursement_amount

Reimbursement

 

3. Якщо skip_medication_dispense_sign =

true:

      3.1. Перевірити, чи payment_amount наявний в запиті.

  • в разі відсутності - повернути 422 зі шляхом: $.payment_amount та повідомленням "required property payment_amount was not present"

      3.2. Визвати процес Process Medication Dispense, але без перевірки цифрового підпису та збереження підписного контенту в бакет.

      3.3. Додати записи як описано на кроках 2.2-2.3, але з наступними відмінностями: 

             medication_dispenses таблиця

Параметр

Джерело

Опис

Параметр

Джерело

Опис

payment_id

Request: payment_id

опціональний параметр

payment_amount

Request: payment_amount

обов'язковий параметр

status

Const: PROCESSED

PROCESSED skip_medication_dispense_sign = true
Див: 

Status Charts (reimbursement)

 

 

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