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

Реєстрація/зміна Legal Entity Type

Передумови процесу

  1. Керівник закладу, бухгалтер закладу попередньо отримують електронний цифровий підпис (ЕЦП) від цього закладу як суб’єкту господарювання.

  2. Юридична особа зареєстрована згідно чинного законодавства.

Типи Legal Entity

Типи Legal Entity відповідають видам медичної допомоги, яка може надаватися суб'єктами господарювання.

Code

Description

Code

Description

PRIMARY CARE

Заклад з надання первинної медичної допомоги

PHARMACY

Аптека

OUTPATIENT

Вторинна, третинна, паліативна медична допомога та реабілітація

EMERGENCY

Заклад з надання екстренної медичної допомоги

Бізнес правила

  1. Для реєстрації Суб'єкта господарювання та додання видів медичної допомоги, які він надає, необхідно створити запит на реєстрацію Legal Entity з відповідними типами (один запит на один тип).

  2. Legal Entity вважається активним, якщо його стан Active (діючий) або Suspended (призупинений, Legal Entity набуває даного статусу при створенні за замовченням)

  3. Legal Entity вважається деактивованим, якщо його стан Closed (закрито)

  4. В системі одночасно може існувати декілька активних Legal Entity з одним і тим же ЄДРПОУ та різними типами

  5. В системі не може існувати більше одного активного Legal Entity  з одним і тим же ЄДРПОУ та типом

  6. Авторизація запиту проводиться за API Secret Key виданого МІС

  7. ЄДРПОУ для облікового запису MSP  має бути звірено з ЄДРПОУ що міститься в ЕЦП керівника

  8. Разом з набором даних для реєстрації MSP подаються дані для створення користувача з типом “керівник” медичного закладу (owner)

  9. Створити користувача з типом “керівник” (owner) можливо лише шляхом створення запиту на реєстрацію MSP

    1. Подальша реєстрація користувача виконується в рамках стандартного  процесу реєстрації користувача, в рамках цього процесу:

      1. керівник закладу отримує посилання для логіну та паролю на свій вказаний робочий email. 

      2. Після входу в систему керівник закладу має можливість назначити ролі та ввести інформацію про бухгалтера та уповноважену особу, що має можливість створювати інших користувачів, обов’язково вказавши контакти – номер телефону та email.

  10. Зміна керівника виконується шляхом виконання запиту на  реєстрацію / зміну MSP

    1. У MSP може бути лише 1 співробітник з типом керівник - відповідно у разі виконання запиту на реєстрацію/зміну MSP з новим керівником, попередній пов’язаний співробітник з типом “керівник” повинен бути деактивований, проте обліковий запис особи (party), користувач E-Health та інші пов’язані співробітники повинні залишитися. При виконанні запиту на реєстрацію / зміну MSP ідентифікатор попереднього керівника не передається, а це означає, що в системі буде створений новий запис працівника з типом “керівник”, а попередній буде деактивований.

  11. Зміна даних керівника (співробітника) виконується також шляхом виконання запиту на реєстрацію/зміну MSP, але з передаванням ідентифікатору співробітника з типом “керівник”, присвоєного під час реєстрації. Таким чином, дані поточного керівника будуть оновлені в системі.

  12. Разом з набором даних для реєстрації MSP подаються дані для створення чи оновлення ліцензії, якщо вона необхідна для обраного типу:

    1. Для реєстрації з типом PHARMACY необхідно мати діючу ліцензію з типом PHARMACY

    2. Для реєстрації з типом PRIMARY_CARE,  OUTPATIENT або EMERGENCY необхідно мати діючу ліцензію з типом MSP

  13. Для активних Legal Entity з одним і тим же ЄДРПОУ одночасно у системі може існувати тільки одна ліцензія обраного типу.

  14. Зміна даних ліцензіі виконується шляхом повторної реєстрації MSP із передаванням ідентифікатору ліцензії, отриманого під час реєстрації

  15. Зміна інформації закріплюється ЕЦП керівника.

  16. Оновити дані про Legal Entity може тільки його керівник

  17. При обробці нового запиту система повинна:

    1. отримати та оновити актуальні дані з ЄДР, а також верифікувати стан запису в ЄДР

    2. виконати оновлення (update) чи створення нового облікового запису MSP (create) в залежності від результатів пошуку за ЄДРПОУ, типу, та стану медичного закладу на стороні E-Health:

      1. оновлення відбувається у тому разі, якщо знайдено запис із тим же ЄДРПОУ, типом у стані Active чи Suspended, та такий запис пов'язано з активним записом у ЄДР

        1. Унікальний ID, створений під час реєстрації у системі, не повинен змінитися.

      2. створення відбувається у тому разі, якщо у системі не існує запису із тим же ЄДРПОУ, типом, та станом Active чи Suspended, та в ЄДР існує активний запис із тим же ЄДРПОУ

    3. Обробка запиту припиняється якщо:

      1. Запис у ЄДР відсутній

      2. У системі є активний Legal Entity з тим же ЄДРПОУ та типом, але пов'язаний з ним ідентифікатор запису у ЄДР не співпадає з ідентифікатором активного запису у ЄДР (суб'єкт господарювання закрився, а потім був зареєстрований у ЄДР знову із тим же ЄДРПОУ чи ІПН для ФОП, при цьому він не закрив свою діяльність у E-Health)

        1. Перед повторним запитом у такій ситуації необхідно деактивувати існуючий запис у системі через процес Деактивація Legal Entity Type

  18.  Після створення нового Legal Entity, або оновлення ліцензії існуючого Legal Entity, Legal Entity потребує верифікації від імені НСЗУ*

    1. верифікація проходить за окремим процесом Верифікація Legal Entity Type з боку NHS

    2. у разі непроведення верифікації у фіксований строк (конфігурований параметр) Legal Entity повинно перейти у стан "призупинений" процесом Suspend contract and legal entity type cron job, що також повинно призвести до призупинки дії пов'язаного контракту, якщо такий існує. При цьому повторні виклики не повинні призводити до відліку часу наново.

    3. всі існуючі запити на контракт від імені цього Legal Entity незалежно від їх стану, окрім фінальних, повинні бути відмінені. 

  19. Після успішної реєстрації Legal Entity з типом PHARMACY у системі, має бути можливість відобразити аптеки (не суб’єкт господарювання, а всі зареєстровані “точки” (divisions), де можна отримати ліки за рецептом на карті України, що розміщується на порталі НСЗУ/eHealth

  20. Структурні підрозділи (divisions) реєструються окремим API call

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

Опис процесу 

Технічний опис процесу: IL.Create/Update Legal Entity V2 - Old

  1. Через відповідний державний сайт керівник закладу заходить обирає інтерфейс медичної інформаційної системи (МІС), через який він працює або хотів би працювати.

  2. Через інтерфейс МІС керівник закладу починає процес реєстрації закладу будь-якої форми власності

  3. Через інтерфейс МІС керівник закладу вводить дані про заклад: 





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

  5. Підписує введені дані ЕЦП керівника закладу від цього суб’єкту господарювання.

  6. Введена інформація про заклад потрапивши у електронну систему проходить процес верифікації відповідно до бізнес-правил, виконується запит на отримання стану та оновлення наступних даних з ЄДР: 



  7. Якщо верифікація даних пройшла успішно, виконується обробка запиту, в результаті якої:

    1. створено чи оновлено обліковий запис МСП із актуальними даними з ЄДР

    2. створено/оновлено чи зв'язано ліцензію відповідного типу для МСП із запиту

    3. виконано запит на створення/оновлення співробітника з типом керівник (employee request).

    4. якщо дані ліцензії змінились, або створено новий Legal Entity, флаги nhs_verified та nhs_reviewed встановлено у false та оновлено дату зміни флагу, якщо nhs_verified був true

    5. якщо дані ліцензії змінились, всі існуючі запити на контракт від імені цього Legal Entity, окрім таких, що знаходяться у фінальних станах, переведені у стан TERMINATED. 

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