ЕСОЗ - публічна документація

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Короткий опис бізнес-процесу про укладення-договорів по реімбурсації

КрокДія

РезультатМетоди API
1Керівник/уповноважена особа аптечного закладу ініціює створення заявки, заповнує та підписує дані КЕП.
  • У відповідь надходять згенеровані лінки для завантаження документів
    (опціонально для аптек)
  • Створюється заявка в статусі NEW
2Представник НСЗУ розглядає заявку: призначає виконавця для розгляду заявки
  • Заявка автоматично переходить в статус IN_PROCESS
3Назначений НСЗУ працівник:

Відхилена заявка на контрактування
(status='TERMINATED').

Заява в статусі APPROVED та має доповнені дані 

  • nhs_signer_id - підписант
  • nhs_signer_base – підстава підписання
  • issue_city – місце підписання
  • miscellaneous – додаткові умови
4Відхиляє заявку, вказавши причину.Дозаповнює дані та підписує заявку на котрактування 
5Керівник аптечного закладу
Погоджена заявка набуває статусу PENDING_NHS_SIGN та стає драфтом контракту.
Відхилена заявка набуває статусу 'TERMINATED'
6Погоджується з умовами та накладає ЕЦП.Не погоджується з умовами і відхиляє заявку.
7Представник НСЗУ отримує заявку в статусі PENDING_NHS_SIGN та підписує контракт накладаючи КЕП та цифрова печатка НСЗУСтатус заявки змінюється на NHS_SIGNED.
8Керівник/уповноважена особа аптечного закладу отримує лінк та завантажує контракт в статусі NHS_SIGNED та  pkcs7 файл; підписує контракт накладаючи  КЕП

Статус заявки змінюється на SIGNED

Створеня сутності Договір

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

Переукладання договору необхідне у випадку:

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

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

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

Детальні специфікації для укладання договорів між аптечними закладами та НСЗУ:
Детальний опис бізнес-процесів реєстрації аптечних закладів:

Загальна документація  eHealth 

Опис методів API для сторони МІС 

Для Медичних Інформаційні Системи, які не інтегрувались з eHealth раніше

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

Специфікація для розробки функціоналу реєстрації аптечних закладів.

Функціонал реєстрації аптечного закладу в eHealth повинен складатися з:

Реєстрації/апдейту/деактивації 

Аптечного закладу, як сутності 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.

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

Специфікація виписування та погашення рецепту

Зверніть увагу:

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

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

А також

Відповідаючи на питання щодо реєстрації аптечних закладів:
  • Як реєструвати співробітників аптеки, які без рівня кваліфікації провізора або ще навчаються, однак працюють в аптеці як провізори, фармацевти?
  • Як необхідно назвати поля в МІС, для вірності відображення сутністі атрибутів співробітника?
  • Як зареєструвати аптечний пункт в якості підрозділу аптечного закладу?

Ми створили файл, який буде корисним всім розробникам МІС без виключення, що реалізовують функціонал реєстрації аптек в eHealth:

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

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

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


  • No labels

ЕСОЗ - публічна документація