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

Reimbursation

Owned by Гліб Ущенко (Unlicensed)
Last updated: Sep 11, 2019

Короткий опис бізнес-процесу про укладення-договорів по реімбурсації

КрокДія

РезультатМетоди API
1Керівник/уповноважена особа аптечного закладу ініціює створення заявки, заповнує та підписує дані КЕП.
  • У відповідь надходять згенеровані лінки для завантаження документів
    (опціонально для аптек)
  • Створюється заявка в статусі NEW
2Представник НСЗУ розглядає заявку: призначає виконавця для розгляду заявки
  • Заявка автоматично переходить в статус IN_PROCESS
3Назначений НСЗУ працівник:

Відхилена заявка на контрактування
(status='TERMINATED').

Заява в статусі APPROVED та має доповнені дані 

  • nhs_signer_id - підписант
  • nhs_signer_base – підстава підписання
  • issue_city – місце підписання
  • miscellaneous – додаткові умови
4Відхиляє заявку, вказавши причину.Дозаповнює дані та підписує заявку на котрактування 
5Керівник аптечного закладу
Погоджена заявка набуває статусу PENDING_NHS_SIGN та стає драфтом контракту.
Відхилена заявка набуває статусу 'TERMINATED'
6Погоджується з умовами та накладає ЕЦП.Не погоджується з умовами і відхиляє заявку.
7Представник НСЗУ отримує заявку в статусі PENDING_NHS_SIGN та підписує контракт накладаючи КЕП та цифрова печатка НСЗУСтатус заявки змінюється на NHS_SIGNED.
8Керівник/уповноважена особа аптечного закладу отримує лінк та завантажує контракт в статусі NHS_SIGNED та  pkcs7 файл; підписує контракт накладаючи  КЕП

Статус заявки змінюється на SIGNED

Створеня сутності Договір

  • Повторна заявка від закладу деактивує попередні непідписані заявки (ті заявки,що мають 'NEW', 'IN_PROCESS','APPROVED', 'PENDING_NHS_SIGN', 'NHS_SIGNED') 
  • Зміна в переліку підрозділів та їх атрибутах не впливає на стан контракту.
    Перелік підрозділів є динамічним та підрозділ вважається чинним, якщо він зареєстровано в системі eHealth.
  • Контракт в статусі TERMINATED не підлягає  оновленню, потрібно створювати новий.

Переукладання договору необхідне у випадку:

  • Зміни даних legal entity аптечного закладу (назва, адреса, статус), керівника (ПІБ, статус) в системі, активний контракт тимчасово призупиняється (is_suspended=true).
  • Видалення підрозділу, що є в договорі - контракт тимчасово призупиняється (is_suspended=true)
  • Якщо в аптечний заклад бажає відпускати ліки за реімбурсацією в нових, зареєстрованих після укладання контракту, підрозділах, необхідно переукласти контракт, включивши в нього дані нових підрозділів. 

Контракт оновлюється через новий Contract Request зі вказаним contract_number призупиненого контракту. 

При оновлені контракту слід передати всю інформацію аптечного закладу, включаючи підрозділи, що входять до контракту, адже в процесі оновлення контракту, накладання другого підпису НСЗУ, анулює попередній контракт .

Детальні специфікації для укладання договорів між аптечними закладами та НСЗУ:

Детальний опис бізнес-процесів реєстрації аптечних закладів:

Специфікація для розробки функціоналу реєстрації аптечних закладів.

Для Медичних Інформаційні Системи, які не інтегрувались з eHealth раніше

Необхідно забезпечити реалізацію сервісів Medical Service Provider Integration Layer : авторизації (oAuth), тощо...

Функціонал реєстрації аптечного закладу в eHealth повинен складатися з:
  1. Реєстрації/апдейту/деактивації Аптечного закладу, як сутності legal entity з типом "PHARMACY" (Аналог ПМД legal entity з типом "MSP"); Nа перегляду інформації щодо legal entity для необхідних користувачів модуля.
    1. Опис технологічного процессу.
    2. Посилання на API.

  2. Реєстрації/апдейту/деактивації/активації/ Підрозділу аптечного закладу як сутності Division з типом DRUGSTORE (Аптека) або DRUGSTORE_POINT (Аптечний пункт) (Аналоги з ПМД  Division з типом CLINIC, AMBULANT_CLINIC, FAP); Та перегляду інформації щодо divisions для необхідних користувачів модуля.
    1. Опис технологічного процесу.
    2. Посилання на API.

  3. Реєстрації/апдейту/деактивації/активації Підрозділу аптечного закладу як сутності Division з типом DRUGSTORE (Аптека) або DRUGSTORE_POINT (Аптечний пункт) (Аналоги з ПМД  Division з типом CLINIC, AMBULANT_CLINIC, FAP); xперегляду інформації щодо divisions для необхідних користувачів модуля.

    1. Опис технологічного процесу.
    2. Посилання на API.

  4. Реєстрацію/деактивацію cпівробітників підрозділів аптечного закладу, як сутність employee з типами:
    "PHARMACY_OWNER" (Аналог з ПМД employee з типом "OWNER")
    "PHARMACIST" (Аналог з ПМД employee з типом "DOCTOR")
    "HR"(Аналог з ПМД employee з типом "HR")
    Та перегляду інформації щодо employees для необхідних користувачів модуля.
    1. Опис технологічного процесу.
    2. Посилання на API.

