Доступ до сервісів медичної інформаційної системи «Медікс» у вигляді ліцензій користувача

Дата: 04.01.2024 16:13

Кількість переглядів: 255

Обґрунтування технічних та якісних характеристик предмета закупівлі, розміру бюджетного призначення, очікуваної вартості предмета закупівлі

Предмет закупівлі послуг за предметом:  код ДК 021:2015 код 48810000-9 – «Інформаційні системи» (Доступ до сервісів медичної інформаційної системи  «Медікс» у вигляді ліцензій користувача) Закупівля зареєстрована за Ідентифікатором закупівлі:

UA-2024-01-04-005713-a

Обґрунтування обсягів закупівлі. Обсяги визначено відповідно до очікуваної потреби, обрахованої  замовником та обсягу фінансування.

Обґрунтування технічних та якісних характеристик закупівлі. В основі медичної інформаційної системи  «Медікс»  - лежить вільний доступ пацієнта до своїх медичних даних, а також вільний вибір лікаря, клініки чи послуги. Система  автоматизує роботу реєстратури, упорядкувавши і спростивши процедуру запису пацієнтів на прийом; систематизує інформацію про всіх пацієнтів клініки, медичні послуги і співробітників; управляє своїм матеріальним фондом, чергою на місця в стаціонарі; упорядковує роботу лабораторій і діагностичних кабінетів; організовує оперативне передавання даних про результати досліджень фахівцеві у автоматичному режимі; збирає статистику; готує звіти та аналітику в кілька кліків тощо.

Очікувана вартість закупівлі: 310 000,00 гривень.

Строк надання послуг–  31.12.2024 р.

Технічні, якісні та кількісні характеристики предмета закупівлі                        

1. Номенклатура та обсяги закупівлі

ІІ. Технічні та якісні вимоги до предмету закупівлі

(ТЕХНІЧНА СПЕЦИФІКАЦІЯ):

1.  Вимоги до надійності та безпеки

1.1.  Вимоги до авторизації користувача у системі

Щоб отримати доступ до можливостей системи, кожен користувач має пройти авторизацію.

Авторизація користувача має виконуватись шляхом зчитування кваліфікованого електронного підпису (КЕП)/удосконаленого електронного підпису (УЕП) користувача (зазначення файлу із цифровим підписом, що зберігається на зовнішньому носії, та введення паролю до ключа) та його перевірки у АЦСК, де було отримано цей ключ, або вебтокену (хмарного електронного підпису).

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

Для забезпечення  захисту персональних та інших даних користувачів при використанні системою електронних підписів та задля дотримання вимог законодавства щодо використання електронних підписів надати у складі пропозиції ліцензію на використання учасником бібліотек програмного комплексу користувача центру сертифікації ключів "ІТТ Користувач ЦСК -1"

1.2.  Вимоги до протоколювання роботи користувачів системи

Система має виконувати протоколювання наступних дій користувачів:

• Спроба підключення до системи;
• Результат спроби підключення до системи;
• Завершення сеансу роботи у системі;
• Додавання інформації щодо наданих пацієнту медичних послуг;
• Додавання інформації щодо результатів наданих пацієнту медичних послуг;
• Зчитування інформації щодо наданих пацієнту медичних послуг;
• Зчитування інформації щодо результатів наданих пацієнту медичних послуг;
• Внесення персональних даних пацієнта;
• Зміна персональних даних пацієнта;
• Зчитування персональних даних пацієнта;
• Створення профілю користувача системи;
• Зміна профілю користувача.

Під час протоколювання мають фіксуватись наступні дані:

• Дата та час події;
• Користувач, який ініціював подію;
• IP адреса користувача, який ініціював подію;
• Тип події з наведеного переліку.

Для подій, пов’язаних зі створенням, зміною або отриманням доступу до даних користувачів, пацієнтів, медичних працівників, медичних послуг та їхніх результатів, має фіксуватись інформація про об’єкт доступу - результат події (завершено вдало або ні).

У якості сховища протоколів роботи системи має використовуватися кластер СУДБ MongoDB з не менш ніж трьох нод, кожна з яких має містити повну копію протоколу.

1.3. Вимоги до резервного копіювання

Створення архівних копій баз даних системи має бути налаштовано штатними механізмами системами.

Мінімальна періодичність створення архівних копій не має перевищувати 1 доби.

Для забезпечення можливості відновлення інформації архіви мають зберігатися з такою періодичністю:

• Останні 7 щоденних архівів (станом на 00:00 кожного дня)
• Останні 12 місячних архівів (станом на 00:00 першого дня місяця)

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

1.4.  Вимоги до надійності

Робота системи має бути організована у цілодобовому режимі з можливістю доступу не менше 99,0% за рік.   

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

Задля забезпечення надійності  та безпечності системи в учасника має бути впроваджена система управління інформаційною безпекою, що відповідає вимогам  ДСТУ ISO/IEC 27001:2015 Інформаційні технології. Методи захисту cистеми управління інформаційною безпекою. Вимоги (ISO/IEC 27001:2013; Cor 1:2014, IDT), стосовно розробки та налаштування програмного забезпечення, аналітика програмного забезпечення, архітектура, дизайн, розробка та тестування, послуги програмного та хмарного забезпечення, технічна підтримка та UX/UI послуги, навчання користувачів, що підтверджується поданням у складі пропозиції відповідного сертифікату. Також учасник має підтвердити повноваження органу( установи, організації) що видала такий сертифікат, шляхом надання у складі пропозиції  документів щодо акредитації (нотифікації) організації,  що видала зазначений сертифікат.

1.5. Вимоги до інформаційної та програмної сумісності

У якості мови розробки прикладного програмного забезпечення мають використовуватися Python 3.6, Django 2.2. Для системи керування базами даних мають використовуватися PostgreSQL 12.7, MongoDB  не нижче 3.6. Також мають бути задіяні наступні інструменти: система керування файлами - Ceph, система логування та збору статистики - Logstash, база даних користувацьких логів роботи - MongoDB не нижче 3.6, система моніторингу - Sentry 8.22.0.

1.6. Технічні вимоги до сумісності МІС з мінімальними програмно-апаратними характеристиками автоматизованого робочого місця доступу персоналу до системи

Системні Характеристики АРМ Замовника (мінімальні):

• процесор: 2 core Intel/AMD 2 GHz;
• відеоадаптер: будь який;
• об’єм оперативної пам’яті: 4 Гб;
• дисковий простір HDD/SSD: не менше 100 ГБ;
• засіб для зчитування КЕП/УЕП із носія інформації (USB-порт);
• монітор із роздільною здатністю екрану 1280*1024;
• наявність мережевого адаптеру з пропускною здатністю 10 Мб/с.

Характеристики мережі Замовника (мінімальні):

• Пропускна здатність каналу зв’язку до мережі Інтернет 1 Мbit/s.

У разі використання сервісів відеозв'язку:

• гарнітура;
• веб-камера 720р.

Характеристики операційних систем та веб-браузерів Замовника:

• операційні середовища: сімейства Windows та Linux;
• Google Chrome.

1.7 Умови надання послуг та технічної підтримки адміністратором оператору МІС

Виконавець має забезпечити наявність веб-сайту, де публікується контактні дані для зв’язку зі службою клієнтської (технічної) підтримки.

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

Виконавець має забезпечити безвідмовну роботу МІС (ЦБД) та доступність її всіх основних функцій протягом 99,0 % часу кожного місяця.

Виконавець має забезпечувати підтримку тестових середовищ системи 95% часу безвідмовної роботи кожного місяця, опрацювання інцидентів, надання консультаційних запитів щодо тестових середовищ у термін не більше 12 (дванадцять) робочих днів з моменту отримання запиту.

1.8. Вимоги до взаємодії системи з центральною базою даних електронної системи охорони здоров’я України

Для забезпечення коректної взаємодії з центральною базою даних електронної системи охорони здоров’я України Система має відповідати Технічним вимогам до електронної медичної інформаційної системи для її підключення до центральної бази даних електронної системи охорони здоров’я, затвердженим наказом Національної служби здоров’я України № 28 від 06.02.2019 (з урахуванням змін та в редакції, чинній на момент оголошення закупівлі).

Учасник повинен бути уповноваженим Оператором Електронної системи охорони здоров’я (eHealth), що приєднався до відповідного Договору з ДП «Електронне здоров’я» та повинен мати протестовані та підключені до Центральної бази даних Електронної системи охорони здоров’я наступні функціональні модулі:

• Адмін модуль НМП СМД;
• Електронні медичні записи;
• Даагностичні звіти;
• ЕМЗ та ЕН для неідентифікованих пацієнтів;
• ЕМЗ Стаціонар: надходження;
• ЕМЗ Стаціонар: виписка;
• Доступ до даних;
• Робота з записами про ідентифікованих пацієнтів;
• Робота з записами про неідентифікованих пацієнтів;
• Приєднання записів неідентифікованого пацієнта до ідентифікованого;
• Медичні висновки про народження дитини;
• Медичні висновки про тимчасову непрацездатність;
• Виписування електронного рецепту;
• План лікування;
• Робоче місце середнього медичного персоналу;
• Неонатальний скринінг;
• Робоче місце адміністратора медичних записів;
• Клінічна оцінка;
• Електронні направлення;
• Процедури;
• Спостереження;
• Виписування електронного рецепту на ЛЗ.

Замовник також може перевіряти інформацію щодо підключення МІС та проходження тестування відповідних функціональних модулів на офіційному сайті ДП «Електронне здоров’я».

1.9. Вимоги до взаємодії з Електронним реєстром листків непрацездатності

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

2. Загальні вимоги до системи

2.1.  Вимоги до інтерфейсу користувача

Інтерфейс взаємодії користувачів з електронними реєстрами даних повинен бути заснований на принципі візуального графічного інтерфейсу (GUI). Інтерфейс системи має бути зрозумілим і зручним, не перевантаженим графічними елементами, повинен забезпечувати швидке відображення екранних форм. Навігаційні елементи мають бути виконані у зручній для користувача формі. Введення-виведення даних системи, прийом команд керування і відображення результатів їх виконання повинні виконуватися в інтерактивному режимі. Інтерфейс повинен відповідати сучасним ергономічним вимогам і забезпечувати зручний доступ до основних функцій системи.

Інтерфейс повинен бути розрахований на переважне використання маніпулятора типу «миша», тобто управління системою має здійснюватися за допомогою керуючих елементів. Клавіатурний режим введення повинен використовуватися головним чином для заповнення та/або редагування текстових і числових полів екранних форм.

Система повинна використовувати вибрану мову для оформлення будь-яких елементів інтерфейсу, включаючи підписи, екранні кнопки, меню, документацію, підказки системи і повідомлення програми користувачеві (крім повідомлень від загальносистемного ПЗ).

