Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

1. Функціональні вимоги до створення та погашення рецептів у реімбурсації 2.0 складаються з переліку змін до реімбурсації 1.0 для eHealth

Назва CR

Статус

1.1

Часові позначки: налаштування інтервалу повторного виписування рецепту.


Для ЛЗ, що підлягають реімбурсації, новий рецепт на той же ЛЗ (МНН+Форма випуску) можна виписати не раніше ніж за таку кількість днів до закінчення лікування:
1) Якщо тривалість лікування дорівнює або більше ніж 21 день, то повторно пацієнт може отримати рецепт на той же самий МНН+форма випуску за 7 днів до закінчення лікування (ended at - 7 days)


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

Змінити перелік полів для рецепту, що бачить співробітник аптеки:

  • cкорочення ПІБ до Прізвища та ініціалів;
  • інформація про акредитацію та ліцензії ЗОЗ в якому було виписано рецепт.

Заплановано на реліз 8.12

1.11

Поля довідника SNOMED в INN management зробити опціональними

Зроблено

+

1.12

Закрити можливість owner створювати “клони” облікового запису

Зроблено

+

1.13

Додати до учасника програми атрибути, які заповнюються в адмінці:

  1. Оптово-відпускна ціна за упаковку, грн (формат до 1 копейки: хх,хх грн) - параметр участника
  2. Роздрібна ціна за упаковку, грн (формат до 1 копейки: хх,хх грн)- параметр участника
  3. Добова доза лікарського засобу, рекомендована ВООЗ mg - параметр торгового найменування
  4. Розмір відшкодування добової дози лікарського засобу, грн (формат 4 знаки після коми: хх,хххх грн) - параметр участника

  1. Сума доплати пацієнтом за упаковку, грн (формат до 1 копейки: хх,хх грн) - параметр участника

Перевірити неймінг та формат:


  1. Розмір відшкодування за упаковку лікарського засобу, грн (формат до 1 копейки: хх,хх грн) - параметр участника


- participants.wholesale_price: оптововідпускна ціна за упаковку, грн  - параметр участника

- 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_qty: кількість в упаковці

-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


Для ЛЗ, що підлягають реімбурсації, новий рецепт на той же ЛЗ (МНН+Форма випуску) можна виписати не раніше ніж за таку кількість днів до закінчення лікування:


1) Якщо тривалість лікування дорівнює або більше ніж 21 день, то повторно пацієнт може отримати рецепт на той же самий МНН+форма випуску за 7 днів до закінчення лікування (ended at - 7 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": {
     "id": "d290f1ee-6c54-4b01-90e6-d701748f0851",
     "position": "P6",
     "party": {
       "id": "b075f148-7f93-4fc2-b2ec-2d81b19a9b7b",
       "no_tax_id": true,
       "first_name": "Петро",
       "last_name": "Іванов",
       "second_name": "Миколайович",
       "email": "email@example.com",
       "phones": [
         {
           "type": "MOBILE",
           "number": "+380503410870"
         }
       ]
     }
   },

1) Забрати в employee та party всі поля, крім полей first_name и second_name

2) Скоротити поля в “employee”, які віддаються аптекам на запити стосовно рецепту пацієнта first_name и second_name до першої літери

Приклад json після сhange request:

"employee": {
       "party": {
       "first_name_initials": "П",
       "last_name": "Іванов",
       "second_name_initials": "М",
       }
   },

Таким чином, провізору буде доступна інформація про лікаря: Прізвище на ініціали

3. Надавач

Повне найменування надавача / ПІБ лікаря ФОП

Код ЄДРПОУ / РНОКПП (ІПН) або серія і номер паспорту

Юридична адреса надавача

Інформація про ліцензію на медичну практику  (такої інформації в системі не має)

Технічний аналіз

Приклад поточного json:

