Благодійна організація «Світло надії» (далі – БО «Світло надії») оголошує закупівлю на обрання постачальника послуг розробки мобільного застосунку для БО «Світло надії».
Предмет закупівлі: послуг розробки мобільного застосунку (перелік, найменування, розмір та ін. характеристики зазначені у Технічному завданні);
Джерело фінансування закупівлі – закупівля здійснюється у рамках проєкту: «Інтегрована первинна медична допомога та психосоціальна підтримка в прикордонних регіонах України (Сумська, Харківська, Полтавська області)» здійснюється в межах мультидонорського проєкту «Посилення постраждалих від війни громад України через місцеві ініціативи (EMPOWER)», що фінансується Федеральним міністерством економічного співробітництва та розвитку Німеччини (BMZ) спільно з Генеральним Директоратом Європейської Комісії з питань цивільного захисту та гуманітарної допомоги та реалізується Німецьким товариством міжнародного співробітництва (GIZ) ГмбХ.
Термін надання послуг:
за потребою організатора закупівлі – БО «Світло надії».
Очікуваний результат: підписання угоди про співпрацю.
Орієнтовані обсяги закупівлі вказані у Технічному завданні.
Організація залишає за собою право збільшити або зменшити обсяг закупівлі у межах 20% від обсягу.
ДЛЯ УЧАСТІ В КОНКУРСІ НЕОБХІДНО ПОДАТИ ТАКІ ДОКУМЕНТИ:
- Пропозиція подається у формі офіційної цінової пропозиції, що відповідає технічним та кваліфікаційним вимогам вказаним в оголошенні та технічному завданні.
- Копії:
- Свідоцтва про державну реєстрацію юридичної особи або фізичної особи-підприємця або Виписки з єдиного державного реєстру юридичних осіб та фізичних осіб-підприємців;
- Свідоцтва про сплату єдиного податку;
- Витягу з єдиного державного реєстру юридичних осіб та фізичних осіб підприємців, виданого не раніше 01.01.2012 р.;
3. Також, просимо додати до Вашої цінової пропозиції будь-які інші документи, що, на Вашу думку, можуть бути корисними для оцінки пропозиції (наприклад, рекомендаційні листи тощо).
Правила оформлення цінової пропозиції учасника:
- Всі копії будь-яких документів, що включаються в цінову пропозицію, мають бути завіреними підписом учасника, а якщо учасником є юридична особа, то печаткою та підписом уповноваженої особи. До цінової пропозиції повинні додаватись документи, які посвідчують право такої уповноваженої особи підписувати цінову пропозицію (наказ про призначення керівника або довіреність).
- Надані копії документів мають бути розбірливими та якісними.
- Відповідальність за достовірність наданої інформації в своїй ціновій пропозиції несе учасник.
- Строк дії цінової пропозиції повинен становити не менше 30 календарних днів з дати підписання угоди про співпрацю, що повинно бути зазначено у самій пропозиції.
Посадова особа замовника, уповноважена здійснювати зв'язок з постачальниками:
Маніленко Катерина Андріївна, пров. Братів Шеметів 17а.
Моб. 0991997876.
e-mail kateryna.manilenko@lightofhope.com.ua
Пропозиції приймаються на e-mail: kateryna.manilenko@lightofhope.com.ua або за адресою:
Україна, 36039, м. Полтава, пров. Братів Шеметів 17а.
Пропозиції приймаються за адресою:
Україна, 36039, м. Полтава, пров. Шеметів Братів, 17а.
Приймання пропозицій, які подаються учасниками особисто, здійснюється з 09 год. 00 хв. до 17 год. 00 хв. З понеділка по п’ятницю за київським часом,
або e-mail: kateryna.manilenko@lightofhope.com.ua.
Кінцевий термін приймання цінових пропозицій від учасників:
«12» лютий 2026 року, до 17 год. 00 хв. за київським часом.
Технічне завдання для обрання постачальника послуг розробки мобільного застосунку для БО «Світло надії».
Послуги надаються у рамках проєкту: «Інтегрована первинна медична допомога та психосоціальна підтримка в прикордонних регіонах України (Сумська, Харківська, Полтавська області)» здійснюється в межах мультидонорського проєкту «Посилення постраждалих від війни громад України через місцеві ініціативи (EMPOWER)», що фінансується Федеральним міністерством економічного співробітництва та розвитку Німеччини (BMZ) спільно з Генеральним Директоратом Європейської Комісії з питань цивільного захисту та гуманітарної допомоги та реалізується Німецьким товариством міжнародного співробітництва (GIZ) ГмбХ.
1. Мета відеоролика
Створення інклюзивного мобільного застосунку (Android та iOS) для забезпечення швидкого, безпечного та зручного доступу населення до медичних, психологічних, соціальних та гуманітарних послуг організації.
Застосунок також має забезпечувати:
- скринінги (депресія, тривога, ВІЛ, ТБ, НІЗ),
- систему рекомендацій на основі ШІ,
- карту сервісів,
- можливість подати заявку на допомогу,
- модуль зворотного зв’язку (відгуки, скарги)
- опитування (опційно, з можливістю додавати)
- стрічку новин та спільноту.
2. Обсяг проєкту (MVP)
До складу MVP входять наступні модулі:
- особистий кабінет користувача;
- спільнота (пости організації, канали для комунікації);
- новини;
- каталог сервісів;
- скринінги з автоматичним пошуком релевантних локацій;
- модуль «Отримати допомогу» (анкета + rule-based рекомендації);
- карта сервісів;
- зворотний зв’язок;
- адмін-панель для управління контентом;
- опитування;
- база даних;
- рахунок клієнта (бали, бонуси, кошти).
3. Функціональні вимоги
3.1. Особистий кабінет користувача
3.1.1. Авторизація
- Авторизація за SMS-кодом, Google або email;
- гостьовий режим з обмеженим функціоналом.
3.1.2. Згода на обробку персональних даних
При першому вході:
- екран політики конфіденційності;
- кнопка «Погоджуюсь» - повний доступ;
- кнопка «Не погоджуюсь» - гостьовий режим.
3.1.3. Профіль користувача
Поля:
- ПІБ;
- вік або вікова група;
- стать (включно з інклюзивними варіантами);
- місто / область;
- соціальні статуси (мультивибір: ВПО, ветеран, ВІЛ+, людина з інвалідністю тощо);
- історія отриманих послуг (статуси: отримано / в обробці / відмовлено).
Функції:
- QR-код клієнта (case ID);
- мова;
- push-сповіщення;
- дозвіл на збереження результатів скринінгів.
3.1.4. Управління профілем
- редагування та перегляд;
- видалення акаунту;
- повне видалення даних (GDPR);
- чат з адміністратором.
3.1.5. Віртуальний соціальний працівник
3.2. Спільнота
- стрічка постів організації;
3.3. Новини
- каталог новин із тегами, датами, зображеннями.
3.4. Сервіси
Каталог послуг організації:
- медичні;
- психологічні;
- соціальні;
- гуманітарні;
- притулок;
- центр адаптації;
- економічні програми.
З можливістю додаванням нових адміністратором
Картка сервісу:
- назва;
- опис;
- для кого;
- умови;
- геолокація;
- години роботи;
- кнопка «Отримати допомогу».
3.5. Скринінги
Типи:
- депресія;
- тривога;
- ВІЛ-ризики;
- туберкульоз;
- НІЗ;
- ПТЛ і трудова експлуатація;
- гендерно зумовлене насильство.
Функції:
- питання та шкальна оцінка;
- автоматичний розрахунок рівня ризику;
- текстове пояснення результату;
- рекомендації;
- кнопка «Отримати допомогу».
Після кожного скринінгу система повинна автоматично знаходити або сервіс організації, або найближчу релевантну локацію допомоги, враховуючи:
- місто/область користувача;
- тип проблеми;
- цільову групу.
Наприклад:
- високий рівень депресії → Mental Hub / психолог
- ризики ВІЛ → LightMedical / державна служба
- ТБ → тубкабінет у відповідній громаді
Користувачу пропонується подати заявку (щоб клієнта «вело» на потрібну послугу):
- «Показати на карті»
- «Показати адресу»
- «Подати заявку».
3.6. Отримати допомогу (анкета + ШІ логіка)
Анкета:
- хто звертається (я / за іншу людину);
- локація;
- тип потреби (гуманітарна, притулок, психолог, лікар, соціальний працівник);
- статуси (ВПО, ВІЛ+, ветеран, жінка з досвідом насильства тощо);
- опис ситуації;
- контакт (опційно).
3.6.2. Rule-based рекомендаційний двигун (MVP)
Функції:
- зіставляє дані анкети з параметрами сервісів;
- відбирає доступні та релевантні програми;
- формує список рекомендацій;
- пояснює, чому рекомендація підходить;
- пропонує:
- «Подати заявку»
- «Показати контакти»
- «Показати на карті»
3.6.3. Заявки:
- створення заявки в БД;
- статуси: нова, в роботі, закрита;
- перегляд в адмін-панелі.
3.7. Карта сервісів
- інтеграція Google Maps / Leaflet;
- піни за типами (медичні, психологічні, гуманітарні);
- відстань(за дозволом геолокації);
- відкриття картки сервісу зі швидким переходом до заявки.
3.8. Зворотний зв’язок
Форма:
- тип (подяка, пропозиція, скарга);
- текст;
- оцінка;
- контакт (опційно);
- анонімність - дозволена.
Дані йдуть в адмін - панель
4. Інклюзивність (обов’язково)
4.1. Модуль 1:
Рекомендації в «Отримати допомогу»
Етап 1 (MVP)
- rule-based (фільтрація за категоріями, статусами, географією, умовами участі);
- повертає список доступних сервісів;
- формує пояснення.
Етап 2 (опційно)
- підключення LLM;
- аналіз відкритого тексту;
- персоналізовані рекомендації;
- пояснення природною мовою.
4.2. Модуль 2:
Пояснення результатів скринінгів MVP:
- таблиці порогових значень;
- текстові пояснення;
- рекомендації, що робити;
- автоматичний пошук найближчої локації для звернення;
- кнопки «На карту», «Показати адресу», «Заявка».
Етап 2:
- LLM-пояснення;
- адаптація під користувача.
5. Адміністративна панель
- керування новинами;
- керування сервісами та локаціями;
- редагування скринінгів;
- модерація;
- управління заявками;
- міна статусів;
- експорт даних у Excel / CSV;
- аналітика.
5.1. Інтеграція з DHIS2
Мобільний застосунок інтегрується з District Health Information Software 2 (DHIS2) для централізованого збору, обробки та аналізу деперсоналізованих даних з метою формування доказової бази (proof of need) для прийняття управлінських рішень та оптимізації надання послуг.
5.1.1. Мета інтеграції
• Збір уніфікованих деперсоналізованих даних про користувачів, послуги та результати роботи організації.
• Формування статистики для аналізу потреб цільових груп (proof of need).
• Забезпечення сумісності з національними та міжнародними системами моніторингу охорони здоров'я.
• Підтримка прийняття рішень на основі даних (data-driven decision making).
• Автоматизація звітності для донорів та стейкхолдерів.
5.1.2. Архітектура інтеграції
Інтеграція реалізується через REST API DHIS2 з використанням OAuth 2.0 для автентифікації. Дані передаються у форматі JSON згідно зі специфікацією DHIS2 Web API.
Компоненти архітектури:
• Data Aggregation Layer - збір даних з мобільного застосунку та їх деперсоналізація на рівні бекенду;
• DHIS2 Connector Module - мікросервіс для трансформації та передачі даних у DHIS2;
• Metadata Synchronization - синхронізація довідників (програм, організаційних одиниць, індикаторів);
• Event Tracker - реєстрація подій (events) та відстеження програм (tracker programs);
• Analytics Engine - запити до DHIS2 Analytics API для отримання агрегованих звітів.
5.1.3. Дані, що передаються в DHIS2
Всі персональні ідентифікатори замінюються на анонімні UUID. Передаються лише агреговані та знеособлені дані:
Демографічні дані (агреговані):
• Вікові групи (18-25, 26-35, 36-50, 51+)
• Стать (чоловік, жінка, небінарна особа, не вказано)
• Область/місто (без точної адреси)
• Статуси (ВПО, ветеран, ВІЛ+, інвалідність тощо)
Результати скринінгів (знеособлені):
• Тип скринінгу (депресія, тривога, ВІЛ, ТБ, НІЗ)
• Результат (низький/середній/високий ризик)
• Дата проходження
• Рекомендації, що були надані
Послуги та заявки:
• Тип запитаної послуги
• Статус заявки (отримано/в обробці/відмовлено)
• Часові мітки (дата подання, дата відповіді)
• Канал звернення (мобільний застосунок)
Поведінкові метрики:
• Кількість завершених скринінгів на користувача (без прив'язки до особи)
• Використання функцій застосунку (анонімна телеметрія)
• Географічний розподіл активності (на рівні міста/регіону)
Зворотний зв'язок:
• Оцінки послуг (1-5 зірок)
• Категорії скарг (без текстового вмісту)
• Час відповіді на запити
5.1.4. Деперсоналізація даних
Процес деперсоналізації відбувається на стороні бекенду перед передачею даних у DHIS2:
• Видалення ПІБ, контактних даних, точних адрес.
• Заміна user_id на анонімний UUID (окремий для DHIS2).
• Агрегація даних за віковими групами, регіонами, статусами.
• Хешування чутливих полів (якщо потрібна ідентифікація дублікатів без розкриття особи).
• Часове згладжування (aggregation) - дані групуються за тиждень/місяць, а не за точну дату та час.
5.1.5. Технічна реалізація
Метод передачі:
HTTP POST/PUT запити до DHIS2 API endpoints.
Формат даних:
JSON (відповідно до DHIS2 metadata model).
Автентифікація:
OAuth 2.0 / Basic Auth (залежно від налаштувань DHIS2 інстансу).
Частота синхронізації:
Batch processing щодня о 02:00 (UTC+2) або real-time для критичних подій.
Обробка помилок:
Retry mechanism з exponential backoff, логування помилок, алерти для адміністраторів.
Валідація даних:
Схема валідації на стороні бекенду перед відправкою (відповідність DHIS2 Data Elements).
5.1.6. Використання даних (Proof of Need)
Дані з DHIS2 використовуються для:
• Ідентифікації пріоритетних регіонів та демографічних груп для розширення послуг.
• Оцінки ефективності програм та втручань (наприклад, зменшення кількості високоризикових результатів скринінгу).
• Підготовки звітів для донорів із чіткими метриками впливу (impact metrics).
• Формування запитів на фінансування (грантові заявки) з підтвердженням потреб даними.
• Порівняння з національними показниками (benchmarking) через інтеграцію з державними DHIS2 системами.
5.1.7. Відповідність стандартам
• GDPR / Закон України «Про захист персональних даних» - повна анонімізація перед передачею.
• DHIS2 Web API specification - сумісність з останньою версією DHIS2 (v2.40+).
• WHO Health Data Standards - використання стандартизованих кодів для діагнозів, процедур та послуг.
• ISO 27001 - забезпечення інформаційної безпеки при передачі та зберіганні даних.
5.2. Digital Twin організації
Система Digital Twin (цифровий двійник) організації створює віртуальну модель діяльності БО «Світло надії», яка в реальному часі відображає стан послуг, взаємодію з клієнтами та ключові операційні метрики. Це дозволяє керівництву та менеджерам проектів отримувати актуальну інформацію для швидкого реагування та стратегічного планування.
5.2.1. Концепція Digital Twin
Digital Twin - це цифрова репрезентація фізичних процесів та активностей організації, що оновлюється в реальному часі на основі даних з мобільного застосунку, адмін-панелі та зовнішніх систем.
Ключові компоненти:
• Service Layer Twin - відображення всіх сервісів організації (психологічна підтримка, юридичні консультації, тестування на ВІЛ/ТБ тощо) з метриками доступності, навантаження та результативності.
• Client Interaction Twin - модель взаємодії з клієнтами: активність користувачів, запити на послуги, проходження скринінгів, зворотний зв'язок.
• Operational Twin - внутрішні процеси: обробка заявок, час відповіді, завантаженість команди, географічне покриття.
• Impact Twin - вимірювання впливу (outcomes): зміна показників здоров'я клієнтів, ступінь задоволення послугами, соціальні ефекти.
5.2.2. Real-time моніторинг та аналітика
Система забезпечує моніторинг у реальному часі з можливістю відстеження наступних метрик:
Послуги (Services):
• Кількість активних користувачів сервісів (у реальному часі).
• Завантаженість сервісів (кількість запитів на годину/день).
• Доступність послуг (uptime, час відповіді).
• Географічний розподіл запитів (heat map).
• Оцінка якості послуг (середній рейтинг, NPS).
Клієнти (Clients):
• Онлайн/офлайн користувачі (active sessions).
• Кількість нових реєстрацій за період.
• Коефіцієнт утримання користувачів (retention rate).
• Сегментація клієнтів за статусами (ВПО, ветеран, ВІЛ+ тощо).
• Частота взаємодії з застосунком (DAU/MAU).
Заявки та запити:
• Кількість активних заявок.
• Середній час обробки заявки.
• Статуси заявок (нові/в обробці/завершені/відмовлені).
• Розподіл за типами послуг.
• Пікові години активності.
Скринінги:
• Кількість пройдених скринінгів (за типом).
• Розподіл результатів (низький/середній/високий ризик).
• Конверсія у запити на послуги після скринінгу.
• Регіони з найвищими показниками ризику.
Операційні метрики:
• Навантаження на сервер (CPU, memory, DB queries).
• API response time.
• Кількість помилок / збоїв.
• Доступність системи (SLA compliance).
5.2.3. Dashboard для візуалізації Digital Twin
Для керівництва та менеджерів створюється окремий веб-інтерфейс (Dashboard) з візуалізацією Digital Twin.
Інтерфейс включає:
Головний екран (Overview):
• Загальна кількість активних користувачів.
• Кількість заявок у реальному часі (новi / в обробці / завершені).
• Карта активності (heat map за регіонами).
• Ключові індикатори (KPI): NPS, retention rate, conversion rate.
Сервіси (Services Dashboard):
• Список всіх сервісів із метриками (запити, завантаженість, оцінка).
• Графіки використання сервісів у часі (hourly/daily/weekly).
• Порівняння сервісів за популярністю та ефективністю.
Клієнти (Client Analytics):
• Демографічний розподіл (вік, стать, регіон, статуси).
• Когортний аналіз (retention по тижнях/місяцях).
• Сегментація клієнтів за поведінкою (активні, неактивні, high-risk).
Скринінги (Screening Insights):
• Динаміка проходження скринінгів.
• Розподіл за типами та результатами.
• Географічні зони з високим ризиком (для планування інтервенцій).
Операційна панель (Operations):
• Час відповіді команди на заявки.
• Завантаженість команди (кількість активних кейсів на менеджера).
• Статус системи (uptime, помилки).
5.2.4. Експорт даних та звітність
Dashboard надає можливості експорту даних для подальшого аналізу та звітності:
Формати експорту:
• CSV - для завантаження в Excel/Google Sheets.
• JSON - для інтеграції з іншими системами.
• PDF - для створення executive reports.
• Excel (XLSX) - з готовими зведеними таблицями та графіками.
Налаштування звітів:
• Вибір періоду (день, тиждень, місяць, квартал, рік).
• Фільтрація за регіонами, сервісами, демографічними групами.
• Автоматичні звіти (scheduled reports) — щотижневі/щомісячні email з аналітикою.
Інтеграція з BI-інструментами:
• Підтримка експорту у Power BI / Tableau.
• REST API для отримання даних у реальному часі.
• Webhooks для сповіщень про критичні події (наприклад, перевищення порогового значення заявок).
5.2.5. Технічна архітектура Digital Twin
Data Ingestion Layer:
Збір даних з мобільного застосунку, адмін-панелі, DHIS2 у реальному часі через event streams (Kafka / RabbitMQ).
Real-time Processing Engine:
Обробка подій у реальному часі (Apache Flink / Spark Streaming) для розрахунку метрик.
Time-series Database:
InfluxDB / TimescaleDB для зберігання метрик з часовою міткою.
Analytics Database:
PostgreSQL / ClickHouse для агрегованих даних та historical analytics.
Visualization Layer:
React-based dashboard з charts (Chart.js / D3.js) та real-time updates (WebSockets).
API Layer:
REST API / GraphQL для доступу до даних Digital Twin з інших систем.
5.2.6. Використання Digital Twin для прийняття рішень
Digital Twin дозволяє приймати обґрунтовані рішення на основі даних у реальному часі:
• Оптимізація розподілу ресурсів - визначення регіонів та сервісів з найбільшою потребою.
• Швидке реагування на проблеми - алерти при перевищенні порогових значень (наприклад, час відповіді на заявки >24 години).
• Планування масштабування - прогнозування зростання кількості користувачів та необхідності розширення команди.
• Оцінка ефективності програм - порівняння метрик до/після впровадження нових ініціатив.
• Звітність для донорів - автоматичне формування звітів з реальними метриками впливу (impact reports).
5.2.7. Безпека та конфіденційність
• Доступ до Dashboard лише для авторизованих користувачів (Role-Based Access Control).
• Шифрування даних у транзиті (TLS/SSL) та у спокої (encryption at rest).
• Аудит логів - запис всіх дій користувачів Dashboard для забезпечення підзвітності.
• Деперсоналізація - жодних персональних ідентифікаторів у метриках Digital Twin.
• Відповідність GDPR - можливість видалення даних за запитом (Right to be Forgotten).
6. Нефункціональні характеристики системи
6.1. Інформаційна безпека та захист даних
Система повинна забезпечувати високий рівень захисту персональних та чутливих даних користувачів відповідно до вимог GDPR та Закону України «Про захист персональних даних».
6.1.1. Шифрування та передача даних
- Усі з’єднання між клієнтським застосунком, бекендом та сторонніми сервісами повинні здійснюватися з використанням протоколу HTTPS (TLS версії 1.2 або вище).
- Персональні та чутливі дані у базах даних повинні зберігатися у зашифрованому вигляді (encryption at rest).
6.1.2. Контроль доступу та логування
- Система повинна підтримувати рольову модель доступу (RBAC).
- Усі адміністративні дії та операції із заявками повинні логуватися.
- Журнали подій повинні зберігатися протягом визначеного періоду для цілей аудиту та забезпечення безпеки.
6.1.3. Обробка медичних і соціальних даних
- Система не повинна зберігати чутливі медичні дані (результати скринінгів, статуси, історію звернень) без отримання явної згоди користувача.
- Користувач повинен мати можливість у будь-який момент відкликати дозвіл на збереження своїх даних.
6.1.4. Анонімізація та деперсоналізація
- Перед передачею даних у аналітичні системи та DHIS2 всі персональні ідентифікатори повинні видалятися.
- Ідентифікація користувачів у системі аналітики повинна здійснюватися виключно через анонімні UUID.
- Для аналітичних цілей повинна застосовуватися агрегація даних за віком, регіонами та статусами.
6.1.5. Право на видалення даних (GDPR)
Система повинна забезпечувати користувачу можливість:
- видалити власний акаунт;
- ініціювати повне видалення всіх персональних даних;
- отримати підтвердження про виконання запиту (Right to be Forgotten).
7. Інклюзивність та доступність (обов’язково)
Мобільний застосунок повинен відповідати стандартам WCAG 2.1 рівня AA та забезпечувати повноцінне користування для людей з різними формами інвалідності.
7.1.1. Підтримка screen readers
Система повинна:
- коректно працювати з TalkBack (Android) та VoiceOver (iOS);
- містити альтернативні текстові описи (alt-text) для іконок, кнопок, зображень та інтерактивних елементів;
- підтримувати голосову навігацію та коректне фокусування елементів.
7.1.2. Масштабування тексту
- Інтерфейс повинен залишатися функціональним і читабельним при збільшенні розміру шрифтів до 200%.
- Жоден елемент інтерфейсу не повинен перекриватися або втрачати доступність при масштабуванні.
7.1.3. Контраст і читабельність
- Кольорові схеми інтерфейсу повинні відповідати вимогам WCAG 2.1 AA щодо контрастності.
- Текст, іконки та кнопки повинні бути чітко відокремлені від фону та легко читатися.
7.1.4. Зони натискання
- Усі інтерактивні елементи (кнопки, поля, іконки) повинні мати мінімальний розмір активної зони 48 × 48 dp.
- Повинна забезпечуватися достатня відстань між інтерактивними елементами для уникнення помилкових натискань.
Термін надання послуг: Послуги з розробки мобільного застосунку для БО «Світло надії» надаються у період до кінця травня 2026 року.