Система повинна забезпечувати коректну обробку аварійних ситуацій, викликаних неправильними діями користувачів, невірним форматом або неприпустимими значеннями вхідних даних. У зазначених випадках система повинна видавати користувачу відповідні повідомлення, після чого повертатися в робочий стан, що передував невірній (неприпустимій) команді або некоректному введенню даних.

Екранні форми повинні проектуватися з урахуванням вимог уніфікації: всі екранні форми користувальницького інтерфейсу повинні бути виконані в єдиному графічному стилі, з однаковим розташуванням основних елементів керування та навігації; для позначення подібних операцій повинні використовуватися подібні керуючі (навігаційні) елементи. Терміни, що використовуються для позначення типових операцій (додавання/редагування значень), а також послідовності дій користувача при їх виконанні, повинні бути уніфіковані; зовнішня поведінка подібних елементів інтерфейсу (реакція на наведення покажчика «миші», перемикання фокусу, натиснення кнопки) повинні реалізовуватися однаково для однотипних елементів.

Наявність навчального порталу для користувачів.

2.2.  Модуль адміністратора юридичної особи

Для забезпечення керування роботою юридичної особи в системі система має містити модуль адміністратора юридичної особи.

Авторизація користувача має виконуватись за процедурою, вказаною у розділі “Вимоги до авторизації користувача у системі”. У разі проходження процедури авторизації та наявності серед знайдених облікових записів користувачів активного облікового запису із групою доступу “Адміністратор”, користувач отримує доступ до системи з правами, які налаштовані для цієї групи доступу.

Модуль адміністратора має давати можливість користувачам виконувати у системі наступні функції:

• Редагувати інформацію про юридичну особу в Електронній системі охорони здоров’я;
• Створювати профіль користувачів в межах своєї організації;
• Створювати та редагувати підрозділи організації;
• Встановлювати ролі за функціональними обов’язками та підрозділами організації;
• Встановлювати недоступність лікаря з існуючим графіком із можливістю призначення лікаря, який заміщує
• Переглядати перелік записів на прийом до лікарів;
• Переглядати перелік записів на прийом, які потребують зміни параметрів прийому через недоступність лікарів;
• Переглядати загальний графік роботи лікарів установи із зазначенням загальної кількості планових прийомів лікаря та вже зайнятих за попереднім записом пацієнтів;
• Реєструвати пацієнта у системі для подальшого затвердження лікарем;
• Записувати пацієнта на прийом;
• Укладати для організації договори з НСЗУ та продовжувати їхній термін;
• Налаштовувати перелік послуг, які надає організація;
• Редагувати параметри придбаних ліцензій (змінювати кількість спеціалістів для кожної ролі та призначати для них співробітників);
• Формувати журнали за довільний період з можливістю експорту у формат xls:
• Журнал прийомів
• Журнал викликів додому
• Журнал вакцинацій за формою 063/о
• Журнал аналізів та їхні результати
• Журнал реєстрації амбулаторних пацієнтів
• Журнал обліку процедур
• Формувати звіти та статистичні форми:         
  • • Звіт про прийоми, які були проведені лікарями організації, в розрізі лікаря, структурного підрозділу, відділення, або організації в цілому;
    • Відомість обліку відвідувань пацієнтів - дані про відвідування у закладі охорони здоров’я та вдома дітей віком до 17 років та дорослих;
    • Звіт про надані послуги лікарів установи із зазначенням наданих послуг, їх кількості та вартості;
    • Звіт про всі рецепти для отримання лікарських засобів, видані пацієнтам;
    • Звіт про вхідні та вихідні лабораторні дослідження;
    • Звіт про виконання процедур маніпуляційним кабінетом установи;
    • Дані про пацієнтів, які відносяться до певних груп ризику залежно від встановленого діагнозу;
    • Дані про епізоди лікування;
    • Звіт про видані пацієнтам листки непрацездатності;
    • Звіт по групам диспансерного нагляду;
    • Звіт про склад пацієнтів закладів області за статтю, віком та певними пільговими категоріями;
    • Звіт щодо записів на прийом;
    • Звіт із даними про імунізацію пацієнтів;
    • Довідки про тимчасову непрацездатність;
    • Медичні висновки про тимчасову непрацездатність;
    • Звіт про направлення, сформовані у даному функціоналі та передані до системи eHealth;
    • Перелік електронних медичних записів, зареєстрованих у eHealth;
    • Перелік діагностичних звітів та процедур;
    • Перелік зареєстрованих спостережень;
    • Звіт щодо госпіталізацій та виписок зі стаціонару;
    • Звіт з показниками якості ведення медичних записів лікарями організації;
    • Звіт про роботу палат та ліжок;
    • Звіт про виписані та погашені електронні направлення;
    • Звіт по хірургічній роботі стаціонару.

• Формувати графік роботи лікарів за допомогою схем прийому, на певний проміжок часу, а також за індивідуальними графіками. Формування графіку роботи лікарів має відбуватись із зазначенням таких параметрів:
• Лікар;
• Спеціальність обраного лікаря;
• Підрозділ установи, в якому буде працювати лікар;
• Номер кабінету, в якому буде вести прийом лікар;
• Дата та час роботи лікаря;
• Тип робочого часу лікаря (амбулаторний прийом, виклик додому, перерва);
• Інтервал на один прийом пацієнта;
• Можливість пацієнтам самостійно записатись на прийом до лікаря (опціонально) через веб-версію сайту, або мобільний додаток;
• Дозвіл записувати у живу чергу до лікаря (опціонально, якщо тип робочого часу - амбулаторний прийом);
• Обмеження віку пацієнтів, які можуть записатись на прийом;
• Дозвіл лікарю самостійно записувати пацієнтів собі на прийом (опціонально, якщо тип робочого часу - амбулаторний прийом). Можливість блокування онлайн запису на прийом в межах цілого ЗОЗ?

3. Забезпечення робочого процесу медичних працівників

1. 1.  Вимоги до модулю реєстратора

Для забезпечення виконання обов'язків працівника реєстратури в системі має бути модуль реєстратора.

Авторизація користувача має виконуватись за процедурою, вказаною у розділі “Вимоги до авторизації користувача у системі”. У разі проходження процедури авторизації та наявності серед знайдених акаунтів користувачів активного аккаунту з групою доступу “Реєстратор” користувач отримує доступ до системи з правами, які налаштовані для цієї групи доступу.

Модуль реєстратора має надавати змогу реєстраторам виконувати в системі наступні функції:

• формування профілю пацієнта в системі;
• редагування персональних (не медичних) даних пацієнта;
• верифікація даних пацієнта;
• верифікація телефону пацієнта через СМС;
• введення та коригування графіку прийому лікаря (опціонально);
• запис пацієнта на прийом до лікаря;
• скасування запису пацієнта до лікаря;
• друк талонів на прийом до лікаря;
• перегляд списку записів на прийом, встановлення відміток про прибуття пацієнта або відмітки про скасування візиту;
• перегляд загального розкладу роботи лікарів установи;
• друк журналу викликів лікарів;
• друк журналу запланованих прийомів лікарів;
• встановлення і підтвердження методу автентифікації пацієнта;
• можливість виконувати пошук електронних направлень у системі eHealth і змінювати статус записів для реалізації направлень:
• можливість прийняти направлення для реалізації, помістивши його у чергу для обробки;
• можливість за бажанням пацієнта скасувати призначення направлення, прийнятого для обробки в іншій організації, і призначити його виконання у поточній організації, прийнявши у чергу.

1. 2. Вимоги до модулю кадровика

Для забезпечення виконання обов’язків кадровика закладу, в системі має бути реалізований модуль “Кадровик”.

Авторизація користувача має виконуватись за процедурою, вказаною у розділі “Вимоги до авторизації користувача у системі”. У разі проходження процедури авторизації та наявності серед знайдених акаунтів користувачів активного аккаунту з групою доступу “Кадровик” користувач отримує доступ до системи з правами, які налаштовані для цієї групи доступу.

Модуль кадровика має надавати змогу кадровикам виконувати в системі наступні функції:

• Авторизація в системі;
• Перегляд персоналу закладу;
• Можливість перегляду працівників в залежності від спеціальності за допомогою фільтрів;
• Можливість пошуку працівника за ключовими параметрами (ПІБ, спеціальність);
• Можливість редагувати дані про працівника, в електронній системі охорони здоров’я;
• Можливість підписувати тза завіряти зміни в персоналі власним КЕП;
• Можливість присвоювати роль працівникам закладу, відповідно до видів медичних послуг;

1. 3.  Вимоги до модулю статистика

Для забезпечення виконання обов’язків статистика закладу, в системі має бути реалізований модуль “Статистик”.

Авторизація користувача має виконуватись за процедурою, вказаною у розділі “Вимоги до авторизації користувача у системі”. У разі проходження процедури авторизації та наявності серед знайдених акаунтів користувачів активного аккаунту з групою доступу “Статистик” користувач отримує доступ до системи з правами, які налаштовані для цієї групи доступу.

Модуль статистика має надавати змогу статистикам виконувати в системі наступні функції:

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

1. 4.  Вимоги до модулю лікаря амбулаторного відділення спеціалізованої (вторинної) медичної допомоги

 Для забезпечення виконання обов'язків лікаря у системі має бути наявний амбулаторний модуль лікаря вторинної (спеціалізованої) медичної допомоги. Авторизація користувача має виконуватися за процедурою, вказаною у розділі “Вимоги до авторизації користувача у системі”. У разі проходження процедури авторизації та наявності серед знайдених облікових записів користувачів активного облікового запису із групою доступу “Лікар” користувач отримує доступ до системи із правами, які налаштовані для цієї групи доступу.

Для планування роботи лікар повинен мати можливість відкривати для перегляду власний розклад амбулаторних прийомів пацієнтів;

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

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

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

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

Система має надавати можливість фіксувати наступні дані:

• Назва епізоду;
• Тип епізоду;
• Дата початку епізоду;
• Дата закриття епізоду;
• Причина закриття епізоду;
• Тип взаємодії;
• Дата та час взаємодії з можливістю ручного корегування;
• Скарги пацієнта за класифікатором ICPC-2;
• Основний діагноз за класифікатором МКХ-10 АМ;
• Додаткові діагнози за класифікатором МКХ-10 АМ;
• Надані пацієнту послуги за класифікатором АКМІ;
• Результати обстежень через ЕМЗ “діагностичний звіт”.
• Результати обстежень ЕМЗ “діагностичний звіт”, коли інформація вноситься з “вторинного джерела”
• Проведення процедур/хірургічних процедур через ЕМЗ “процедури”
• Проведення процедур/хірургічних процедур ЕМЗ “процедура”. коли інформація вноситься з “вторинного джерела”
• Об’єктивний статус;
• Дані про вакцинацію;
• Дані про клінічну оцінку;
• Спостереження.

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

Лікар повинен мати можливість сформувати медичний висновок про тимчасову непрацездатність з передачею даних до ЕРЛН для формування електронного лікарняного і можливістю продовжувати і скорочувати термін висновку.

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