"legal_entity": {
     "name": "Клініка Ноунейм",
     "short_name": "Ноунейм",
     "public_name": "Клініка Ноунейм",
     "type": "MSP",
     "edrpou": "5432345432",
     "status": "ACTIVE"
   },
   "division": {
     "id": "d290f1ee-6c54-4b01-90e6-d701748f0851",
     "legal_entity_id": "c8aadb87-ecb9-41ca-9ad4-ffdfe1dd89c9",
     "name": "Бориспільське відділення Клініки Ноунейм",
     "addresses": [
       {
         "type": "RESIDENCE",
         "country": "UA",
         "area": "Житомирська",
         "region": "Бердичівський",
         "settlement": "Київ",
         "settlement_type": "CITY",
         "settlement_id": "43432432",
         "street_type": "STREET",
         "street": "вул. Ніжинська",
         "building": "15",
         "apartment": "23",
         "zip": "02090"
       } ],
     "phones": [
       {
         "type": "MOBILE",
         "number": "+380503410870"
       }
     ],
     "email": "email@example.com",
     "working_hours": {
       "mon": [
         [
           "08.00",
           "12.00"
     "sun": []
     },
     "type": "clinic",
     "external_id": "3213213",
     "location": {
       "latitude": 30.1233,
       "longitude": 50.32423
     }
   },

  1. Забрати у сутностей legal_entity та division всі поля, крім полей "name", "edrpou",
  2. Додати юридичну адресу  для сутності legal_entity
  3. Додати Інформацію про ліцензію на медичну практику (такої інформації в системі не має)

Таким чином, інформація, яка доступна по запросам провізору буде:

  • Повне найменування надавача / ПІБ ФОП
  • Код ЄДРПОУ / РНОКПП (ІПН) або серія і номер паспорту
  • Юридична адреса надавача
  • Інформація про ліцензію на медичну практику  (такої інформації в системі не має)

Приклад json після сhange request:


"legal_entity": {
     "name": "Клініка Ноунейм",
     "edrpou": "5432345432",

     "addresses": [
       {
         "type": "RESIDENCE",
         "country": "UA",
         "area": "Житомирська",
         "region": "Бердичівський",
         "settlement": "Київ",
         "settlement_type": "CITY",
         "settlement_id": "43432432",
         "street_type": "STREET",
         "street": "вул. Ніжинська",
         "building": "15",
         "apartment": "23",
         "zip": "02090"
       }

       ],
},

4. Рецепт

ID рецепта

Статус

Дата виписування рецепта

Термін дії рецепту

Технічний аналіз

Приклад поточного json:

{

   "id": "b075f148-7f93-4fc2-b2ec-2d81b19a9b7b",
   "status": "ACTIVE",
   "request_number": "0000-243P-1X53-EH38",
   "created_at": "2017-08-17",
   "started_at": "2017-08-17",
   "ended_at": "2017-09-16",
   "dispense_valid_from": "2017-08-17",
   "dispense_valid_to": "2017-09-16"

5. Призначення

Назва МНН (INN)

Форма випуску

Сила дії

Кількість доз

Поля сигнатури

Технічний аналіз

Приклад поточного json:

 "medication_info": {
     "medication_id": "4a63b858-c138-4921-9341-ae9e384bcbd6",
     "medication_name": "Аміодарон 200мг таблетки",
     "form": "PILL",
     "dosage": {
       "numerator_unit": "MG",
       "numerator_value": 200,
       "denumerator_unit": "PILL",
       "denumerator_value": 1
     },
     "medication_qty": 10
Cледует добавить поля сигнатуры:

-   Кількість прийому на день (qty_per_day)

-   Кількість доз на прийом (qty_per_time)

-   Тривалість лікування (treatment_days)

-   Додаткові вказівки (treatment_info)

Опції відпуску

Можливі торгові назви фармацевтичних продуктів (відповідно до призначення за МНН) та їх атрибути.

Технічний аналіз

Приклад поточного json:

"details": [
       {
         "medication": {
           "name": "Амідарон",
           "type": "MEDICATION",
           "manufacturer": {
             "name": "ПАТ \"Київський вітамінний завод\"",
             "country": "UA"
           },
           "form": "PILL",
           "container": {
             "numerator_unit": "PILL",
             "numerator_value": 1,
             "denumerator_unit": "PILL",
             "denumerator_value": 1
           }
         },
         "medication_qty": 10,
         "sell_price": 18.65,
         "sell_amount": 186.5,
         "discount_amount": 150,
         "reimbursement_amount": 450
       }
     ],

Фінансування (для рецептів за програмами реімбурсації)

Назва програми реімбурсації

Повна ціна відпуску за упаковку 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

Повністю реалізувати на стороні МІС


  1. Функціональні вимоги до створення та погашення рецептів у реімбурсації 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