...
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 |
Срок валидности заключения врача. Сколько заключение это может быть?
...
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 слід забезпечити наступний рекомендований функціонал на стороні МІС
№ | Назва 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. Позначення рецептів, що були оформлені по зверненню пацієнта за телефоном
...
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) |
Комментарий разработчика:
...
DRAFT рецепт - рецепт сформований лікарем, але не підписаний ЕЦП. Лікар може в будь-який час повернутися до рецепту у такому статусі, зробити коригування введених даних, та підписавши ЕЦП перевести його в статус ACTIVE.
https://edenlab.atlassian.net/wiki/spaces/EH/overview