-
Відкриті торги з особливостями
-
Однолотова
-
КЕП
Послуги із постачання та впровадження «Програмного забезпечення «Особистий кабінет пацієнта»
Згідно умов цієї процедури закупівлі тендерною документацією вважається сукупність інформації у вигляді заповнених електронних полів в розділі "Тендерна документація" та прикріпленого текстового документу " ТЕНДЕРНА ДОКУМЕНТАЦІЯ", що містить всю іншу інформацію, передбачену згідно ст. 22 Закону. З урахуванням обсягу фінансування видатків замовника до розгляду не приймається тендерна пропозиція, ціна якої є вищою ніж очікувана вартість предмета закупівлі, визначена замовником в оголошенні про проведення цих відкритих торгів.
Завершена
3 000 000.00
UAH з ПДВ
Період уточнення:
24.02.2026 16:39 - 01.03.2026 00:00
Відповідь надана
Запит на роз’яснення до тендерної документації - технічні питання
Номер:
76c7629c5a2746768a180ee5828612ad
Дата опублікування:
27.02.2026 18:06
Опис:
Шановний Замовнику!
Для коректної підготовки тендерної пропозиції та формування реалістичного плану впровадження просимо надати роз’яснення щодо технічних вимог та організаційних залежностей.
1) Межі предмету закупівлі
1.1. Чи очікується постачання вже існуючого готового продукту (ліцензія на типове ПЗ) з налаштуванням, чи допускається/очікується індивідуальна розробка під процеси Замовника?
1.2. Чи є перелік функцій, які вважаються обов’язковими саме в межах впровадження (до підписання акту приймання), а які можуть бути винесені в подальші покращення/зміни?
1.3. Чи існує у Замовника макет/референс/вимоги до UX/UI (брендбук, гайдлайни, приклади) або свобода дизайну на стороні Виконавця?
2) Інтеграція з МІС Doctor Eleks — найкритичніша залежність
2.1. Просимо уточнити: інтеграція з Doctor Eleks здійснюється через який саме інтерфейс (API/HL7/FHIR/веб-сервіси/інше)? Яка версія/модуль Doctor Eleks використовується у закладах зі списку?
2.2. Чи є єдиний централізований контур Doctor Eleks, чи кожен заклад має *окремий* контур/БД/сервер/версію/політики доступу?
2.3. Чи буде надано тестове середовище (staging) з тестовими даними (анонімізованими) + доступ до нього?
2.4. В тендері вказано гарантійний лист від розробника Doctor Eleks щодо сумісності. Просимо уточнити:
- чи є шаблон такого листа;
- чи Замовник забезпечує взаємодію з Doctor Eleks для отримання листа;
- чи достатньо листа про можливість інтеграції через стандартні API чи потрібне підтвердження конкретних методів/ендпоїнтів.
2.5. Які є обмеження по навантаженню на Doctor Eleks (rate limits, графік вікон, заборонені запити), щоб не впливати на роботу закладів?
3) Ідентифікація пацієнта, реєстрація та ризик дублювання акаунтів
3.1. У вимогах описано варіант “логін = ідентифікатор пацієнта”. Просимо уточнити, *що саме* є ідентифікатором (номер медкартки/EMR ID/інший ключ) і як пацієнт його отримує.
3.2. Як вирішується ситуація, якщо пацієнт має записи в кількох закладах (різні картки/різні ID)? Чи потрібне “об’єднання” профілю, чи окремі профілі?
3.3. Самостійна реєстрація: яким чином відбувається верифікація що користувач — саме той пацієнт (окрім SMS/email)? Чи потрібна перевірка з Doctor Eleks по комбінації ПІБ+ДН+телефон/інші атрибути?
3.4. Вимога: “в ЕМК в десктопній версії має відображатися інформація про наявність облікового запису”. Просимо уточнити:
- де саме відображається (який розділ/поле);
- чи потрібно робити зворотний запис у Doctor Eleks;
- хто погоджує структуру цього поля/зміни;
- чи є стандартний механізм у Doctor Eleks для такого прапорця.
4) Запис на прийом, слоти, календар, відміни
4.1. Звідки формуються слоти для запису: з Doctor Eleks (розклад лікарів/кабінетів) чи є окремий сервіс?
4.2. Чи допускаються подвійні бронювання і які правила блокування/підтвердження?
4.3. Які правила скасування запису (за скільки годин, чи потрібні причини, чи є штрафні політики, чи змінюється статус у Doctor Eleks)?
4.4. Які вимоги до фільтрації лікарів/послуг (довідники, спеціальності, відділення) — чи є готові довідники з Doctor Eleks і в якому форматі?
5) “Стаціонар / курс лікування / показники / призначення”
5.1. По “показникам” (пульс/тиск/сатурація/температура тощо):
- чи ці показники вводить пацієнт сам, чи медперсонал;
- чи потрібно зберігати їх в Doctor Eleks, чи в окремому сховищі;
- чи є медичні/регуляторні вимоги до точності/частоти/валідації даних.
5.2. Документи по стаціонару: це вже існуючі PDF у Doctor Eleks чи їх потрібно формувати на льоту?
5.3. “Медикаментозні призначення” — це перегляд призначень з Doctor Eleks, чи передбачена можливість взаємодії (підтвердження/відмітка прийому/коментарі)?
6) Документи та файли: PDF + “фото документів в ЕМК”
6.1. “Документи з МІС”: які типи документів (аналізи/виписки/направлення) і чи всі вони доступні у вигляді PDF?
6.2. “Фотографувати документи й прикріплювати до ЕМК”:
- чи підтримує Doctor Eleks прийом файлів через API (які формати/ліміти/метадані)?
- де фізично мають зберігатись файли (у Doctor Eleks, на сервері Замовника, у зовнішньому сховищі)?
- вимоги до компресії, розміру, водяних знаків/маскування ПД;
- чи потрібні статуси модерації/перевірки завантажених файлів.
6.3. Чи потрібна можливість видаленн завантажених користувачем файлів (за GDPR/законодавством/політикою), чи лише додавання?
7) Push-сповіщення та сервіс нотифікацій
7.1. Хто забезпечує та адмініструє FCM/APNs ключі (зі сторони Замовника чи Виконавця) і на кого реєструються?
7.2. Який перелік подій для push, окрім “за день до візиту”? (наприклад: зміна часу, скасування, готовність результатів, нові документи тощо)
7.3. Чи потрібні налаштування користувачем (opt-in/opt-out), “тиха ніч”, мовні шаблони, аудит доставки?
7.4. Таймзона для відправки (особливо якщо заклади в різних місцях)?
8) Інфраструктура, доступи, кібербезпека та межі відповідальності
8.1. Просимо підтвердити, хто відповідає за сервер інтеграцій, сертифікати SSL, домени, зовнішній IP, VPN/RDP — Замовник чи Виконавець.
8.2. Які вимоги по логуванню/аудиту (зберігання логів, термін, доступ ІБ)?
8.3. Чи є вимоги/політики щодо *захисту персональних даних* (локальне законодавство, внутрішні інструкції, заборона сторонніх сервісів, шифрування “at rest/in transit”)?
8.4. Чи потрібно проходити пентест/сканування, надавати звіти, виправляти вразливості в межах гарантії/підтримки?
9) Публікація в App Store / Google Play та права доступу
9.1. Підтвердьте, будь ласка, що аккаунти Apple/Google створюються Замовником, а Виконавець отримує роль доступу (Admin/Developer) для публікації.
9.2. Хто є власником: назва видавця, юридична особа, контактні email/телефони для сторів?
9.3. Чи потрібні підготовлені Замовником: тексти політик (Privacy Policy/Terms), опис, скріншоти, контент/матеріали?
10) Приймання, критерії успішності, гарантія і підтримка до 31.12.2026
10.1. Які формальні критерії приймання впровадження (перелік сценаріїв, UAT, протоколи, чек-листи)?
10.2. Який порядок приймання по етапах: один загальний акт чи поетапно (MVP → реліз → проміжні акти)?
10.3. Для сервісної підтримки:
- очікуваний графік (робочі години/24/7);
- бажані SLA (час першої відповіді/вирішення);
- очікуваний обсяг звернень (щоб правильно закласти помісячну вартість).
10.4. Просимо уточнити межу між “підтримкою/оновленнями/багфіксами” та “індивідуальними доопрацюваннями”, які не входять: чи є список прикладів, щоб уникнути різного трактування.
11) Дані/мови/контент/довідники
11.1. Якими мовами має працювати додаток (укр/англ/інші) та хто надає переклади?
11.2. Контент розділів “Інфо/Контакти”: хто його готує і як оновлюється (через CMS/адмінку/конфіг)?
11.3. Довідники послуг/закладів/лікарів: це довідники Doctor Eleks чи окремі. Хто відповідає за їх актуальність?
Пояснення, чому питаємо: частина вимог залежить від наявності доступів, API Doctor Eleks, контурів закладів та інфраструктури Замовника. Відповіді дозволять уникнути ризиків на етапі впровадження та коректно сформувати цінову пропозицію й план робіт.
З повагою,
Відповідь:
Шановний Учасник!
У відповідь на Ваші питання, надаємо максимально-можливий широкий перелік відповідей:
1. Щодо «Межі предмету закупівлі»
1.1. Очікується постачання вже існуючого готового продукту (ліцензія на типове ПЗ) з налаштуванням.
1.2. Усі функції мають відповідати «Технічним, якісним та кількісним характеристикам предмета закупівлі».
1.3. Питання реалізації визначатимуться відповідно до вимог тендерної документації та погоджуються сторонами під час виконання договору.
2. Щодо «Інтеграція з МІС Doctor Eleks — найкритичніша залежність»
2.1. Інформація щодо версій та конфігурацій програмного забезпечення, що використовується у закладах, належить до внутрішньої технічної інфраструктури Замовника. Учасник повинен передбачити можливість інтеграції із діючою системою «Доктор Елекс» незалежно від конкретної версії чи модуля.
2.2. Архітектура розгортання та конфігурація медичної інформаційної системи «Доктор Елекс» у закладах визначається внутрішніми організаційними та технічними рішеннями Замовника. Замовник не встановлює вимог щодо конкретної моделі (централізований чи децентралізований контур). Учасник повинен передбачити можливість інтеграції із діючою інфраструктурою незалежно від її архітектурної реалізації.
2.3. Питання щодо надання тестового середовища та доступу до нього визначатиметься на етапі реалізації договору. У разі необхідності інтеграційного тестування Замовник забезпечить належні умови для перевірки працездатності рішення із дотриманням вимог інформаційної безпеки та захисту персональних даних. Використання тестових (у тому числі «анонімізованих») даних погоджується окремо в робочому порядку.
2.4. Замовник не встановлює обов’язкового шаблону гарантійного листа. Лист надається у довільній формі від розробника або правовласника МІС «Доктор Елекс». Замовник не здійснює посередництво та не забезпечує взаємодію учасників із розробником «Доктор Елекс» для отримання відповідного листа. Отримання такого документа є відповідальністю Учасника. Достатнім вважається підтвердження можливості інтеграції із використанням штатних механізмів та стандартних інтерфейсів, передбачених розробником системи. Вимога щодо зазначення конкретних методів або технічних «ендпоїнтів» не встановлюється.
2.5. Замовник не встановлює наперед визначених публічних параметрів щодо граничного навантаження (rate limits), технічних вікон чи переліку заборонених запитів. Разом із тим, інтеграційна взаємодія не повинна створювати надмірного навантаження на діючу медичну інформаційну систему та не повинна впливати на безперебійну роботу закладів охорони здоров’я. Конкретні технічні параметри обміну (у тому числі частота запитів, пакетна обробка, часові обмеження тощо) погоджуються сторонами під час виконання договору з урахуванням вимог інформаційної безпеки та продуктивності системи.
3. Щодо «Ідентифікація пацієнта, реєстрація та ризик дублювання акаунтів»
3.1. Під ідентифікатором пацієнта розуміється унікальний обліковий запис (ідентифікаційний атрибут), що використовується в медичній інформаційній системі для ідентифікації пацієнта. Конкретна форма та тип такого ідентифікатора (номер медичної картки, системний ID або інший ключ) визначаються внутрішніми налаштуваннями системи та не розкриваються з міркувань інформаційної безпеки. Порядок отримання пацієнтом доступу до облікового запису визначається регламентом роботи закладу та погоджується під час реалізації проєкту.
3.2. Питання консолідації або розмежування профілів пацієнтів визначається технічними можливостями діючої системи та погоджується сторонами на етапі реалізації договору.
3.3. Тендерною документацією для самостійної реєстрації передбачено підтвердження через код, надісланий SMS (за наявності послуги) або на e-mail. Інші способи верифікації не є обов’язковою вимогою ТД та можуть пропонуватися учасником додатково за умови відповідності вимогам ТД та законодавства про захист персональних даних.
3.4. Тендерною документацією не встановлено конкретного розділу або поля відображення інформації про наявність облікового запису. Спосіб візуалізації у десктопній версії ЕМК визначається під час реалізації проєкту та має бути зручним для користувача. Необхідність зворотного запису в МІС «Доктор Елекс» визначається технічним рішенням, запропонованим Учасником, та погоджується сторонами на етапі виконання договору. Структура відображення та можливі зміни погоджуються із Замовником у робочому порядку із врахуванням вимог розробника МІС та інформаційної безпеки. Замовник не встановлює вимоги щодо використання конкретного стандартного механізму або вбудованого “прапорця” у «Доктор Елекс». Учасник повинен забезпечити коректну реалізацію відповідно до штатних можливостей системи. Відповідальність за реалізацію безпечного механізму ідентифікації покладається на Учасника.
4. Щодо «Запис на прийом, слоти, календар, відміни»
4.1. Джерелом даних для формування доступних слотів є розклад, що ведеться у МІС «Доктор Елекс». Створення паралельного або незалежного контуру управління розкладом не передбачається.
4.2. Тендерною документацією не передбачено можливість подвійного бронювання одного й того самого слоту. Учасник повинен забезпечити механізм резервування та підтвердження запису, що виключає виникнення дублюючих записів і гарантує коректну синхронізацію з розкладом у МІС. Конкретний алгоритм блокування (тимчасове резервування, підтвердження, тайм-аут тощо) визначається технічним рішенням Учасника та погоджується на етапі реалізації договору.
4.3. Тендерною документацією не встановлено окремих штрафних або фінансових політик у разі скасування запису пацієнтом. Порядок та часові обмеження скасування запису визначаються регламентом роботи закладу та погоджуються під час реалізації проєкту. У разі скасування запису зміни повинні коректно відображатися у діючій медичній інформаційній системі відповідно до її штатної логіки обробки статусів.
4.4. Джерелом істини щодо довідників лікарів, спеціальностей, відділень та послуг є МІС «Доктор Елекс». Створення окремої системи довідників або ручне дублювання даних не передбачається.
5. Щодо «Стаціонар / курс лікування / показники / призначення»
5.1. Дані, введені користувачем самостійно, не повинні автоматично трактуватися як клінічно підтверджені без відповідної медичної оцінки. Остаточний порядок відображення та використання таких показників у МІС визначається під час впровадження.
5.2. Документи стаціонару відображаються відповідно до даних, що сформовані та зберігаються у діючій медичній інформаційній системі. Тендерною документацією не передбачено обов’язкового формування нових клінічних документів “на льоту”. Учасник повинен забезпечити коректне відображення наявних документів (у тому числі у форматі, в якому вони зберігаються в МІС) без зміни їх структури та/або змісту.
5.3. Тендерною документацією передбачено можливість відображення медичних даних, що містяться у МІС «Доктор Елекс». Обов’язкова вимога щодо внесення змін до медикаментозних призначень, їх підтвердження або коментування через мобільний додаток у ТД не встановлена. Учасник повинен забезпечити коректне відображення інформації про призначення без порушення штатної логіки ведення медичної документації. Додатковий функціонал взаємодії (наприклад, відмітка прийому або коментарі пацієнта) може бути реалізований лише за окремим погодженням сторін та з урахуванням вимог інформаційної безпеки.
6. Щодо «Документи та файли: PDF + “фото документів в ЕМК”»
6.1. Перелік та формат документів визначаються фактичним функціоналом МІС «Доктор Елекс» у закладі. Учасник повинен забезпечити їх коректне відображення без зміни структури або змісту.
6.2. Тендерною документацією не встановлено окремих технічних вимог щодо прийому файлів МІС «Доктор Елекс» через API (формати, обмеження розміру, метадані тощо). Реалізація завантаження документів повинна здійснюватися із використанням штатних механізмів системи та відповідно до технічних можливостей МІС. Місце фізичного зберігання файлів (у МІС, на сервері Замовника або в окремому сховищі з інтеграцією) визначається технічним рішенням Учасника та погоджується сторонами під час реалізації договору з урахуванням вимог інформаційної безпеки. Тендерною документацією не встановлено окремих вимог щодо компресії, граничного розміру файлів або нанесення водяних знаків/маскування персональних даних. Учасник повинен забезпечити відповідність рішення законодавству у сфері захисту персональних даних та інформаційної безпеки. Вимога щодо обов’язкової модерації або додаткових статусів перевірки завантажених файлів ТД не передбачена. За потреби такі механізми можуть бути погоджені під час реалізації проєкту.
6.3. Самостійне безумовне видалення користувачем документів, що можуть бути частиною медичної документації, не передбачається. Порядок видалення або обмеження доступу визначається Замовником з урахуванням вимог чинного законодавства.
7. Щодо «Push-сповіщення та сервіс нотифікацій»
7.1. Тендерною документацією не встановлено окремого регламенту щодо адміністрування FCM/APNs. Облікові записи та ключі, необхідні для роботи мобільного застосунку, мають бути оформлені на Замовника або уповноважену ним особу. Технічне налаштування здійснює Учасник у межах виконання договору.
7.2. Тендерною документацією обов’язково передбачено нагадування про візит (зокрема за день до прийому). Інші події для push-повідомлень (зміна часу або скасування прийому, готовність результатів, поява нових документів тощо) можуть бути реалізовані Учасником за умови відповідності функціоналу системи та погоджуються під час виконання договору. Вичерпний перелік подій ТД не встановлює.
7.3. Тендерною документацією не встановлено обов’язкових вимог щодо додаткових налаштувань push-повідомлень (opt-in/opt-out, “тиха ніч”, мовні шаблони, аудит доставки). Такі можливості можуть бути передбачені Учасником як складова технічного рішення та погоджуються під час реалізації договору.
7.4. Тендерною документацією не встановлено окремих вимог щодо налаштування таймзони відправки повідомлень.
8. Щодо «Інфраструктура, доступи, кібербезпека та межі відповідальності»
8.1. Сервер інтеграцій належить до інфраструктури Замовника. Замовник забезпечує серверні та мережеві ресурси (у тому числі домен, зовнішній IP, доступи). Учасник здійснює налаштування та інтеграцію в межах виконання договору.
8.2. Тендерною документацією не встановлено окремих детальних вимог щодо логування та аудиту.
8.3. Обробка персональних даних повинна здійснюватися відповідно до чинного законодавства України у сфері захисту персональних даних та внутрішніх регламентів Замовника.
8.4. Тендерною документацією обов’язковий пентест або окремі звіти з безпеки не передбачені, однак Учасник зобов’язаний забезпечити відповідність рішення вимогам інформаційної безпеки та усувати виявлені вразливості в межах гарантійних зобов’язань.
9. Щодо «Публікація в App Store / Google Play та права доступу»
9.1. Облікові записи Apple та Google створюються Замовником самостійно, а Учаснику надається відповідний рівень доступу для публікації та технічного супроводу застосунку.
9.2. Власником облікових записів та сторінки застосунку в Apple App Store та Google Play є Замовник; назва видавця, юридична особа та контактні дані для сторів зазначаються даними Замовника або уповноваженої ним особи.
9.3. Тендерною документацією окремих вимог щодо підготовки матеріалів для публікації в сторах не встановлено, тому тексти політик (Privacy Policy/Terms), опис, скріншоти та інші «контентні» матеріали надаються Замовником, а їх технічне оформлення та розміщення забезпечує Учасник.
10. Щодо «Приймання, критерії успішності, гарантія і підтримка до 31.12.2026»
10.1. Приймання впровадження здійснюється за результатами перевірки відповідності реалізованого функціоналу вимогам тендерної документації та умовам договору. Конкретні сценарії тестування та порядок проведення приймальних випробувань погоджуються сторонами під час реалізації проєкту та оформлюються відповідними актами.
10.2. Тендерною документацією не встановлено окремого поетапного порядку приймання (MVP/реліз тощо), тому приймання здійснюється після виконання робіт відповідно до умов договору з оформленням актів приймання, а деталізація етапності може бути погоджена сторонами під час реалізації проєкту.
10.3. Тендерною документацією не визначено окремих параметрів щодо графіку підтримки, конкретних SLA або прогнозованого обсягу звернень. Учасник повинен передбачити надання сервісної підтримки в обсязі, достатньому для забезпечення безперебійної роботи рішення, а конкретні умови погоджуються сторонами в межах договору.
10.4. Тендерною документацією не визначено вичерпного переліку прикладів розмежування підтримки та індивідуальних доопрацювань. До підтримки відносяться усунення помилок, забезпечення працездатності та оновлення в межах реалізованого функціоналу, передбаченого ТД. Роботи, що змінюють або розширюють функціонал понад вимоги ТД, вважаються індивідуальними доопрацюваннями та виконуються за окремим погодженням сторін.
11. Щодо «Дані/мови/контент/довідники»
11.1. Основною мовою застосунку має бути українська. У разі реалізації додаткових мовних версій переклади надаються Замовником, а їх технічну інтеграцію забезпечує Учасник за окремою домовленістю.
11.2. Контент розділів “Інфо/Контакти” надається Замовником. Спосіб його оновлення (через адміністративну панель або інший технічний механізм) визначається рішенням Учасника та погоджується під час реалізації проєкту.
11.3. Довідники послуг, закладів та лікарів формуються на підставі даних, що ведуться у діючій медичній інформаційній системі. Актуальність таких довідників забезпечується Замовником у межах ведення МІС. Учасник повинен забезпечити коректну синхронізацію та відображення актуальних даних.
Інші технічні та організаційні параметри, не деталізовані в тендерній документації, визначаються сторонами під час реалізації проєкту з урахуванням чинного законодавства та технічних можливостей системи.
Дата відповіді:
03.03.2026 15:20