ЕСОЗ - публічна документація
Reimbursement v.3 changes
Реімбурсація 3.0: Функціональні вимоги до створення та погашення рецептів
Основа функціоналу реімбурсації 2.0 є розроблений функціонал реімбурсації 1.0 в системі eHealth :https://edenlab.atlassian.net/wiki/spaces/EH/pages/2830222/Reimbursement
1. Функціональні вимоги до створення та погашення рецептів у реімбурсації 2.0 складаються з переліку змін до реімбурсації 1.0 для eHealth
№ | Назва CR | Статус |
1.1 | Часові позначки: налаштування інтервалу повторного виписування рецепту.
2) Якщо тривалість лікування менше ніж 21 день, то повторно пацієнт може отримати рецепт на той же самий МНН+форма випуску за 3 дні до закінчення лікування (ended at - 3 days) | Тестування + |
1.2 | Сценарій перевірки номера телефону пацієнта перед виписуванням рецепта Маскування номеру телефону +38066*****55 | Тестування + |
1.3 | Додати поля для сигнатури рецепту Буде зроблено в грудні як сутність Medication Plan | Тестування + |
1.4 | Погашення рецепту в аптеці повинно підписуватись ЕЦП особою, як співробітником закладу | Тестування + |
1.5 | Підпис відзиву рецепту ЕЦП лікарем | Тестування + |
1.6 | Додати можливість реєструвати співробітника, який не має фармацевтичної освіти в аптеці Новий тип співробітника можна додати через довідник. Це може бути зроблено в будь який момент та не потребує додаткової розробки | Заплановано на реліз 8.12 |
1.7 | Доопрацювання пошуку ЛЗ фільтром за програмою реімбурсації НСЗУ | Тестування + |
1.8 | Налаштувати метод pre-qualify в програмі реімбурсації | Зроблено + |
1.9 | Додати текст СМС при створенні та анулюванні рецепту | Тестування + |
1.10 | Змінити перелік полів для рецепту, що бачить співробітник аптеки:
| Заплановано на реліз 8.12 |
1.11 | Поля довідника SNOMED в INN management зробити опціональними | Зроблено + |
1.12 | Закрити можливість owner створювати “клони” облікового запису | Зроблено + |
1.13 | Додати до учасника програми атрибути, які заповнюються в адмінці:
Перевірити неймінг та формат:
- participants.consumer_price: роздрібна ціна за упаковку, грн - параметр участника - participants.daily_dosage: добова доза лікарського засобу, рекомендована ВООЗ - параметр участника - participants.reimbursement_daily_dosage: розмір відшкодування добової дози лікарського засобу, грн - параметр торгового найменування - participants.reimbursement_amount: розмір відшкодування за упаковку лікарського засобу, грн. - параметр участника - participants.estimated_payment_amount: сума доплати за упаковку, грн - параметр участника | Заплановано на реліз 8.12 |
1.14 | Рецепт по реімбурсації може бути погашений тільки з підрозділу, який присутній в контракті | Заплановано на реліз 8.12 |
1.15 | Налаштування окремого СМС каналу для відправки СМС по реімбурсації | Питання на стороні НСЗУ |
1.16 | Доповнення запиту фармацевта інформацією про упаковку участника програми:
-participants.package_min_qty: мінімальна неподільна кратність в упаковці | Заплановано на реліз 8.12 |
1.17 | Налаштування середовища по реімбурсації: - реєстр по реімбурсації; - налаштування довідників (юніти, форми випуска, тощо, кваліфікації тощо.) | Заплановано на реліз 8.12 |
1.18 | ОТП код для пациентов с оффлайн верификацией. Разработчики против | На обговорені з розробниками |
1.19 | Два реестри по реїмбурсації одночасно | На обговорені з розробниками. Задача буде реалізована після 1.04 |
1.20 | Вивести в адмінку налаштування часових проміжків | На обговоренні |
1.21 | Інтеграція з реєстром ДЛС | На обговоренні |
* Імпортувати словник МНН з файлу від НСЗУ | ||
* Інтеграція реєстру ДРЛЗ | ||
* Періодичне оновлення реєстру ДРЛЗ | ||
* Деактивація торгового найменування при його видаленні з реєстру ДРЛЗ | ||
* Якщо division буде додано після підписання договору, то LE може подати заявку і вона буде автоматично ухвалено зі стороні НСЗУ Реєстрація division в системі не означає, що він може працювати з програмою реімбурсації |
1.1. Часові позначки: налаштування інтервалу повторного виписування рецепту
Логіка часових позначків в системі повинно бути налаштована згідно вказаних в таблиці нижче
Дата створення рецепту є першим днем, коли за ним можна отримати ЛЗ | dispense valid from = created at Забрати з API dispense valid from |
Строк дії рецепту складає 30 днів | dispensed valid to = dispensed valid from + 30 days |
Дата початку лікування зазначається лікарем при виписуванні рецепту. | started at = > created at |
Дата завершення лікування визначається лікарем при виписуванні рецепту в системі шляхом зазначення тривалості лікування в днях -- treatment days (МІС вертає в ЦК дату ended at). | ended at = started at + treatment days |
Для ЛЗ, що підлягають реімбурсації, новий рецепт на той же ЛЗ (МНН+Форма випуску) можна виписати не раніше ніж за таку кількість днів до закінчення лікування:
2) Якщо тривалість лікування менше ніж 21 день, то повторно пацієнт може отримати рецепт на той же самий МНН+форма випуску за 3 дні до закінчення лікування (ended at - 3 days) | if (ended at - started at) => 21 days than NEW created at := (ended at) - 7 days if (ended at - started at) < 21 days than NEW created at := (ended at) - 3 days |
Срок валидности заключения врача. Сколько заключение это может быть?
Created at <= Started at <= dispensed valid to
1.2. Сценарій перевірки номера телефону пацієнта перед виписуванням рецепта
Перед тим як СМС з номером рецепту та кодом погашення буде відправлено на телефон пацієнта слід його вивести на екран в МІС.
Мета: уточнити лікарю у пацієнта чи цей номер належить до пацієнта або ні.
Якщо номер відомий пацієнту, то лікар підтверджує натисканням кнопки “ТАК” - рецепт формується, та СМС надсилається пацієнту на вказаний номер телефону.
Якщо лікар натисніть “НІ”, то рецепт не може бути виписаний пацієнту. СМС не надсилається. Пацієнту слід звернутися до НСЗУ для зміни номеру телефону.
1.3. Додати поля для сигнатури рецепту
Сигнатура рецепту буде частиною сутності Medication Plan
Додати в запит на створення електронного рецепту масив полей, які характеризують спосіб вживання ліків.
На даному випадку був прийнятий наступний перелік полів для електронного рецепту:
- Кількість прийому на день (qty_per_day)
- Кількість доз на прийом (qty_per_time)
- Тривалість лікування (treatment_days)
- Додаткові вказівки (treatment_info).
1.4. Погашення рецепту в аптеці повинно підписуватись ЕЦП особою, як співробітником закладу
Співробітники аптеки, що реєструють відпущення ліків повинні бути зареєстровані в системі і мати ЕЦП як співробітника закладу.
Система повинна перевіряти таке ЕЦП при погашені рецепту.
Якщо ЕЦП видано не на зареєстровану в системі особу, або ЕЦП яким підписаний факт погашення рецепту не відноситься до ЕЦП особи, що працює в аптечному закладі, то повинна повертатися помилка. На зміну статусу рецепту дана помилка не впливає.
1.5. Підпис відкликання рецепту ЕЦП лікарем
В разі відкликання рецепту лікар повинен підписати таку операцію своїм ЕЦП.
Відкликати рецепт може лікар, який його виписав.
Рецепт може бути відкликаний тільки в статусі ACTIVE
1.6. Додати можливість реєструвати співробітника, який не має фармацевтичної освіти в аптеці
В системі додати ще один тип співробітника pharmacist 3, який повністю повторює scope прав співробітника pharmacist 2.
Створення нового співробітника можливо на рівні довідників
1.7. Доопрацювання пошуку ЛЗ фільтром за програмою реімбурсації НСЗУ
З метою організації пошуку на стороні МІС ЛЗ тільки по програмі реімбурсації зробити можливим використовувати фільтр за конкретною програмою
1.8. Налаштувати метод pre-qualify в програмі реімбурсації
1.9. Додати текст СМС при створенні та анулюванні рецепту
Текст смс при створенні рецепту: “Вам виписано рецепт: ХХХХ-ХХХХ-ХХХХ-ХХХХ, код підтвердження: ХХХХ” 67 символів
Текст смс при анулюванні рецепту лікарем необхідно додати можливість надсилання СМС на номер пацієнта. Текст смс: “Рецепт анульовано: номер ХХХХ-ХХХХ-ХХХХ-ХХХХ”
1.10. Змінити перелік полів для рецепту, що бачить співробітник аптеки
- Інформація щодо пацієнта, яка може бути доступна по запросам співробітників аптеки: id пацієнта, прізвище та ініціали пацієнта, повний вік пацієнта
Юридичний аналіз:
https://docs.google.com/document/d/1aTgluLapOg8dmpLUja_V1tokbw0nqk7ECBQiynpmquE/edit?usp=sharing
2) Додати до атрибутів legal_entity, які повертаються при запитах співробітників аптеки Інформацію про ліцензію на медичну практику
Елемент даних який необхідно передавати в аптеку | |
1. Пацієнт | |
ID пацієнта (відображення в МІС як “Номер медичної карти амбулаторного хворого”) | |
Прізвище та ініціали пацієнта | |
Кількість повних років пацієнта | |
Технічний аналіз Приклад поточного json: "person": { "id": "b075f148-7f93-4fc2-b2ec-2d81b19a9b7b", "first_name": "Петро", "last_name": "Іванов", "second_name": "Миколайович", "age": 35 }, Скоротити поля у сутності person, які віддаються аптекам на запити стосовно рецепту пацієнта first_name и second_name до першої літери Таким чином, інформація, яка доступна по запросам провізору буде: id пацієнта, прізвище та ініціали пацієнта, повний вік пацієнта. Приклад json після сhange request: "person": { "id": "b075f148-7f93-4fc2-b2ec-2d81b19a9b7b", "first_name_initials": "П", "last_name": "Іванов", "second_name_initials": "М", "age": 35 | |
Юридичний аналіз: | |
2. Лікар | |
Прізвище та ініціали лікаря що виписав рецепт | |
Технічний аналіз Приклад поточного json: "employee": { 1) Забрати в employee та party всі поля, крім полей first_name и second_name 2) Скоротити поля в “employee”, які віддаються аптекам на запити стосовно рецепту пацієнта first_name и second_name до першої літери Приклад json після сhange request: "employee": { Таким чином, провізору буде доступна інформація про лікаря: Прізвище на ініціали | |
3. Надавач | |
Повне найменування надавача / ПІБ лікаря ФОП | |
Код ЄДРПОУ / РНОКПП (ІПН) або серія і номер паспорту | |
Юридична адреса надавача | |
Інформація про ліцензію на медичну практику (такої інформації в системі не має) | |
Технічний аналіз Приклад поточного json: "legal_entity": {
Таким чином, інформація, яка доступна по запросам провізору буде:
Приклад json після сhange request: "legal_entity": { "addresses": [ ], | |
4. Рецепт | |
ID рецепта | |
Статус | |
Дата виписування рецепта | |
Термін дії рецепту | |
Технічний аналіз Приклад поточного json: { "id": "b075f148-7f93-4fc2-b2ec-2d81b19a9b7b", | |
5. Призначення | |
Назва МНН (INN) | |
Форма випуску | |
Сила дії | |
Кількість доз | |
Поля сигнатури | |
Технічний аналіз Приклад поточного json: "medication_info": { - Кількість прийому на день (qty_per_day) - Кількість доз на прийом (qty_per_time) - Тривалість лікування (treatment_days) - Додаткові вказівки (treatment_info) | |
Опції відпуску | |
Можливі торгові назви фармацевтичних продуктів (відповідно до призначення за МНН) та їх атрибути. | |
Технічний аналіз Приклад поточного json: "details": [ | |
Фінансування (для рецептів за програмами реімбурсації) | |
Назва програми реімбурсації | |
Повна ціна відпуску за упаковку sell_price | |
Сума відшкодування за упаковку reimbursement_amount | |
Сума для доплати пацієнтом за упаковку sell_price-reimbursement_amount | |
Технічний аналіз Приклад поточного json: "program_id": "59781de0-2e64-4359-b716-bcc05a32c10f", "program_name": "Програма "Доступні ліки"", "sell_price": 18.65, - цена за минимальное неделимое количество таблеток. "sell_amount": 186.5, - Повна ціна відпуску за упаковку "reimbursement_amount": 450 - Сума відшкодування за упаковку |
1.11. Поля довідника SNOMED в INN management зробити опціональними
Поскольку на данном этапе справочник является практически неиспользуемым в Украине, а структура данного справочника уже интегрирована в eHealth, то все заполняемые поля, которые касаются данного справочника сделать опциональным и не использовать в поиске.
1.12. Закрити можливість owner створювати “клони” облікового запису
Слід закрити можливість для owner створювати “клони” свого облікового запису зі скоупом виписування рецептів.
Раніше даний функціонал було створено з наступною метою.
В аптеках працюють не тільки співробітники, які не мають фармацевтичної освіти, але такі, що навіть не працевлаштовані офіційно (!). Тому в системі був реалізований функціонал (це були напрацювання проектного офісу з представниками аптечних закладів), який дозволяє “клонувати” власнику аптеки свій обліковий запис. І саме це була одна з причин відмови від ЕЦП.
Така проблема є масовою. І може бути ризиком, чому аптека не буде підключатись до програми реімбурсації.
1.13. Інтеграція реєстру реімбурсованих препаратів в eHealth
http://moz.gov.ua/uploads/1/6148-dn_20180723_1367_dod.pdf
Додати до учасника програми атрибути, які заповнюються в адмінці:
- Оптово-відпускна ціна за упаковку, грн (формат до 1 копейки: хх,хх грн)
- Роздрібна ціна за упаковку, грн (формат до 1 копейки: хх,хх грн)
- Добова доза лікарського засобу, рекомендована ВООЗ mg
- Розмір відшкодування добової дози лікарського засобу, грн (формат 4 знаки після коми: хх,хххх грн)
- Сума доплати пацієнтом за упаковку, грн (формат до 1 копейки: хх,хх грн)
Перевірити неймінг та формат:
- Розмір відшкодування за упаковку лікарського засобу, грн (формат до 1 копейки: хх,хх грн)
Повертати всі атрибути при запиті аптекою лікарського засобу за програмою.
1.14. Друкована форма типового договору
https://drive.google.com/file/d/1YFvHYsOuxc-gQjIu7dDy1ni0vwWL2yU8/view?usp=sharing
1.15. Два реєстри по реімбурсації одночасно
Согласно законодательства одновременно может существовать два реестра по реимбурсации "доступні ліки".
Один еще продолжает действовать, когда другой уже начинает действовать.
Другой принятый реестр автоматически отменяет предыдущий реестр через 30 дней.
Для чего это сделано:
законодательно заложили временной лаг в 1 месяц, чтобы аптеки успели продать закупленные ранее препараты, а государство компенсировало их стоимость согласно предыдущего реестра под который препараты закупались.
Логика на примере:
01.01.19 МОЗ принимается реестр 0119.
01.06.19 МОЗ принимается реестр 0219, при этом для реестра 0119 устанавливается срок жизни 01.06.19 + 30 дней.
С 01.01.19 до 01.06.19 аптекам на запрос по рецепту возвращаются участники программы с реестра 0119
С 01.06.19 до 01.07.19 аптекам на запрос по рецепту возвращаются участники программы с реестров 0119 и 0219.
с 01.07.19 все участники программы с реестра 0119 становятся terminated (не могут быть выданы на запрос по рецепту), они могут отражаться только в отчетах.
В двух реестрах могут быть одни и теже участники программы реимбурсации. Торговое название, производитель - одинаковые, но могут отличаться столбцы 11-16 http://moz.gov.ua/uploads/1/6148-dn_20180723_1367_dod.pdf
Таким образом, с периода 01.06.19 по 01.07.19 в аптеку за запрос по рецепту будут приходить две строчки с одинаковым торговым наименованием, но разной ценой.
Какую строчку из двух выбрать аптеке для погашения рецепта выбранным торговым наименованием решает аптека (внешние процессы связанные со складским учетом и остатками на складе)
Вариант решения задачи:
1) подготовить основу для дальнейшей логики до 03.19
2) реализовать логику задачи до 06.19
Основа:
1) Для участника программы внести атрибут "Номер реестра по реимбурсации"
2) Для участника программы внести атрибут "Дата старта действия в программе"
3) Для участника программы внести атрибут "Дата окончания действия в программе"
Логика:
1) Если в систему вносится новый участник программы с таким же торговым наименованием, но уже с отличным номером реестра, то на участника программы с таким же торговым наименованием, который ранее был в системе автоматически проставляется атрибут "Дата окончания действия в программе" = дата старта по новому реесту + 30 дней.
1.14.* Імпортувати словник МНН з файлу від НСЗУ
Це є задачею для адмінки НСЗУ, структуру файлу та сам файл НСЗУ нададуть пізніше. Задача може бути виконане з низьким пріоритетом.
При наявності даного файлу зробити імпорт МНН у систему.
Структура файлу повинна мати mnn name та mnn original name поля.
Розглянути можливість організації контекстного пошуку на стороні МІС.
1.15.* Інтеграція реєстру ДРЛЗ
Первоисточником о зарегистрированных торговых наименованиях лекарственных средств является реестр ДРЛЗ.
Сейчас происходит изменение бизнес требований к архитектуре ДРЛЗ и после ее утверждения будет поставлена задача на его интеграцию
Буде файл, який необхідно імпортувати
1.16.* Оновлення реєстру ДРЛЗ
Создать скрипт для периодического обновления ДРЛЗ в eHealth,
Ориентировочный интервал обновления- 1 сутки,
Продумать механизм обновления,
1.17.* Деактивація торгового найменування при його видаленні з реєстру ДРЛЗ
Требования к деактивации и срокам будут прописаны позднее.
2. Функціональні вимоги до створення та погашення рецептів у реімбурсації 2.0 складаються з переліку змін до реімбурсації 1.0 для розробників МІС
В рамках створення системи eHealth слід забезпечити наступний рекомендований функціонал на стороні МІС
№ | Назва CR | Статус |
2.1 | Позначення рецептів, що були оформлені по зверненню пацієнта за телефоном | до реалізації МІС |
2.2 | Взаємодія з іншими процесами: вхід лікаря на процес виписування рецепту | до реалізації МІС |
2.3 | Передача результатів виписки лікарського засобу в резюме візиту до лікаря | до реалізації МІС |
2.4 | Пошук в Drugs dictionary по АТХ коду | до реалізації МІС |
2.5 | Сповіщення лікаря щодо непогашеного рецепту за 30 днів | до реалізації МІС |
2.6 | Зберігати рецепт, що не підписано ЕЦП на стороні МІС в статусі DRAFT | Повністю реалізувати на стороні МІС |
- Функціональні вимоги до створення та погашення рецептів у реімбурсації 2.0 складаються з переліку змін до реімбурсації 1.0 для розробників МІС які буде імплементовано в релізах після 01.04.19
№ | Назва CR | Статус |
3.1 | Можливість повторної отправки СМС | На обговоренні з розробниками |
3.2 | Налаштування % часу для повторного виписування рецепту за програмою реімбурсації в адмінці | На обговоренні з розробниками |
3.3 | Перелік причин анулювання рецепту | На обговоренні з НСЗУ та розробниками |
3.4 | Додати інформацію про час при погашені рецепту | На обговоренні з розробниками |
3.5 | Після потрапляння заявки до НСЗУ автоматично поставити її у статус APPROVED і автоматично сформувати драфт контракту | На обговоренні з НСЗУ |
3.6 | Інтеграція з ліцензійним реєстром ДЛС та налаштування правил автоматичних перевірок | Очікуємо якісного реєстру ДЛС |
2.1. Позначення рецептів, що були оформлені по зверненню пацієнта за телефоном
Функціональність реалізована в першій фазі Medical Events: у нас є Encounter.type які мають діагностовані хронічні захворювання та стабільну схему лікування. Такі пацієнти звертаються до лікаря телефоном, повідомляють про потребу в ліках та просять виписати рецепт. Лікар, що веде такого пацієнта знає його/її історію хвороби, бачить попередні призначення і може прийняти рішення про виписування рецепту по телефону. Таке виписування ЛЗ помічається в системі спеціальною позначкою (атрибут рецепту в реєстрі рецептів).
Слід добавити новий обов'язковий до заповнення атрибут до рецепту, яким чином він був створений:
- рецепт виписано при прийомі: visit;
- рецепт виписано віддалено: remote.
Ця задача буде виконана в рамках мед-івентів приблизно у релізі квітня. Тобто, лікар записує мед-рекорд, і вказує, що пацієнт звернувся за телефоном, і результат звернення - рецепт. Це логічний шлях.
2.2. Взаємодія з іншими процесами: вхід лікаря на процес виписування рецепту
Задача для МІС. Рецепт виписується в рамках Encounter, з посиланням на нього. Але, варто зазначити, що технічно подається через окремий endpoint і є окремим документом.
Лікар оформляє звернення пацієнта в системі в рамках функціоналу електронних медичних записів. За умови вибору коду процесу 50 “Призначення ліків / ін’єкцій” (ICPC-2), у лікаря з’являється можливість до інших призначень (за наявності) додати призначення ЛЗ.
Додавання ЛЗ до призначень може відбуватися в окремому вікні, але структурно здійснюється в межах формування пакету даних щодо медичної взаємодії (Encounter) між пацієнтом та лікарем ПМД.
2.3. Передача результатів виписки лікарського засобу в резюме візиту до лікаря
Задача для МІС. Необхідно комунікувати МІС, що після виписки лікарського засобу в консультативний висновок лікаря попадала інформація щодо виписаного лікарського засобу та сигнатура з рецепту
Незалежно від наявності номеру телефону для верифікації, пацієнту роздруковується висновок (резюме візиту як медичної взаємодії, Encounter), який містить інформацію про візит, в тому числі рекомендації, в тому числі -- призначення ЛЗ (дані електронного рецепту).
1) При виписці ЛЗ і якщо є верифікований номер мобільного телефону, то передається поля з рецепта з поміткою, що номер рецепту та код його погашення було відправлено на ваш номер телефону
2) При виписці ЛЗ і якщо в базі немає верифікованого номеру телефону, крім полей з електронного рецепту передавати номер необхідно передавати у висновок поля електронного рецепту + номер рецепта + код погашення
За відсутності телефону для верифікації у висновку зазначається, крім номеру рецепту, також код підтвердження для відпуску ЛЗ в аптеці.
2.4. Поиск в Drugs dictionary по АТХ коду (внедрение на стороне МИС)
С учетом внедрения массива АТХ кодов необходимо создать поиск МНН и лекарственной формы по АТХ коду для заинтересованных лиц (врачей).
Введя номер АТХ кода или его часть до определенного уровня необходимо отдавать список МНН и лекарственных форм доступных для выписывания в электронном рецепте.
https://www.whocc.no/atc/structure_and_principles/
Например,
A | Alimentary tract and metabolism (1st level, anatomical main group) |
A10 | Drugs used in diabetes (2nd level, therapeutic subgroup) |
A10B | Blood glucose lowering drugs, excl. insulins (3rd level, pharmacological subgroup) |
A10BA | Biguanides (4th level, chemical subgroup) |
A10BA02 | metformin (5th level, chemical substance) |
Комментарий разработчика:
Предлагается частичный поиск по АТХ коду и справочник АТХ внедрять на стороне МИС.
Любой МИС может получить абсолютно весь справочник себе с помощью метода GET {{host}}/api/drugs?
Таким образом, они смогут периодически его обновлять и настроить частичный поиск и по АТХ номенклатуре
2.5. Уведомление врача о непогашенном за 30 дней рецепте
Если рецепт не был погашен, то необходимо про это уведомлять врача через МИС.
Комментарий разработчика:
Данный функционал может интегрировать у себя МИС. Ежедневно для legal_entity
могут запрашивать Get Reimbursement report и по дате и по статусу фильтровать
2.6. Додати новий статус рецепту DRAFT
DRAFT рецепт - рецепт сформований лікарем, але не підписаний ЕЦП. Лікар може в будь-який час повернутися до рецепту у такому статусі, зробити коригування введених даних, та підписавши ЕЦП перевести його в статус ACTIVE.
ЕСОЗ - публічна документація