Доступ до сервісів медичної інформаційної системи «Медікс» у вигляді ліцензій користувача
Обґрунтування технічних та якісних характеристик предмета закупівлі, розміру бюджетного призначення, очікуваної вартості предмета закупівлі
Предмет закупівлі послуг за предметом: код ДК 021:2015 код 48810000-9 – «Інформаційні системи» (Доступ до сервісів медичної інформаційної системи «Медікс» у вигляді ліцензій користувача) Закупівля зареєстрована за Ідентифікатором закупівлі: UA-2025-02-25-006441-a
Обґрунтування обсягів закупівлі. Обсяги визначено відповідно до очікуваної потреби, обрахованої замовником та обсягу фінансування.
Обґрунтування технічних та якісних характеристик закупівлі. В основі медичної інформаційної системи «Медікс» - лежить вільний доступ пацієнта до своїх медичних даних, а також вільний вибір лікаря, клініки чи послуги. Система автоматизує роботу реєстратури, упорядкувавши і спростивши процедуру запису пацієнтів на прийом; систематизує інформацію про всіх пацієнтів клініки, медичні послуги і співробітників; управляє своїм матеріальним фондом, чергою на місця в стаціонарі; упорядковує роботу лабораторій і діагностичних кабінетів; організовує оперативне передавання даних про результати досліджень фахівцеві у автоматичному режимі; збирає статистику; готує звіти та аналітику в кілька кліків тощо.
Очікувана вартість закупівлі: 300 000,00 гривень.
Строк надання послуг– 31.12.2025 р.
Технічні, якісні та кількісні характеристики предмета закупівлі
- Номенклатура та обсяги закупівлі
|
№ з/п |
Найменування |
Одиниця виміру |
Кількість |
|
1. |
Доступ до сервісів медичної інформаційної системи «Медікс» у вигляді ліцензій користувача код ДК 021:2015 48810000-9 – «Інформаційні системи» |
послуга
|
80 |
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), що приєднався до відповідного Договору з ДП «Електронне здоров’я» та повинен мати протестовані та підключені до Центральної бази даних Електронної системи охорони здоров’я наступні функціональні модулі:
- Електронний рецепт на медичні вироби
- Реєстрація НМП, підрозділів, користувачів
- Укладення капітаційних договорів з НСЗУ
- Перегляд декларації (Primary Care)
- Управління ліцензіями
- Заключення декларацій
- Електронні медичні записи (Імунізація)
- Доступ до даних
- Медичний висновок про тимчасову непрацездатність
- Виписування електронного рецепту на ЛЗ
- Робоче місце середнього медичного персоналу
- Вакцинація середнім медичним персоналом
- Робоче місце адміністратора медичних записів
- Клінічна оцінка
- Електронні направлення
- Процедури
- Спостереження
Замовник також може перевіряти інформацію щодо підключення МІС та проходження тестування відповідних функціональних модулів на офіційному сайті ДП «Електронне здоров’я».
1.9. Вимоги до взаємодії з Електронним реєстром листків непрацездатності
Для забезпечення реєстрації випадків, які супроводжуються настанням тимчасової непрацездатності пацієнта та вимагають створення листка непрацездатності й отримання відповідної компенсації від інститутів соціальних гарантій, система має дозволяти передавати медичні висновки про тимчасову непрацездатність до Електронного реєстру листків непрацездатності для забезпечення автоматичного формування електронного лікарняного, включно з можливістю скорочення та продовження терміну його дії.
2. Загальні вимоги до системи
2.1. Вимоги до інтерфейсу користувача
Інтерфейс взаємодії користувачів з електронними реєстрами даних повинен бути заснований на принципі візуального графічного інтерфейсу (GUI). Інтерфейс системи має бути зрозумілим і зручним, не перевантаженим графічними елементами, повинен забезпечувати швидке відображення екранних форм. Навігаційні елементи мають бути виконані у зручній для користувача формі. Введення-виведення даних системи, прийом команд керування і відображення результатів їх виконання повинні виконуватися в інтерактивному режимі. Інтерфейс повинен відповідати сучасним ергономічним вимогам і забезпечувати зручний доступ до основних функцій системи.
Інтерфейс повинен бути розрахований на переважне використання маніпулятора типу «миша», тобто управління системою має здійснюватися за допомогою керуючих елементів. Клавіатурний режим введення повинен використовуватися головним чином для заповнення та/або редагування текстових і числових полів екранних форм.
Система повинна використовувати вибрану мову для оформлення будь-яких елементів інтерфейсу, включаючи підписи, екранні кнопки, меню, документацію, підказки системи і повідомлення програми користувачеві (крім повідомлень від загальносистемного ПЗ).
Система повинна забезпечувати коректну обробку аварійних ситуацій, викликаних неправильними діями користувачів, невірним форматом або неприпустимими значеннями вхідних даних. У зазначених випадках система повинна видавати користувачу відповідні повідомлення, після чого повертатися в робочий стан, що передував невірній (неприпустимій) команді або некоректному введенню даних.
Екранні форми повинні проектуватися з урахуванням вимог уніфікації: всі екранні форми користувальницького інтерфейсу повинні бути виконані в єдиному графічному стилі, з однаковим розташуванням основних елементів керування та навігації; для позначення подібних операцій повинні використовуватися подібні керуючі (навігаційні) елементи. Терміни, що використовуються для позначення типових операцій (додавання/редагування значень), а також послідовності дій користувача при їх виконанні, повинні бути уніфіковані; зовнішня поведінка подібних елементів інтерфейсу (реакція на наведення покажчика «миші», перемикання фокусу, натиснення кнопки) повинні реалізовуватися однаково для однотипних елементів.
Система повинна містити документацію/портал (відео інструкції) щодо роботи і функціональності системи для користувачів відповідно до їхніх функціональних обов´язків. Інструкції мають бути створені українською мовою
2.2. Модуль адміністратора юридичної особи
Для забезпечення керування роботою юридичної особи в системі система має містити модуль адміністратора юридичної особи.
Авторизація користувача має виконуватись за процедурою, вказаною у розділі “Вимоги до авторизації користувача у системі”. У разі проходження процедури авторизації та наявності серед знайдених облікових записів користувачів активного облікового запису із групою доступу “Адміністратор”, користувач отримує доступ до системи з правами, які налаштовані для цієї групи доступу.
Модуль адміністратора має давати можливість користувачам виконувати у системі наступні функції:
● Редагувати інформацію про юридичну особу в Електронній системі охорони здоров’я;
● Створювати профіль користувачів в межах своєї організації;
● Створювати та редагувати підрозділи організації;
● Встановлювати ролі за функціональними обов’язками та підрозділами організації;
● Встановлювати недоступність лікаря з існуючим графіком із можливістю призначення лікаря, який заміщує
● Переглядати перелік записів на прийом до лікарів;
● Переглядати перелік записів на прийом, які потребують зміни параметрів прийому через недоступність лікарів;
● Переглядати загальний графік роботи лікарів установи із зазначенням загальної кількості планових прийомів лікаря та вже зайнятих за попереднім записом пацієнтів;
● Реєструвати пацієнта у системі для подальшого затвердження лікарем;
● Записувати пацієнта на прийом;
● Укладати для організації договори з НСЗУ та продовжувати їхній термін;
● Налаштовувати графік лікаря, та кабінет в якому лікар здійснює прийом (у форматі керуванян календарем працівника, тощо;
● Налаштовувати перелік послуг, які надає організація;
● Редагувати параметри придбаних ліцензій (змінювати кількість спеціалістів для кожної ролі та призначати для них співробітників);
● Формувати журнали за довільний період з можливістю експорту у формат xls:
● Журнал прийомів
● Журнал викликів додому
● Журнал вакцинацій за формою 063/о
● Журнал аналізів та їхні результати
● Журнал реєстрації амбулаторних пацієнтів
● Журнал обліку процедур
● Формувати звіти:
■ Звіт про кількість прийомів по кожному лікарю (кількість доступних слотів прийому, кількість записаних осіб, кількість завершених прийомів);
■ Звіт про кількість прийомів по кожному підрозділу організації (кількість доступних слотів прийому, кількість записаних осіб, кількість завершених прийомів);
■ Відомість обліку відвідувань пацієнтів - дані про відвідування у закладі охорони здоров’я та вдома дітей віком до 17 років та дорослих;
■ Звіт про надані послуги лікарів установи із зазначенням наданих послуг, їх кількості;
■ Звіт про всі рецепти для отримання лікарських засобів, видані пацієнтам;
■ Звіт по рецептам виписаних відповідно до медичних програм
■ Звіт про вхідні та вихідні лабораторні дослідження;
■ Дані про пацієнтів, які відносяться до певних груп ризику залежно від встановленого діагнозу;
■ Звіт про встановлені діагнози;
■ Дані про епізоди лікування;
■ Звіт про діагностичні звіти внесені з паперових носіїв
■ Звіт про видані пацієнтам листки непрацездатності;
■ Звіт по групам диспансерного нагляду;
■ Звіт про склад пацієнтів закладів області за статтю, віком та певними пільговими категоріями;
■ Звіт щодо записів на прийом
● Звіт по відвідуваності пацієнтів за ЕМЗ
● Звіт по можливим дублікатам декларацій
● Звіт із даними про імунізацію пацієнтів;
● Довідки про тимчасову непрацездатність;
● Медичні висновки про тимчасову непрацездатність;
● Звіт з даними про декларації, укладені лікарями, зареєстрованими у системі eHealth, можливе групування за населеними пунктами;
● Звіт про направлення, сформовані у даному функціоналі та передані до системи eHealth;
● Перелік електронних медичних записів, зареєстрованих у eHealth;
● Перелік діагностичних звітів та процедур;
● Перелік зареєстрованих спостережень.
● Звіт з показниками якості ведення медичних записів лікарями організації;
● Звіт проведення вакцинації дітям до 6 років включно (Контрольний список)
● Звіт по оглядам пацієнтів вікової групи 40-64 років (Контрольний список)
● Звіт по оглядам пацієнтів вікової групи 65 років і старше (Контрольний список)
● Формувати графік роботи лікарів за допомогою схем прийому, на певний проміжок часу, а також за індивідуальними графіками. Формування графіку роботи лікарів має відбуватись із зазначенням таких параметрів:
● Лікар;
● Спеціальність обраного лікаря;
● Підрозділ установи, в якому буде працювати лікар;
● Номер кабінету, в якому буде вести прийом лікар;
● Дата та час роботи лікаря;
● Тип робочого часу лікаря (амбулаторний прийом, виклик додому, перерва);
● Інтервал на один прийом пацієнта;
● Послуга, яка буде надаватись (опціонально);
● Дозвіл записувати у живу чергу до лікаря (опціонально, якщо тип робочого часу - амбулаторний прийом);
● Обмеження віку пацієнтів, які можуть записатись на прийом;
● Дозвіл лікарю самостійно записувати пацієнтів собі на прийом (опціонально, якщо тип робочого часу - амбулаторний прийом).
3. Забезпечення робочого процесу медичних працівників
3.1. Вимоги до модулю реєстратора
Для забезпечення виконання обов'язків працівника реєстратури в системі має бути модуль реєстратора.
Авторизація користувача має виконуватись за процедурою, вказаною у розділі “Вимоги до авторизації користувача у системі”. У разі проходження процедури авторизації та наявності серед знайдених акаунтів користувачів активного аккаунту з групою доступу “Реєстратор” користувач отримує доступ до системи з правами, які налаштовані для цієї групи доступу.
Модуль реєстратора має надавати змогу реєстраторам виконувати в системі наступні функції:
- формування профілю пацієнта в системі;
- часткове редагування будь-яких персональних (не медичних) даних пацієнта;
- верифікація даних пацієнта;
- верифікація телефону пацієнта через СМС;
- введення та коригування графіку прийому лікаря (опціонально);
- запис пацієнта на прийом до лікаря;
- скасування запису пацієнта до лікаря;
- друк талонів на прийом до лікаря;
- перегляд списку записів на прийом, встановлення відміток про прибуття пацієнта або відмітки про скасування візиту;
- перегляд загального розкладу роботи лікарів установи;
- аналіз доступності лікарів;
- друк журналу викликів лікарів на поточну добу;
- друк журналу запланованих прийомів лікарів на поточну добу;
- встановлення і підтвердження методу аутентифікації пацієнта;
3.2. Вимоги до модулю кадровика
Для забезпечення виконання обов’язків кадровика закладу, в системі має бути реалізований модуль “Кадровик”.
Авторизація користувача має виконуватись за процедурою, вказаною у розділі “Вимоги до авторизації користувача у системі”. У разі проходження процедури авторизації та наявності серед знайдених акаунтів користувачів активного аккаунту з групою доступу “Кадровик” користувач отримує доступ до системи з правами, які налаштовані для цієї групи доступу.
Модуль кадровика має надавати змогу кадровикам виконувати в системі наступні функції:
● Авторизація в системі;
● Перегляд персоналу закладу;
● Можливість перегляду працівників в залежності від спеціальності за допомогою фільтрів;
● Можливість пошуку працівника за ключовими параметрами (ПІБ, спеціальність);
● Можливість редагувати дані про працівника, в електронній системі охорони здоров’я;
● Можливість підписувати тза завіряти зміни в персоналі власним КЕП;
● Можливість присвоювати роль працівникам закладу, відповідно до видів медичних послуг;
3.3. Вимоги до модулю статистика
Для забезпечення виконання обов’язків статистика закладу, в системі має бути реалізований модуль “Статистик”.
Авторизація користувача має виконуватись за процедурою, вказаною у розділі “Вимоги до авторизації користувача у системі”. У разі проходження процедури авторизації та наявності серед знайдених акаунтів користувачів активного аккаунту з групою доступу “Статистик” користувач отримує доступ до системи з правами, які налаштовані для цієї групи доступу.
Модуль статистика має надавати змогу статистикам виконувати в системі наступні функції:
• Можливість генерувати звіти та статистичні форми в розрізі всього закладу, структурного підрозділу, стаціонарного відділення, або окремого працівника;
• Можливість додатково відфільтрувати дані, для подальшого генерування звіту;
• Можливість зробити запит на відправку звіту на електронну пошту;
• Можливість роздрукувати звіт, або завантажити на локальний пристрій.
• Можливість переглядати показники якості за наступними критеріями у вигляді графіку з урахуванням перегляду за певні проміжки часу (тиждень, місяць, рік), та у вигляді контрольних списків:
• Кількість декларантів за рік
• Кількість декларантів за 30 днів
• Огляди вікової групи пацієнтів віком 40-64 роки
• Огляди вікової групи пацієнтів віком 65 років і старше
• Проведення вакцинації дітей до 6 років включно
• Верифікація пацієнтів
3.4. Вимоги до модулю бухгалтерія
Для забезпечення виконання обов’язків статистика закладу, в системі має бути реалізований модуль “Бухгалтер”.
Авторизація користувача має виконуватись за процедурою, вказаною у розділі “Вимоги до авторизації користувача у системі”. У разі проходження процедури авторизації та наявності серед знайдених акаунтів користувачів активного аккаунту з групою доступу “Бухгалтер” користувач отримує доступ до системи з правами, які налаштовані для цієї групи доступу.
Модуль бухгалтерія має надавати змогу бухгалтерам виконувати в системі наступні функції:
● Вносити налаштування до бухгалтерського звіт згідно правил нарахувань заробітньої плати в закладі;
● Генерувати звіт по заробітнім платам;
● Мати можливість роздрукувати звіт, або зберегти на локальному пристрої.
3.5. Вимоги до модулю лікаря амбулаторного прийому (первинної) медичної допомоги
Для забезпечення виконання обов'язків лікаря у системі має бути наявний амбулаторний модуль лікаря первинної медичної допомоги. Авторизація користувача має виконуватися за процедурою, вказаною у розділі “Вимоги до авторизації користувача у системі”. У разі проходження процедури авторизації та наявності серед знайдених облікових записів користувачів активного облікового запису із групою доступу “Лікар” користувач отримує доступ до системи із правами, які налаштовані для цієї групи доступу.
Для планування роботи лікар повинен мати можливість:
● відкривати для перегляду власний розклад амбулаторних прийомів пацієнтів;
За допомогою інструментів фільтрації та пошуку лікар повинен мати змогу обрати медичні документи пацієнта та відкрити їх для перегляду. Система має надавати можливість призначити пацієнтові диспансерний облік та скасувати його у разі потреби. Лікар повинен мати можливість використати метод автентифікації пацієнта за допомогою СМС, або за допомогою документів.
Надаючи послуги пацієнтові, лікар повинен мати можливість співпрацювати з лікарями вторинної ланки. Система має надавати можливість використовувати декілька направлень на різні послуги.
У процесі роботи лікар повинен мати змогу фіксувати взаємодії з пацієнтом у формі епізодів лікування, вказуючи основний діагноз, а також можливі супутні діагнози та ускладнення. Для визначення характеру дій лікаря потрібно використовувати класифікатор ІСРС-2.
Для призначення пацієнтові лікарських засобів система має надавати можливість застосовувати загальні класифікатори для вибору параметрів цих засобів (МНН, комерційної назви, існуючих варіантів дозування, особливостей прийому, та наявного пакування даного препарату в аптеках), а також формувати і затверджувати рецепти. Під час призначення лікарських засобів система має надавати змогу обирати умови відпуску рецепту для пацієнта – безкоштовно, з частковою оплатою або за повну вартість.
Створюючи пільгові рецепти, лікар повинен мати можливість зазначати пільгову програму, за якою надається цей рецепт. При формуванні друкованих форм рецептів за лікарськими засобами, які призначені за пільговою програмою, має формуватися окрема форма на кожний лікарський засіб. Перелік доступних пільгових програм та лікарських засобів, які можуть бути призначені за цією програмою, має надаватись модулем взаємодії з системами постачання довідкової інформації. Відповідно до записів у картці пацієнта система має повідомити лікаря, якщо у нього наявна алергічна реакція на призначений препарат.
Система має надавати можливість фіксувати наступні дані:
● направлення на обстеження або прийом до інших фахівців включно з переліком призначених послуг;
● направлення на госпіталізацію до стаціонарного відділення медичного закладу.
Для отримання даних про стан пацієнта із застосуванням додаткових досліджень система має надавати лікареві можливість створювати направлення для проведення лабораторних аналізів та діагностики. Лікар повинен мати можливість завантажити з інших інформаційних систем результати досліджень та зберегти їх. Також лікар повинен мати змогу призначити пацієнтові процедури у маніпуляційному кабінеті, сформувавши відповідне направлення і вказавши призначення. У лікаря має бути доступна функція запису висновків лабораторних та інструментальних аналізів пацієнта.
Лікар повинен мати можливість вказати причини звернення пацієнта (скарги) за класифікатором ICPC-2
Лікар повинен мати можливість сформувати медичний висновок про тимчасову непрацездатність з передачею даних до ЕРЛН для формування електронного лікарняного і можливістю продовжувати і скорочувати термін висновку.
Лікар повинен мати можливість формування і реалізації плану лікування для пацієнта, стан або діагноз якого вимагає застосування комплексу заходів протягом тривалого періоду. У рамках плану лікування лікар повинен мати можливість створювати призначення послуг та лікарських препаратів.
Лікар повинен мати можливість виконати та зареєструвати вакцинацію із зазначенням всіх обов’язкових для передачі до центрального компоненту параметрів. Також він повинен мати можливість зареєструвати невиконання вакцинації із зазначенням причин. Для реалізації щеплення лікар повинен мати змогу залучити маніпуляційний кабінет.
Лікар повинен мати можливість виписати електронне направлення, на діагностику, процедури, консультації інших фахівців, або на госпіталізацію. Також має бути можливість друку направлень
Лікар повинен мати можливість створювати шаблони прийому, та застосовувати їх при створенні взаємодій.
Лікар повинен мати можливість створювати та застосовувати шаблони направлень (група направлень).
Лікар повинен мати можливість створити, зберегти, та роздрукувати медичні довідки для пацієнта.
Лікар повинен мати можливість без запису пацієнта на прийом:
● Переглядати його медичну інформацію;
● Позначати помилковими медичні записи;
● Друкувати медичні записи;
● Формувати медичний висновок про непрацездатність на підставі раніше проведеного прийому, в часових рамках встановлених вимогами НСЗУ;
● Закривати існуючий епізод;
● Формувати електронне направлення на підставі раніше проведеного прийому, в часових рамках встановлених вимогами НСЗУ
Лікар повинен мати можливість проводити прийом пацієнту, який записаний на прийом для лікуванняпрофілактикиконсультації, та вносити свій медичний запис, який може бути збережений локально.
Лікар повинен мати можливість отримати доступ до груп чутливих станів, а також безпосередньо до медичних записів - як для перегляду записів, так і для обробки направлення, що містить чутливі дані. Лікар повинен мати можливість скасувати доступ, отриманий ним безпосередньо.
Система має фіксувати всі процедури чи послуги, які отримав пацієнт під час прийому у лікаря. За результатами роботи лікар повинен мати можливість друку введеної інформації під час прийому паціʼєнта
Під час внесення даних до медичної картки потрібно обирати скарги та об’єктивні дані з довідників системи. Кількість полів, які потрібно заповнювати вручну, не має перевищувати 20% від загальної кількості.Лікар повинен мати змогу оформити підсумки прийому у вигляді звіту. Під час реєстрації подій, які формують електронну медичну історію пацієнта, лікар, який їх ініціював, повинен мати змогу затвердити їх за допомогою особистого КЕП/УЕП.
Використовуючи інструменти системи, лікар повинен мати змогу створювати звітність за результатами роботи:
● реєстр пацієнтів, які пройшли амбулаторний прийом;
● реєстр візитів пацієнтів до медичного закладу;
● відвідуваність пацієнтів за ЕМЗ
● дані про можливі дублікати декларацій
● дані проведення вакцинації дітям до 6 років включно (Контрольний список)
● дані по оглядам пацієнтів вікової групи 40-64 років (Контрольний список)
● дані по оглядам пацієнтів вікової групи 65 років і старше (Контрольний список)
● медичний висновок консультативного характеру (довідка);
● витяг за даними персональної медичної картки пацієнта, що пройшов амбулаторний прийом;
● направлення на лікування пацієнта в умовах стаціонару;
● перелік визначених діагнозів у розрізі пацієнтів;
● дані про видані тимчасові листки непрацездатності;
● перелік послуг, отриманих пацієнтами в результаті відвідування медичного закладу;
● дані про призначення лікарських засобів пацієнтам;
● дані про виконані лабораторні дослідження;
● перелік реалізованих діагностичних звітів та процедур;
● перелік категорій населення, які мають певні пільги;
● перелік епізодів лікування;
● дані про електронні медичні записи “Взаємодія”;
● звіт, який містить дані про імунізацію пацієнтів;
● розширений звіт про виконані у поточному медичному закладі та зареєстровані у системі eHealth щеплення;
● реєстр спостережень;
● довідки про тимчасову непрацездатність;
● сертифікат про вакцинацію міжнародного зразка;
4. Вимоги до достовірності медичної інформації
Для забезпечення достовірності медичної інформації, що вноситься медичними працівниками особисто за допомогою системи або переноситься з інших медичних інформаційних систем, кожний такий запис має бути підписаний КЕП/УЕП/вебтокеном медичного працівника.
5. ФУНКЦІОНАЛ ДЛЯ ПАЦІЄНТА
6.1. Вимоги до інтерфейсу для веб-версії “Особистий кабінет пацієнта”
Сервіс для пацієнта має забезпечувати наступні функції:
● Здійснювати вхід до системи.
● Надавати доступ до власної електронної медичної картки.
● Здійснювати пошук медичного закладу та лікаря в системі;
● Переглядати рейтинг лікаря та відгуки про нього;
● Надавати можливість доступу до особистої загальної медичної інформації.
● Надавати можливість здійснювати запис на прийом (в клініці/онлайн).
● Надавати можливість користувачу заповнювати щоденники вимірювань свого стану.
● Переглядати історію звернень;
● Створювати запис на прийом до лікаря;
● Скасовувати запис на прийом до лікаря;
● Можливість виставити рейтинг та залишити відгук про лікаря, після прийому;
● Можливість керувати записами на прийом членів своєї родини, за їх згодою;
● Можливість надавати доступ на перегляд особистої інформації та на керування записами на прийом членам родини.
6.2. Вимоги до інтерфейсу для мобільного застосунку для пацієнта
Пацієнт повинен мати можливість користуватися сервісом для пацієнта за допомогою мобільного застосунку (для смартфонів, айфонів або планшетів на операційних системах Android/iOS). Мобільний застосунок має забезпечувати для пацієнта наступні функції:
● Здійснювати вхід до системи.
● Надавати доступ до власної електронної медичної картки.
● Надавати можливість доступу до інформації, пов'язаної з записами на прийом, а також до перегляду запису на майбутні відвідування.
● Надавати можливість пошуку та запису до лікарів на прийом (в клініці/онлайн).
● Надавати можливість сортувати результати пошуку.
● Надавати можливість скасування запису до лікаря.
● Надавати можливість залишати відгук про лікаря.
● Надавати можливість налаштовувати сповіщення зсередини мобільних додатків по нагадуваннях.
● Забезпечувати отримання на мобільний пристрій користувача повідомлень, які відправлені Медичною інформаційною системою.
● Забезпечувати отримання та передачу інформації з мобільного пристрою пацієнта до Медичної інформаційної системи.
На підтвердження наявності в учасника сервісу МІС для пацієнта з використанням мобільного застосунку, учасником надається гарантійний лист з зазначенням адреси відповідних інтернет-ресурсів (Google Play та App Store), де розміщені зазначені застосунки для інсталяції, а також скріншоти електронних сторінок цих ресурсів, на яких повинна бути зазначена інформація про назву мобільного застосунку пацієнта та його виробника (власника), а також опис, з якого можна зробити висновок про його інтеграцію до запропонованої учасником системи.
7. Технічні вимоги до працездатності Системи відповідно до швидкості передачі даних каналами Учасника
Система має бути працездатною при наступній мінімальній швидкості каналів зв’язку
Швидкість каналу для роботи із системою без відеозв'язку 128 Кбіт/секунду на 1 користувача
Швидкість каналу для роботи із системою з відеозв'язком 1 Мбіт/секунду на 1 користувача
8. Вимоги до захисту інформації в МІС
8.1 Вимоги до обробки персональних даних
Персональні дані повинні оброблятися у МІС із застосуванням комплексної системи захисту інформації, що підтверджується атестатом відповідності КСЗІ на МІС (зазначені документи учасник повинен надати у складі тендерної пропозиції. Допускається надання титульних листів цих документів без додатків та невід’ємних частин)
9. Додаток для середнього медичного персоналу (сестер медичних)
- У пропонованій МІС має бути забезпечена можливість для середнього медичного персоналу (сестри медичні) користуватися сервісами системи за допомогою безкоштовного мобільного додатку (для смартфонів або планшетів).
- Мобільний додаток має забезпечувати для такі функції:
- Прив’язка до відділення закладу, відображення списку пацієнтів, їхні палати, профілі ліжок і перелік назначених послуг.
- Виконувати позначку проходження послуг (процедур) пацієнтів.
- Інформувати працівника шляхом сповіщень про необхідність виконання процедур, тощо
Наявність додатку підтверджується листом що містить посилання, за яким додаток доступний для завантаження з відповідних сервісів.
При розробленні та експлуатації пропонованої системи учасник має дотримуватись загальноприйнятних вимог щодо управління якістю. На підтвердження цього учасник має надати у складі пропозиції сертифікат яким підтверджується те що в учасника впроваджена та функціонує у відповідності система управління якістю відповідно до ДСТУ ІSO 9001:2015 «Системи управління якістю. Вимоги» (ISO 9001:2015, IDT) стосовно розробки та налаштування програмного забезпечення, аналітика програмного забезпечення, архітектура, дизайн, розробка та тестування, послуги програмного та хмарного забезпечення, технічна підтримка та UX/UI послуги, навчання користувачів. Також учасник має підтвердити повноваження органу( установи, організації) що видала такий сертифікат, шляхом надання у складі пропозиції документів щодо акредитації (нотифікації) організації, що видала зазначений сертифікат.
Також, на вимогу Замовника Учасник має забезпечити можливість доступу Замовника до пропонованої МІС у режимі демонстраційного доступу, для перевірки відповідності МІС вказаним вимогам.
Невідповідність запропонованої Учасником МІС встановленим технічним, якісним та іншим вимогам до предмета закупівлі розцінюється як невідповідність пропозиції умовам технічної специфікації та іншим вимогам щодо предмета закупівлі цього оголошення та пропозиція такого учасника підлягає відхиленню.