Лікар повинен мати можливість виконати та зареєструвати вакцинацію із зазначенням всіх обов’язкових для передачі до центрального компоненту параметрів. Також він повинен мати можливість зареєструвати невиконання вакцинації із зазначенням причин. Для реалізації щеплення лікар повинен мати змогу залучити маніпуляційний кабінет.

Лікар повинен мати можливість виписати електронне направлення, на діагностику, процедури, консультації інших фахівців, або на госпіталізацію. Також має бути можливість друку направлень

Лікар повинен мати можливість створювати шаблони прийому, та застосовувати їх при створенні взаємодій, для пришвидшення роботи.

Лікар повинен мати можливість створювати та застосовувати шаблони направлень (група направлень), для пришвидшення роботи.

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

Лікар повинен мати можливість без запису пацієнта на прийом:

Переглядати його медичну інформацію;

Позначати помилковими медичні записи;

Друкувати медичні записи;

Формувати медичний висновок про непрацездатність на підставі раніше проведеного прийому, в часових рамках встановлених вимогами НСЗУ;

Закривати існуючий активний епізод;

Формувати електронне направлення на підставі раніше проведеного прийому, в часових рамках встановлених вимогами НСЗУ    

Лікар повинен мати можливість отримати доступ до груп чутливих станів, а також безпосередньо до медичних записів - як для перегляду записів, так і для обробки направлення, що містить чутливі дані. Лікар повинен мати можливість скасувати доступ, отриманий ним безпосередньо.

Система має фіксувати всі процедури чи послуги, які отримав пацієнт під час прийому у лікаря.

Під час внесення даних до медичної картки потрібно обирати скарги та об’єктивні дані з довідників системи. Кількість полів, які потрібно  заповнювати вручну, не має перевищувати 20% від загальної кількості. До певних полів, де доступний вибір із довідників системи, лікар повинен мати можливість власноруч додавати значення, після чого ці значення мають зберігатися у довіднику лікаря, який їх додав.

Лікар повинен мати змогу оформити підсумки прийому у вигляді звіту. Під час реєстрації подій, які формують електронну медичну історію пацієнта, лікар, який їх ініціював, повинен мати змогу затвердити їх за допомогою особистого КЕП/УЕП.

Використовуючи інструменти системи, лікар повинен мати змогу створювати звітність за результатами роботи:

• реєстр пацієнтів, які пройшли амбулаторний прийом;
• реєстр візитів пацієнтів до медичного закладу;
• медичний висновок консультативного характеру (довідка);
• витяг за даними персональної медичної картки пацієнта, що пройшов амбулаторний прийом;
• виписані направлення;;
• перелік визначених діагнозів у розрізі пацієнтів;
• дані про видані тимчасові листки непрацездатності;
• дані щодо диспансерного обліку пацієнтів;
• перелік послуг, отриманих пацієнтами в результаті відвідування медичного закладу;
• дані про призначення лікарських засобів пацієнтам;
• дані про виконані лабораторні дослідження;
• перелік реалізованих діагностичних звітів та процедур;
• перелік категорій населення, які мають певні пільги;
• перелік епізодів лікування;
• звіт, який містить дані про імунізацію пацієнтів;
• розширений звіт про виконані у поточному медичному закладі та зареєстровані у системі eHealth щеплення;
• реєстр спостережень;
• довідки про тимчасову непрацездатність;
• сертифікат про вакцинацію міжнародного зразка;

Забезпечення функцій діагностичних відділень (кабінетів)

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

• автоматичне формування списку пацієнтів, що направлені на діагностичні дослідження на робочому місці;
• структурування даних по пацієнтам за допомогою системи фільтрів на робочому місці;
• можливість створення направлень для фіксації самозвернень пацієнтів;
• можливість пошуку пацієнта за номером направлення;
• перегляд історії хвороби пацієнта (лише для лікаря);
• фіксація первинної інформації щодо дослідження (номер дослідження, вид дослідження, мета та ін.);
• створення лікарського заключення;
• автоматична фіксація результатів дослідження в ЕМК пацієнта;
• Формування статистичного звіту про виконані дослідження з можливістю експорту даних;
• друк діагностичного звіту з результатами дослідження.

3.5.  Вимоги до модулю Лікаря стаціонарного відділення спеціалізованої (вторинної) медичної допомоги

3.5.1.   Приймальне відділення

Для забезпечення виконання робочих процесів реєстратора в приймальному відділенні система повинна містити модуль приймального відділення. Модуль приймального відділення повинен містити наступний функціонал:

• Реєстрація всіх звернень пацієнтів в приймальному відділенні;
• Поетапне внесення даних по зверненню. Можливість відкласти внесення даних по поточному зверненню для внесення наступного звернення;
• Реєстрація даних про амбулаторний прийом в разі відмови від госпіталізації;
• Реєстрація пацієнтів, що госпіталізуються в стаціонарні відділення (планово та ургентно);
• Пошук пацієнта за номером електронного направлення;
• Госпіталізація неідентифікованих пацієнтів;
• Реєстрація даних про травми;
• Журнал реєстрації амбулаторних пацієнтів (форма 074/О);
• Перегляд списків звернень з можливістю пошуку та фільтрації за параметрами звернення;
• Призначення пацієнту відділення для госпіталізації;
• Редагування даних про госпіталізацію;
• Перегляд даних пацієнтів які виписані зі стаціонарного лікування.
• Формування та друк титульної сторінки Медичної карти пацієнта стаціонару (форма №003/О)

3.5.2.  Керування ліжковим фондом

Для забезпечення можливості керування матеріально-технічною базою лікувального закладу в системі повинен бути модуль Керування ліжко фондом. Модуль повинен забезпечити наступні функціональні можливості:

• Можливість формування структури ліжкового фонду стаціонарних відділень з визначенням наступних параметрів - номер ліжка, профіль ліжка, номер палати, стаціонарне відділення;
• Реєстрація робочого статусу відділень, палат, ліжок;
• Контроль зайнятості кожного ліжка стаціонару;
• Призначення палати та ліжка для конкретного пацієнта;
• Призначення лікуючого лікаря;
• Переміщення та вибуття пацієнтів.
• Переведення пацієнта до іншого відділення для подальшого лікування

3.5.3.  Забезпечення функцій лікаря стаціонарного відділення

Для забезпечення робочих процесів лікарського персоналу в системі повинен бути модуль Кабінет лікаря. Модуль повинен забезпечувати наступні можливості:

• Перегляд відомостей з електронної медичної картки пацієнта;
• Реєстрація основного і супутнього діагнозів за МКХ-10-АМ;
• Можливість призначення лікарських засобів;
• Можливість направлення на консультації, лабораторні та інструментальні дослідження, операції та інші процедури;
• Ведення реєстру направлень:
• можливість взяти направлення в роботу;
• можливість погасити направлення;
• можливість відкликати і скасувати направлення
• пошук направлення у системі eHealth;
• можливість поставити направлення у чергу та вилучити з черги за бажанням пацієнта;
• Ведення реєстру взаємодій;
• Ведення реєстру діагностичних звітів;
• Реєстрація даних про виконані хірургічні операції (згідно з АКМІ);
• Можливість зареєструвати вакцинацію та реакцію на вакцинацію
• ведення класифікатора вакцин та протидії загрозам;
• створення чернетки запису про виконану або невиконану вакцинацію;
• внесення історичних даних про вакцинацію (наприклад, на підставі паперових носіїв);
• фіксація запису про вакцинацію за допомогою взаємодії;
• реєстрація вакцинації у системі eНealth;
• скасування запису про вакцинацію в eНealth за допомогою позначення “Введено помилково”;
• Автоматичне формування списку наданих пацієнту послуг;
• Введення даних про листки непрацездатності;
• Формування медичних висновків про непрацездатність (МВТН):
• реєстрація МВТН на підставі затвердженої взаємодії;
• використання категорій, затверджених у системі eHealth;
• позначення особливих обставин випадку відповідно до вимог системи  eHealth;
• контроль періодів непрацездатності відповідно до вимог системи  eHealth;
• відправка МВТН до системи eHealth;
• можливість отримати із системи  eHealth актуальні дані щодо зареєстрованих для пацієнта МВТН;
• затвердження МВТН за допомогою КЕП;
• можливість повторно надіслати МВТН до ЕРЛН у разі помилки або технічних проблем;
• можливість надрукувати МВТН;
• можливість продовжити період непрацездатності відповідно до стану пацієнта або додаткових обставин;
• можливість скоротити період непрацездатності відповідно до стану пацієнта або додаткових обставин;
• можливість позначити МВТН як введений помилково;
• Можливість переглядати загальний перелік медичних висновків та формування вибірок за допомогою фільтрів;
• Можливість отримувати доступ до медичних висновків, створених в інших організаціях;
• Можливість отримувати доступ до обробки чутливих даних у зверненні та направленні, використовуючи дозвіл пацієнта;
• Можливість переглядати і скасовувати доступ до медичних записів, отриманий за дозволом пацієнта;
• Можливість вносити локальні дані, які пізніше формуватимуть виписку пацієнта (щоденні огляди тощо)
• Автоматизоване формування заключення для виписки на підставі внесених у звернення даних;
• Можливість внесення та передачі даних про взаємодію (виписку) до центрального компоненту eHealth;
• Можливість створення та передачі до центрального компоненту eHealth неідентифікованих та ідентифікованих пацієнтів;
• Можливість переглядати зведену інформацію про пацієнта, отримуючи дані із системи eHealth та використовуючи дозвіл пацієнта;
• Можливість створення та передачі до центрального компоненту eHealth діагностичних звітів, процедур, спостережень у складі взаємодії;
• Можливість погашення направлення eHealth на госпіталізацію;
• Можливість об’єднання неідентифікованих пацієнтів з ідентифікованими;
• Можливість змінити eHealth ідентифікатор пацієнта у зверненні, щоб визначити приналежність медичних даних;
• Можливість керування методами автентифікації ідентифікованого пацієнта;
• Автоматичне формування та друк Медичної карти пацієнта стаціонару (форма №003/О);
• Формування Карти пацієнта, який вибув зі стаціонару (форма №066/О);
• Формування та друк «Виписки із медичної карти амбулаторного (стаціонарного) хворого» (форма №027/О).

4. Вимоги до достовірності медичної інформації

Для забезпечення достовірності медичної інформації, що вноситься медичними працівниками особисто за допомогою системи або переноситься з інших медичних інформаційних систем, кожний такий запис має бути підписаний КЕП/УЕП/вебтокеном медичного працівника.

5. Вимоги до інтеграції з іншими системами

5.1. Модуль взаємодії із системами постачання довідникової інформації

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

Із поточної системи до систем постачання довідникової інформації може передаватись наступна інформація:

