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

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

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

1. Для реєстрації Суб'єкта господарювання необхідно створити запит на реєстрацію Legal Entity з відповідним типом:
   1. якщо суб'єкт господарювання приймає участь в капітації (первинна медична допомога) - з типом PRIMARY CARE
   2. якщо суб'єкт господарювання приймає участь в реімбурсації в якості аптеки - з типом PHARMACY 
   3. якщо суб'єкт господарювання приймає участь в наданні вторинної медичної допомоги - з типом OUTPATIENT
   4. якщо суб'єкт господарювання приймає участь в наданні екстренної медичної допомоги - з типом EMERGENCY
2. Legal Entity вважається активним, якщо його стан Active (діючий) або Suspended (призупинений)
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 та інші пов’язані співробітники повинні залишитися.
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 - Change

...