При розробці інтерфейсів  просимо врахувати факт, що для для аптечних закладів при укладення договорів по реімбурсації, завантаження статуту та додаткових документів не обов’язкове.

Специфікації виписування та погашення рецепту

Зверніть увагу:

На виконання закону України «Про захист персональних даних», закону України «Про захист інформації в інформаційно-телекомунікаційних системах», постанови КМУ №373 від 29.03.2006 р. та №938 від 07.09.2011р., інформаційно-телекомунікаційні системи, де є персональні дані громадян України, повинні бути захищені. 

За детальною інформацією по цьому напрямку Ви можете звернутись до відповідальної особи зі сторони ДП «Електронне здоров’я» Романа Єгорченко, електронна адреса: roman.iegorchenko@ehealth.gov.ua

Зміни щодо технічного бізнес-процесу погашення Електроного Рецепту

У зв’язку з наявністю в НПА можливості відпускати ліки аптечним закладам протягом 30 днів після прийняття нового «Реєстру лікарських засобів, які підлягають реімбурсації» (далі - Реєстр) за старим Реєстром, в ЦБД та МІС повинні бути внесені зміни.

НПА, що регламентують наявність двох одночасних Реєстрів:

Постанова Кабінету Міністрів України від 17 березня 2019 року № 152 “Про забезпечення доступності лікарських засобів” (далі - Постанова), зокрема, 

  • пункт 18 Порядку визначення розміру реімбурсації лікарських засобів затвердженого Постановою згідно якого аптекам та аптечним пунктом дозволяється протягом 30 календарних днів з дати затвердження МОЗ оновленого Реєстру завершити реалізацію закуплених до зазначеної дати лікарських засобів, які підлягають реімбурсації, відповідно до цін та у порядку, що діяли до дати затвердження МОЗ оновленого Реєстру.

Зміни в API

  • Додаткові параметри в API eHealth по endpoint Qualify Medical Request by ID 

    В масиві participants по кожному participant (участнику програми “Доступні ліки”) додатково будуть надходити наступні параметри:
    • program participant identifier - унікальний ідентифікатор учасника програми “Доступні ліки” в Реєстрі 
    • participants.id = program_medication_id- Торгова назва з конкретними цінами з визначеного та діючого на поточний час реєстру.
    • participants.start_date - дата початку дії реєстру в якому є даний participant. 
    • participants.end_date - дата початку дії реєстру в якому є даний participant.
    • articipants.registry_number- номер реєстру в якому є даний participant.

МІС користувач (фармацевт) окрім переліку можливих до відпуску за ЕР торгівельних назв і цін повинен бачити в інтерфейсі:

  • номер реєстру  participants.registry_number
  • дата початку дії реєстру participants.start_date
  • дата закінчення дії реєстру participants.end_date

Якщо в якомусь participant параметр буде пустий, це означає, що цей параметр нормативно невідомий на поточний час.

Наприклад, параметр end_date конкретного participant  може бути визначений в системі лише після дати прийняття нового реєстру.

Увага!

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

Увага!

Слід чітко розділяти зміст сутностей medication.id та program_medication_id

  • medication.id  - ідентифікатор, який характеризує торгівельну назву засобу.
  • program_medication_id - ідентифікатор, який характеризує ціни торгівельну назви в конкретному «Реєстрі лікарських засобів, які підлягають реімбурсації».


Увага!

 В переліку кандидатів на погашення Електроного Рецепту тепер може бути декілька program_medication_id з однаковим medication.id, але з різними цінами на відшкодування згідно декількох одночасно діючих реєстрів.

  • Додаткова передача id участника програми  (program_medication_id) при погашені ЕР.

Після вибору можливого кандидата на погашення ЕР за програмою “Доступні ліки” з переліку participants, в endpoint`ах Сreate Medication Dispense, Process Medication Dispense, Reject Medication DispenseМІС додатково передає id учасника програми program_medication_id в масиві даних dispense_details.

Для недопущення зупинки процесу погашення рецептів параметр program_medication_id після появи функціоналу в ЦБД буде опційний і якщо МІС не вкаже program_medication_id то  в ЦБД буде вказуватись program_medication_id з останнього прийнятого реєстру по-замовчуванню. 

Після затвердження нового реєстру (орієнтовно 01.08.19) program_medication_id стане обов’язковим параметром.Також параметр program_medication_id буде повертатися в запитах Get Medication Dispenses List, Get Medication Dispense by ID

В системі повинно бути зафіксовано саме яким участником Реєстру буде погашено ЕР і саме за яким Реєстром Аптечний Заклад буде очікувати відшкодування за відпущені ліки.

Увага!

Якщо ЕР буде виписаний поза програмою, то program_medication_id не потрібно вказувати в endpoint`ах Сreate Medication Dispense та Proccess Medication Dispense .

 ПРОЕКТ ЗМІН ДО ТЕХНІЧНИХ ВИМОГ