• Деперсоналізована інформація щодо наданих медичних послуг та результати надання медичних послуг;
• Інформація щодо юридичних осіб, структурних підрозділів, медичних працівників, які надають медичні послуги за допомогою системи;
• Інформація щодо події, за умови виконання якої виконується звернення до системи постачання довідникової інформації.

Для деперсоналізації має вилучатися вся персональна інформація про пацієнта крім даних про такі характеристики:

• Стать пацієнта
• Дата народження пацієнта
• Населений пункт та вулиця проживання пацієнта

Перелік інформації, яка має надаватись системами постачання довідникової інформації:

• Реєстр лікарських засобів;
• Перелік пільгових програм для пільгових рецептів;
• Перелік лікарських засобів у пільгових програмах;
• Класифікатор МКХ-10-АМ або ICPC-2;
• Територіальні класифікатори (області, населені пункти, назви та типи вулиць);
• Класифікатор типів медичних послуг.

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

6. ФУНКЦІОНАЛ ДЛЯ ПАЦІЄНТА

1. 1. Вимоги до інтерфейсу для веб-версії “Особистий кабінет пацієнта”

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

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

1. 2. Вимоги до інтерфейсу для мобільного застосунку для пацієнта

Пацієнт повинен мати можливість користуватися сервісом для пацієнта за допомогою мобільного застосунку (для смартфонів, айфонів або планшетів на операційних системах Android/iOS). Мобільний застосунок має забезпечувати для пацієнта наступні функції:

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

На підтвердження наявності в учасника сервісу МІС для пацієнта з використанням мобільного застосунку, учасником надається гарантійний лист з зазначенням адреси відповідних інтернет-ресурсів (Google Play та App Store), де розміщені зазначені застосунки для інсталяції, а також скріншоти електронних сторінок цих ресурсів, на яких повинна бути зазначена інформація про назву мобільного застосунку пацієнта та його виробника (власника), а також опис, з якого можна зробити висновок про його інтеграцію до запропонованої учасником системи.

7. Технічні вимоги до працездатності Системи відповідно до швидкості передачі даних каналами Учасника

Система має бути працездатною при наступній мінімальній швидкості каналів зв’язку

8. Вимоги до захисту інформації в МІС

8.1 Вимоги до обробки персональних даних

Персональні дані повинні оброблятися у МІС із застосуванням комплексної системи захисту інформації, що підтверджується атестатом відповідності КСЗІ ІТС на МІС та експертним висновком на організаційно-технічне рішення на типове робоче місце користувача ІТС МІС (зазначені документи учасник повинен надати у складі тендерної пропозиції. Допускається надання титульних листів цих документів без додатків та невід’ємних частин)

       9. Додаток для середнього медичного персоналу (сестер медичних)

-          У пропонованій МІС має  бути забезпечена можливість для середнього медичного персоналу (сестри медичні) користуватися сервісами системи за допомогою безкоштовного мобільного додатку (для смартфонів або планшетів).

-          Мобільний додаток має забезпечувати для такі функції:

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

-          Виконувати позначку проходження послуг (процедур) пацієнтів.

-          Інформувати працівника шляхом сповіщень про необхідність виконання процедур, тощо

Наявність додатку підтверджується листом що містить посилання, за яким додаток доступний для завантаження з відповідних сервісів.

Також, на вимогу Замовника Учасник має забезпечити можливість  доступу Замовника до пропонованої МІС у режимі демонстраційного доступу, для перевірки відповідності МІС вказаним вимогам.

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

Обґрунтування технічних та якісних характеристик предмета закупівлі, розміру бюджетного призначення, очікуваної вартості предмета закупівлі

Предмет закупівлі послуг за предметом:  код ДК 021:2015 код 48810000-9 – «Інформаційні системи» (Доступ до сервісів медичної інформаційної системи  «Медікс» у вигляді ліцензій користувача) Закупівля зареєстрована за Ідентифікатором закупівлі:

UA-2024-01-04-005713-a

Обґрунтування обсягів закупівлі. Обсяги визначено відповідно до очікуваної потреби, обрахованої  замовником та обсягу фінансування.

Обґрунтування технічних та якісних характеристик закупівлі. В основі медичної інформаційної системи  «Медікс»  - лежить вільний доступ пацієнта до своїх медичних даних, а також вільний вибір лікаря, клініки чи послуги. Система  автоматизує роботу реєстратури, упорядкувавши і спростивши процедуру запису пацієнтів на прийом; систематизує інформацію про всіх пацієнтів клініки, медичні послуги і співробітників; управляє своїм матеріальним фондом, чергою на місця в стаціонарі; упорядковує роботу лабораторій і діагностичних кабінетів; організовує оперативне передавання даних про результати досліджень фахівцеві у автоматичному режимі; збирає статистику; готує звіти та аналітику в кілька кліків тощо.

Очікувана вартість закупівлі: 310 000,00 гривень.

Строк надання послуг–  31.12.2024 р.

Технічні, якісні та кількісні характеристики предмета закупівлі                        

1. Номенклатура та обсяги закупівлі

ІІ. Технічні та якісні вимоги до предмету закупівлі

(ТЕХНІЧНА СПЕЦИФІКАЦІЯ):

1.  Вимоги до надійності та безпеки

1.1.  Вимоги до авторизації користувача у системі

Щоб отримати доступ до можливостей системи, кожен користувач має пройти авторизацію.

Авторизація користувача має виконуватись шляхом зчитування кваліфікованого електронного підпису (КЕП)/удосконаленого електронного підпису (УЕП) користувача (зазначення файлу із цифровим підписом, що зберігається на зовнішньому носії, та введення паролю до ключа) та його перевірки у АЦСК, де було отримано цей ключ, або вебтокену (хмарного електронного підпису).

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

Для забезпечення  захисту персональних та інших даних користувачів при використанні системою електронних підписів та задля дотримання вимог законодавства щодо використання електронних підписів надати у складі пропозиції ліцензію на використання учасником бібліотек програмного комплексу користувача центру сертифікації ключів "ІТТ Користувач ЦСК -1"

1.2.  Вимоги до протоколювання роботи користувачів системи

Система має виконувати протоколювання наступних дій користувачів:

• Спроба підключення до системи;
• Результат спроби підключення до системи;
• Завершення сеансу роботи у системі;
• Додавання інформації щодо наданих пацієнту медичних послуг;
• Додавання інформації щодо результатів наданих пацієнту медичних послуг;
• Зчитування інформації щодо наданих пацієнту медичних послуг;
• Зчитування інформації щодо результатів наданих пацієнту медичних послуг;
• Внесення персональних даних пацієнта;
• Зміна персональних даних пацієнта;
• Зчитування персональних даних пацієнта;
• Створення профілю користувача системи;
• Зміна профілю користувача.

Під час протоколювання мають фіксуватись наступні дані:

• Дата та час події;
• Користувач, який ініціював подію;
• IP адреса користувача, який ініціював подію;
• Тип події з наведеного переліку.

Для подій, пов’язаних зі створенням, зміною або отриманням доступу до даних користувачів, пацієнтів, медичних працівників, медичних послуг та їхніх результатів, має фіксуватись інформація про об’єкт доступу - результат події (завершено вдало або ні).

У якості сховища протоколів роботи системи має використовуватися кластер СУДБ MongoDB з не менш ніж трьох нод, кожна з яких має містити повну копію протоколу.

1.3. Вимоги до резервного копіювання

Створення архівних копій баз даних системи має бути налаштовано штатними механізмами системами.

Мінімальна періодичність створення архівних копій не має перевищувати 1 доби.

Для забезпечення можливості відновлення інформації архіви мають зберігатися з такою періодичністю:

• Останні 7 щоденних архівів (станом на 00:00 кожного дня)
• Останні 12 місячних архівів (станом на 00:00 першого дня місяця)

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

1.4.  Вимоги до надійності

Робота системи має бути організована у цілодобовому режимі з можливістю доступу не менше 99,0% за рік.   

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

Задля забезпечення надійності  та безпечності системи в учасника має бути впроваджена система управління інформаційною безпекою, що відповідає вимогам  ДСТУ ISO/IEC 27001:2015 Інформаційні технології. Методи захисту cистеми управління інформаційною безпекою. Вимоги (ISO/IEC 27001:2013; Cor 1:2014, IDT), стосовно розробки та налаштування програмного забезпечення, аналітика програмного забезпечення, архітектура, дизайн, розробка та тестування, послуги програмного та хмарного забезпечення, технічна підтримка та UX/UI послуги, навчання користувачів, що підтверджується поданням у складі пропозиції відповідного сертифікату. Також учасник має підтвердити повноваження органу( установи, організації) що видала такий сертифікат, шляхом надання у складі пропозиції  документів щодо акредитації (нотифікації) організації,  що видала зазначений сертифікат.

1.5. Вимоги до інформаційної та програмної сумісності

У якості мови розробки прикладного програмного забезпечення мають використовуватися Python 3.6, Django 2.2. Для системи керування базами даних мають використовуватися PostgreSQL 12.7, MongoDB  не нижче 3.6. Також мають бути задіяні наступні інструменти: система керування файлами - Ceph, система логування та збору статистики - Logstash, база даних користувацьких логів роботи - MongoDB не нижче 3.6, система моніторингу - Sentry 8.22.0.

1.6. Технічні вимоги до сумісності МІС з мінімальними програмно-апаратними характеристиками автоматизованого робочого місця доступу персоналу до системи

Системні Характеристики АРМ Замовника (мінімальні):

• процесор: 2 core Intel/AMD 2 GHz;
• відеоадаптер: будь який;
• об’єм оперативної пам’яті: 4 Гб;
• дисковий простір HDD/SSD: не менше 100 ГБ;
• засіб для зчитування КЕП/УЕП із носія інформації (USB-порт);
• монітор із роздільною здатністю екрану 1280*1024;
• наявність мережевого адаптеру з пропускною здатністю 10 Мб/с.

Характеристики мережі Замовника (мінімальні):

• Пропускна здатність каналу зв’язку до мережі Інтернет 1 Мbit/s.

У разі використання сервісів відеозв'язку:

• гарнітура;
• веб-камера 720р.

Характеристики операційних систем та веб-браузерів Замовника:

• операційні середовища: сімейства Windows та Linux;
• Google Chrome.

1.7 Умови надання послуг та технічної підтримки адміністратором оператору МІС

Виконавець має забезпечити наявність веб-сайту, де публікується контактні дані для зв’язку зі службою клієнтської (технічної) підтримки.

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

Виконавець має забезпечити безвідмовну роботу МІС (ЦБД) та доступність її всіх основних функцій протягом 99,0 % часу кожного місяця.

Виконавець має забезпечувати підтримку тестових середовищ системи 95% часу безвідмовної роботи кожного місяця, опрацювання інцидентів, надання консультаційних запитів щодо тестових середовищ у термін не більше 12 (дванадцять) робочих днів з моменту отримання запиту.

1.8. Вимоги до взаємодії системи з центральною базою даних електронної системи охорони здоров’я України

