Короткий опис бізнес-процесу про укладення-договорів по реімбурсації
| Крок | Дія | Результат | Методи API | ||
|---|---|---|---|---|---|
| 1 | Керівник/уповноважена особа аптечного закладу ініціює створення заявки, заповнує та підписує дані КЕП. |
| |||
| 2 | Представник НСЗУ розглядає заявку: призначає виконавця для розгляду заявки |
| |||
| 3 | Назначений НСЗУ працівник: | Відхилена заявка на контрактування | Заява в статусі APPROVED та має доповнені дані
| ||
| 4 | Відхиляє заявку, вказавши причину. | Дозаповнює дані та підписує заявку на котрактування | |||
| 5 | Керівник аптечного закладу | Погоджена заявка набуває статусу PENDING_NHS_SIGN та стає драфтом контракту. | Відхилена заявка набуває статусу ' TERMINATED' | ||
| 6 | Погоджується з умовами та накладає ЕЦП. | Не погоджується з умовами і відхиляє заявку. | |||
| 7 | Представник НСЗУ отримує заявку в статусі PENDING_NHS_SIGN та підписує контракт накладаючи КЕП та цифрова печатка НСЗУ | Статус заявки змінюється на NHS_SIGNED. | |||
| 8 | Керівник/уповноважена особа аптечного закладу отримує лінк та завантажує контракт в статусі NHS_SIGNED та pkcs7 файл; підписує контракт накладаючи КЕП | Статус заявки змінюється на Створеня сутності Договір | |||
- Повторна заявка від закладу деактивує попередні непідписані заявки (ті заявки,що мають '
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 повинен складатися з:
Співробітників підрозділів аптечного закладу, як сутність employee з типами:
"PHARMACY_OWNER"(Аналог з ПМДemployeeз типом"OWNER")"PHARMACIST"(Аналог з ПМДemployeeз типом"DOCTOR")"HR"(Аналог з ПМД employee з типом"HR")
Та перегляду інформації щодо employees для необхідних користувачів модуля.
При розробці інтерфейсів просимо врахувати факт, що для для аптечних закладів при укладення договорів по реімбурсації, завантаження статуту та додаткових документів не обов’язкове.
Специфікація виписування та погашення рецепту
- Технічний опис бізнес-процесу виписування рецепту за програмою реімбурсації:
- Технічний опис бізнес-процесу погашення рецепту за програмою реімбурсації:
- Загальне 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:
В файлі є дві вкладки:
- Співробітники (
pharmacy_employees) - описує поля бази даних щодо аптечних співробітників; - Підрозділи (
divisions) - описує поля щодо аптечних підрозділів.
Примітка: стосовно реєстрації аптечного закладу, як юридичної особи (legal entity) розшифровку полів можна визначити по API.