Table of Contents |
---|
Короткий опис бізнес-процесу про укладення-договорів по реімбурсації
Крок | Дія | Результат | Методи API | ||
---|---|---|---|---|---|
1 | Керівник/уповноважена особа аптечного закладу ініціює створення заявки, заповнує та підписує дані КЕП. |
| |||
2 | Представник НСЗУ розглядає заявку: призначає виконавця для розгляду заявки |
| |||
3 | Назначений НСЗУ працівник: | Відхилена заявка на контрактування | Заява в статусі APPROVED та має доповнені дані
| ||
4 | Відхиляє заявку, вказавши причину. | Дозаповнює дані та підписує заявку на котрактування | |||
5 | Керівник аптечного закладу | Погоджена заявка набуває статусу PENDING_NHS_SIGN та стає драфтом контракту. | Відхилена заявка набуває статусу ' TERMINATED ' | ||
6 | Погоджується з умовами та накладає ЕЦП. | Не погоджується з умовами і відхиляє заявку. | |||
7 | Представник НСЗУ отримує заявку в статусі PENDING_NHS_SIGN та підписує контракт накладаючи КЕП та цифрова печатка НСЗУ | Статус заявки змінюється на NHS_SIGNED . | |||
8 | Керівник/уповноважена особа аптечного закладу отримує лінк та завантажує контракт в статусі NHS_SIGNED та pkcs7 файл; підписує контракт накладаючи КЕП | Статус заявки змінюється на Створеня сутності Договір |
Note |
---|
|
Tip | ||
---|---|---|
| ||
Контракт оновлюється через новий Contract Request зі вказаним contract_number призупиненого контракту. При оновлені контракту слід передати всю інформацію аптечного закладу, включаючи підрозділи, що входять до контракту, адже в процесі оновлення контракту, накладання другого підпису НСЗУ, анулює попередній контракт . |
Детальні специфікації для укладання договорів між аптечними закладами та НСЗУ:
Детальний опис бізнес-процесів реєстрації аптечних закладів:
Специфікація для розробки функціоналу реєстрації аптечних закладів.
Note | ||
---|---|---|
| ||
Необхідно забезпечити реалізацію сервісів Medical Service Provider Integration Layer : авторизації (oAuth), тощо... |
Panel | ||
---|---|---|
| ||
Panel | ||
|
При розробці інтерфейсів просимо врахувати факт, що для для аптечних закладів при укладення договорів по реімбурсації, завантаження статуту та додаткових документів не обов’язкове.
Специфікаці]Специфікації виписування та погашення рецепту
- Технічний опис бізнес-процесу виписування рецепту за програмою реімбурсації:
- Технічний опис бізнес-процесу погашення рецепту за програмою реімбурсації:
- Загальне API щодо електронних рецептів:
- Загальний бізнес-процес щодо погашення рецептів:
- Бізнес-процеси, пов’язані з виписуванням електронного рецептута відпуску ЛЗ за електронним рецептом в рамках реімбурсації
Note | ||
---|---|---|
| ||
На виконання закону України «Про захист персональних даних», закону України «Про захист інформації в інформаційно-телекомунікаційних системах», постанови КМУ №373 від 29.03.2006 р. та №938 від 07.09.2011р., інформаційно-телекомунікаційні системи, де є персональні дані громадян України, повинні бути захищені. За детальною інформацією по цьому напрямку Ви можете звернутись до відповідальної особи зі сторони ДП «Електронне здоров’я» Романа Єгорченко, електронна адреса: roman.iegorchenko@ehealth.gov.ua |
Зміни щодо технічного бізнес-процесу погашення Електроного Рецепту
Info |
---|
У зв’язку з наявністю в НПА можливості відпускати ліки аптечним закладам протягом 30 днів після прийняття нового «Реєстру лікарських засобів, які підлягають реімбурсації» (далі - Реєстр) за старим Реєстром, в ЦБД та МІС повинні бути внесені зміни. НПА, що регламентують наявність двох одночасних Реєстрів: Постанова Кабінету Міністрів України від 17 березня 2019 року № 152 “Про забезпечення доступності лікарських засобів” (далі - Постанова), зокрема,
|
Anchor | ||||
---|---|---|---|---|
|
Додаткові параметри в 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 може бути визначений в системі лише після дати прийняття нового реєстру.
Note | ||
---|---|---|
| ||
Поява тих чи інших торгівельних назв з конкретними цінами та даними приналежністі до того чи іншого реєстру, в переліку буде відбувається автоматично та згідно прийнятих законодавчо реєстрів. |
Note | ||
---|---|---|
| ||
Слід чітко розділяти зміст сутностей
|
Note | ||
---|---|---|
| ||
В переліку кандидатів на погашення Електроного Рецепту тепер може бути декілька |
Додаткова передача 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
В системі повинно бути зафіксовано саме яким участником Реєстру буде погашено ЕР і саме за яким Реєстром Аптечний Заклад буде очікувати відшкодування за відпущені ліки.
Note | ||
---|---|---|
| ||
Якщо ЕР буде виписаний поза програмою, то program_medication_id не потрібно вказувати в endpoint`ах Сreate Medication Dispense та Proccess Medication Dispense . |
Expand | ||
---|---|---|
| ||
В технічні вимоги до МІС буде внесено наступні доповнення: (виділено блакитним шрифтом): 3.4.4.5 отримання та відображення переліку ЛЗ з «Реєстру лікарських засобів, вартість яких підлягає відшкодуванню» (далі - Реєстр відшкодування), які задовольняють вимогам ЕР. 3.4.4.5.1 обов’язковий перелік:
«participants.estimated_payment_amount». 3.4.4.6 Обрання користувачем торгівельного найменування для відпуску, відповідно до побажань пацієнта та внутрішніх процесів АЗ пов’язаних з реалізацією ліків за відповідними реєстрами відшкодування. 3.4.4.6.1 МІС повинна забезпечити користувачу можливість обрати з запропонованого переліку тільки одну торгову назву і тільки з одного визначеного користувачем реєстру відшкодування «participants.registry_number» сформувавши таку інформацію:
3.4.4.7 створення заявки на погашення ЕР, введення коду підтвердження ЕР: 3.4.4.7.1 якщо в результаті процесу обрання торгової назви є згода між пацієнтом на користувачем та керуючись внутрішніми процесами АЗ, пов’язаних з обранням користувачем того чи іншого реєстру відшкодування, МІС повинна створити заявку на погашення ЕР з кодом підтвердження від пацієнта та обов’язковим зазначенням «program_medication_id» що відповідає обраному користувачем учасника реєстру відшкодування. В результаті успішного створення заявки ЕР закріплюється за поточним АЗ для виписування на 10 хвилин і не може бути погашений в іншому АЗ протягом цього терміну; 3.4.4.9 погашення ЕР та скріплення факту відпуску ліків КЕП користувача як співробітника АЗ:
Візуалізація прикладу дії двох реєстрів одночасноВізуалізація різних прикладів-кейсів роботи з одним ТН в двох реєстрахr-a = reimbursement amount |
Модель даних та словник термінів
Panel | ||
---|---|---|
| ||
Ми створили Модель даних та словник термінів, який буде корисним всім розробникам МІС без виключення, що реалізовують функціонал реєстрації аптек в eHealth: В файлі є дві вкладки:
Примітка: стосовно реєстрації аптечного закладу, як юридичної особи (legal entity) розшифровку полів можна визначити по API. |