Для забезпечення коректної взаємодії з центральною базою даних електронної системи охорони здоров’я України Система має відповідати Технічним вимогам до електронної медичної інформаційної системи для її підключення до центральної бази даних електронної системи охорони здоров’я, затвердженим наказом Національної служби здоров’я України № 28 від 06.02.2019 (з урахуванням змін та в редакції, чинній на момент оголошення закупівлі).

Учасник повинен бути уповноваженим Оператором Електронної системи охорони здоров’я (eHealth), що приєднався до відповідного Договору з ДП «Електронне здоров’я» та повинен мати протестовані та підключені до Центральної бази даних Електронної системи охорони здоров’я наступні функціональні модулі:

• Адмін модуль НМП СМД;
• Електронні медичні записи;
• Даагностичні звіти;
• ЕМЗ та ЕН для неідентифікованих пацієнтів;
• ЕМЗ Стаціонар: надходження;
• ЕМЗ Стаціонар: виписка;
• Доступ до даних;
• Робота з записами про ідентифікованих пацієнтів;
• Робота з записами про неідентифікованих пацієнтів;
• Приєднання записів неідентифікованого пацієнта до ідентифікованого;
• Медичні висновки про народження дитини;
• Медичні висновки про тимчасову непрацездатність;
• Виписування електронного рецепту;
• План лікування;
• Робоче місце середнього медичного персоналу;
• Неонатальний скринінг;
• Робоче місце адміністратора медичних записів;
• Клінічна оцінка;
• Електронні направлення;
• Процедури;
• Спостереження;
• Виписування електронного рецепту на ЛЗ.

Замовник також може перевіряти інформацію щодо підключення МІС та проходження тестування відповідних функціональних модулів на офіційному сайті ДП «Електронне здоров’я».

1.9. Вимоги до взаємодії з Електронним реєстром листків непрацездатності

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

2. Загальні вимоги до системи

2.1.  Вимоги до інтерфейсу користувача

Інтерфейс взаємодії користувачів з електронними реєстрами даних повинен бути заснований на принципі візуального графічного інтерфейсу (GUI). Інтерфейс системи має бути зрозумілим і зручним, не перевантаженим графічними елементами, повинен забезпечувати швидке відображення екранних форм. Навігаційні елементи мають бути виконані у зручній для користувача формі. Введення-виведення даних системи, прийом команд керування і відображення результатів їх виконання повинні виконуватися в інтерактивному режимі. Інтерфейс повинен відповідати сучасним ергономічним вимогам і забезпечувати зручний доступ до основних функцій системи.

Інтерфейс повинен бути розрахований на переважне використання маніпулятора типу «миша», тобто управління системою має здійснюватися за допомогою керуючих елементів. Клавіатурний режим введення повинен використовуватися головним чином для заповнення та/або редагування текстових і числових полів екранних форм.

Система повинна використовувати вибрану мову для оформлення будь-яких елементів інтерфейсу, включаючи підписи, екранні кнопки, меню, документацію, підказки системи і повідомлення програми користувачеві (крім повідомлень від загальносистемного ПЗ).

Система повинна забезпечувати коректну обробку аварійних ситуацій, викликаних неправильними діями користувачів, невірним форматом або неприпустимими значеннями вхідних даних. У зазначених випадках система повинна видавати користувачу відповідні повідомлення, після чого повертатися в робочий стан, що передував невірній (неприпустимій) команді або некоректному введенню даних.

Екранні форми повинні проектуватися з урахуванням вимог уніфікації: всі екранні форми користувальницького інтерфейсу повинні бути виконані в єдиному графічному стилі, з однаковим розташуванням основних елементів керування та навігації; для позначення подібних операцій повинні використовуватися подібні керуючі (навігаційні) елементи. Терміни, що використовуються для позначення типових операцій (додавання/редагування значень), а також послідовності дій користувача при їх виконанні, повинні бути уніфіковані; зовнішня поведінка подібних елементів інтерфейсу (реакція на наведення покажчика «миші», перемикання фокусу, натиснення кнопки) повинні реалізовуватися однаково для однотипних елементів.

Наявність навчального порталу для користувачів.

2.2.  Модуль адміністратора юридичної особи

Для забезпечення керування роботою юридичної особи в системі система має містити модуль адміністратора юридичної особи.

Авторизація користувача має виконуватись за процедурою, вказаною у розділі “Вимоги до авторизації користувача у системі”. У разі проходження процедури авторизації та наявності серед знайдених облікових записів користувачів активного облікового запису із групою доступу “Адміністратор”, користувач отримує доступ до системи з правами, які налаштовані для цієї групи доступу.

Модуль адміністратора має давати можливість користувачам виконувати у системі наступні функції:

• Редагувати інформацію про юридичну особу в Електронній системі охорони здоров’я;
• Створювати профіль користувачів в межах своєї організації;
• Створювати та редагувати підрозділи організації;
• Встановлювати ролі за функціональними обов’язками та підрозділами організації;
• Встановлювати недоступність лікаря з існуючим графіком із можливістю призначення лікаря, який заміщує
• Переглядати перелік записів на прийом до лікарів;
• Переглядати перелік записів на прийом, які потребують зміни параметрів прийому через недоступність лікарів;
• Переглядати загальний графік роботи лікарів установи із зазначенням загальної кількості планових прийомів лікаря та вже зайнятих за попереднім записом пацієнтів;
• Реєструвати пацієнта у системі для подальшого затвердження лікарем;
• Записувати пацієнта на прийом;
• Укладати для організації договори з НСЗУ та продовжувати їхній термін;
• Налаштовувати перелік послуг, які надає організація;
• Редагувати параметри придбаних ліцензій (змінювати кількість спеціалістів для кожної ролі та призначати для них співробітників);
• Формувати журнали за довільний період з можливістю експорту у формат xls:
• Журнал прийомів
• Журнал викликів додому
• Журнал вакцинацій за формою 063/о
• Журнал аналізів та їхні результати
• Журнал реєстрації амбулаторних пацієнтів
• Журнал обліку процедур
• Формувати звіти та статистичні форми:         
  • • Звіт про прийоми, які були проведені лікарями організації, в розрізі лікаря, структурного підрозділу, відділення, або організації в цілому;
    • Відомість обліку відвідувань пацієнтів - дані про відвідування у закладі охорони здоров’я та вдома дітей віком до 17 років та дорослих;
    • Звіт про надані послуги лікарів установи із зазначенням наданих послуг, їх кількості та вартості;
    • Звіт про всі рецепти для отримання лікарських засобів, видані пацієнтам;
    • Звіт про вхідні та вихідні лабораторні дослідження;
    • Звіт про виконання процедур маніпуляційним кабінетом установи;
    • Дані про пацієнтів, які відносяться до певних груп ризику залежно від встановленого діагнозу;
    • Дані про епізоди лікування;
    • Звіт про видані пацієнтам листки непрацездатності;
    • Звіт по групам диспансерного нагляду;
    • Звіт про склад пацієнтів закладів області за статтю, віком та певними пільговими категоріями;
    • Звіт щодо записів на прийом;
    • Звіт із даними про імунізацію пацієнтів;
    • Довідки про тимчасову непрацездатність;
    • Медичні висновки про тимчасову непрацездатність;
    • Звіт про направлення, сформовані у даному функціоналі та передані до системи eHealth;
    • Перелік електронних медичних записів, зареєстрованих у eHealth;
    • Перелік діагностичних звітів та процедур;
    • Перелік зареєстрованих спостережень;
    • Звіт щодо госпіталізацій та виписок зі стаціонару;
    • Звіт з показниками якості ведення медичних записів лікарями організації;
    • Звіт про роботу палат та ліжок;
    • Звіт про виписані та погашені електронні направлення;
    • Звіт по хірургічній роботі стаціонару.

• Формувати графік роботи лікарів за допомогою схем прийому, на певний проміжок часу, а також за індивідуальними графіками. Формування графіку роботи лікарів має відбуватись із зазначенням таких параметрів:
• Лікар;
• Спеціальність обраного лікаря;
• Підрозділ установи, в якому буде працювати лікар;
• Номер кабінету, в якому буде вести прийом лікар;
• Дата та час роботи лікаря;
• Тип робочого часу лікаря (амбулаторний прийом, виклик додому, перерва);
• Інтервал на один прийом пацієнта;
• Можливість пацієнтам самостійно записатись на прийом до лікаря (опціонально) через веб-версію сайту, або мобільний додаток;
• Дозвіл записувати у живу чергу до лікаря (опціонально, якщо тип робочого часу - амбулаторний прийом);
• Обмеження віку пацієнтів, які можуть записатись на прийом;
• Дозвіл лікарю самостійно записувати пацієнтів собі на прийом (опціонально, якщо тип робочого часу - амбулаторний прийом). Можливість блокування онлайн запису на прийом в межах цілого ЗОЗ?

3. Забезпечення робочого процесу медичних працівників

1. 1.  Вимоги до модулю реєстратора

Для забезпечення виконання обов'язків працівника реєстратури в системі має бути модуль реєстратора.

Авторизація користувача має виконуватись за процедурою, вказаною у розділі “Вимоги до авторизації користувача у системі”. У разі проходження процедури авторизації та наявності серед знайдених акаунтів користувачів активного аккаунту з групою доступу “Реєстратор” користувач отримує доступ до системи з правами, які налаштовані для цієї групи доступу.

Модуль реєстратора має надавати змогу реєстраторам виконувати в системі наступні функції:

• формування профілю пацієнта в системі;
• редагування персональних (не медичних) даних пацієнта;
• верифікація даних пацієнта;
• верифікація телефону пацієнта через СМС;
• введення та коригування графіку прийому лікаря (опціонально);
• запис пацієнта на прийом до лікаря;
• скасування запису пацієнта до лікаря;
• друк талонів на прийом до лікаря;
• перегляд списку записів на прийом, встановлення відміток про прибуття пацієнта або відмітки про скасування візиту;
• перегляд загального розкладу роботи лікарів установи;
• друк журналу викликів лікарів;
• друк журналу запланованих прийомів лікарів;
• встановлення і підтвердження методу автентифікації пацієнта;
• можливість виконувати пошук електронних направлень у системі eHealth і змінювати статус записів для реалізації направлень:
• можливість прийняти направлення для реалізації, помістивши його у чергу для обробки;
• можливість за бажанням пацієнта скасувати призначення направлення, прийнятого для обробки в іншій організації, і призначити його виконання у поточній організації, прийнявши у чергу.

1. 2. Вимоги до модулю кадровика

Для забезпечення виконання обов’язків кадровика закладу, в системі має бути реалізований модуль “Кадровик”.

Авторизація користувача має виконуватись за процедурою, вказаною у розділі “Вимоги до авторизації користувача у системі”. У разі проходження процедури авторизації та наявності серед знайдених акаунтів користувачів активного аккаунту з групою доступу “Кадровик” користувач отримує доступ до системи з правами, які налаштовані для цієї групи доступу.