В технічні вимоги до МІС буде внесено наступні доповнення: (виділено блакитним шрифтом):


3.4.4.5 отримання та відображення переліку ЛЗ з «Реєстру лікарських засобів, вартість яких підлягає відшкодуванню» (далі - Реєстр відшкодування), які задовольняють вимогам ЕР. 

3.4.4.5.1 обов’язковий перелік: 

  • торгівельна назва «participants.medication_name»,
  • форма випуску «participants.form», 
  • назва виробника та країна виробника «participants.manufacturer»,
  • кількість в упаковці «participants.package_qty», 
  • номер реєстру відшкодування «participants.registry_number» ,
  • дата початку дії реєстру відшкодування «participants.start_date»,
  • дата закінчення дії реєстру відшкодування «participants.end_date», (якщо параметр відсутній, слід виводити текст “не визначено”),
  • розмір відшкодування за упаковку лікарського засобу згідно реєстру відшкодування «participants.registry_number» , грн. «participants.reimbursement_amount»,
  • сума доплати пацієнтом за упаковку згідно реєстру відшкодування «participants.registry_number», грн

«participants.estimated_payment_amount».


3.4.4.6 Обрання користувачем торгівельного найменування для відпуску, відповідно до побажань пацієнта та внутрішніх процесів АЗ пов’язаних з реалізацією ліків за відповідними реєстрами відшкодування. 

3.4.4.6.1 МІС повинна забезпечити користувачу можливість обрати з запропонованого переліку тільки одну торгову назву і тільки з одного визначеного користувачем реєстру відшкодування «participants.registry_number» сформувавши таку інформацію:

  • обране торгове найменування у реєстрі відшкодування «participants.registry_number».
  • кількість виписаного ЛЗ «medication_qty», 
  • ціна за 1 упаковку «sell_price», 
  • загальна ціна «sell_amount», 
  • вартість на відшкодування однієї упаковки «Reimbursement_amount» у реєстрі відшкодування «participants.registry_number» , 
  • загальна вартість відшкодування в рамках реімбурсації даного рецепту «discount_amount» згідно реєстру відшкодування «participants.registry_number».

3.4.4.7 створення заявки на погашення ЕР, введення коду підтвердження ЕР:

3.4.4.7.1 якщо в результаті процесу обрання торгової назви є згода між пацієнтом на користувачем та керуючись внутрішніми процесами АЗ, пов’язаних з обранням користувачем того чи іншого реєстру відшкодування, МІС повинна створити заявку на погашення ЕР з кодом підтвердження від пацієнта та обов’язковим зазначенням «program_medication_id» що відповідає обраному користувачем учасника реєстру відшкодування. В результаті успішного створення заявки ЕР закріплюється за поточним АЗ для виписування на 10 хвилин і не може бути погашений в іншому АЗ протягом цього терміну;

3.4.4.9 погашення ЕР та скріплення факту відпуску ліків КЕП користувача як співробітника АЗ:

  • МІС повинна сформувати необхідний контент у json файл відповідно до API системи та технічних вимог до МІС,
  • користувач в МІС повинен підписати json КЕП співробітника аптеки,
  • МІС повинна перекодувати підписаний json у base64 формат,
  • МІС повинна виконати відповідний запит до системи;

Візуалізація прикладу дії двох реєстрів одночасно

Візуалізація різних прикладів-кейсів роботи з одним ТН в двох реєстрах

r-a = reimbursement amount


Модель даних та словник термінів

Відповідаючи на питання щодо реєстрації аптечних закладів:
  • Як реєструвати співробітників аптеки, які без рівня кваліфікації провізора або ще навчаються, однак працюють в аптеці як провізори, фармацевти?
  • Як необхідно назвати поля в МІС, для вірності відображення сутністі атрибутів співробітника?
  • Як зареєструвати аптечний пункт в якості підрозділу аптечного закладу?

Ми створили Модель даних та словник термінів, який буде корисним всім розробникам МІС без виключення, що реалізовують функціонал реєстрації аптек в eHealth:

В файлі  є дві вкладки:

  1. Співробітники (pharmacy_employees) - описує поля бази даних щодо аптечних співробітників;
  2. Підрозділи  (divisions) - описує поля щодо аптечних підрозділів.

Примітка: стосовно реєстрації аптечного закладу, як юридичної особи (legal entity) розшифровку полів можна визначити по API.

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