• Повторна заявка від закладу деактивує попередні непідписані заявки (ті заявки,що мають 'NEW', 'IN_PROCESS','APPROVED', 'PENDING_NHS_SIGN', 'NHS_SIGNED') 
• Зміна в переліку підрозділів та їх атрибутах не впливає на стан контракту.
  Перелік підрозділів є динамічним та підрозділ вважається чинним, якщо він зареєстровано в системі eHealth.
• Контракт в статусі TERMINATED не підлягає  оновленню, потрібно створювати новий.

• Зміни даних legal entity аптечного закладу (назва, адреса, статус), керівника (ПІБ, статус) в системі, активний контракт тимчасово призупиняється (is_suspended=true).
  
• Видалення підрозділу, що є в договорі - контракт тимчасово призупиняється (is_suspended=true)
• Якщо в аптечний заклад бажає відпускати ліки за реімбурсацією в нових, зареєстрованих після укладання контракту, підрозділах, необхідно переукласти контракт, включивши в нього дані нових підрозділів. 

Контракт оновлюється через новий Contract Request зі вказаним contract_number призупиненого контракту. 

При оновлені контракту слід передати всю інформацію аптечного закладу, включаючи підрозділи, що входять до контракту, адже в процесі оновлення контракту, накладання другого підпису НСЗУ, анулює попередній контракт .

• Бізнес-процес запиту
• API
• Опис даних та методів

Необхідно забезпечити реалізацію сервісів Medical Service Provider Integration Layer : авторизації (oAuth), тощо...

Аптечного закладу, як сутності legal entity з типом "PHARMACY" (Аналог ПМД legal entity з типом "MSP");

Та перегляду інформації щодо legal entity для необхідних користувачів модуля.

• Опис технологічного процессу.
• Посилання на API.

Підрозділу аптечного закладу як сутності Division з типом DRUGSTORE _{(Аптека)} або DRUGSTORE_POINT _{(Аптечний пункт)} (Аналоги з ПМД  Division з типом CLINIC, AMBULANT_CLINIC, FAP);

Та перегляду інформації щодо divisions для необхідних користувачів модуля.

• Опис технологічного процесу.
• Посилання на API.

Співробітників підрозділів аптечного закладу, як сутність employee з типами:

• "PHARMACY_OWNER" (Аналог з ПМД employee з типом "OWNER")
• "PHARMACIST" (Аналог з ПМД employee з типом "DOCTOR")
• "HR"(Аналог з ПМД employee з типом "HR")

Та перегляду інформації щодо employees для необхідних користувачів модуля.

• Опис технологічного процесу.
• Посилання на API.

• Технічний опис бізнес-процесу виписування рецепту за програмою реімбурсації:
• Технічний опис бізнес-процесу погашення рецепту за програмою реімбурсації:
• Загальне API щодо електронних рецептів:
• Загальний бізнес-процес щодо погашення рецептів:
• Бізнес-процеси, пов’язані з виписуванням електронного рецептута відпуску ЛЗ за електронним рецептом в рамках реімбурсації

На виконання закону України «Про захист персональних даних», закону України «Про захист інформації в інформаційно-телекомунікаційних системах», постанови КМУ №373 від 29.03.2006 р. та №938 від 07.09.2011р., інформаційно-телекомунікаційні системи, де є персональні дані громадян України, повинні бути захищені. 

За детальною інформацією по цьому напрямку Ви можете звернутись до відповідальної особи зі сторони ДП «Електронне здоров’я» Романа Єгорченко, електронна адреса: roman.iegorchenko@ehealth.gov.ua

У зв’язку з наявністю в НПА можливості відпускати ліки аптечним закладам протягом 30 днів після прийняття нового «Реєстру лікарських засобів, які підлягають реімбурсації» (далі - Реєстр) за старим Реєстром, в ЦБД та МІС повинні бути внесені зміни.

НПА, що регламентують наявність двох одночасних Реєстрів:

Постанова Кабінету Міністрів України від 17 березня 2019 року № 152 “Про забезпечення доступності лікарських засобів” (далі - Постанова), зокрема, 

• пункт 18 Порядку визначення розміру реімбурсації лікарських засобів затвердженого Постановою згідно якого аптекам та аптечним пунктом дозволяється протягом 30 календарних днів з дати затвердження МОЗ оновленого Реєстру завершити реалізацію закуплених до зазначеної дати лікарських засобів, які підлягають реімбурсації, відповідно до цін та у порядку, що діяли до дати затвердження МОЗ оновленого Реєстру.

Поява тих чи інших торгівельних назв з конкретними цінами та даними приналежністі до того чи іншого реєстру, в переліку буде відбувається автоматично та згідно прийнятих законодавчо реєстрів. 

Слід чітко розділяти зміст сутностей medication.id та program_medication_id

• medication.id  - ідентифікатор, який характеризує торгівельну назву засобу.
• program_medication_id - ідентифікатор, який характеризує ціни торгівельну назви в конкретному «Реєстрі лікарських засобів, які підлягають реімбурсації».

 В переліку кандидатів на погашення Електроного Рецепту тепер може бути декілька program_medication_id з однаковим medication.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:

В файлі  є дві вкладки:

1. Співробітники (pharmacy_employees) - описує поля бази даних щодо аптечних співробітників;
2. Підрозділи  (divisions) - описує поля щодо аптечних підрозділів.

_{Примітка: стосовно реєстрації аптечного закладу, як юридичної особи (legal entity) розшифровку полів можна визначити по API.}