Модуль кадровика має надавати змогу кадровикам виконувати в системі наступні функції:

• Авторизація в системі;
• Перегляд персоналу закладу;
• Можливість перегляду працівників в залежності від спеціальності за допомогою фільтрів;
• Можливість пошуку працівника за ключовими параметрами (ПІБ, спеціальність);
• Можливість редагувати дані про працівника, в електронній системі охорони здоров’я;
• Можливість підписувати тза завіряти зміни в персоналі власним КЕП;
• Можливість присвоювати роль працівникам закладу, відповідно до видів медичних послуг;

1. 3.  Вимоги до модулю статистика

Для забезпечення виконання обов’язків статистика закладу, в системі має бути реалізований модуль “Статистик”.

Авторизація користувача має виконуватись за процедурою, вказаною у розділі “Вимоги до авторизації користувача у системі”. У разі проходження процедури авторизації та наявності серед знайдених акаунтів користувачів активного аккаунту з групою доступу “Статистик” користувач отримує доступ до системи з правами, які налаштовані для цієї групи доступу.

Модуль статистика має надавати змогу статистикам виконувати в системі наступні функції:

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

1. 4.  Вимоги до модулю лікаря амбулаторного відділення спеціалізованої (вторинної) медичної допомоги

 Для забезпечення виконання обов'язків лікаря у системі має бути наявний амбулаторний модуль лікаря вторинної (спеціалізованої) медичної допомоги. Авторизація користувача має виконуватися за процедурою, вказаною у розділі “Вимоги до авторизації користувача у системі”. У разі проходження процедури авторизації та наявності серед знайдених облікових записів користувачів активного облікового запису із групою доступу “Лікар” користувач отримує доступ до системи із правами, які налаштовані для цієї групи доступу.

Для планування роботи лікар повинен мати можливість відкривати для перегляду власний розклад амбулаторних прийомів пацієнтів;

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

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

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

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

Система має надавати можливість фіксувати наступні дані:

• Назва епізоду;
• Тип епізоду;
• Дата початку епізоду;
• Дата закриття епізоду;
• Причина закриття епізоду;
• Тип взаємодії;
• Дата та час взаємодії з можливістю ручного корегування;
• Скарги пацієнта за класифікатором ICPC-2;
• Основний діагноз за класифікатором МКХ-10 АМ;
• Додаткові діагнози за класифікатором МКХ-10 АМ;
• Надані пацієнту послуги за класифікатором АКМІ;
• Результати обстежень через ЕМЗ “діагностичний звіт”.
• Результати обстежень ЕМЗ “діагностичний звіт”, коли інформація вноситься з “вторинного джерела”
• Проведення процедур/хірургічних процедур через ЕМЗ “процедури”
• Проведення процедур/хірургічних процедур ЕМЗ “процедура”. коли інформація вноситься з “вторинного джерела”
• Об’єктивний статус;
• Дані про вакцинацію;
• Дані про клінічну оцінку;
• Спостереження.

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

Лікар повинен мати можливість сформувати медичний висновок про тимчасову непрацездатність з передачею даних до ЕРЛН для формування електронного лікарняного і можливістю продовжувати і скорочувати термін висновку.

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

Лікар повинен мати можливість виконати та зареєструвати вакцинацію із зазначенням всіх обов’язкових для передачі до центрального компоненту параметрів. Також він повинен мати можливість зареєструвати невиконання вакцинації із зазначенням причин. Для реалізації щеплення лікар повинен мати змогу залучити маніпуляційний кабінет.

Лікар повинен мати можливість виписати електронне направлення, на діагностику, процедури, консультації інших фахівців, або на госпіталізацію. Також має бути можливість друку направлень

Лікар повинен мати можливість створювати шаблони прийому, та застосовувати їх при створенні взаємодій, для пришвидшення роботи.

Лікар повинен мати можливість створювати та застосовувати шаблони направлень (група направлень), для пришвидшення роботи.

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

Лікар повинен мати можливість без запису пацієнта на прийом:

Переглядати його медичну інформацію;

Позначати помилковими медичні записи;

Друкувати медичні записи;

Формувати медичний висновок про непрацездатність на підставі раніше проведеного прийому, в часових рамках встановлених вимогами НСЗУ;

Закривати існуючий активний епізод;

Формувати електронне направлення на підставі раніше проведеного прийому, в часових рамках встановлених вимогами НСЗУ    

Лікар повинен мати можливість отримати доступ до груп чутливих станів, а також безпосередньо до медичних записів - як для перегляду записів, так і для обробки направлення, що містить чутливі дані. Лікар повинен мати можливість скасувати доступ, отриманий ним безпосередньо.

Система має фіксувати всі процедури чи послуги, які отримав пацієнт під час прийому у лікаря.

Під час внесення даних до медичної картки потрібно обирати скарги та об’єктивні дані з довідників системи. Кількість полів, які потрібно  заповнювати вручну, не має перевищувати 20% від загальної кількості. До певних полів, де доступний вибір із довідників системи, лікар повинен мати можливість власноруч додавати значення, після чого ці значення мають зберігатися у довіднику лікаря, який їх додав.

Лікар повинен мати змогу оформити підсумки прийому у вигляді звіту. Під час реєстрації подій, які формують електронну медичну історію пацієнта, лікар, який їх ініціював, повинен мати змогу затвердити їх за допомогою особистого КЕП/УЕП.

Використовуючи інструменти системи, лікар повинен мати змогу створювати звітність за результатами роботи:

• реєстр пацієнтів, які пройшли амбулаторний прийом;
• реєстр візитів пацієнтів до медичного закладу;
• медичний висновок консультативного характеру (довідка);
• витяг за даними персональної медичної картки пацієнта, що пройшов амбулаторний прийом;
• виписані направлення;;
• перелік визначених діагнозів у розрізі пацієнтів;
• дані про видані тимчасові листки непрацездатності;
• дані щодо диспансерного обліку пацієнтів;
• перелік послуг, отриманих пацієнтами в результаті відвідування медичного закладу;
• дані про призначення лікарських засобів пацієнтам;
• дані про виконані лабораторні дослідження;
• перелік реалізованих діагностичних звітів та процедур;
• перелік категорій населення, які мають певні пільги;
• перелік епізодів лікування;
• звіт, який містить дані про імунізацію пацієнтів;
• розширений звіт про виконані у поточному медичному закладі та зареєстровані у системі eHealth щеплення;
• реєстр спостережень;
• довідки про тимчасову непрацездатність;
• сертифікат про вакцинацію міжнародного зразка;

Забезпечення функцій діагностичних відділень (кабінетів)

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

• автоматичне формування списку пацієнтів, що направлені на діагностичні дослідження на робочому місці;
• структурування даних по пацієнтам за допомогою системи фільтрів на робочому місці;
• можливість створення направлень для фіксації самозвернень пацієнтів;
• можливість пошуку пацієнта за номером направлення;
• перегляд історії хвороби пацієнта (лише для лікаря);
• фіксація первинної інформації щодо дослідження (номер дослідження, вид дослідження, мета та ін.);
• створення лікарського заключення;
• автоматична фіксація результатів дослідження в ЕМК пацієнта;
• Формування статистичного звіту про виконані дослідження з можливістю експорту даних;
• друк діагностичного звіту з результатами дослідження.

3.5.  Вимоги до модулю Лікаря стаціонарного відділення спеціалізованої (вторинної) медичної допомоги

3.5.1.   Приймальне відділення

Для забезпечення виконання робочих процесів реєстратора в приймальному відділенні система повинна містити модуль приймального відділення. Модуль приймального відділення повинен містити наступний функціонал:

• Реєстрація всіх звернень пацієнтів в приймальному відділенні;
• Поетапне внесення даних по зверненню. Можливість відкласти внесення даних по поточному зверненню для внесення наступного звернення;
• Реєстрація даних про амбулаторний прийом в разі відмови від госпіталізації;
• Реєстрація пацієнтів, що госпіталізуються в стаціонарні відділення (планово та ургентно);
• Пошук пацієнта за номером електронного направлення;
• Госпіталізація неідентифікованих пацієнтів;
• Реєстрація даних про травми;
• Журнал реєстрації амбулаторних пацієнтів (форма 074/О);
• Перегляд списків звернень з можливістю пошуку та фільтрації за параметрами звернення;
• Призначення пацієнту відділення для госпіталізації;
• Редагування даних про госпіталізацію;
• Перегляд даних пацієнтів які виписані зі стаціонарного лікування.
• Формування та друк титульної сторінки Медичної карти пацієнта стаціонару (форма №003/О)

3.5.2.  Керування ліжковим фондом

Для забезпечення можливості керування матеріально-технічною базою лікувального закладу в системі повинен бути модуль Керування ліжко фондом. Модуль повинен забезпечити наступні функціональні можливості:

• Можливість формування структури ліжкового фонду стаціонарних відділень з визначенням наступних параметрів - номер ліжка, профіль ліжка, номер палати, стаціонарне відділення;
• Реєстрація робочого статусу відділень, палат, ліжок;
• Контроль зайнятості кожного ліжка стаціонару;
• Призначення палати та ліжка для конкретного пацієнта;
• Призначення лікуючого лікаря;
• Переміщення та вибуття пацієнтів.
• Переведення пацієнта до іншого відділення для подальшого лікування

3.5.3.  Забезпечення функцій лікаря стаціонарного відділення

Для забезпечення робочих процесів лікарського персоналу в системі повинен бути модуль Кабінет лікаря. Модуль повинен забезпечувати наступні можливості:

• Перегляд відомостей з електронної медичної картки пацієнта;
• Реєстрація основного і супутнього діагнозів за МКХ-10-АМ;
• Можливість призначення лікарських засобів;
• Можливість направлення на консультації, лабораторні та інструментальні дослідження, операції та інші процедури;
• Ведення реєстру направлень:
• можливість взяти направлення в роботу;
• можливість погасити направлення;
• можливість відкликати і скасувати направлення
• пошук направлення у системі eHealth;
• можливість поставити направлення у чергу та вилучити з черги за бажанням пацієнта;
• Ведення реєстру взаємодій;
• Ведення реєстру діагностичних звітів;
• Реєстрація даних про виконані хірургічні операції (згідно з АКМІ);
• Можливість зареєструвати вакцинацію та реакцію на вакцинацію
• ведення класифікатора вакцин та протидії загрозам;
• створення чернетки запису про виконану або невиконану вакцинацію;
• внесення історичних даних про вакцинацію (наприклад, на підставі паперових носіїв);
• фіксація запису про вакцинацію за допомогою взаємодії;
• реєстрація вакцинації у системі eНealth;
• скасування запису про вакцинацію в eНealth за допомогою позначення “Введено помилково”;
• Автоматичне формування списку наданих пацієнту послуг;
• Введення даних про листки непрацездатності;
• Формування медичних висновків про непрацездатність (МВТН):
• реєстрація МВТН на підставі затвердженої взаємодії;
• використання категорій, затверджених у системі eHealth;
• позначення особливих обставин випадку відповідно до вимог системи  eHealth;
• контроль періодів непрацездатності відповідно до вимог системи  eHealth;
• відправка МВТН до системи eHealth;
• можливість отримати із системи  eHealth актуальні дані щодо зареєстрованих для пацієнта МВТН;
• затвердження МВТН за допомогою КЕП;
• можливість повторно надіслати МВТН до ЕРЛН у разі помилки або технічних проблем;
• можливість надрукувати МВТН;
• можливість продовжити період непрацездатності відповідно до стану пацієнта або додаткових обставин;
• можливість скоротити період непрацездатності відповідно до стану пацієнта або додаткових обставин;
• можливість позначити МВТН як введений помилково;
• Можливість переглядати загальний перелік медичних висновків та формування вибірок за допомогою фільтрів;
• Можливість отримувати доступ до медичних висновків, створених в інших організаціях;
• Можливість отримувати доступ до обробки чутливих даних у зверненні та направленні, використовуючи дозвіл пацієнта;
• Можливість переглядати і скасовувати доступ до медичних записів, отриманий за дозволом пацієнта;
• Можливість вносити локальні дані, які пізніше формуватимуть виписку пацієнта (щоденні огляди тощо)
• Автоматизоване формування заключення для виписки на підставі внесених у звернення даних;
• Можливість внесення та передачі даних про взаємодію (виписку) до центрального компоненту eHealth;
• Можливість створення та передачі до центрального компоненту eHealth неідентифікованих та ідентифікованих пацієнтів;
• Можливість переглядати зведену інформацію про пацієнта, отримуючи дані із системи eHealth та використовуючи дозвіл пацієнта;
• Можливість створення та передачі до центрального компоненту eHealth діагностичних звітів, процедур, спостережень у складі взаємодії;
• Можливість погашення направлення eHealth на госпіталізацію;
• Можливість об’єднання неідентифікованих пацієнтів з ідентифікованими;
• Можливість змінити eHealth ідентифікатор пацієнта у зверненні, щоб визначити приналежність медичних даних;
• Можливість керування методами автентифікації ідентифікованого пацієнта;
• Автоматичне формування та друк Медичної карти пацієнта стаціонару (форма №003/О);
• Формування Карти пацієнта, який вибув зі стаціонару (форма №066/О);
• Формування та друк «Виписки із медичної карти амбулаторного (стаціонарного) хворого» (форма №027/О).

4. Вимоги до достовірності медичної інформації

Для забезпечення достовірності медичної інформації, що вноситься медичними працівниками особисто за допомогою системи або переноситься з інших медичних інформаційних систем, кожний такий запис має бути підписаний КЕП/УЕП/вебтокеном медичного працівника.

5. Вимоги до інтеграції з іншими системами

5.1. Модуль взаємодії із системами постачання довідникової інформації

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

Із поточної системи до систем постачання довідникової інформації може передаватись наступна інформація:

• Деперсоналізована інформація щодо наданих медичних послуг та результати надання медичних послуг;
• Інформація щодо юридичних осіб, структурних підрозділів, медичних працівників, які надають медичні послуги за допомогою системи;
• Інформація щодо події, за умови виконання якої виконується звернення до системи постачання довідникової інформації.

Для деперсоналізації має вилучатися вся персональна інформація про пацієнта крім даних про такі характеристики:

• Стать пацієнта
• Дата народження пацієнта
• Населений пункт та вулиця проживання пацієнта

Перелік інформації, яка має надаватись системами постачання довідникової інформації:

• Реєстр лікарських засобів;
• Перелік пільгових програм для пільгових рецептів;
• Перелік лікарських засобів у пільгових програмах;
• Класифікатор МКХ-10-АМ або ICPC-2;
• Територіальні класифікатори (області, населені пункти, назви та типи вулиць);
• Класифікатор типів медичних послуг.

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

6. ФУНКЦІОНАЛ ДЛЯ ПАЦІЄНТА

1. 1. Вимоги до інтерфейсу для веб-версії “Особистий кабінет пацієнта”

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

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

1. 2. Вимоги до інтерфейсу для мобільного застосунку для пацієнта

Пацієнт повинен мати можливість користуватися сервісом для пацієнта за допомогою мобільного застосунку (для смартфонів, айфонів або планшетів на операційних системах Android/iOS). Мобільний застосунок має забезпечувати для пацієнта наступні функції:

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

На підтвердження наявності в учасника сервісу МІС для пацієнта з використанням мобільного застосунку, учасником надається гарантійний лист з зазначенням адреси відповідних інтернет-ресурсів (Google Play та App Store), де розміщені зазначені застосунки для інсталяції, а також скріншоти електронних сторінок цих ресурсів, на яких повинна бути зазначена інформація про назву мобільного застосунку пацієнта та його виробника (власника), а також опис, з якого можна зробити висновок про його інтеграцію до запропонованої учасником системи.

7. Технічні вимоги до працездатності Системи відповідно до швидкості передачі даних каналами Учасника

Система має бути працездатною при наступній мінімальній швидкості каналів зв’язку

8. Вимоги до захисту інформації в МІС

8.1 Вимоги до обробки персональних даних

Персональні дані повинні оброблятися у МІС із застосуванням комплексної системи захисту інформації, що підтверджується атестатом відповідності КСЗІ ІТС на МІС та експертним висновком на організаційно-технічне рішення на типове робоче місце користувача ІТС МІС (зазначені документи учасник повинен надати у складі тендерної пропозиції. Допускається надання титульних листів цих документів без додатків та невід’ємних частин)

       9. Додаток для середнього медичного персоналу (сестер медичних)

-          У пропонованій МІС має  бути забезпечена можливість для середнього медичного персоналу (сестри медичні) користуватися сервісами системи за допомогою безкоштовного мобільного додатку (для смартфонів або планшетів).

-          Мобільний додаток має забезпечувати для такі функції:

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

-          Виконувати позначку проходження послуг (процедур) пацієнтів.

-          Інформувати працівника шляхом сповіщень про необхідність виконання процедур, тощо

Наявність додатку підтверджується листом що містить посилання, за яким додаток доступний для завантаження з відповідних сервісів.

Також, на вимогу Замовника Учасник має забезпечити можливість  доступу Замовника до пропонованої МІС у режимі демонстраційного доступу, для перевірки відповідності МІС вказаним вимогам.

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

Обґрунтування технічних та якісних характеристик предмета закупівлі, розміру бюджетного призначення, очікуваної вартості предмета закупівлі

Предмет закупівлі послуг за предметом:  код ДК 021:2015 код 48810000-9 – «Інформаційні системи» (Доступ до сервісів медичної інформаційної системи  «Медікс» у вигляді ліцензій користувача) Закупівля зареєстрована за Ідентифікатором закупівлі:

UA-2024-01-04-005713-a

Обґрунтування обсягів закупівлі. Обсяги визначено відповідно до очікуваної потреби, обрахованої  замовником та обсягу фінансування.

Обґрунтування технічних та якісних характеристик закупівлі. В основі медичної інформаційної системи  «Медікс»  - лежить вільний доступ пацієнта до своїх медичних даних, а також вільний вибір лікаря, клініки чи послуги. Система  автоматизує роботу реєстратури, упорядкувавши і спростивши процедуру запису пацієнтів на прийом; систематизує інформацію про всіх пацієнтів клініки, медичні послуги і співробітників; управляє своїм матеріальним фондом, чергою на місця в стаціонарі; упорядковує роботу лабораторій і діагностичних кабінетів; організовує оперативне передавання даних про результати досліджень фахівцеві у автоматичному режимі; збирає статистику; готує звіти та аналітику в кілька кліків тощо.

Очікувана вартість закупівлі: 310 000,00 гривень.

Строк надання послуг–  31.12.2024 р.

Технічні, якісні та кількісні характеристики предмета закупівлі                        

1. Номенклатура та обсяги закупівлі

ІІ. Технічні та якісні вимоги до предмету закупівлі

(ТЕХНІЧНА СПЕЦИФІКАЦІЯ):

1.  Вимоги до надійності та безпеки

1.1.  Вимоги до авторизації користувача у системі

Щоб отримати доступ до можливостей системи, кожен користувач має пройти авторизацію.

Авторизація користувача має виконуватись шляхом зчитування кваліфікованого електронного підпису (КЕП)/удосконаленого електронного підпису (УЕП) користувача (зазначення файлу із цифровим підписом, що зберігається на зовнішньому носії, та введення паролю до ключа) та його перевірки у АЦСК, де було отримано цей ключ, або вебтокену (хмарного електронного підпису).

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

Для забезпечення  захисту персональних та інших даних користувачів при використанні системою електронних підписів та задля дотримання вимог законодавства щодо використання електронних підписів надати у складі пропозиції ліцензію на використання учасником бібліотек програмного комплексу користувача центру сертифікації ключів "ІТТ Користувач ЦСК -1"

1.2.  Вимоги до протоколювання роботи користувачів системи

Система має виконувати протоколювання наступних дій користувачів:

• Спроба підключення до системи;
• Результат спроби підключення до системи;
• Завершення сеансу роботи у системі;
• Додавання інформації щодо наданих пацієнту медичних послуг;
• Додавання інформації щодо результатів наданих пацієнту медичних послуг;
• Зчитування інформації щодо наданих пацієнту медичних послуг;
• Зчитування інформації щодо результатів наданих пацієнту медичних послуг;
• Внесення персональних даних пацієнта;
• Зміна персональних даних пацієнта;
• Зчитування персональних даних пацієнта;
• Створення профілю користувача системи;
• Зміна профілю користувача.

Під час протоколювання мають фіксуватись наступні дані:

• Дата та час події;
• Користувач, який ініціював подію;
• IP адреса користувача, який ініціював подію;
• Тип події з наведеного переліку.

Для подій, пов’язаних зі створенням, зміною або отриманням доступу до даних користувачів, пацієнтів, медичних працівників, медичних послуг та їхніх результатів, має фіксуватись інформація про об’єкт доступу - результат події (завершено вдало або ні).

У якості сховища протоколів роботи системи має використовуватися кластер СУДБ MongoDB з не менш ніж трьох нод, кожна з яких має містити повну копію протоколу.

1.3. Вимоги до резервного копіювання

Створення архівних копій баз даних системи має бути налаштовано штатними механізмами системами.

Мінімальна періодичність створення архівних копій не має перевищувати 1 доби.

Для забезпечення можливості відновлення інформації архіви мають зберігатися з такою періодичністю:

• Останні 7 щоденних архівів (станом на 00:00 кожного дня)
• Останні 12 місячних архівів (станом на 00:00 першого дня місяця)

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

1.4.  Вимоги до надійності

Робота системи має бути організована у цілодобовому режимі з можливістю доступу не менше 99,0% за рік.   

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

Задля забезпечення надійності  та безпечності системи в учасника має бути впроваджена система управління інформаційною безпекою, що відповідає вимогам  ДСТУ ISO/IEC 27001:2015 Інформаційні технології. Методи захисту cистеми управління інформаційною безпекою. Вимоги (ISO/IEC 27001:2013; Cor 1:2014, IDT), стосовно розробки та налаштування програмного забезпечення, аналітика програмного забезпечення, архітектура, дизайн, розробка та тестування, послуги програмного та хмарного забезпечення, технічна підтримка та UX/UI послуги, навчання користувачів, що підтверджується поданням у складі пропозиції відповідного сертифікату. Також учасник має підтвердити повноваження органу( установи, організації) що видала такий сертифікат, шляхом надання у складі пропозиції  документів щодо акредитації (нотифікації) організації,  що видала зазначений сертифікат.

1.5. Вимоги до інформаційної та програмної сумісності

У якості мови розробки прикладного програмного забезпечення мають використовуватися Python 3.6, Django 2.2. Для системи керування базами даних мають використовуватися PostgreSQL 12.7, MongoDB  не нижче 3.6. Також мають бути задіяні наступні інструменти: система керування файлами - Ceph, система логування та збору статистики - Logstash, база даних користувацьких логів роботи - MongoDB не нижче 3.6, система моніторингу - Sentry 8.22.0.

1.6. Технічні вимоги до сумісності МІС з мінімальними програмно-апаратними характеристиками автоматизованого робочого місця доступу персоналу до системи

Системні Характеристики АРМ Замовника (мінімальні):

• процесор: 2 core Intel/AMD 2 GHz;
• відеоадаптер: будь який;
• об’єм оперативної пам’яті: 4 Гб;
• дисковий простір HDD/SSD: не менше 100 ГБ;
• засіб для зчитування КЕП/УЕП із носія інформації (USB-порт);
• монітор із роздільною здатністю екрану 1280*1024;
• наявність мережевого адаптеру з пропускною здатністю 10 Мб/с.

Характеристики мережі Замовника (мінімальні):

• Пропускна здатність каналу зв’язку до мережі Інтернет 1 Мbit/s.

У разі використання сервісів відеозв'язку:

• гарнітура;
• веб-камера 720р.

Характеристики операційних систем та веб-браузерів Замовника:

• операційні середовища: сімейства Windows та Linux;
• Google Chrome.

1.7 Умови надання послуг та технічної підтримки адміністратором оператору МІС

Виконавець має забезпечити наявність веб-сайту, де публікується контактні дані для зв’язку зі службою клієнтської (технічної) підтримки.

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

Виконавець має забезпечити безвідмовну роботу МІС (ЦБД) та доступність її всіх основних функцій протягом 99,0 % часу кожного місяця.

Виконавець має забезпечувати підтримку тестових середовищ системи 95% часу безвідмовної роботи кожного місяця, опрацювання інцидентів, надання консультаційних запитів щодо тестових середовищ у термін не більше 12 (дванадцять) робочих днів з моменту отримання запиту.

1.8. Вимоги до взаємодії системи з центральною базою даних електронної системи охорони здоров’я України

Для забезпечення коректної взаємодії з центральною базою даних електронної системи охорони здоров’я України Система має відповідати Технічним вимогам до електронної медичної інформаційної системи для її підключення до центральної бази даних електронної системи охорони здоров’я, затвердженим наказом Національної служби здоров’я України № 28 від 06.02.2019 (з урахуванням змін та в редакції, чинній на момент оголошення закупівлі).

Учасник повинен бути уповноваженим Оператором Електронної системи охорони здоров’я (eHealth), що приєднався до відповідного Договору з ДП «Електронне здоров’я» та повинен мати протестовані та підключені до Центральної бази даних Електронної системи охорони здоров’я наступні функціональні модулі:

• Адмін модуль НМП СМД;
• Електронні медичні записи;
• Даагностичні звіти;
• ЕМЗ та ЕН для неідентифікованих пацієнтів;
• ЕМЗ Стаціонар: надходження;
• ЕМЗ Стаціонар: виписка;
• Доступ до даних;
• Робота з записами про ідентифікованих пацієнтів;
• Робота з записами про неідентифікованих пацієнтів;
• Приєднання записів неідентифікованого пацієнта до ідентифікованого;
• Медичні висновки про народження дитини;
• Медичні висновки про тимчасову непрацездатність;
• Виписування електронного рецепту;
• План лікування;
• Робоче місце середнього медичного персоналу;
• Неонатальний скринінг;
• Робоче місце адміністратора медичних записів;
• Клінічна оцінка;
• Електронні направлення;
• Процедури;
• Спостереження;
• Виписування електронного рецепту на ЛЗ.

Замовник також може перевіряти інформацію щодо підключення МІС та проходження тестування відповідних функціональних модулів на офіційному сайті ДП «Електронне здоров’я».

1.9. Вимоги до взаємодії з Електронним реєстром листків непрацездатності

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

2. Загальні вимоги до системи

2.1.  Вимоги до інтерфейсу користувача

Інтерфейс взаємодії користувачів з електронними реєстрами даних повинен бути заснований на принципі візуального графічного інтерфейсу (GUI). Інтерфейс системи має бути зрозумілим і зручним, не перевантаженим графічними елементами, повинен забезпечувати швидке відображення екранних форм. Навігаційні елементи мають бути виконані у зручній для користувача формі. Введення-виведення даних системи, прийом команд керування і відображення результатів їх виконання повинні виконуватися в інтерактивному режимі. Інтерфейс повинен відповідати сучасним ергономічним вимогам і забезпечувати зручний доступ до основних функцій системи.

Інтерфейс повинен бути розрахований на переважне використання маніпулятора типу «миша», тобто управління системою має здійснюватися за допомогою керуючих елементів. Клавіатурний режим введення повинен використовуватися головним чином для заповнення та/або редагування текстових і числових полів екранних форм.

Система повинна використовувати вибрану мову для оформлення будь-яких елементів інтерфейсу, включаючи підписи, екранні кнопки, меню, документацію, підказки системи і повідомлення програми користувачеві (крім повідомлень від загальносистемного ПЗ).

Система повинна забезпечувати коректну обробку аварійних ситуацій, викликаних неправильними діями користувачів, невірним форматом або неприпустимими значеннями вхідних даних. У зазначених випадках система повинна видавати користувачу відповідні повідомлення, після чого повертатися в робочий стан, що передував невірній (неприпустимій) команді або некоректному введенню даних.

Екранні форми повинні проектуватися з урахуванням вимог уніфікації: всі екранні форми користувальницького інтерфейсу повинні бути виконані в єдиному графічному стилі, з однаковим розташуванням основних елементів керування та навігації; для позначення подібних операцій повинні використовуватися подібні керуючі (навігаційні) елементи. Терміни, що використовуються для позначення типових операцій (додавання/редагування значень), а також послідовності дій користувача при їх виконанні, повинні бути уніфіковані; зовнішня поведінка подібних елементів інтерфейсу (реакція на наведення покажчика «миші», перемикання фокусу, натиснення кнопки) повинні реалізовуватися однаково для однотипних елементів.

Наявність навчального порталу для користувачів.

2.2.  Модуль адміністратора юридичної особи

Для забезпечення керування роботою юридичної особи в системі система має містити модуль адміністратора юридичної особи.

Авторизація користувача має виконуватись за процедурою, вказаною у розділі “Вимоги до авторизації користувача у системі”. У разі проходження процедури авторизації та наявності серед знайдених облікових записів користувачів активного облікового запису із групою доступу “Адміністратор”, користувач отримує доступ до системи з правами, які налаштовані для цієї групи доступу.

Модуль адміністратора має давати можливість користувачам виконувати у системі наступні функції:

• Редагувати інформацію про юридичну особу в Електронній системі охорони здоров’я;
• Створювати профіль користувачів в межах своєї організації;
• Створювати та редагувати підрозділи організації;
• Встановлювати ролі за функціональними обов’язками та підрозділами організації;
• Встановлювати недоступність лікаря з існуючим графіком із можливістю призначення лікаря, який заміщує
• Переглядати перелік записів на прийом до лікарів;
• Переглядати перелік записів на прийом, які потребують зміни параметрів прийому через недоступність лікарів;
• Переглядати загальний графік роботи лікарів установи із зазначенням загальної кількості планових прийомів лікаря та вже зайнятих за попереднім записом пацієнтів;
• Реєструвати пацієнта у системі для подальшого затвердження лікарем;
• Записувати пацієнта на прийом;
• Укладати для організації договори з НСЗУ та продовжувати їхній термін;
• Налаштовувати перелік послуг, які надає організація;
• Редагувати параметри придбаних ліцензій (змінювати кількість спеціалістів для кожної ролі та призначати для них співробітників);
• Формувати журнали за довільний період з можливістю експорту у формат xls:
• Журнал прийомів
• Журнал викликів додому
• Журнал вакцинацій за формою 063/о
• Журнал аналізів та їхні результати
• Журнал реєстрації амбулаторних пацієнтів
• Журнал обліку процедур
• Формувати звіти та статистичні форми:         
  • • Звіт про прийоми, які були проведені лікарями організації, в розрізі лікаря, структурного підрозділу, відділення, або організації в цілому;
    • Відомість обліку відвідувань пацієнтів - дані про відвідування у закладі охорони здоров’я та вдома дітей віком до 17 років та дорослих;
    • Звіт про надані послуги лікарів установи із зазначенням наданих послуг, їх кількості та вартості;
    • Звіт про всі рецепти для отримання лікарських засобів, видані пацієнтам;
    • Звіт про вхідні та вихідні лабораторні дослідження;
    • Звіт про виконання процедур маніпуляційним кабінетом установи;
    • Дані про пацієнтів, які відносяться до певних груп ризику залежно від встановленого діагнозу;
    • Дані про епізоди лікування;
    • Звіт про видані пацієнтам листки непрацездатності;
    • Звіт по групам диспансерного нагляду;
    • Звіт про склад пацієнтів закладів області за статтю, віком та певними пільговими категоріями;
    • Звіт щодо записів на прийом;
    • Звіт із даними про імунізацію пацієнтів;
    • Довідки про тимчасову непрацездатність;
    • Медичні висновки про тимчасову непрацездатність;
    • Звіт про направлення, сформовані у даному функціоналі та передані до системи eHealth;
    • Перелік електронних медичних записів, зареєстрованих у eHealth;
    • Перелік діагностичних звітів та процедур;
    • Перелік зареєстрованих спостережень;
    • Звіт щодо госпіталізацій та виписок зі стаціонару;
    • Звіт з показниками якості ведення медичних записів лікарями організації;
    • Звіт про роботу палат та ліжок;
    • Звіт про виписані та погашені електронні направлення;
    • Звіт по хірургічній роботі стаціонару.