ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/6679| Title: | Управління стартапом створення мобільного застосунку для медичних працівників та пацієнтів |
| Authors: | Оксамитна, Любов Павлівна Макота, Євгеній Васильович |
| Keywords: | УПРАВЛІННЯ;ОНЛАЙН-ДОДАТОК;ЗАДАЧІ;МЕДИЧНА ГАЛУЗЬ;ШІ-ТЕХНОЛОГІЇ;КАЛЕНДАРНЕ ПЛАНУВАННЯ;МОДЕЛЮВАННЯ ПРОДУКТУ;АНАЛІЗ РИНКУ;СТАРТАП;КРИТИЧНІЙ ШЛЯХ. |
| Issue Date: | 17-Dec-2025 |
| Abstract: | Актуальність теми. Стрімкий розвиток цифрових технологій у медицині змінює характер взаємодії між лікарем і пацієнтом, а мобільні застосунки дедалі частіше стають основним інструментом такої комунікації. Зростання кількості хронічних захворювань, потреба у постійному контролі стану здоров’я та обмежена ефективність традиційних каналів зв’язку підсилюють попит на рішення, що поєднують телемедицину, аналітику даних та інтелектуальні підказки. Сучасні цифрові системи орієнтовані на безперервний моніторинг пацієнтів, раннє виявлення потенційних ризиків, автоматизацію рутинних процесів і підтримку лікаря у прийнятті клінічних рішень. Інтеграція штучного інтелекту, алгоритмів обробки медичних даних та інструментів комунікації робить такі рішення особливо актуальними для українського ринку, де комплексні інтелектуальні платформи поки що майже не представлені. У цьому контексті питання організації та ефективного управління стартапом, що створює подібні технології, набуває визначального значення як для ІТ-сфери, так і для сучасної медицини. Мета роботи і задачі дослідження. Основним завданням роботи є розроблення аргументованого підходу до управління стартапом, що займається створенням мобільного застосунку для медичних працівників і пацієнтів, із урахуванням вимог сучасної eHealth-інфраструктури, технічних обмежень та реальних потреб користувачів. Об’єктом дослідження є процес управління стартапом у сфері розробки цифрових медичних систем. Предметом дослідження є методи й моделі управління стартапом, що охоплюють планування, координацію, організацію роботи команди, ресурсне забезпечення, ризик-менеджмент та управління якістю при створенні мобільного медичного застосунку. Апробація результатів роботи. Основні положення і результати кваліфікаційної роботи магістра доповідалися і були обговорені на ІV Міжнародній науково-практичній Інтернет-конференції «ІННОВАЦІЇ ТА ПЕРСПЕКТИВНІ ШЛЯХИ РОЗВИТКУ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ (ІПШРІТ-2025)», Черкаси, 25 листопада 2025 року. Публікації. Макота Є.В. Управління ризиками при створенні мобільного застосунку для медичних працівників та пацієнтів [Текст]: // ІV Міжнародна науково-практична Інтернет-конференція «ІПШРІТ-2025», Черкаси, 25 листопада 2025 року, ЧДТУ. С. 45. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/6679 |
| Appears in Collections: | 122 Комп’ютерні науки (Управління стартапами і проектами в галузі інформаційних технологій) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Пояснювальна записка_Макота Євгеній_МСТП-2402_2025-2026.pdf Restricted Access | 2.62 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра комп’ютерних наук та системного аналізу
Пояснювальна записка
до кваліфікаційної роботи
магістра
(освітньо-кваліфікаційний рівень)
на тему: «Управління стартапом створення мобільного застосунку для медичних
працівників та пацієнтів»
Виконав: студент 2 курсу, групи МСТП-2402
спеціальності 122 «Комп’ютерні науки»
(шифр і назва спеціальності)
освітня програма «Управління стартапами
(назва освітньої програми)
і проєктами в галузі інформаційних технологій»
Макота Євгеній Васильович
Керівник Оксамитна Л.П.
(прізвище та ініціали)
Рецензент Мельник В.П.
(прізвище та ініціали)
Черкаси 2025 року
2
Черкаський державний технологічний університет
Факультет Інформаційних технологій і систем
Кафедра Комп’ютерних наук та системного аналізу
Освітньо-кваліфікаційний рівень Магістр
Спеціальність 122 – комп’ютерні науки
Освітня програма Управління стартапами і проєктами в галузі інформаційних технологій
ЗАТВЕРДЖУЮ
Завідувач кафедри КНСА
_______________ Юрій ТРИУС
«____» _____________ 2025 р.
ЗАВДАННЯ
на кваліфікаційну роботу магістра студенту
Макоті Євгенію Васильовичу
(прізвище, ім‘я, по батькові)
1. Тема роботи Управління стартапом створення мобільного застосунку
для медичних працівників та пацієнтів
Керівник роботи Оксамитна Любов Павлівна, к.т.н., доцент
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «07» жовтня 2025 р. №307/03-03
2. Строк подання студентом роботи до «15» грудня 2025 року.
3. Вихідні дані до роботи:
Результати та матеріали з проходження виробничої та переддипломної практики.
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
1. Аналіз та дослідження характеристики обʼєкту управління.
2. Формування задума стартапу та розробка концепції.
3. Планування та проєктування застосунку.
4. Моделювання виконання стартапу.
Висновки
5.
5.1. Додаток А. Специфікація 482. ЧДТУ. 52412-01.
5.2. Додаток Б. Публікація по темі кваліфікаційної роботи магістра.
5.3. Презентація у вигляді 27 слайдів.
3
6. Консультанти розділів роботи
Прізвище, ініціали та Підпис, дата
Розділ посада
завдання видав завдання прийняв
консультанта
7. Дата видачі завдання 02.09.2025 р.
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№ з/п Назва етапів кваліфікаційної роботи магістра Примітка
етапів роботи
1 Видача завдання на кваліфікаційну роботу виконано
до 02.09.2025
магістра.
2 Аналіз літературних джерел, об’єкту та виконано
до 15.09.2025
предмету дослідження.
3 Написання теоретичного розділу кваліфікаційної виконано
до 01.10.2025
роботи магістра.
4 Написання аналітичного розділу (аналіз об’єкту виконано
до 03.11.2025
й предмету дослідження).
5 Написання практичних розділів й висновків виконано
до 01.12.2025
кваліфікаційної роботи магістра.
6 Передзахист кваліфікаційної роботи магістра на виконано
до 01.12.2025
засіданні випускової кафедри.
7 Подання роботи завідувачу кафедри КНСА. до 15.12.2025 виконано
8 Захист кваліфікаційної роботи магістра. 18.12.2025 виконано
Студент _____________________________ Євгеній МАКОТА
(підпис)
Керівник роботи ____________________________ Любов ОКСАМИТНА
(підпис)
4
РЕФЕРАТ
Кваліфікаційна робота магістра містить: 134 с., 6 рис., 31 табл., 44
використаних джерел, 2 додатки.
Актуальність теми. Стрімкий розвиток цифрових технологій у медицині
змінює характер взаємодії між лікарем і пацієнтом, а мобільні застосунки дедалі
частіше стають основним інструментом такої комунікації. Зростання кількості
хронічних захворювань, потреба у постійному контролі стану здоров’я та обмежена
ефективність традиційних каналів зв’язку підсилюють попит на рішення, що
поєднують телемедицину, аналітику даних та інтелектуальні підказки. Сучасні
цифрові системи орієнтовані на безперервний моніторинг пацієнтів, раннє
виявлення потенційних ризиків, автоматизацію рутинних процесів і підтримку
лікаря у прийнятті клінічних рішень. Інтеграція штучного інтелекту, алгоритмів
обробки медичних даних та інструментів комунікації робить такі рішення особливо
актуальними для українського ринку, де комплексні інтелектуальні платформи поки
що майже не представлені. У цьому контексті питання організації та ефективного
управління стартапом, що створює подібні технології, набуває визначального
значення як для ІТ-сфери, так і для сучасної медицини.
Мета роботи і задачі дослідження. Основним завданням роботи є
розроблення аргументованого підходу до управління стартапом, що займається
створенням мобільного застосунку для медичних працівників і пацієнтів, із
урахуванням вимог сучасної eHealth-інфраструктури, технічних обмежень та
реальних потреб користувачів. Для реалізації поставленої мети були виконані
основні завдання:
здійснити аналіз ринку цифрової медицини, простежити актуальні
тренди телемедицини та розвиток інтелектуальних медичних сервісів;
ідентифікувати основних стейкхолдерів проєкту, визначити їхні
очікування та рівень впливу на перебіг робіт;
встановити цілі стартапу, критерії досягнення успіху та ключові
характеристики майбутнього продукту;
5
окреслити зміст, архітектуру та функціональні компоненти застосунку;
побудувати модель життєвого циклу продукту та сформувати план його
реалізації;
провести оцінку необхідних ресурсів, тривалості етапів, бюджету та
можливих ризиків;
визначити підходи до забезпечення якості продукту й організації
процесів розробки;
напрацювати практичні рекомендації щодо впровадження, тестування та
подальшого масштабування рішення.
Об’єктом дослідження є процес управління стартапом у сфері розробки
цифрових медичних систем.
Предметом дослідження є методи й моделі управління стартапом, що
охоплюють планування, координацію, організацію роботи команди, ресурсне
забезпечення, ризик-менеджмент та управління якістю при створенні мобільного
медичного застосунку.
У роботі використано набір методів, що відповідають особливостям ІТ-
проєктів у сфері eHealth. Архітектуру застосунку структуровано за допомогою
системного аналізу. Планування життєвого циклу, ролей і процесів команди
здійснювалося з опорою на підходи Agile/Scrum та рекомендації PMBOK. Для
формування змісту проєкту застосовано методи моделювання — декомпозицію,
WBS, мережеве планування та оцінку строків і ресурсів. Економічні інструменти
були використані для розрахунку бюджету, а методи ризик-менеджменту — для
виявлення та мінімізації загроз. Порівняльний аналіз міжнародних і українських
рішень дав змогу оцінити конкурентне середовище та можливості адаптації
продукту.
Практична цінність дослідження полягає в створенні узгодженої моделі
управління стартапом, яку можна застосувати під час розробки медичного
мобільного застосунку. Запропоновані підходи сприяють покращенню комунікації
лікаря з пацієнтом, зменшенню кількості офлайн-візитів, підвищенню якості
6
первинної оцінки стану здоров’я та впровадженню інтелектуальних інструментів у
медичну практику. Отримані результати можуть бути корисними для стартапів,
медичних установ і розробників програмних рішень у сфері охорони здоров’я.
Апробація результатів роботи. Основні положення і результати
кваліфікаційної роботи магістра доповідалися і були обговорені на ІV Міжнародній
науково-практичній Інтернет-конференції «ІННОВАЦІЇ ТА ПЕРСПЕКТИВНІ
ШЛЯХИ РОЗВИТКУ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ (ІПШРІТ-2025)», Черкаси,
25 листопада 2025 року.
Публікації. Макота Є.В. Управління ризиками при створенні мобільного
застосунку для медичних працівників та пацієнтів [Текст]: // ІV Міжнародна
науково-практична Інтернет-конференція «ІПШРІТ-2025», Черкаси, 25 листопада
2025 року, ЧДТУ. С. 45.
Перелік ключових слів: УПРАВЛІННЯ, ОНЛАЙН-ДОДАТОК, ЗАДАЧІ,
МЕДИЧНА ГАЛУЗЬ, ШІ-ТЕХНОЛОГІЇ, КАЛЕНДАРНЕ ПЛАНУВАННЯ,
МОДЕЛЮВАННЯ ПРОДУКТУ, АНАЛІЗ РИНКУ, СТАРТАП, КРИТИЧНІЙ ШЛЯХ.
ABSTRACT
Master's qualifying work includes: 134 p., 6 rites, 31 tabl., 44 sources used, 2
applications.
Actuality of theme. The rapid development of digital technologies in medicine is
changing the nature of interaction between a doctor and a patient, and mobile applications
are increasingly becoming the main tool for such communication. The growth of the
number of chronic diseases, the need for constant health monitoring, and the limited
effectiveness of traditional communication channels are increasing the demand for
solutions that combine telemedicine, data analytics, and intelligent prompts. Modern
digital systems are focused on continuous patient monitoring, early detection of potential
risks, automation of routine processes, and support for doctors in making clinical
decisions. The integration of artificial intelligence, medical data processing algorithms,
and communication tools makes such solutions especially relevant for the Ukrainian
market, where complex intelligent platforms are still almost unrepresented. In this context,
7
the issue of organizing and effectively managing a startup that creates such technologies is
of decisive importance for both the IT sphere and modern medicine.
Purpose and tasks of research. The main task of the work is to develop a
reasoned approach to managing a startup that is engaged in creating a mobile application
for medical professionals and patients, taking into account the requirements of modern
eHealth infrastructure, technical limitations and real needs of users. To achieve this goal,
the following main tasks were completed:
to analyze the digital medicine market, track current trends in telemedicine
and the development of intelligent medical services;
to identify the main stakeholders of the project, determine their expectations
and the level of influence on the progress of work;
to establish the goals of the startup, criteria for achieving success and key
characteristics of the future product;
to outline the content, architecture and functional components of the
application;
to build a product life cycle model and form a plan for its implementation;
to assess the necessary resources, duration of stages, budget and possible
risks;
to determine approaches to ensuring product quality and organizing
development processes;
to develop practical recommendations for implementing, testing and further
scaling the solution.
Object of research: is the process of managing a startup in the field of developing
digital medical systems.
Subject of research: there are startup management methods and models that cover
planning, coordination, team organization, resource provision, risk management, and
quality management when creating a mobile medical application.
The work used a set of methods that meet the specifics of IT projects in the
eHealth field. The application architecture was structured using system analysis. Planning
8
of the team's life cycle, roles and processes was carried out based on Agile/Scrum
approaches and PMBOK recommendations. To form the project content, modeling
methods were used - decomposition, WBS, network planning and assessment of terms and
resources. Economic tools were used to calculate the budget, and risk management
methods - to identify and minimize threats. A comparative analysis of international and
Ukrainian solutions made it possible to assess the competitive environment and product
adaptation possibilities.
The practical value of the study lies in creating a consistent startup management
model that can be applied during the development of a medical mobile application. The
proposed approaches contribute to improving doctor-patient communication, reducing the
number of offline visits, improving the quality of the initial health assessment and
implementing intelligent tools in medical practice. The results obtained may be useful for
startups, medical institutions, and developers of software solutions in the healthcare sector.
Approval of the results of work. The main provisions and results of the master's
qualification work were reported and discussed at the IV International Scientific and
Practical Internet Conference «INNOVATIONS AND PROSPECTIVE PATHS OF
DEVELOPMENT OF INFORMATION TECHNOLOGIES (IPSHRIT-2025)», Cherkasy,
November 25, 2025.
Publications. Makota E.V. Risk management in creating a mobile application for
medical workers and patients [Text]: // IV International Scientific and Practical Internet
Conference «IPSHRIT-2025», Cherkasy, November 25, 2025, ChSTU. Р. 45.
The key words: MANAGEMENT, ONLINE APPLICATION, TASKS,
MEDICAL INDUSTRY, AI TECHNOLOGIES, CALENDAR PLANNING, PRODUCT
MODELING, MARKET ANALYSIS, STARTUP, CRITICAL PATH.
9
ЗМІСТ
ВСТУП ................................................................................................................................ 12
1 АНАЛІЗ ТА ДОСЛІДЖЕННЯ ХАРАКТЕРИСТИКИ ОБ’ЄКТУ УПРАВЛІННЯ .... 14
1.1 Аналіз та загальна характеристика галузі ............................................................. 14
1.2 Проведення аналізу конкурентів ............................................................................ 16
1.3 Аналізу галузі за методом “5 сил Портера” .......................................................... 23
1.4 SWOT-аналіз ............................................................................................................ 32
1.5 Особливості управління в галузі цифрових медичних сервісів ......................... 37
Висновки до розділу 1 ................................................................................................... 41
2 ФОРМУВАННЯ ЗАДУМУ СТАРТАПУ ТА РОЗРОБКА КОНЦЕПЦІЇ ................... 43
2.1 Аналіз оточення стартапу ....................................................................................... 43
2.2 Первинні та вторинні зацікавлені сторони ........................................................... 54
2.3 Місія, цілі та розробка коцепції стартапу ............................................................. 61
2.4 Опис продукту проєкту ........................................................................................... 65
2.5 Життєвий цикл проєкту .......................................................................................... 71
Висновки до розділу 2 ................................................................................................... 74
3 ПАНУВАННЯ ТА УПРАВЛІННЯ СТАРТАПОМ ...................................................... 76
3.1 Управління змістом стартапу ................................................................................. 76
3.2 Побудова складу команди стартапу та розподіл відповідальностей .................. 83
3.3 Календарне планування стартапу .......................................................................... 86
3.4 Планування ресурсів та вартості стартапу ........................................................... 91
3.5 Управління якістю стартапу ................................................................................... 96
3.6 Управління ризиками стартапу ............................................................................ 100
Висновки до розділу 3 ................................................................................................. 106
4 МОДЕЛЮВАННЯ ВИКОНАННЯ СТАРТАПУ ........................................................ 108
4.1 Опис моделювання продукту стартапу ............................................................... 108
4.2 Тестування мобільного застосунку .......................................................................110
4.3 Управління змінами та комунікаціями під час проєктування стартапу ............118
Висновки до розділу 4 ................................................................................................. 122
10
ВИСНОВКИ ..................................................................................................................... 123
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ....................................................................... 125
ДОДАТОК А. Специфікація 482. ЧДТУ. 52412-01 ............................................. ……..129
ДОДАТОК Б. Публікація по темі кваліфікаційної роботи магістра ........................... 131
11
ВСТУП
Актуальність теми. Стрімкий розвиток цифрових технологій у медицині
змінює характер взаємодії між лікарем і пацієнтом, а мобільні застосунки дедалі
частіше стають основним інструментом такої комунікації. Зростання кількості
хронічних захворювань, потреба у постійному контролі стану здоров’я та обмежена
ефективність традиційних каналів зв’язку підсилюють попит на рішення, що
поєднують телемедицину, аналітику даних та інтелектуальні підказки. Сучасні
цифрові системи орієнтовані на безперервний моніторинг пацієнтів, раннє
виявлення потенційних ризиків, автоматизацію рутинних процесів і підтримку
лікаря у прийнятті клінічних рішень. Інтеграція штучного інтелекту, алгоритмів
обробки медичних даних та інструментів комунікації робить такі рішення особливо
актуальними для українського ринку, де комплексні інтелектуальні платформи поки
що майже не представлені. У цьому контексті питання організації та ефективного
управління стартапом, що створює подібні технології, набуває визначального
значення як для ІТ-сфери, так і для сучасної медицини.
Метою цього дослідження є обґрунтування підходів до управління стартапом
зі створення мобільного застосунку, призначеного для медичних працівників і
пацієнтів, з урахуванням вимог eHealth-середовища, технологічних обмежень і
потреб користувачів.
Для досягнення окресленої мети необхідно виконати такі основні завдання:
проаналізувати ринок цифрової медицини, тенденції розвитку
телемедицини та інтелектуальних медичних систем;
визначити зацікавлені сторони стартапу та дослідити їхні вимоги й
ступінь впливу на проєкт;
сформувати цілі, критерії успіху та ключові параметри продукту;
визначити зміст і структуру застосунку, а також особливості його
функціональних модулів;
12
побудувати модель життєвого циклу стартапу та розробити план
реалізації;
оцінити ресурси, строки, вартість і потенційні ризики проєкту;
обґрунтувати методи забезпечення якості продукту й процесів розробки;
сформувати практичні рекомендації щодо впровадження, тестування та
масштабування програмного рішення.
Об’єктом дослідження виступає процес управління стартапом у сфері
розробки цифрових медичних систем.
Предметом дослідження є методи й моделі управління стартапом, що
охоплюють планування, координацію, організацію роботи команди, ресурсне
забезпечення, ризик-менеджмент та управління якістю при створенні мобільного
медичного застосунку.
У процесі роботи застосовано комплекс методів, що відповідають специфіці
ІТ-проєктів у сфері eHealth: системний аналіз для структуризації архітектури
застосунку; підходи управління проєктами (Agile/Scrum, PMBOK) для побудови
життєвого циклу, визначення ролей та процесів у команді; методи проєктного
моделювання (WBS, декомпозиція, мережеве планування, оцінка строків і ресурсів);
економічні методи для розрахунку витрат і бюджету; методи ризик-менеджменту; а
також порівняльний аналіз міжнародних та українських рішень для визначення
конкурентного середовища та можливостей локалізації.
Практичне значення проведеного дослідження полягає у формуванні
комплексної моделі управління стартапом, що може бути використана для створення
реального медичного мобільного застосунку. Запропоновані підходи дають змогу
підвищити якість комунікації лікаря з пацієнтом, зменшити кількість офлайн-візитів,
удосконалити процес первинної медичної оцінки, а також забезпечити інтеграцію
інтелектуальних інструментів у діяльність медичних закладів. Отримані результати
можуть бути застосовані стартапами, медичними установами, розробниками
медичного програмного забезпечення та органами, що займаються цифровою
трансформацією охорони здоров’я.
13
1 АНАЛІЗ ТА ДОСЛІДЖЕННЯ ХАРАКТЕРИСТИКИ ОБ’ЄКТУ УПРАВЛІННЯ
1.1 Аналіз та загальна характеристика галузі
Сфера eHealth за останнє десятиліття зазнала стрімкої трансформації,
перетворившись на розгалужений ринок цифрових медичних рішень, який охоплює
електронні медичні записи, телемедицину, дистанційний моніторинг та мобільні
застосунки. Аналітичні огляди ринку демонструють, що середньорічні темпи
зростання глобального eHealth-сектора залишаються на рівні двозначних показників,
що пов’язано зі старінням населення, збільшенням кількості хронічних захворювань
та зростанням потреби в оптимізації ресурсів систем охорони здоров’я [1].
Пандемія COVID-19 стала каталізатором активного переходу до дистанційних
форматів медичної допомоги. У багатьох країнах використання телемедицини
зросло в рази, а сам формат був інтегрований у повсякденну клінічну практику, що
відображено в офіційних рекомендаціях ВООЗ та у звітах міжнародних регуляторів
[2]. У подальші роки відбулося інституційне закріплення телемедицини: з’явилися
тарифні механізми відшкодування дистанційних послуг, нормативні вимоги до
безпеки каналів зв’язку та зберігання даних, а також регламенти, що визначають
юридичний статус онлайн-консультацій.
Паралельно зростає сегмент цифрових інструментів для дистанційного
моніторингу стану здоров’я (Remote Patient Monitoring, RPM). За оцінками наукових
та галузевих досліджень, кількість користувачів RPM-сервісів щорічно
збільшується, а у найближчі роки очікується подвоєння обсягів ринку, зумовлене
поширенням носимих пристроїв та розвитком IoT-інфраструктури [3]. У цьому
сегменті відбувається зміщення акценту від епізодичного контролю до
довгострокового нагляду за пацієнтами з ризикованими або хронічними станами.
Мобільні медичні застосунки (mHealth) відіграють визначальну роль у
формуванні сучасної медичної екосистеми. Згідно з аналітичними дослідженнями,
кількість користувачів, що регулярно застосовують mHealth-додатки, зростає
14
щороку, а якість функціональних можливостей переходить від простого фіксування
даних до інтегрованих сервісів із підтримкою самоконтролю, телемедичних
консультацій та біометричного аналізу [4]. Застосунки дедалі частіше працюють у
зв’язці з електронними медичними записами, лабораторними системами та
лікарняними інформаційними платформами, забезпечуючи безперервність даних.
Одним із найпомітніших трендів є використання штучного інтелекту в
мобільних медичних рішеннях. Дедалі більше застосунків застосовують алгоритми
машинного навчання для аналізу показників, формування персоналізованих
рекомендацій, виявлення відхилень та прогнозування ризику загострення
захворювань. Дослідження показують, що понад половина нових цифрових
медичних продуктів включає AI-компоненти, що значно підвищує точність
первинної оцінки стану пацієнта та може зменшити кількість офлайн-візитів [5].
Окремий сегмент становлять системи підтримки клінічних рішень (CDS), які
поєднують правила медичних протоколів із алгоритмами машинного навчання.
Прикладом таких платформ є Medical Brain, що реалізує аналіз даних у режимі
реального часу та автоматичні сценарії ескалації до лікаря [6].
Водночас розвиток eHealth супроводжується низкою викликів. До них
належать питання якості та структурованості даних, необхідність дотримання
стандартів захисту медичної інформації (GDPR, HIPAA), забезпечення
інтероперабельності систем, а також потреба у високому рівні цифрової грамотності
користувачів. На українському ринку ці аспекти особливо актуальні, оскільки
національна система eHealth перебуває у процесі розширення функціоналу та
інтеграції з приватними цифровими сервісами. Державні стратегічні документи
окреслюють телемедицину як пріоритетний напрям модернізації медичної
інфраструктури, зосереджуючись на стандартизації процесів, підвищенні безпеки
даних та формуванні середовища для розвитку інноваційних медичних стартапів [7].
У підсумку, сучасний ринок eHealth розвивається у напрямі комплексних
рішень, що поєднують телемедицину, дистанційний нагляд, мобільні медичні
технології та аналітичні AI-модулі. Інтеграція штучного інтелекту змінює підхід до
надання медичної допомоги, сприяючи переходу від реактивного лікування до
15
проактивного прогнозування та персоналізованої профілактики. Для стартапів,
орієнтованих на створення мобільних застосунків для лікарів і пацієнтів, це
відкриває значні можливості за умови дотримання вимог якості, безпеки й
сумісності цифрових медичних рішень.
1.2 Проведення аналізу конкурентів
Аналіз конкурентного середовища є ключовою складовою оцінювання
потенціалу стартапу у сфері цифрової медицини. Ринок eHealth в Україні має
фрагментований характер: кожне рішення охоплює лише окремий сегмент —
дистанційний моніторинг, телемедицину, доставку медикаментів або підтримку
здорового способу життя. Водночас комплексних платформ, здатних поєднати
інтелектуальну аналітику, безперервний моніторинг, клінічні протоколи та зручні
інтерфейси для лікарів і пацієнтів, практично немає. Саме тому порівняльний аналіз
наявних рішень дає змогу окреслити ринкові ніші, конкурентні переваги та
потенційні бар’єри для впровадження високотехнологічного мобільного застосунку,
що інтегрує функції AI-помічника, системи підтримки клінічних рішень і платформи
для взаємодії між медичним працівником і пацієнтом.
Cardiomo — український medtech-стартап, який розробив мініатюрний
носимий сенсор у формі «пластиру» для безперервного моніторингу серцевої
діяльності в реальному часі. Дані з пристрою аналізуються за допомогою AI-
двигуна, що дозволяє виявляти аритмії та інші клінічно значущі події,
попереджаючи про ризик інфаркту або інсульту заздалегідь [8].
Переваги:
чітка спеціалізація на серцево-судинній патології, що підвищує клінічну
релевантність;
безперервний 24/7 моніторинг з передаванням даних у реальному часі;
наявність AI-аналітики для раннього виявлення небезпечних станів;
міжнародне визнання (нагороди, пілоти в різних країнах, сертифікація).
Обмеження:
16
фокус лише на серцево-судинних захворюваннях; немає
мультисистемного охоплення;
орієнтація передусім на B2B (клініки, страхові), а не на повноцінний
пацієнтський мобільний застосунок із широкими сервісами;
відсутність функції універсального «віртуального помічника» для
пацієнта (чат, тріаж, поради щодо інших нозологій);
немає відкритих даних про глибоку інтеграцію з національною системою
eHealth.
ImagineCare (Швеція, впроваджується в Україні) — шведська платформа
дистанційного моніторингу пацієнтів (RPM), яку використовують для домашнього
спостереження за пацієнтами з хронічними захворюваннями. Платформа дає змогу
пацієнтам передавати показники (артеріальний тиск, пульс тощо) з дому та
отримувати зворотний зв’язок від медперсоналу [9]. В Україні ImagineCare
використовується як технологічна основа для перших проєктів RPM, спрямованих на
підтримку системи охорони здоров’я в умовах війни, зокрема для пацієнтів із
серцевою недостатністю та артеріальною гіпертензією.
Переваги:
зріла платформа RPM із уже відпрацьованими сценаріями для різних
груп пацієнтів;
сильний акцент на домашньому моніторингу та зменшенні
госпіталізацій;
досвід впровадження на рівні регіональних систем охорони здоров’я;
гнучкі інструменти взаємодії між пацієнтом і клінічною командою.
Обмеження:
базова логіка переважно протокольно-правилова; AI-складова менш
виражена, ніж у повноцінних CDS-платформах;
іноземне походження, отже, додаткові витрати на локалізацію,
інтеграцію та дотримання українських регуляторних вимог;
17
не є повноцінним «супер застосунком» для пацієнта, а радше
компонентом клінічного контурів RPM.
Doc.ua — один із найбільших в Україні онлайн-сервісів для пошуку лікарів,
запису на прийом, організації онлайн-консультацій та бронювання діагностичних
послуг. Платформа поєднує каталог лікарів, клінік, діагностичних центрів, а також
модулі телемедицини й пошуку ліків [10].
Переваги:
потужний маркетплейс медичних послуг із великою базою лікарів і
клінік;
зручний інтерфейс для запису на прийом, включно з онлайн-
консультаціями;
інтеграція з рядом аптечних сервісів і можливість пошуку ліків;
висока впізнаваність бренду серед українських користувачів.
Обмеження:
основний фокус — на логістиці медичних послуг (запис, пошук,
знижки), а не на клінічній аналітиці;
відсутність повноцінних AI-модулів для медичних рішень або
моніторингу стану пацієнтів;
немає безперервного RPM; стан здоров’я фіксується епізодично (під час
звернень).
Liki24.com — український стартап, що працює як маркетплейс і логістичний
сервіс для пошуку та доставки ліків. Система агрегує ціни в аптеках, дозволяє
порівнювати пропозиції, замовляти медикаменти з доставкою або самовивозом,
включно з експрес-доставкою та відправленням по Україні й у Європу [11].
Переваги:
вирішення «остання миля» для медикаментів: пошук, порівняння цін,
доставка;
широкий географічний охват, включно з міжнародною експансією;
18
опосередковане підвищення прихильності до лікування (adherence) за
рахунок полегшення доступу до ліків;
розвинуті логістичні сценарії (експрес, пошта, кур’єр тощо).
Обмеження:
сервіс не є медичною інформаційною системою чи платформою
телемедицини;
відсутні AI-модулі клінічного аналізу, CDS чи RPM;
немає прямого збору і аналізу медичних показників; працює лише з
товарами й замовленнями.
BetterMe — українська компанія, що створює цифрові продукти для здорового
способу життя: мобільні застосунки для фітнесу, харчування та ментального
здоров’я (BetterMe: Health Coaching, BetterMe: Mental Health). Компанія орієнтується
на глобальний ринок і заявляє десятки мільйонів користувачів по світу [12].
Переваги:
сильна UX/UI-складова, гейміфікація та персоналізація програм;
глобальна аудиторія, що свідчить про масштабованість рішення;
значний досвід у поведінковій аналітиці, формуванні корисних звичок,
роботі з мотивацією;
окремі соціальні й державні ініціативи (у співпраці з українськими
інституціями, міжнародними організаціями).
Обмеження:
продукт належить до сегменту wellness, а не до клінічних медичних
систем;
відсутня інтеграція з EHR/eHealth, немає статусу сертифікованої системи
підтримки клінічних рішень;
зібрані дані використовуються переважно для коучингу, а не для
формалізованих медичних протоколів.
Національна система eHealth України — це державна цифрова
інфраструктура, яка об’єднує ключові реєстри (пацієнтів, лікарів, закладів, договорів
19
з НСЗУ), електронні медичні записи, електронні рецепти та інші сервіси. Система
забезпечує обмін медичними даними через стандартизовані API, використовує
засоби криптографічного захисту та налаштована як базова «основа» для різних
медичних інформаційних систе [13].
Переваги:
національний масштаб та обов’язковість для закладів, що працюють з
НСЗУ;
стандартизація медичних даних, єдині реєстри, уніфіковані процеси;
відкриті API, що дозволяють зовнішнім системам інтегруватися з
eHealth;
акцент на безпеці, цілісності та верифікованості даних.
Обмеження:
eHealth — це базова інфраструктура, а не прикладний мобільний
застосунок для пацієнта;
система не має власного AI-рівня для клінічної аналітики, покладаючись
на зовнішні рішення;
користувацький досвід пацієнта залежить від сторонніх МІС та
застосунків, які інтегруються з eHealth.
Розглянемо порівняльну таблицю конкурентних рішень (Таблиця 1.1)
У таблиці умовно позначено: + – є/реалізовано, (+/-) – частково або
опосередковано, – – відсутнє/не є основною функцією.
У підсумку можна відзначити, що жодне з перелічених рішень не є прямим
аналогом Medical Brain / MedOglad AI у повному обсязі: кожен гравець закриває
власний «шар» цифрової медичної екосистеми (RPM, логістика ліків, телемедицина,
wellness або державна інфраструктура). Це створює вікно можливостей для стартапу,
який поєднує функції AI-підтримки клінічних рішень, дистанційного моніторингу та
зручного мобільного інтерфейсу для лікарів і пацієнтів, із глибокою інтеграцією в
національну систему eHealth.
Таблиця 1.1 – Порівняння конкурентних рішень
RPM Інтеграція з
Телемедицин Робота з
Основний AI / (дистанційн держ. Сильні Основні
Рішення Тип рішення а (відео/чат з ліками /
фокус аналітика ий eHealth (стан сторони обмеження
лікарем) логістика
моніторинг) на сьогодні)
Серцево- Лише CVD,
(+/-) Глибока
судинні (+/-) через немає
Medtech + + (AI- + (24/7 потенційна, спеціалізація
Cardiomo захворювання, клініки- – універсального
wearable двигун) ECG) не публічно , реальний
CVD- партнери застосунку для
деталізована час, AI
моніторинг всіх нозологій
Іноземне
Хронічні (+/-) Зріла
(+/-) + (+/-) через рішення,
Imagine Платформа захворювання, вбудована платформа
правила + (мультисист – проєкти потребує
Care RPM домашній взаємодія з RPM, досвід
аналітика емний RPM) інтеграції локалізації та
моніторинг клінікою у ЄС
кастомізації
(+/-) Немає AI і
Маркетплейс Пошук лікаря, опосередков Велика база RPM, в основі
+ (онлайн- (+/-) пошук/
doc.ua медичних запис, онлайн- – – ано через лікарів/кліні логістика, а не
консультації) бронювання
послуг консультації МІС к, зручність клінічна
партнерів аналітика
Відсутній
Сильна медичний
Маркетплейс Пошук і (+/-) точкова
+ (пошук і логістика, функціонал,
Liki24 + логістика доставка – – – (через
доставка) доступність немає
ліків медикаментів партнерів)
ліків моніторингу та
CDS
Wellness, а не
Фітнес, UX,
mHealth / (+/-) клінічна
харчування, гейміфікація,
BetterMe wellness- персоналі – – – – система, немає
ментальне глобальна
платформа зація EHR/eHealth
здоров’я аудиторія
інтеграції
Продовження таблиці 1.1
RPM Інтеграція з
Телемедицин Робота з
Основний AI / (дистанційн держ. Сильні Основні
Рішення Тип рішення а (відео/чат з ліками /
фокус аналітика ий eHealth (стан сторони обмеження
лікарем) логістика
моніторинг) на сьогодні)
Національна – – (залежить Інфраструктур
Стандартиза
цифрова Реєстри, EHR, (вбудова- від (+/-) через + (ядро всієї а, а не окремий
eHealth – ція, безпека,
інфраструкту- e-рецепт, дані ного AI МІС/засто- e-рецепт системи) застосунок для
масштаб
ра немає) сунків) пацієнта
1.3 Аналізу галузі за методом “5 сил Портера”
Проаналізуємо галузь цифрових медичних сервісів (eHealth, телемедицина,
мобільні медичні застосунки для медичних працівників та пацієнтів) в Україні за
методом «п’яти сил» М. Портера. Такий підхід дозволяє не лише описати поточний
стан ринку, а й оцінити привабливість галузі для нового стартапу, визначити ключові
ризики та точки зростання. Вихідною рамкою є державна політика цифрової
трансформації охорони здоров’я, закріплена на рівні урядових рішень та галузевих
програм, а також практичний досвід впровадження медичних інформаційних систем
і сервісів eHealth в закладах охорони здоров’я України [13–15].
Даний підхід охоплює такі ключові елементи аналізу:
1. Конкуренція між фірмами на цільовому ринку.
2. Потенційні нові конкуренти, які можуть з'явитися на ринку та
конкурувати з існуючими компаніями.
3. Вплив постачальників на вартість та характеристики продуктів.
4. Вплив клієнтів на їхні потреби та цінову політику продуктів.
5. Ризик заміщення продукту або послуги іншими альтернативами.
Конкуренція між наявними гравцями (галузева конкуренція).
Конкурентне поле eHealth в Україні складається з кількох груп гравців:
постачальники медичних інформаційних систем (МІС), інтегрованих із
центральною системою eHealth;
телемедичні платформи та маркетплейси медичних послуг;
сервіси дистанційного моніторингу (RPM) та вузькоспеціалізовані
рішення (наприклад, для кардіології);
міжнародні платформи, що поступово виходять на український ринок.
Державна цифрова інфраструктура створює єдине «поле гри» та задає
мінімальні вимоги до функціональності й захисту даних, але не вирівнює рівень
інноваційності окремих гравців [13; 14]. На практиці спостерігається поєднання
кількох тенденцій:
23
висока конкуренція між МІС за контракти із закладами, що працюють із
НСЗУ;
нішевість окремих стартапів (RPM, кардіомоніторинг, логістика
медикаментів), які слабо перетинаються між собою;
обмежена кількість комплексних рішень з повноцінною AI-аналітикою
та підтримкою клінічних рішень.
Для нового стартапу це означає, що конкуренція за увагу медичних закладів та
лікарів уже досить відчутна, але місце для платформи, яка об’єднає мобільний
інтерфейс, AI-аналіз, RPM і глибоку інтеграцію з eHealth, усе ще залишається.
Загроза появи нових конкурентів.
Бар’єри входу в галузь цифрової медицини мають змішаний характер. З одного
боку, розробка мобільного застосунку та базової серверної частини відносно
доступна для невеликої ІТ-команди. З іншого боку, конкурентоспроможний продукт
у медичній сфері повинен відповідати низці вимог:
дотримання стандартів захисту персональних і медичних даних,
криптографічних протоколів, вимог eHealth-інфраструктури [13];
інтеграція з центральними реєстрами, електронними рецептами та
іншими компонентами державної системи [14];
відповідність клінічним протоколам, наявність експертизи у медичній
галузі, підтверджені клінічні результати;
довіра медичних працівників і пацієнтів до нової технології, яка
формується поступово [15].
Крім регуляторних бар’єрів, важливою є потреба в капіталомісткій
інфраструктурі: хмарні потужності для обробки даних, системи безперервного
моніторингу, аналітичні модулі. Це стримує випадкових новачків, але не зупиняє
цілеспрямовані стартап-команди та міжнародні компанії, які бачать потенціал
українського ринку. У підсумку загроза появи нових конкурентів оцінюється як
середня: високі вимоги ускладнюють вхід, але привабливість сегмента AI eHealth
стимулює нові проєкти.
24
Сила постачальників.
До ключових «постачальників» для стартапу в eHealth належать:
ІТ-кадри (розробники, інженери з даних, спеціалісти з кібербезпеки,
DevOps, UI/UX-дизайнери);
медичні експерти (клініцисти, науковці, які валідовують алгоритми та
протоколи);
провайдери інфраструктури (хмарні платформи, дата-центри, телеком-
оператори);
держава як власник центральної eHealth-інфраструктури й регулятор
правил доступу до даних [13; 14].
Ринок висококваліфікованих ІТ-фахівців в Україні залишається конкурентним:
провідні спеціалісти можуть обирати між внутрішніми й міжнародними
роботодавцями, що підвищує їхню ринкову силу. Аналогічно, вузькі медичні
експерти з досвідом у цифрових проєктах є дефіцитним ресурсом. Постачальники
хмарної інфраструктури (AWS, Azure, локальні оператори) формально конкурують
між собою, але міграція між ними потребує часу й ресурсів.
Особливе місце посідає держава, яка контролює центральну базу eHealth,
визначає технічні вимоги та доступ до API. З одного боку, це обмежує маневр
приватних гравців; з іншого – забезпечує єдині правила гри та підвищує довіру до
цифрової медицини [13; 15]. Загалом сила постачальників для стартапу є середньою,
чи високою, що вимагає продуманих стратегій роботи з кадрами, інфраструктурою й
регулятором.
Сила покупців (клієнтів).
У сегменті eHealth покупцями виступають кілька груп:
держава / НСЗУ, яка опосередковано визначає попит через контракти з
закладами, вимоги до МІС та фінансові стимули;
медичні заклади й приватні клініки, що обирають конкретні цифрові
рішення для своєї роботи;
25
лікарі як користувачі, від рівня задоволеності яких залежать тривалість
контрактів і масштаб впровадження;
пацієнти, котрі використовують мобільні застосунки, телемедицину й
електронні сервіси [14; 15].
Державна політика цифровізації охорони здоров’я надає НСЗУ й МОЗ значну
переговорну силу: зміна правил контрактування або вимог до функціоналу систем
може суттєво вплинути на бізнес-моделі постачальників [13; 14]. Медичні заклади
часто мають можливість обирати між кількома МІС чи сервісами, що посилює їхню
позицію у перемовинах щодо вартості й сервісної підтримки.
З боку лікарів та пацієнтів спостерігається поступове зростання вимог до
зручності інтерфейсів, стабільності роботи та можливостей мобільного доступу, про
що свідчать матеріали щодо практики використання МІС та мобільних рішень у
повсякденній роботі [15]. Користувачі очікують від цифрових сервісів не лише
базової функціональності, а й зрозумілий «пацієнтський кабінет», історію візитів,
рецепти, нагадування, можливість дистанційної взаємодії з лікарем.
У результаті сила покупців оцінюється як висока, що вимагає від стартапу
гнучкої цінової політики, підвищеної уваги до якості продукту та клієнтського
сервісу.
Загроза товарів-замінників.
Товарами-замінниками для цифрових медичних сервісів можна вважати:
традиційну модель надання медичної допомоги без цифрових
інструментів (паперові картки, телефонні дзвінки, очні візити);
загальні ІТ-сервіси, які частково підміняють спеціалізовані рішення
(месенджери, неспеціалізовані відеоплатформи для консультацій);
зарубіжні платформи, які не інтегровані з українською eHealth-
інфраструктурою, але можуть використовуватися для окремих задач.
Попри нормативне закріплення електронної системи як основного каналу
роботи медичних закладів, досвід воєнного часу показує, що перехід назад до
паперових схем усе ще можливий у кризових ситуаціях [15]. Це свідчить про
26
наявність «інерційної» альтернативи цифровій моделі. Використання загальних
месенджерів для консультацій або обміну медичною інформацією формально
заборонене або обмежене з міркувань безпеки, але в реальній практиці все ще
зустрічається.
Водночас, із розвитком державної eHealth-інфраструктури та посиленням
вимог до захисту даних можливості для неформальних замінників поступово
звужуються [13; 14]. Таким чином, загроза товарів-замінників оцінюється як
середня: альтернативи існують, але регуляторні й безпекові обмеження поступово
знижують їхню конкурентоспроможність.
Нижче подано кількісну оцінку загроз за всіма п’ятьма силами Портера,
виконану за шкалою:
1–3 — низький вплив,
4–7 — середній вплив,
8–10 — високий вплив.
Оцінювання здійснено для ринку eHealth / мобільних медичних застосунків в
Україні, з урахуванням регуляторного середовища, структури конкуренції та
специфіки цифрової трансформації медицини.
1. Конкуренція між наявними гравцями.
Оцінка: 7 / 10 — середній (наближений до високого) вплив.
Обґрунтування:
значна кількість нішевих продуктів (МІС, телемедицина, RPM,
marketplace-рішення);
відсутність єдиної домінуючої платформи, але помітні локальні лідери;
конкуренція за державні контракти та взаємодію з НСЗУ;
підсилення ролі UX і швидкості впровадження.
Висновок: галузева конкуренція суттєва, але ще достатньо простору для
інноваційних AI-рішень.
2. Загроза появи нових конкурентів.
Оцінка: 5 / 10 — середній вплив.
27
Обґрунтування:
ринок привабливий для стартапів та іноземних компаній;
водночас високі бар’єри входу: регуляція (eHealth), відповідність
клінічним протоколам, вимоги до безпеки, необхідність AI- і медичної
експертизи;
значні витрати на валідацію алгоритмів і технологічну інфраструктуру.
Висновок: загроза нових учасників існує, однак регуляторні та технологічні
бар’єри її стримують.
3. Сила постачальників.
Оцінка: 8 / 10 — високий вплив.
Обґрунтування:
дефіцит кваліфікованих ІТ-фахівців і медичних експертів;
залежність від постачальників хмарних рішень;
держава контролює доступ до центрального сегмента eHealth, API та
регламентів;
зміна вимог або тарифів МІС може впливати на бізнес-модель будь-якого
стартапу.
Висновок: сила постачальників є значною, оскільки ринок критично залежить
від фахівців, інфраструктури та державних правил.
4. Сила покупців (держави, медичних закладів, лікарів і пацієнтів).
Оцінка: 9 / 10 — високий вплив.
Обґрунтування:
держава (НСЗУ, МОЗ) формує вимоги до цифрових сервісів;
заклади охорони здоров’я можуть обирати між кількома МІС і
телемедичними платформами;
лікарі очікують зручних сценаріїв роботи та мінімального навантаження;
пацієнти чутливі до зручності, швидкості, прозорості сервісів та захисту
даних.
28
Висновок: покупці мають надзвичайно сильні переговорні позиції й
визначають успішність впровадження продукту.
5. Загроза товарів-замінників.
Оцінка: 6 / 10 — середній вплив.
Обґрунтування:
традиційні форми взаємодії (очні візити, паперові картки, телефонні
дзвінки) все ще поширені;
можливість використання неспеціалізованих інструментів (месенджери,
відеозв’язок);
wellness-додатки частково підміняють базові функції;
під час кризових ситуацій можливе повернення до офлайн-форм роботи.
Висновок: замінники є, але вони лише частково перекривають
функціональність медичного AI-застосунку.
Далі представлено узагальнену таблицю оцінки п’яти сил Портера.
Таблиця 1.2 – Кількісні оцінки загроз за всіма п’ятьма силами Портера
Оцінка Рівень Коротка
Конкурентна сила
(1–10) впливу характеристика
Конкуренція між Середній – Наявні нішеві рішення, сильні
7
наявними гравцями високий локальні конкуренти.
Загроза нових Бар’єри входу стримують нових
5 Середній
конкурентів учасників.
Дефіцит кадрів, залежність від
Сила постачальників 8 Високий
eHealth і хмарних сервісів.
Держава, клініки й пацієнти
Сила покупців 9 Високий
визначають успіх продукту.
Офлайн-альтернативи та
Загроза товарів-
6 Середній неспеціалізовані інструменти
замінників
зберігають позиції.
Загальна структура галузі eHealth в Україні характеризується високою силою
покупців та значним впливом постачальників, що підвищує вимоги до якості,
безпеки й відповідності державним стандартам. У той же час загроза нових
конкурентів і замінників залишається помірною, що відкриває перспективи для
29
інноваційних AI-продуктів, здатних об’єднати мобільний інтерфейс, клінічну
аналітику та інтеграцію з eHealth.
Для системного узагальнення результатів аналізу конкурентного середовища
доцільно звести оцінки всіх п’яти сил М. Портера в єдину структуру. Така
інтегрована форма дозволяє порівняти інтенсивність впливу окремих факторів на
розвиток стартапу у сфері eHealth, визначити найбільш критичні з них та
сформувати комплексне уявлення про привабливість галузі (Таблия 1.3).
Таблиця 1.3 – Узагальнений аналіз галузі за моделлю «5 сил Портера»
Конкурентна Рівень Ключові Наслідки
сила впливу фактори для стартапу
1. Конкуренція Середній– Фрагментований ринок; Потрібна чітка
між наявними високий значна кількість нішевих диференціація (AI-
гравцями рішень (МІС, телемедицина, аналітика, RPM,
RPM); відсутність мобільний інтерфейс,
домінуючої платформи; інтеграція з eHealth);
регуляторні вимоги. необхідність
забезпечення високої
якості продукту.
2. Загроза появи Середній Високі бар’єри входу: Бар’єри створюють
нових регуляція, інтеграція з певний захист, але
конкурентів eHealth, компетенції в ІТ і галузь залишається
медицині; одночасно — привабливою; стартапу
зростання інтересу до AI потрібні ресурси для
eHealth. швидкої валідації та
відповідності
стандартам.
3. Сила Середній– Дефіцит Необхідні стратегії
постачальників високий висококваліфікованих ІТ- утримання талантів,
спеціалістів; потреба у оптимальний вибір
медичних експертах; технологічної
залежність від хмарних інфраструктури,
провайдерів; контроль побудова партнерств з
державою доступу до клінічними
eHealth API. експертами.
4. Сила покупців Високий Держава формує політику Необхідні гнучка
(держави, клінік, цифровізації й вимоги до цінова політика,
лікарів, пацієнтів) МІС; медичні заклади мають прозора комунікація,
змогу обирати між розвиток підтримки.
30
Конкурентна Рівень Ключові Наслідки
сила впливу фактори для стартапу
альтернативами; зростання користувачів; фокус на
очікувань лікарів і пацієнтів UX та клінічній
щодо зручності сервісів. корисності.
5. Загроза товарів- Середній Традиційні офлайн-процеси; Стартап має показати
замінників неформальне використання переваги офіційних
месенджерів; наявність цифрових каналів:
загальних ІТ-рішень без безпека даних, точність
медичної спеціалізації; аналітики, інтеграція з
проте підсилення eHealth- національними
стандартів знижує реєстрами.
можливість замінників.
Проведений аналіз галузі за моделлю «п’яти сил» Портера показує, що ринок
цифрової медицини в Україні знаходиться на етапі активної трансформації та
характеризується поєднанням значних можливостей і суттєвих викликів для нових
учасників. Найбільш впливовими факторами виступають сила покупців та позиція
постачальників, що зумовлено високими вимогами до якості цифрових медичних
сервісів, необхідністю відповідності регуляторним нормам і залежністю від
кваліфікованих ІТ- і медичних фахівців. Конкуренція між наявними гравцями є
відчутною, однак ринок залишається фрагментованим, що створює простір для
інноваційних рішень, здатних об’єднати функції телемедицини, аналітики та
дистанційного моніторингу.
Загроза появи нових конкурентів та вплив товарів-замінників оцінюються як
середні, що свідчить про наявність природних бар’єрів входу й водночас —
життєздатність альтернативних форм медичної взаємодії. У сукупності ці чинники
формують середньо-високий рівень конкурентного тиску, який вимагає від
майбутнього стартапу чіткої диференціації, технологічної складності, відповідності
стандартам eHealth та орієнтації на користувацьку зручність. Таким чином, галузь є
перспективною, проте потребує зваженого стратегічного підходу та побудови стійкої
бізнес-моделі.
31
1.4 SWOT-аналіз
SWOT-аналіз є одним із найпоширеніших інструментів стратегічного
оцінювання, що дає змогу системно розглянути внутрішній потенціал галузі або
проєкту та зовнішні чинники, які впливають на його розвиток. Метод передбачає
поділ характеристик на чотири групи:
S (Strengths) — внутрішні сильні сторони, які забезпечують конкурентні
переваги;
W (Weaknesses) — внутрішні слабкі сторони та обмеження;
O (Opportunities) — зовнішні можливості, що відкривають перспективи
розвитку;
T (Threats) — зовнішні загрози, що можуть ускладнювати діяльність або
зменшувати ефективність реалізації проєкту [17].
У сфері eHealth SWOT-аналіз дозволяє врахувати взаємодію медичних,
технологічних, нормативно-правових та соціальних чинників, які визначають
успішність створення мобільних медичних платформ. З огляду на специфіку
українського ринку, він є критично важливим для оцінювання потенціалу таких
систем і формування стратегічних пріоритетів цифрової трансформації охорони
здоров’я [18].
SWOT-аналіз галузі створення мобільного застосунку для медичних
працівників та пацієнтів
S — Сильні сторони
1. Наявність державної цифрової інфраструктури eHealth. Центральні реєстри,
електронні медичні записи та стандартизовані API створюють стабільну
основу для інтеграції мобільних рішень із національною системою охорони
здоров’я [17].
2. Зростання попиту на дистанційні медичні послуги. Телемедицина та мобільні
сервіси стали невід’ємною частиною доступу до медичної допомоги, що
особливо проявилося в умовах пандемії та воєнного стану [18].
32
3. Високий рівень розвитку українського ІТ-сектора. Наявність кваліфікованих
спеціалістів і досвід реалізації масштабних цифрових проєктів створюють
підґрунтя для технологічно складних рішень у медичній сфері.
4. Можливість об’єднання медичних даних з AI-аналітикою. Використання
алгоритмів підтримки клінічних рішень здатне покращити діагностику,
моніторинг і персоналізоване планування лікування [19].
5. Підтримка міжнародних організацій та донорських програм. Цифрова
медицина входить до пріоритетів реформування сектору, що забезпечує
додаткові ресурси та експертизу [20].
W — Слабкі сторони
1. Нерівномірний рівень цифрової готовності закладів охорони здоров’я. Частина
медичних установ використовує застаріле обладнання або не має повноцінної
IT-інфраструктури, що ускладнює впровадження мобільних сервісів [17].
2. Фрагментація ринку eHealth. На ринку існує багато несумісних рішень, що
ускладнює міжсистемну інтеграцію та створює додаткові технічні бар’єри [18].
3. Обмежений доступ до клінічних даних для розробки AI-моделей. Високі
вимоги до захисту інформації та відсутність широких датасетів для навчання
знижують темп розвитку інтелектуальних функцій у мобільних застосунках
[19].
4. Недостатня цифрова грамотність частини лікарів і пацієнтів. Це обмежує
швидкість масштабування нових мобільних сервісів та потребує додаткових
навчальних заходів [20].
5. Висока вартість сертифікації та забезпечення відповідності законодавству.
Медичні програми повинні відповідати вимогам щодо обробки персональних
даних та клінічної безпеки, що ускладнює вихід на ринок [15].
O — Можливості
1. Розширення функціоналу мобільної телемедицини. Попит на онлайн-
консультації та цифровий супровід пацієнта стимулює розвиток мобільних
платформ [17].
33
2. Інтеграція з носимими пристроями та домашніми моніторами. Розвиток IoT
дозволяє збирати дані в режимі реального часу, забезпечуючи безперервний
моніторинг клінічних показників [19].
3. Створення персоналізованих медичних сервісів на основі AI. Алгоритми
машинного навчання можуть формувати індивідуальні рекомендації,
оцінювати ризики та автоматизувати частину рутинних задач лікаря [20].
4. Зміцнення міжнародної співпраці в рамках програм цифрової трансформації.
Україна отримує підтримку від міжнародних інституцій у сфері модернізації
охорони здоров’я, що відкриває нові інноваційні можливості [18].
5. Загальна тенденція до переходу від паперових процесів до електронних.
Цифровізація медичних закладів створює сприятливе середовище для
поширення мобільних сервісів [21].
T — Загрози
1. Посилення конкуренції з боку міжнародних платформ. Глобальні компанії
можуть працювати в Україні, пропонуючи більш масштабні рішення з
більшими ресурсами [17].
2. Регуляторні ризики та зміни в законодавстві. Корегування вимог щодо eHealth,
електронних медичних записів, обробки даних може вплинути на бізнес-
модель мобільного застосунку [18].
3. Висока сила покупців: держава, НСЗУ, медичні заклади. Зміни у механізмах
контрактування чи вимогах до цифрових сервісів можуть знижувати
комерційну привабливість проєктів [20].
4. Можливість використання замінників — від телефонних консультацій до
месенджерів. Такі альтернативи можуть частково замінити функціональність
мобільної медичної платформи, особливо у некритичних сценаріях [15].
5. Кризові умови (війна, перебої енергопостачання, кіберзагрози). Зовнішні
фактори можуть впливати на стабільність цифрових сервісів та доступність
інтернет-інфраструктури [19].
Для системного представлення результатів SWOT-аналізу доцільно
узагальнити виявлені сильні та слабкі сторони, а також зовнішні можливості й
34
загрози у форматі структурованої таблиці. Така форма дозволяє наочно порівняти
внутрішній потенціал галузі та зовнішні впливи, визначити ключові точки зростання
та ризики, а також забезпечує зручну основу для формування стратегії розвитку
мобільного застосунку. Подана нижче таблиця 1.4 відображає інтегровану картину
чинників, що впливають на створення та впровадження цифрових медичних рішень
в Україні.
Таблиця 1.4 – Розширена SWOT-таблиця галузі створення мобільного медичного
застосунку
Характеристика
Категорія Ключові фактори
впливу на галузь
Забезпечує єдині реєстри, стандартизовані
Наявність державної
API та централізовану інфраструктуру, що
системи eHealth
спрощує інтеграцію мобільних сервісів.
Пацієнти та медики зацікавлені у
Зростання попиту на швидкому доступі до медичної допомоги,
телемедицину дистанційних консультаціях та
моніторингу стану здоров’я.
Наявність кваліфікованих інженерів,
Розвинений досвіду роботи з великими даними та
український ІТ-сектор високий рівень цифрової компетентності
команд.
Можливість AI дозволяє підвищувати точність
використання AI- діагностики, прогнозування та
аналітики персоналізувати медичні рекомендації.
Ініціативи з цифровізації охорони
Підтримка
здоров’я підтримуються державними та
міжнародних програм
міжнародними партнерами.
Нерівномірна ІТ- Частина установ використовує застарілу
готовність медичних інфраструктуру, що ускладнює
закладів впровадження мобільних рішень.
Велика кількість несумісних платформ
Фрагментація ринку
знижує ефективність інтеграції та
eHealth
стандартизації процесів.
Необхідність дотримання суворих норм
Високі вимоги до
щодо конфіденційності збільшує витрати
захисту даних
на розробку та сертифікацію.
W — Слабкі сторони S — Сильні сторони
35
Продовження таблиці 1.4
Характеристика
Категорія Ключові фактори
впливу на галузь
Недостатня кількість спеціалістів, здатних
Дефіцит експертів у
працювати з медичними даними та
медичній аналітиці
клінічними моделями.
Низька цифрова Ускладнює швидке впровадження
грамотність частини мобільних рішень серед лікарів і
користувачів пацієнтів.
Розширення Зростаюча потреба в онлайн-
функціоналу консультаціях створює попит на мобільні
телемедичних сервісів платформи нового покоління.
Носимі датчики та домашні монітори
Інтеграція з IoT-
дозволяють створювати комплексні
пристроями
системи дистанційного спостереження.
Персоналізована Активний розвиток ML-алгоритмів
медицина та AI- дозволяє створювати індивідуальні плани
рішення лікування та тріаж-системи.
Доступ до фінансування, експертизи та
Участь у міжнародних
технологій для швидшого розвитку
проєктах
продуктів.
Поступовий відхід від Зростає попит на електронні сервіси та
паперових процесів зручні мобільні інструменти.
Конкуренція з боку
Глобальні компанії мають великі ресурси
міжнародних
та можуть швидко зайняти частину ринку.
платформ
Зміни у сфері eHealth або захисту даних
Регуляторні зміни та
можуть впливати на функціонування
правові обмеження
продукту.
НСЗУ, медзаклади, лікарі та пацієнти
Висока сила покупців формують жорсткі вимоги до функцій та
якості сервісів.
Месенджери та телефонні консультації
Альтернативні канали
зменшують потребу в спеціалізованих
взаємодії
застосунках.
Перебої з електроживленням, інтернетом
Військові та кризові або кіберзагрози можуть тимчасово
ризики знижувати доступність мобільних
сервісів.
T — Загрози O — Можливості
36
Проведений SWOT-аналіз демонструє, що галузь створення мобільних
застосунків для медичних працівників і пацієнтів має значний потенціал розвитку
завдяки поєднанню державної цифрової інфраструктури, зростаючого попиту на
дистанційні медичні послуги та високої технологічної зрілості українського ІТ-
сектору. Водночас її розвиток стримується фрагментованістю ринку, високими
регуляторними вимогами, дефіцитом експертів у сфері медичних даних та
нерівномірною цифровою готовністю медичних закладів. Серед зовнішніх
можливостей найбільш перспективними є інтеграція з IoT-пристроями, розвиток
персоналізованої медицини та участь у міжнародних програмах цифровізації.
Загрози стосуються посилення конкуренції, правових обмежень та кризових
факторів, які можуть впливати на стабільність системи.
Отже, галузь має високий стратегічний потенціал, але потребує зваженої
моделі впровадження, чіткої диференціації продукту та дотримання державних
стандартів у сфері цифрової медицини.
1.5 Особливості управління в галузі цифрових медичних сервісів
Управління проєктами в сфері цифрової медицини має низку характерних
особливостей, що зумовлені поєднанням технологічної складності, високих вимог
до безпеки даних та необхідністю дотримання медичних протоколів. На відміну від
класичних ІТ-проєктів, реалізація eHealth-рішень передбачає одночасну взаємодію з
державними інституціями, медичними закладами, фахівцями клінічних
спеціальностей та кінцевими користувачами — лікарями й пацієнтами. Це формує
специфічне управлінське середовище, у якому повинні поєднуватись стандарти ІТ-
галузі та вимоги системи охорони здоров’я [21].
Однією з ключових рис управління такими проєктами є залежність від
державної цифрової інфраструктури eHealth. Центральні реєстри, електронні
медичні записи, електронний рецепт і механізми аутентифікації створюють рамку, в
межах якої мають функціонувати всі медичні застосунки. Будь-який проєкт з
мобільної медицини повинен забезпечувати технічну сумісність з вимогами
37
Міністерства охорони здоров’я та НСЗУ, що визначає суворі стандарти інтеграції,
захисту даних і процесів обміну інформацією [22]. Невідповідність цим вимогам
унеможливлює використання продукту в закладах охорони здоров’я та обмежує
масштаби впровадження.
Важливою особливістю є й потреба у медичній експертизі. Розробники
мобільних застосунків повинні залучати лікарів, клінічних аналітиків і фахівців із
медичних даних як на етапі проєктування, так і під час тестування. Саме ці експерти
визначають алгоритми клінічної безпеки, протоколи моніторингу пацієнтів,
структуру медичних записів та сценарії взаємодії користувачів. Досвід українських
проєктів телемедицини свідчить, що наявність мультидисциплінарних команд є
одним із ключових факторів успішної реалізації [23].
Ще однією специфічною рисою є регламентованість обробки медичних даних.
Медична інформація належить до категорії особливо чутливих даних, тому
розробники повинні забезпечити шифрування, надійні механізми доступу, аудит
операцій та відповідність нормативно-правовим актам. Українські дослідження
показують, що неналежне управління інформаційною безпекою є одним із основних
бар’єрів у масштабуванні цифрових медичних продуктів, особливо в частині
мобільних платформ [24]. Тому управління ризиками та захистом даних повинно
бути інтегровано в усі фази життєвого циклу проєкту.
Особливістю eHealth-проєктів є також необхідність формування
користувацької довіри. Мобільні застосунки для лікарів і пацієнтів мають вплив на
реальні клінічні рішення, тому від них очікують стабільності, інтуїтивності,
коректності рекомендацій та відповідності практичним медичним процесам.
Дослідження цифрової взаємодії в українській медичній сфері демонструють, що
рівень прийняття технологій значною мірою залежить від того, наскільки зручно
працювати із застосунком у повсякденних клінічних сценаріях [25]. Це зумовлює
потребу у ретельному UX-проєктуванні, комплексному тестуванні та підготовці
користувачів.
Управління проєктами в телемедицині та мобільній медицині також вимагає
врахування етичних аспектів: відповідальність за автоматизовані рекомендації,
38
прозорість алгоритмів, відповідність клінічним протоколам та недопущення
дискримінації при аналізі даних. Проєктні команди повинні передбачати механізми
пом’якшення ризиків, перевірки алгоритмічної коректності та регулярного перегляду
моделей.
Загалом управління проєктами у галузі цифрової медицини ґрунтується на
поєднанні класичних підходів (Agile, SCRUM, PMBOK) та медичних стандартів
роботи, включно з клінічними протоколами, вимогами eHealth та безпековими
регламентами. Успішність проєкту визначається здатністю забезпечити високу якість
програмного продукту, відповідність нормативній базі, безпечну роботу з медичними
даними й тісну співпрацю з медичними закладами та державними структурами.
З огляду на специфіку цифрових медичних сервісів, управління проєктами в
цій галузі охоплює взаємопов’язані технологічні, клінічні, організаційні та
регуляторні аспекти. Комплексність таких рішень вимагає поєднання стандартів ІТ-
менеджменту з особливостями медичної практики, вимогами до захисту даних і
залежністю від центральної eHealth-інфраструктури. Для узагальнення ключових
характеристик було проведено систематизування основних особливостей управління
проєктами в форматі аналітичної таблиці 1.5, яка допомагає відобразити їхню
сутність та управлінські наслідки.
Таблиця 1.5 – Особливості управління проєктами в галузі цифрових медичних
сервісів
Управлінські
№ Особливість Сутність
наслідки
Залежність Проєкт має працювати в Необхідність суворої відповідності
від державної межах визначених технічним стандартам, інтеграційним
цифрової державою реєстрів, вимогам та нормативним регламентам
1
інфраструкту протоколів обміну МОЗ і НСЗУ
ри eHealth даними та вимог
сумісності
Потреба у Для розробки та Формування мультидисциплінарної
клінічній тестування залучаються команди, додаткові ресурси на
2 експертизі лікарі, медичні медичний консалтинг, необхідність
аналітики, фахівці із клінічної валідації рішень
клінічних протоколів
39
Продовження таблиці 1.5
Управлінські
№ Особливість Сутність
наслідки
Підвищені Дані про здоров’я Пріоритет інформаційної безпеки,
вимоги до належать до категорії впровадження криптографії, аудит
3 захисту особливо чутливих і доступів, додаткові витрати на
медичних регулюються окремими відповідність законодавству
даних нормами
Необхідність Сервіси впливають на Посилений акцент на тестуванні,
високої ухвалення медичних резервуванні, безвідмовності та якості
надійності та рішень та використання користувацького досвіду
4
стабільності у критичних ситуаціях
роботи
системи
Залежність Рівень цифрової Потреба у навчальних програмах,
від цифрової грамотності адаптації UX/UI, поетапному
готовності користувачів впливає на впровадженні та підтримці
5
медичних прийняття технології та користувачів
працівників і швидкість її поширення
пацієнтів
Складна Наявність різних МІС, Високі вимоги до архітектури, API,
міжсистемна телемедичних платформ модульності, масштабованості та
6 інтеграція і пристроїв потребує тестування інтеграцій
сумісності з багатьма
технологіями
Регуляторні Сфера регулюється Необхідність постійного моніторингу
та етичні клінічними законодавчих змін, впровадження
7 обмеження протоколами, нормами політик етичності й відповідальності
обробки даних і
вимогами до безпеки
Вплив Можливі перебої Розробка стратегій забезпечення
зовнішніх зв’язку, стійкості, аварійного відновлення та
факторів електроживлення або гнучких операційних моделей
8
(кризи, війна, кіберзагрози
інфраструкту
рні ризики)
Управління проєктами в сфері цифрових медичних сервісів має комплексний
характер і суттєво відрізняється від класичних ІТ-проєктів. Основними чинниками,
що визначають специфіку цієї галузі, є інтеграція з державною eHealth-
інфраструктурою, суворі вимоги до захисту медичних даних, необхідність залучення
40
клінічних експертів та забезпечення високої надійності сервісів. Важливу роль
відіграє й поведінковий аспект: рівень цифрової грамотності лікарів і пацієнтів
впливає на прийняття продукту та ефективність його використання.
Поєднання цих факторів формує складне управлінське середовище, яке
вимагає мультидисциплінарного підходу, системного планування, гнучких
методологій та безперервного моніторингу нормативно-правових змін. Успішність
таких проєктів залежить від здатності інтегрувати технологічні можливості з
медичними потребами, забезпечити інформаційну безпеку та створити зручний,
надійний і клінічно обґрунтований цифровий продукт.
Висновки до розділу 1
У першому розділі проведено всебічний аналіз галузі цифрових медичних
сервісів та окреслено умови функціонування проєкту мобільного застосунку для
медичних працівників і пацієнтів. Встановлено, що ринок eHealth в Україні
динамічно розвивається під впливом цифровізації охорони здоров’я, поширення
телемедицини та зростання попиту на дистанційний моніторинг і аналітичні
інструменти. Державна інфраструктура eHealth, стандартизовані реєстри та
електронні медичні записи створюють сприятливе підґрунтя для появи інноваційних
мобільних рішень.
Конкурентний аналіз засвідчив наявність різнопрофільних локальних і
міжнародних сервісів, однак відсутність комплексних платформ відкриває простір
для продуктів із розширеною аналітикою та глибокою інтеграцією з eHealth. Модель
Портера вказує на високий вплив покупців, помітну роль постачальників та середню
загрозу нових конкурентів і товарів-замінників.
SWOT-аналіз підтвердив сильні сторони галузі, серед яких — технологічна
готовність, попит на цифрові послуги та можливість використання AI, а також
окреслив слабкі сторони, пов’язані з фрагментацією ринку, вимогами до безпеки та
потребою в клінічній експертизі. Разом із визначеними можливостями
(персоналізація, IoT, міжнародні програми) та зовнішніми загрозами (регуляторні й
41
конкуренційні ризики), ці фактори формують стратегічний контекст розвитку
мобільних медичних рішень.
Узагальнення особливостей управління проєктами показало необхідність
дотримання державних стандартів eHealth, мультидисциплінарного підходу, високої
надійності сервісу та орієнтації на потреби лікарів і пацієнтів. Отримані результати
створюють обґрунтовану основу для наступних етапів розробки та проєктування
мобільного медичного застосунку.
42
2 ФОРМУВАННЯ ЗАДУМУ СТАРТАПУ ТА РОЗРОБКА КОНЦЕПЦІЇ
2.1 Аналіз оточення стартапу
Аналіз зовнішнього середовища для стартапу «МедОгляд AI» є критично
важливим, оскільки проєкт працює на стику кількох чутливих сфер: цифрової
медицини, обробки персональних медичних даних та інтеграції з державною
eHealth-інфраструктурою. Сервіс, що пропонує попередній аналіз симптомів,
формування рекомендацій щодо подальших дій пацієнта та підтримку лікаря під час
прийняття рішень, опиняється в полі дії не лише ринкових факторів, але й державної
політики, нормативного регулювання, етичних вимог та технічних стандартів.
Україна вже кілька років послідовно реалізує курс на цифрову трансформацію
системи охорони здоров’я, розбудовуючи електронну систему охорони здоров’я
(eHealth / ЕСОЗ), центральну базу даних, медичні інформаційні системи та
супровідні сервіси. Ці процеси закріплені в офіційних документах і методичних
матеріалах МОЗ України, де eHealth розглядається як ключовий інструмент
підвищення прозорості, якості та керованості медичної сфери [27; 28; 31].
Водночас відбувається активне обговорення та практичне впровадження
рішень на основі штучного інтелекту в клінічній медицині, діагностиці,
телемедицині та освітньому процесі, де українські дослідники наголошують на
потенціалі таких технологій та ризиках, пов’язаних із етикою, безпекою та правовою
відповідальністю [29; 30]. У цих умовах PESTEL-аналіз дає змогу комплексно
оцінити середовище функціонування «МедОгляду AI» та використати результати для
налаштування бізнес-моделі, архітектури рішення та стратегії його впровадження в
екосистему цифрової охорони здоров’я України.
P — Політичні чинники
На політичному рівні «МедОгляд AI» працює в середовищі, де цифровізація
охорони здоров’я проголошена одним із системних пріоритетів держави. МОЗ
України у своїх матеріалах окреслює цифрову трансформацію як довгостроковий
43
процес, що включає створення єдиної цифрової медичної платформи, інтеграцію
медичних інформаційних систем, розбудову eHealth та використання даних для
управлінських рішень [27; 31]. Це формує сприятливий політичний фон для появи
стартапів, які можуть «вбудовуватися» у вже наявну цифрову інфраструктуру.
Важливим політичним чинником є також воєнний контекст. В умовах
повномасштабної агресії держава паралельно вирішує завдання підтримки стійкості
системи охорони здоров’я, забезпечення безперервності надання медичної допомоги
та розвитку телемедицини. Це робить сервіси дистанційної взаємодії з пацієнтом,
попереднього сортування звернень та моніторингу стану здоров’я ще більш
затребуваними, особливо для територій з обмеженим доступом до медичних
закладів.
Політичні ризики для «МедОгляду AI» пов’язані з можливими змінами
пріоритетів державної політики, оновленням регуляторних актів, що стосуються
eHealth та обігу медичних даних, а також із залежністю від рішень щодо технічних
стандартів та інтероперабельності на рівні МОЗ та НСЗУ [28; 31]. Водночас курс на
інтеграцію з європейськими підходами до цифрової медицини та статистики
охорони здоров’я створює вікно можливостей для рішень, сумісних з міжнародними
стандартами та практиками.
E — Економічні чинники
З економічної точки зору стартап працює в системі, де триває реформування
фінансування медицини, запроваджений механізм оплати за медичні послуги через
НСЗУ, а цифрові сервіси розглядаються як засіб підвищення ефективності
використання бюджетних коштів [31]. Цифрова трансформація, зокрема
впровадження eHealth, за результатами українських досліджень, розглядається як
фактор, що дозволяє підвищувати якість управлінських рішень, покращувати
прозорість фінансових потоків і зменшувати транзакційні витрати у системі охорони
здоров’я [31].
Для «МедОгляду AI» це створює декілька економічних можливостей:
опосередковане зниження витрат закладів охорони здоров’я.
Автоматизація збору анамнезу, попередня оцінка симптомів і пріоритизація
44
звернень дають змогу зменшити навантаження на лікарів, скоротити час
прийому та оптимізувати черги;
підвищення цінності даних. У міру розвитку eHealth зростає попит на
аналітичні сервіси, які можуть використовувати знеособлені медичні дані для
прогнозування навантаження, аналізу якості послуг, виявлення
закономірностей у стані здоров’я населення;
ринки B2G та B2B. Потенційними клієнтами «МедОгляду AI» стають не
лише окремі медичні заклади, а й керуючі компанії, страхові організації,
оператори телемедичних платформ, а в перспективі — державні замовники в
межах пілотних або інноваційних проєктів.
Водночас економічні ризики включають нестабільність макроекономічної
ситуації, обмежені інвестиційні ресурси, конкуренцію з боку міжнародних рішень,
що виходять на український ринок, а також залежність від того, наскільки швидко
заклади охорони здоров’я готові інвестувати в цифрові сервіси, що не є
безпосередньо «обов’язковою» частиною державних програм.
S — Соціальні чинники
Соціальний контекст для eHealth-рішень в Україні є неоднорідним. З одного
боку, спостерігається зростання цифрової грамотності населення, активне
використання смартфонів, довіра до електронних сервісів і готовність пацієнтів
взаємодіяти з медичною системою через онлайн-канали. З іншого — зберігаються
суттєві відмінності між регіонами, віковими групами та соціальними категоріями
щодо доступу до інтернету, рівня цифрових навичок та ставлення до обробки
персональних даних.
Рішення на основі штучного інтелекту в медицині, як показують українські
наукові та публіцистичні матеріали, викликають одночасно інтерес і настороженість:
з одного боку, пацієнти очікують швидших і точніших діагностичних рішень, з
іншого — побоюються «знеособлення» медицини, помилок алгоритмів і витоку
конфіденційної інформації [29; 30].
Для «МедОгляду AI» це означає, що:
45
необхідно формувати довіру до сервісу через прозоре пояснення логіки
роботи алгоритмів, зрозумілі інтерфейси та чітке розмежування
відповідальності між ШІ та лікарем;
важливо акцентувати, що сервіс не замінює клінічне рішення, а
допомагає структуровано підготувати візит, зменшити ризик втрати важливої
інформації та підтримати пацієнта між консультаціями;
слід враховувати різний рівень цифрової грамотності — передбачити
адаптивні сценарії для користувачів із базовими навичками та інтеграцію через
знайомі канали (наприклад, мобільний додаток клініки або веб-портал
eHealth).
Соціальним ресурсом є також готовність медичної спільноти залучатися до
пілотних проєктів з використання ШІ, особливо там, де він допомагає зменшувати
рутинне документування та вивільняє час лікаря для безпосереднього спілкування з
пацієнтом [30].
T — Технологічні чинники
Технологічне середовище для «МедОгляду AI» визначається двома ключовими
складовими:
1) наявністю розбудованої державної eHealth-інфраструктури;
2) станом розвитку та прийняттям технологій штучного інтелекту в
українській медицині.
Офіційні матеріали МОЗ описують інформаційну екосистему електронної
охорони здоров’я України як багаторівневу систему, що включає центральну базу
даних, медичні інформаційні системи, реєстри, модулі аналітики та низку супутніх
сервісів [28]. Наголошується на тому, що eHealth має забезпечувати
інтероперабельність з іншими державними реєстрами, підтримувати єдині стандарти
кодування та обміну медичними даними [31].
Для стартапу це означає, що технологічна архітектура «МедОгляду AI» має:
відповідати вимогам до інтеграції з ЕСОЗ (через визначені API, формат
даних, стандарти безпеки);
46
забезпечувати масштабованість та резервування, оскільки сервіс працює
з критично важливою інформацією та повинен бути доступний навіть у
періоди пікових навантажень;
враховувати обмеження інфраструктури окремих закладів охорони
здоров’я (нестабільний інтернет, різний рівень технічного оснащення).
З погляду ШІ, українські дослідження відзначають, що впровадження
алгоритмів машинного навчання, комп’ютерного зору та інших інструментів ШІ вже
відбувається у різних галузях медицини — від кардіології до лабораторної
діагностики, і демонструє потенціал підвищення точності діагностики та оптимізації
навантаження на лікарів [29]. Окремі роботи фокусуються саме на українському
контексті, підкреслюючи можливості ШІ для підтримки клінічних рішень,
моніторингу пацієнтів, дистанційного навчання та телемедицини в умовах воєнного
часу [30].
Для «МедОгляду AI» технологічні чинники водночас відкривають можливості
і створюють виклики:
з’являється шанс використовувати найкращі практики цифрової
медицини, поєднуючи дані eHealth з алгоритмами ШІ;
потрібно забезпечити простежуваність рішень ШІ (explainable AI), що
особливо важливо в клінічному контексті;
необхідно будувати кіберзахист відповідно до рекомендацій МОЗ щодо
кібербезпеки цифрових медичних систем [28; 31].
E — Екологічні чинники
Хоча для медичного стартапу екологічний вимір не є настільки очевидним, він
набуває значення у кількох аспектах.
По-перше, дистанційні сервіси, які дозволяють частину звернень
опрацьовувати онлайн, опосередковано зменшують потребу в поїздках до закладів
охорони здоров’я, що скорочує транспортні викиди. Для пацієнтів із хронічними
хворобами або тих, хто мешкає далеко від медичних центрів, це має не лише
екологічний, а й соціальний ефект — економію часу та ресурсів.
47
По-друге, цифровізація медичної документації, стимульована розвитком
eHealth, зменшує обсяг паперового документообігу, що відповідає загальним
трендам «зеленої» цифрової трансформації, які фіксуються в українських
дослідженнях щодо модернізації державного управління і медичної сфери [31].
По-третє, варто враховувати й екологічний слід дата-центрів та ІТ-
інфраструктури, яка забезпечує роботу «МедОгляду AI». Хоча це питання
здебільшого виходить за межі безпосередніх рішень стартапу, вибір хмарних
провайдерів, політика з енергоефективності та оптимізація обчислювальних задач
(наприклад, легші моделі для inference) можуть стати частиною стратегії
корпоративної соціальної відповідальності.
L — Правові чинники
Правове середовище є одним із найбільш чутливих для стартапу «МедОгляд
AI», оскільки він працює з персональними медичними даними, які належать до
категорії особливо чутливої інформації. На національному рівні питання
електронної охорони здоров’я, структури та принципів функціонування ЕСОЗ, а
також інтеграції з іншими державними реєстрами деталізуються в концептуальних і
нормативних документах, що визначають рамки розвитку eHealth [27; 28; 31].
Для «МедОгляду AI» ключовими є такі правові аспекти:
захист персональних даних. Необхідність дотримання законодавства
щодо обробки персональних та медичних даних, отримання інформованої
згоди, визначення цілей і строків зберігання даних, розмежування ролей
володільця та розпорядника бази даних;
регулювання eHealth та інтеграції з ЕСОЗ. Дотримання вимог МОЗ до
інформаційної безпеки, інтероперабельності, структур даних, а також
технічних специфікацій для підключення до центральної бази даних та
реєстрів [28; 31];
статус рішень на основі ШІ. Наукові публікації акцентують, що
впровадження ШІ в клінічну практику потребує чіткого визначення меж
відповідальності лік;
48
етичні стандарти. Згідно з українськими роботами, присвяченими ШІ в
медицині, етичний вимір (недискримінація, запобігання упередженості
алгоритмів, прозорість прийняття рішень) має бути інтегрований у дизайн та
експлуатацію систем із самого початку, а не розглядатися як додаткова опція
[30].
Таким чином, правові чинники одночасно встановлюють суворі обмеження
(що ускладнює розробку та впровадження), але й створюють «правила гри», в межах
яких «МедОгляд AI» може позиціонувати себе як рішення, що відповідає
національним стандартам і може бути масштабоване в межах державної цифрової
інфраструктури.
PESTEL-аналіз показує, що стартап «МедОгляд AI» формується у складному,
але потенційно сприятливому середовищі. Політичний курс на цифрову
трансформацію медицини, розбудова eHealth-інфраструктури та реформування
системи охорони здоров’я створюють основу для інтеграції інноваційних сервісів,
які працюють із медичними даними та підтримують клінічні рішення [27; 28; 31].
Розвиток технологій штучного інтелекту, підтверджений українськими
дослідженнями в клінічній практиці та освітніх програмах, демонструє запит на
інструменти, подібні до «МедОгляду AI», за умови дотримання етичних і правових
вимог [29; 30].
Водночас стартап має врахувати економічні обмеження, різний рівень
цифрової зрілості українських медичних закладів, нерівномірність соціального
сприйняття ШІ та високу чутливість до питань конфіденційності й безпеки даних.
Отримані висновки PESTEL-аналізу можуть слугувати основою для подальшого
деталізованого планування архітектури рішення, бізнес-моделі та стратегії
впровадження «МедОгляду AI» у національну цифрову інфраструктуру охорони
здоров’я.
Заповнена таблиця 2.1 демонструє експертну оцінку ключових факторів
конкурентного середовища саме для стартапу «МедОгляд AI» з урахуванням його
ролі в екосистемі цифрової медицини України.
49
Таблиця 2.1 – Методика експертної оцінки конкурентного середовища за моделлю
М. Портера (для стартапу «МедОгляд AI»)
Оцінка
№ Конкурентні сили Фактор Стан фактору (для МедОгляд AI)
(1–3)
Бар’єри входу на Бар’єри помірні: регулювання
ринок eHealth складне, але доступне для 2
ІТ-компаній
Доступ до Інтерес до медичних ШІ-рішень
інвестицій високий, але інвестиції в Україні 2
нестабільні
Загроза появи нових
1
конкурентів Брендова Лояльність до сторонніх
лояльність клієнтів цифрових медичних сервісів 1
невисока
Економія на Великі гравці мають переваги у
3
масштабі даних та інфраструктурі
Сумарний бал по силі 8 / 12
Альтернативні Існують телемедичні платформи
2
технології та базові чатботи без ШІ
Готовність Користувачі легко переходять між
користувачів до додатками 3
Загроза появи товарів-
2 заміни
замінників
Цінова Частина альтернатив безкоштовна
конкурентність або бюджетна 3
замінників
Сумарний бал по силі 8 / 9
Концентрація Провайдерів медичних ІТ-рішень
2
постачальників багато, залежність помірна
Вартість ресурсів Хмарні сервіси та кваліфіковані
3
3 Сила постачальників ІТ-кадри дорогі
Залежність від Інтеграція з ЕСОЗ та MIS
3
зовнішніх API критично важлива
Сумарний бал по силі 8 / 9
Чутливість до ціни Пацієнти та заклади орієнтовані
3
на економію
Доступність Користувачі легко знаходять
3
інформації аналоги та відгуки
Сила покупців (лікарів,
4 Лояльність до Середня, залежить від
закладів, пацієнтів) 2
бренду функціональності й безпеки
Вимогливість до Висока вимогливість до медичних
3
якості сервісів
Сумарний бал по силі 11 / 12
50
Продовження таблиці 2.1
Оцінка
№ Конкурентні сили Фактор Стан фактору (для МедОгляд AI)
(1–3)
Кількість Ринок eHealth активно зростає,
3
конкурентів гравців стає більше
Темпи зростання Ринок швидко розвивається,
3
ринку конкуренція посилюється
Конкуренція між Диференціація Конкуренти пропонують схожі
5 2
існуючими фірмами продуктів функції
Рівень У сильних гравців активний
маркетингової digital-маркетинг 3
активності
Сумарний бал по силі 11 / 12
За підсумками експертної оцінки впливу конкурентних сил на діяльність
стартапу «МедОгляд AI» були визначені середні значення кожної сили та
розрахований інтегральний коефіцієнт загального конкурентного тиску. Отримані
результати дозволяють оцінити ринкову ситуацію та рівень загроз з боку
зовнішнього конкурентного середовища (Таблиця 2.2).
Таблиця 2.2 – Середні значення конкурентних сил для «МедОгляд AI»:
Сумарний Максимально Середнє
Конкурентна сила
бал можливий бал значення
Загроза нових конкурентів 8 12 2,00
Загроза замінників 8 9 2,67
Сила постачальників 8 9 2,67
Сила покупців 11 12 2,75
Конкуренція між існуючими
11 12 2,75
фірмами
Отримані середні значення демонструють, що чотири з п’яти конкурентних
сил мають значення вище 2,5, що свідчить про сильний тиск конкурентного
середовища. Єдиною силою з нижчим впливом є загроза нових конкурентів (2,00),
що пояснюється вищими бар’єрами входу в сферу етичних, правових та
технологічних вимог медичних систем.
Отримане значення K = 2,57 свідчить про високий рівень конкурентного тиску,
що типово для ринків, які перебувають у стадії активної цифрової трансформації.
Для порівняння, в класичній інтерпретації:
51
K < 2,5 — ринок із надмірним конкурентним тиском, низькою стабільністю,
близький до умов чистої конкуренції.
K > 2,5 — ринок із сильними конкурентними силами, але зі збереженням
можливостей для спеціалізації, диференціації та стратегічного зростання.
Оскільки показник для «МедОгляд AI» трохи перевищує поріг 2,5, це означає:
1. Ринок eHealth України є висококонкурентним, але не повністю «ринком
хаотичної конкуренції».
Хоча тиск конкурентних сил значний, залишаються можливості для
формування стійких позицій через якість сервісу, інноваційність, рівень інтеграції з
eHealth та ЕМК (електронними медичними картками).
2. Найпотужнішим чинником є сила покупців (2,75).
Це означає, що галузь eHealth є ринком споживача, де кінцеві користувачі:
мають доступ до великої кількості альтернатив,
чутливі до ціни,
висувають високі вимоги до якості, безпеки та точності алгоритмів ШІ.
У таких умовах саме користувач формує правила ринку: рішення, що не
забезпечують зручність і достовірність, швидко втрачають позиції.
3. Висока конкуренція та замінники (2,67 і 2,75) ускладнюють вихід на ринок.
Ринок eHealth насичений телемедичними сервісами, базовими симптом-
чекерами, мобільними застосунками клінік. Стартап зобов’язаний
пропонувати унікальний функціонал, щоб вирізнятися.
4. Висока сила постачальників (2,67) зумовлена залежністю від eHealth та MIS.
Українська діджитал-інфраструктура охорони здоров’я побудована на
державних стандартах, що робить стартап залежним від:
специфікацій МОЗ,
стабільності роботи ЕСОЗ,
вимог щодо безпеки медичних даних.
Отриманий коефіцієнт K = 2,57 показує, що стартап «МедОгляд AI» планує
діяти на ринку, де:
52
конкуренція структурно висока,
сила покупців визначає характер ринку,
постачальники мають помітний вплив через технологічну залежність,
замінники створюють значні ризики,
бар’єри для новачків існують, але не є надмірними.
Це не катастрофічна ситуація, а скоріше динамічний ринок з високими
вимогами, на якому можуть успішно закріпитися лише ті продукти, що
забезпечують:
унікальну технологічну цінність,
високу точність ШІ-модулів,
довіру користувачів,
глибоку інтеграцію з eHealth,
сталі партнерські моделі з медичними закладами.
Для «МедОгляд AI» це означає, що успіх буде залежати не лише від якості
програмного продукту, а й від здатності правильно позиціонуватися в умовах
інтенсивного ринкового тиску.
Таким чином, для успішного позиціонування на ринку «МедОгляд AI»
повинен зосередитися на:
унікальності ціннісної пропозиції,
підвищенні точності та безпеки алгоритмів ШІ,
формуванні довіри користувачів,
тісній інтеграції з державними цифровими сервісами та MIS,
підсиленні маркетингової й партнерської стратегії.
2.2 Первинні та вторинні зацікавлені сторони
Успішність стартапу в сфері eHealth визначається не лише якістю
технологічного рішення, але й здатністю правильно структурувати взаємодію із
зацікавленими сторонами. «МедОгляд AI» — це система, що аналізує симптоми
пацієнтів за допомогою алгоритмів штучного інтелекту, взаємодіє з лікарями,
53
інтегрується з електронною системою охорони здоров’я та працює з чутливими
медичними даними. Саме тому стейкхолдерське середовище цього продукту є
багатоаспектним і включає учасників із різними сферами відповідальності, рівнями
впливу та очікуваннями.
Особливість цифрової медицини полягає в тому, що інтереси стейкхолдерів
часто перетинаються: держава встановлює регуляторні рамки; медичні заклади
відповідають за безпосередню участь у впровадженні; пацієнти формують
соціальний попит; технічні партнери забезпечують інтероперабельність; а правові
органи визначають стандарти безпеки. У таких умовах роль первинних та вторинних
зацікавлених сторін суттєво впливає на архітектуру продукту, стратегічні рішення,
бізнес-модель і темп розвитку стартапу.
Врахування позицій стейкхолдерів є також необхідною умовою дотримання
вимог МОЗ України щодо роботи цифрових медичних сервісів, використання даних,
етичних принципів застосування ШІ та інтеграції з eHealth, про що наголошується у
низці національних нормативних та аналітичних документів [15; 32; 33]. Крім того,
українські дослідження у сфері медичного цифрового менеджменту та регулювання
штучного інтелекту підкреслюють зростання ролі регуляторів, пацієнтських
спільнот і технологічних інтеграторів у процесі впровадження інновацій у системі
охорони здоров’я [34; 35].
У цьому контексті детальний аналіз первинних і вторинних стейкхолдерів
стартапу «МедОгляд AI» дозволяє точніше оцінити його ринкове середовище,
визначити ключові залежності та сформувати ефективну модель взаємодії із
зовнішнім та внутрішнім оточенням.
До первинних стейкхолдерів відносяться ті учасники, що безпосередньо
взаємодіють із продуктом, мають високий рівень впливу та отримують прямі вигоди
або несуть ризики від його роботи. Для eHealth-проєктів ця група є особливо
важливою, оскільки саме вони визначають зміст функціональних вимог, рівень
прийняття технології та характер регуляторних зобов’язань.
1. Пацієнти є центральними користувачами сервісу.
Їх інтерес зосереджений на:
54
швидкому доступі до попередньої оцінки стану здоров’я;
можливості раннього виявлення ризиків;
зменшенні потреби в офлайн-візитах до лікаря;
гарантіях захисту персональних медичних даних;
прозорості роботи ШІ-алгоритмів.
На рівні державної політики підкреслюється, що цифрові медичні сервіси
повинні забезпечувати доступність, безпечність і довіру користувачів [15].
Відповідно, пацієнти є ключовим драйвером формування соціального попиту.
2. Лікарі та медичні заклади.
Медичні працівники є одночасно користувачами й експертами, що оцінюють
медичну доцільність алгоритмів. Їхні інтереси пов’язані з:
зменшенням навантаження;
автоматизацією збору анамнезу;
підтримкою прийняття клінічних рішень;
дотриманням клінічних протоколів у рекомендаційній частині сервісу.
Українські клінічні дослідження наголошують на важливості професійного
контролю ШІ та наявності меж відповідальності між лікарем і системою [34].
3. Ініціатор та власник проєкту.
Згідно з проєктною документацією, ініціатором і власником є Макота Є.В.
Його інтереси полягають у:
створенні інноваційного продукту з конкурентною перевагою;
масштабуванні рішення на всю країну;
забезпеченні відповідності стандартам МОЗ;
отриманні стабільного прибутку.
4. Інвестори.
Інвестор зацікавлений у стабільній окупності, мінімізації ризиків та
відповідності продукту державним вимогам, адже лише за таких умов можливе
серійне розгортання платформи [35].
5. Команда проєкту.
55
Команда включає PM, DevOps, BE, FE, QA, Data Science, Medical Engineers,
HR . Її інтереси:
стабільне фінансування;
професійний розвиток у сфері медичного ШІ;
якісна організація процесів;
можливість участі в інноваційному проєкті з високим іміджем.
6. МОЗ України та НСЗУ (регулятори).
МОЗ визначає:
вимоги до роботи eHealth;
стандарти інтеграції;
правила обробки медичних даних;
відповідність GDPR / локальному законодавству [33].
Їхня роль є критичною, оскільки від них залежить юридична можливість
експлуатації продукту.
7. Постачальники технологічних рішень (HealthPrecision та ін.).
HealthPrecision, як постачальник AI-платформи та технологічних концепцій
CDS, впливає на:
архітектуру рішень;
стандартизацію медичних даних;
точність алгоритмів;
технічну підтримку;
інтеграційні сценарії з EHR системами.
Для ефективного планування, розробки та впровадження стартапу «МедОгляд
AI» необхідно чітко визначити групи стейкхолдерів, які прямо впливають на
функціональність та життєздатність продукту. До первинних зацікавлених сторін
належать учасники, що беруть безпосередню участь у створенні, використанні або
регулюванні цифрового медичного сервісу. Саме вони формують ключові вимоги до
технічної архітектури, безпеки даних, клінічної валідності та бізнес-моделі
застосунку. Таблиця 2.3 систематизує їх інтереси, рівень впливу та оптимальні
56
стратегії взаємодії, що дозволяє вибудувати збалансовану комунікацію та
мінімізувати ризики під час реалізації проєкту.
Таблиця 2.3 – Первинні зацікавлені сторони стартапу «МедОгляд AI»
Рівень
Група Інтереси Стратегія взаємодії
впливу
Швидка оцінка стану Постійний зворотний
здоров’я; безпека зв’язок, UX-
Пацієнти даних; зручний Високий дослідження, прозорі
інтерфейс; цілодобовий політики даних,
доступ інформаційна підтримка
Зменшення Спільна розробка
навантаження, протоколів, навчання,
Лікарі та медичні
автоматизація анамнезу, Високий регулярні консультації,
заклади
клінічна точність ШІ, адаптація інструментів
інтеграція з MIS під клінічні потреби
Масштабування
Управління проєктом,
продукту, відповідність
Ініціатор та власник забезпечення ресурсів,
стандартам МОЗ, Високий
проєкту контроль відповідності
прибутковість,
стандартам
репутація
Регулярні фінансові
Окупність, мінімізація
Середній– звіти, демонстрація KPI,
Інвестор ризиків, довготривала
високий прозоре управління
стабільність продукту
витратами
Зрозуміла структура Agile-підхід, технічна
Команда проєкту
роботи, інноваційність документація, регулярні
(PM/BE/FE/QA/DS/ Середній
продукту, розвиток мітинги, стандартизація
ME/HR)
компетенцій процесів
Дотримання стандартів Виконання регламентів
МОЗ України / eHealth, безпека даних, Вищий МОЗ, участь у робочих
НСЗУ відповідність клінічним серед усіх групах, аудит безпеки,
протоколам інтеграція з ЕСОЗ
Постачальники Надання стабільної Технічні угоди, SLA,
технологій інфраструктури та тестування інтеграцій,
Високий
(HealthPrecision, сервісів, технічна спільне вирішення
хмарні сервіси) сумісність інцидентів
Вторинні стейкхолдери здійснюють опосередкований, але системно важливий
вплив на становлення продукту.
57
1. Суспільство та пацієнтські організації.
Вони формують загальний рівень довіри до цифрової медицини, підсилюють
суспільний запит на прозорість, безпеку й доступність медичних сервісів.
Аналітичні звіти підкреслюють важливість участі пацієнтських спільнот у
формуванні політики цифрової охорони здоров’я [32].
2. Приватні клініки та корпоративні медичні мережі.
Зацікавлені в:
інтеграції сервісу для оптимізації записів;
автоматизації первинного тріажу;
зменшенні операційних витрат;
підвищенні задоволеності пацієнтів.
3. Страхові компанії.
Для страхових організацій AI-тріаж є інструментом:
зниження ризиків;
оптимізації страхових виплат;
покращення якісної аналітики щодо стану застрахованих.
4. Академічні установи та наукові центри.
Вони можуть брати участь у:
тестуванні алгоритмів;
підготовці медичних датасетів;
проведенні незалежної експертизи ШІ [34].
5. Конкуренти та ринкові гравці.
В Україні діють часткові конкуренти — платформи дистанційного моніторингу
та онлайн-запису, телемедичні рішення (DOC.ua, Cardiomo, ImagineCare), але жодна
з них не має повної ШІ-архітектури для попереднього аналізу стану.
6. Технічні інтегратори eHealth.
До них належать:
MIS-постачальники;
оператори медичних реєстрів;
58
сервіси ідентифікації та авторизації.
Саме вони забезпечують інтероперабельність платформи з національною
системою.
7. Засоби масової інформації та цифрові платформи.
Мають значення у формуванні:
репутації продукту;
цифрової культури користувачів;
загального ставлення до ШІ в медицині.
Вторинні стейкхолдери формують ширший контекст функціонування eHealth-
продукту, впливаючи на його репутацію, темпи масштабування, конкурентне
середовище та інтеграцію до медичної інфраструктури. Хоча їхній вплив не завжди є
прямим, взаємодія з ними визначає стратегічну стійкість стартапу, забезпечує
легітимність цифрового рішення та підсилює соціальне прийняття технологій
штучного інтелекту у медицині. Таблиця 2.4 узагальнює їхні інтереси та характер
впливу, а також окреслює релевантні стратегії співпраці для підтримки
довготривалого розвитку «МедОгляд AI».
Первинні та вторинні стейкхолдери стартапу «МедОгляд AI» формують
комплексне оточення, у якому проєкт одночасно відповідає на потреби пацієнтів,
лікарів, інвесторів та держави. Ключову роль відіграють регулятори, пацієнти та
медичні заклади, оскільки саме вони визначають практичні умови, в яких застосунок
може бути впроваджений та масштабований. Вторинні стейкхолдери — конкуренти,
страхові компанії, наукові установи, медіа — впливають на стратегічний розвиток
стартапу, формують ринкову динаміку та сприяють або ускладнюють його
інтеграцію в екосистему eHealth.
59
Таблиця 2.4 – Вторинні зацікавлені сторони стартапу «МедОгляд AI»
Рівень Стратегія
Група Інтереси
впливу взаємодії
Суспільство та Доступність і якість Середній Громадські
пацієнтські медичних сервісів, консультації,
організації прозорість роботи ШІ роз’яснювальні
кампанії, публікація
відкритих звітів
Приватні клініки Оптимізація процесів, Середній– Пілотні впровадження,
та медичні скорочення витрат, високий договірні відносини,
мережі покращення сервісу кастомізація продукту
Страхові компанії Зменшення ризиків, Середній Партнерські програми,
покращена аналітика, API-доступ до
підвищення профілактики агрегованих даних,
спільні оцінки ризиків
Академічні Участь у дослідженнях, Низький– Співпраця у валідації
установи та НДІ доступ до даних для середній ШІ, наукові угоди,
наукових проєктів спільні публікації
Конкуренти та Ринкова частка, клієнтські Непрямий, Аналіз ринку,
ринкові гравці потоки, технологічні але значний моніторинг інновацій,
переваги диференціація
продукту
ІТ-інтегратори та Забезпечення Середній API-інтеграції, технічні
постачальники інтероперабельності, обмін угоди, тестування
MIS даними протоколів взаємодії
Медіа та Формування репутації та Середній PR, інтерв’ю, кейси,
інформаційні суспільного сприйняття (іміджевий) участь у галузевих
ресурси технології заходах
Класична матриця «Вплив–Інтерес» дозволяє визначити, яких стейкхолдерів
потрібно залучати до ключових рішень, кому забезпечувати постійний моніторинг, а
кому — надавати базову інформацію (Таблиця 2.5).
60
Таблиця 2.5 – Матриця «Вплив–Інтерес»
Ступінь впливу / Високий Низький
інтересу інтерес інтерес
I. Активно управляти (Manage
Closely)
II. Тримати задоволеними
– МОЗ України / НСЗУ
(Keep Satisfied)
– Лікарі та медичні заклади
– Інвестори
Високий вплив – Ініціатор та власник проєкту
– Великі приватні медичні
– Команда розробки (PM, DS, BE,
мережі
FE, QA)
– Страхові компанії
– Постачальники технологічних
рішень
IV. Мінімальний моніторинг
III. Тримати поінформованими
(Monitor)
(Keep Informed)
– Засоби масової інформації
– Пацієнти та пацієнтські
Низький вплив – Ринок конкурентів
організації
(непрямий вплив)
– Академічні установи
– IT-спільноти та громадські
– Науковці з медичного ШІ
ініціативи
Такий підхід до аналізу дає змогу сформувати збалансовану політику взаємодії
з учасниками, визначити критичні ризики та посилити адаптивність «МедОгляд AI»
у рамках національної цифрової інфраструктури охорони здоров’я.
2.3 Місія, цілі та розробка коцепції стартапу
У сучасних умовах цифрової трансформації охорони здоров’я в Україні
зростає потреба в створенні сервісів, здатних підвищувати доступність медичної
допомоги, оптимізувати навантаження на лікарів, покращувати взаємодію між
пацієнтом і медичною системою та забезпечувати раннє виявлення ризиків. На
цьому фоні проєкт «МедОгляд AI» формує власне призначення та концепцію як
інноваційне рішення у сфері eHealth, спрямоване на підтримку населення й
медичних працівників у процесі прийняття клінічних рішень та первинного
цифрового тріажу.
61
Місія проєкту полягає в підвищенні ефективності первинної медичної
допомоги шляхом використання штучного інтелекту для ранньої оцінки симптомів,
надання персоналізованих рекомендацій та створення безпечного й доступного
цифрового інструмента для пацієнтів та лікарів.
Ця місія ґрунтується на кількох ключових ідеях:
1. Орієнтація на пацієнта. Сервіс забезпечує цілодобовий доступ до
попередньої оцінки стану здоров’я, допомагаючи людині зробити правильний
крок — звернутися до лікаря, отримати дистанційну консультацію або
здійснити самостійні профілактичні заходи.
2. Підтримка лікарів. Інструмент покликаний зменшувати рутинне
навантаження лікарів, автоматизувати попередній збір інформації та
допомагати лікарю отримувати структуровані дані, зменшуючи час прийому.
3. Покращення якості медичної допомоги. Місія передбачає підвищення
своєчасності звернень, точності первинного сортування та зменшення
кількості випадків самолікування.
4. Безпечне використання ШІ. Проєкт реалізує етичний підхід до
використання штучного інтелекту, забезпечуючи прозорість алгоритмів,
збереження конфіденційності, відповідність вимогам eHealth та державним
стандартам захисту даних.
5. Інтеграція з цифровою медичною інфраструктурою України. Місія
передбачає максимальну сумісність сервісу з ЕСОЗ, MIS медзакладів та
електронними медичними реєстрами.
Таким чином, місія проєкту визначає його суспільно важливу роль — бути
інструментом, що поєднує технології, клінічні протоколи й потреби населення,
створюючи сучасний формат доступу до первинної медичної допомоги.
Цілі проєкту розділяються на стратегічні й операційні, що дозволяє системно
вибудовувати траєкторію розвитку сервісу.
1. Стратегічні цілі.
62
Підвищення доступності медичної допомоги. Забезпечення можливості
швидкого дистанційного оцінювання симптомів незалежно від місця
проживання користувача.
Зменшення навантаження на лікарів. Автоматизація первинного
сортування звернень, попереднього збору анамнезу та рекомендацій.
Створення високоточної ШІ-моделі для аналізу симптомів. Забезпечення
якості алгоритмів, що відповідають клінічним стандартам.
Інтеграція з eHealth. Повна технічна сумісність із національною
цифровою інфраструктурою охорони здоров’я.
Формування довіри до цифрових медичних сервісів. Розвиток культури
безпечного та усвідомленого використання медичних ШІ-рішень.
2. Операційні цілі.
розробити функціональні модулі збору симптомів, рекомендацій, тріажу
та ведення цифрового профілю пацієнта;
забезпечити відповідність вимогам захисту персональних даних;
підготувати інтерфейси для пацієнтів та лікарів;
провести пілотні впровадження у медичних закладах;
створити аналітичну панель для медичного персоналу;
забезпечити безперервну технічну підтримку та оновлення моделі.
Досягнення цих цілей дозволить сформувати гнучкий, масштабований і
стійкий цифровий продукт для медичного ринку України.
Розробка концепції проєкту. Концепція «МедОгляду AI» базується на
поєднанні медичних знань, алгоритмів штучного інтелекту, сучасних стандартів
функціональних систем eHealth та потреб основних груп користувачів. Вона
формується як логічна модель, що об’єднує технологічну архітектуру, бізнес-логіку,
клінічну релевантність і нормативну відповідність.
1. Технологічна концепція.
Основою технічної частини є створення ШІ-модуля для:
аналізу введених симптомів;
63
визначення ймовірних сценаріїв стану;
рекомендацій щодо подальших дій;
оцінювання ризиків.
Система використовує структуровані медичні онтології та класифікатори,
забезпечує стандартизований обмін даними (FHIR, HL7) і має можливість
інтегруватися з MIS, електронною медичною карткою та ЕСОЗ.
2. Клінічна концепція.
Концепція передбачає відповідність рекомендацій медичним протоколам,
участь лікарів у валідації алгоритмів та створення безпечних сценаріїв
використання, у яких ШІ не замінює лікаря, а підтримує його рішення.
3. Концепція взаємодії з користувачами.
Сервіс орієнтований на:
інтуїтивно зрозумілий інтерфейс;
адаптивні підказки;
пояснення логіки роботи ШІ;
забезпечення емоційної безпеки та довіри.
Для лікарів передбачена аналітична панель із доступом до даних тріажу,
структурованими симптомами та попередніми висновками.
4. Інфраструктурна концепція.
Проєкт інтегрується з:
національною електронною системою охорони здоров’я;
медичними інформаційними системами приватних і державних закладів;
сервісами ідентифікації та автентифікації користувачів.
Це забезпечує масштабованість і можливість подальшого розширення.
5. Бізнес-концепція.
Сервіс може використовувати моделі:
B2C (користувач → сервіс),
B2B (клініка → сервіс),
B2G (державні програми цифрової медицини).
64
Модель монетизації може включати підписку, API-інтеграції, корпоративні
ліцензії.
Місія, цілі та концепція проєкту «МедОгляд AI» демонструють цілісну логіку
розвитку сервісу як інноваційного інструмента первинної цифрової медичної
допомоги. Проєкт спрямований на підвищення доступності медичних послуг,
покращення якості взаємодії між пацієнтом і лікарем та створення безпечної
інтелектуальної системи, здатної інтегруватися у національну інфраструктуру
eHealth. Чітко сформована концепція забезпечує основу для технічної реалізації,
клінічної валідності та стратегічного масштабування сервісу як важливого елемента
сучасної цифрової медицини України.
2.4 Опис продукту проєкту
Продукт «МедОгляд AI» являє собою інтелектуальну медичну інформаційну
систему, розроблену на основі сучасних принципів цифрової медицини, адаптованих
до української інфраструктури eHealth та взаємодії з електронною медичною
карткою пацієнта. Концепція продукту базується на архітектурних та
функціональних засадах, що застосовуються у міжнародних клінічних AI-
платформах, які поєднують машинне навчання, клінічні правила та стандартизовані
медичні онтології для підтримки лікарів у процесі прийняття клінічних рішень і
безперервного моніторингу стану пацієнтів.
«МедОгляд AI» покликаний виконувати функції попереднього аналізу
симптомів, структурованого збору інформації про пацієнта, первинного цифрового
тріажу, прогнозування стану та формування рекомендацій щодо наступних дій.
Продукт виступає інтеграційною ланкою між пацієнтом, лікарем і медичними
інформаційними системами, надаючи кожній групі користувачів різні рівні доступу
та відповідні функціональні модулі.
Архітектурна модель продукту.
Архітектура «МедОгляд AI» включає кілька функціональних рівнів:
65
Збір і нормалізація даних, що забезпечують отримання інформації від
пацієнта, з MIS та ЕСОЗ.
Медичні онтології та стандарти, що дозволяють уніфікувати дані за HL7
FHIR, SNOMED CT, ICD-10 та LOINC.
AI-модуль, який поєднує rule-based алгоритми, статистичні моделі та
ML-компоненти для оцінки симптомів і тріажу.
Модуль робочих процесів для формування маршруту пацієнта, ескалації
випадків та передачі даних лікарю.
Інтерфейсні модулі — мобільний додаток пацієнта та кабінет лікаря з
аналітичною панеллю.
Подібна архітектурна логіка застосовується у Medical Brain®, де передбачено
багаторівневу обробку клінічних даних, їх стандартизацію та формування
аналітичних сценаріїв для медичного персоналу. Це забезпечує високу точність
моделей, можливість масштабування та безпечний обмін медичною інформацією.
Для комплексного розуміння можливостей «МедОгляд AI» доцільно
систематизувати ключові елементи продукту у таблиці 2.6. Вона узагальнює
функціональні модулі системи та демонструє їхню роль у забезпеченні цифрового
тріажу, безперервного моніторингу та взаємодії між пацієнтами й лікарями. Така
систематизація дозволяє оцінити технологічну зрілість продукту, ланцюг його
цінності та відповідність вимогам eHealth України.
Таблиця 2.6 – Функціональна структура продукту «МедОгляд AI»
Опис Очікуваний
№ Модуль
функцій результат
Модуль збору Збір симптомів, історії Формування повного профілю
даних (Data здоров’я, лабораторних пацієнта, доступного для AI-
1
Intake) даних, інформації з MIS та аналізу
eHealth
Онтологічний Нормалізація даних за HL7 Стандартизована медична
2 модуль FHIR, SNOMED CT, ICD- інформація для коректної
10 інтерпретації
66
Продовження таблиці 2.6
Опис Очікуваний
№ Модуль
функцій результат
AI-модуль Rule-based логіка, ML- Первинний діагностичний прогноз,
3 клінічного моделі, оцінка ризиків, класифікація терміновості
аналізу аналіз симптомів
Модуль Визначення сценарію дій: Покращення маршрутизації
цифрового самолікування, пацієнтів, зменшення
4
тріажу консультація, виклик навантаження на лікарів
швидкої
Модуль Сповіщення, нагадування, Забезпечення безперервності
ескалації та передача лікарю інформації медичної підтримки
5
робочих про ризики
процесів
Мобільний Введення даних, Доступність сервісу 24/7,
6 додаток рекомендації, історія стану, підвищення довіри користувачів
пацієнта пояснення рішень ШІ
Кабінет лікаря Структурований анамнез, Економія часу, поліпшення якості
7 ризик-профіль, аналітична первинного прийому
панель
Представлена структура демонструє, що «МедОгляд AI» — це комплексна
система, що охоплює всі ключові етапи цифрової підтримки пацієнтів: від збору та
нормалізації даних до інтелектуального аналізу й формування клінічно коректних
рекомендацій. Відповідність міжнародним стандартам і гнучкість архітектури
забезпечують можливість масштабування продукту, адаптації до різних медичних
процесів та інтеграції з державними системами охорони здоров’я.
Оскільки «МедОгляд AI» позиціонується як інтелектуальна система для
первинної медичної допомоги, важливо визначити його основні характеристики, які
формують конкурентоспроможність продукту на українському ринку. Наступна
таблиця 2.7 узагальнює технологічні, клінічні, організаційні та етичні аспекти, що
визначають якість сервісу та його відповідність вимогам цифрової медицини.
67
Таблиця 2.7 – Ключові характеристики продукту «МедОгляд AI»
Сутність
№ Категорія Значення для користувачів / лікарів
характеристики
Технологічна Використання AI- Підвищення якості первинного аналізу
1 точність моделей та клінічних симптомів
правил
Інтероперабе Інтеграція з eHealth, Уніфікація даних, скорочення помилок
2 льність MIS, медичними
реєстрами
Пояснюваніс Пояснення логіки Підвищення довіри та безпеки
ть рекомендацій пацієнту
3 алгоритмів та лікарю
(Explainable
AI)
Захист Шифрування, аудит Гарантії конфіденційності
4 медичних доступів,
даних GDPR/HIPAA-підхід
Підтримка Автоматизація збору Економія часу, фокус на медичному
5
лікарів анамнезу, тріаж рішенні
Підтримка Рекомендації, профіль Покращення самоконтролю та
6 пацієнтів здоров’я, профілактики
попередження
Можливість Модульна структура, Розширення в межах країни та для
7 масштабуван хмарні сервіси різних організацій
ня
Наведені характеристики підтверджують, що продукт «МедОгляд AI» має
потенціал стати ядром інтелектуальної первинної медичної допомоги в Україні.
Поєднання точності, інтеграційних можливостей, високих стандартів кібербезпеки
та зручного користувацького інтерфейсу створює фундамент для розширення
системи як у державному, так і в приватному секторі медицини. Завдяки модульності
архітектури проєкт здатний адаптуватися до нових форматів медичної допомоги,
інтегрувати носимі пристрої, удосконалювати алгоритми та реагувати на потреби
ринку.
Описані модулі, характеристики та принципи роботи «МедОгляд AI»
демонструють, що продукт спроєктований відповідно до сучасних трендів eHealth і
68
клінічної інформатики. Він поєднує досвід медичних AI-систем міжнародного рівня,
із вимогами української цифрової інфраструктури охорони здоров’я, забезпечуючи
точність, інтероперабельність, захист даних та клінічну безпечність.
«МедОгляд AI» є перспективним рішенням для модернізації первинної ланки
медицини та підвищення ефективності взаємодії між пацієнтами й лікарями.
Для цілісного розуміння логіки роботи системи та взаємозв’язку її основних
компонентів доцільно представити архітектуру «МедОгляд AI» у вигляді
структурованої графічної схеми (рис.2.1). Оскільки продукт розробляється як
інтелектуальний інструмент первинної медичної допомоги, він має багаторівневу
архітектуру, що поєднує збір даних, їх стандартизацію, роботу алгоритмів штучного
інтелекту, механізми ескалації та інтерфейси взаємодії з користувачами.
За своєю логікою та структурою система поєднує rule-based механізми
клінічної підтримки рішень, машинне навчання, роботу з клінічними онтологіями та
модулі автоматичної маршрутизації пацієнтів. Саме ця концепція була адаптована у
«МедОгляд AI» відповідно до вимог української eHealth-інфраструктури та
архітектури проєкту, визначеної у робочій документації стартапу.
Схема демонструє послідовний рух інформації — від введення симптомів
пацієнтом та отримання медичних даних через інтерфейси MIS або ЕСОЗ — до їх
уніфікації, аналізу AI-двигуном і подальшого формування рішень, рекомендацій та
повідомлень лікарю. Такий підхід забезпечує прозорість роботи системи та дає
змогу побачити її як цілісний комплекс, усі елементи якого взаємодіють у межах
єдиної логічної моделі.
Схема також відображає розподіл відповідальності між компонентами:
на верхньому рівні зображено джерела даних, які надходять у систему;
середні рівні демонструють обробку, стандартизацію та аналіз даних;
нижні рівні відображають UI-модулі — мобільний додаток пацієнта та
кабінет лікаря — через які користувачі отримують результати та взаємодіють із
системою.
69
Рисунок 2.1 – Логіко структурна схема продукту
Завдяки такому представлення архітектури стає зрозуміло, яким чином
система формує рекомендації, якими модулями вона користується на кожному етапі,
як забезпечується відповідність медичним стандартам, а також як реалізуються
робочі процеси для пацієнтів і медичного персоналу. Цей інструмент є одним із
ключових для менеджменту проєкту, оскільки забезпечує прозору комунікацію між
командами розробки, лікарями, інвесторами та стейкхолдерами.
70
2.5 Життєвий цикл проєкту
Життєвий цикл стартапу «МедОгляд AI» доцільно розглядати як послідовність
етапів розвитку інноваційного eHealth-рішення від формування ідеї та концепції до
масштабованої експлуатації в національній цифровій інфраструктурі охорони
здоров’я. На відміну від звичайних ІТ-продуктів, цифрові медичні сервіси мають
додаткові вимоги: вони працюють із медичними даними, підпорядковуються
клінічним протоколам, взаємодіють з електронною системою охорони здоров’я
(ЕСОЗ) та регулюються публічною політикою у сфері цифрової медицини [35; 36].
Це означає, що життєвий цикл такого стартапу включає не лише класичні стадії
ініціації, розробки, тестування й масштабування, а й обов’язкові фази регуляторного
узгодження, інтеграції з державними реєстрами, налаштування інформаційної
безпеки та клінічної валідації алгоритмів штучного інтелекту.
На етапі ініціації та формування ідеї відбувається усвідомлення ключової
проблеми — низької ефективності первинної взаємодії пацієнта з медичною
системою, значного навантаження на лікарів та фрагментованості медичних даних.
У цей період для «МедОгляд AI» визначається місія, цільові групи користувачів
(пацієнти, лікарі, медичні заклади), базові сценарії використання та первинне
бачення продукту як інтелектуального інструмента цифрового тріажу. Важливо, що
вже на цій стадії ідея співвідноситься з існуючою цифровою екосистемою eHealth
України, яка включає ЕСОЗ, медичні інформаційні системи (МИС), електронні
медичні записи й відповідні реєстри [35; 36]. Це дозволяє не вигадувати
«паралельну» інфраструктуру, а проєктувати сервіс відразу як частину загальної
цифрової системи.
Концептуально-проєктний етап пов’язаний із деталізацією життєвого циклу
продукту: формулюються вимоги до функціональності, інформаційних потоків,
алгоритмів ШІ, рівнів доступу до даних, визначаються точки інтеграції з ЕСОЗ та
МИС. У цей період проводиться аналіз нормативних документів МОЗ та НСЗУ,
технічних вимог до МИС, а також огляд європейського та українського досвіду
цифрової трансформації медицини [35; 36]. Особливістю eHealth-стартапу є те, що
71
концепція повинна одразу враховувати вимоги до безпеки та обробки медичних
даних, оскільки будь-яка подальша зміна архітектури на пізніх етапах буде дорогою
та ризикованою.
На етапі дослідження та валідації проблеми життєвий цикл «МедОгляд AI»
включає перевірку гіпотез щодо корисності й практичності сервісу для різних груп
користувачів. Проводиться аналіз потреб пацієнтів і лікарів, глибинні інтерв’ю,
оцінюється готовність медичних закладів до впровадження інструментів ШІ
[38]. Паралельно вивчається поточний стан застосування ШІ в українській медицині
та основні бар’єри його впровадження: недовіра, нормативні обмеження,
необхідність клінічної валідації, потреба в пояснюваності алгоритмів [37; 39]. На
цьому етапі життєвий цикл стартапу не лише рухається вперед, а й може включати
перегляд концепції, якщо виявляються суттєві розбіжності між первинним баченням
і реальними потребами системи охорони здоров’я.
Етап розробки MVP (мінімально життєздатного продукту) є центральною
фазою технічного розвитку стартапу. Для «МедОгляд AI» це означає створення
базової версії системи, яка включає ядро AI-модуля аналізу симптомів, онтологічний
шар (SNOMED CT, ICD-10), інтеграційні інтерфейси з МИС та тестові сценарії
цифрового тріажу. На відміну від звичайних ІТ-стартапів, MVP у сфері eHealth не
може бути «спрощеною іграшковою» версією: він має відповідати базовим вимогам
інформаційної безпеки, коректно працювати з медичними даними та не генерувати
клінічно небезпечних рекомендацій [37; 38]. Тому значну частину цього етапу
займають не лише програмна розробка, а й узгодження медичної логіки з
експертами, побудова прототипів інтерфейсів для лікаря й пацієнта, а також
створення механізмів аудиту дій системи.
Після розробки MVP життєвий цикл переходить до фази пілотного
впровадження та клінічної апробації. Вона полягає у тестуванні «МедОгляд AI» у
співпраці з обмеженою кількістю медичних закладів, що погодилися виступити
пілотними майданчиками. У цьому процесі перевіряється: наскільки точно система
ідентифікує типові симптоми, чи відповідають рекомендації клінічним протоколам,
як сервіс інтегрується в реальні робочі процеси лікарів, чи не створює додаткового
72
навантаження на персонал [37; 38]. Важливо, що частина метрик успіху вже на
цьому етапі пов’язується з даними eHealth — наприклад, зменшення кількості
некоректних звернень, оптимізація запису до лікаря, прискорення первинної
консультації. Пілотний етап у сфері медичних стартапів часто повторюється кілька
разів: на основі зібраних даних життєвий цикл включає фази доопрацювання ШІ-
моделі, зміни інтерфейсу, перебудови сценаріїв тріажу.
Коли система довела свою працездатність у пілотних умовах, стартап виходить
на етап масштабування та комерціалізації. Для «МедОгляд AI» ця стадія має декілька
напрямів: розширення кількості медичних закладів-партнерів, інтеграція з більшою
кількістю МИС (а в Україні їх десятки, підключених до ЕСОЗ [36]), розгортання
сервісу для різних груп користувачів (державні заклади, приватні мережі, страхові
компанії) [36]. Водночас життєвий цикл переходить у фазу активного управління
репутацією, формування довіри до продукту на рівні галузі, участі в галузевих
заходах (наприклад, eHealth Summit), де обговорюються нові проєкти цифрової
охорони здоров’я та оцінюється їх вплив на систему [35; 38]. На цьому етапі
особливо важливо зберігати баланс між швидким зростанням і дотриманням
регуляторних та етичних норм.
Етап зрілої експлуатації та розвитку у життєвому циклі «МедОгляд AI»
пов’язаний з тим, що продукт стає не одноразовою інновацією, а постійно діючим
елементом цифрової медицини. Він вимагає регулярного оновлення ШІ-моделей,
адаптації до нових клінічних протоколів, розширення номенклатури підтримуваних
станів, а також безперервного моніторингу безпеки та якості рекомендацій [37; 39].
У цьому періоді життєвий цикл включає циклічні ітерації вдосконалення: збір даних
з експлуатації, аналіз помилок, ретренування моделей, впровадження нових функцій.
З урахуванням того, що в Україні тривають дискусії про приєднання до міжнародних
рекомендацій щодо управління медичними даними та регулювання ШІ, стартап
мусить постійно відслідковувати зміни нормативного поля та адаптуватися до них
[35; 39].
Окремий вимір зрілої фази — етичний та правозахисний. У вітчизняних
публікаціях наголошується, що впровадження ШІ в медицину має супроводжуватися
73
чітким розподілом відповідальності між алгоритмом і лікарем, гарантіями
конфіденційності, прозорістю логіки прийняття рішень і механізмами захисту прав
пацієнта [39]. Для «МедОгляд AI» це означає, що життєвий цикл продукту включає
не лише технічну експлуатацію, а й постійний діалог із професійною спільнотою,
правозахисними організаціями, регуляторами та користувачами.
Таким чином, життєвий цикл стартапу «МедОгляд AI» можна
охарактеризувати як багатофазний процес, у якому класичні етапи розвитку ІТ-
продукту поєднуються з елементами клінічної валідації, регуляторного узгодження,
інтеграції з ЕСОЗ та постійної адаптації до змін у сфері eHealth і штучного інтелекту
в медицині. Послідовне проходження цих етапів створює умови для того, щоб
проєкт не залишився локальним експериментом, а перетворився на стійкий елемент
національної цифрової інфраструктури охорони здоров’я.
Висновки до розділу 2
У другому розділі проведено аналіз умов, що визначають можливості для
створення стартапу «МедОгляд AI» у сфері цифрової медицини. Вивчення ринку
eHealth, нормативної бази та потреб користувачів дозволило окреслити актуальність
сервісів первинного цифрового тріажу та визначити основні вимоги до продукту.
Визначено первинні та вторинні групи стейкхолдерів — пацієнти, лікарі,
медичні заклади, регулятори, страхові компанії, приватні медичні мережі та технічні
інтегратори. Їхні інтереси стали підґрунтям для формування стратегії взаємодії та
визначення напрямів розвитку проєкту.
Сформульовано місію «МедОгляд AI» як створення безпечного та доступного
інструмента для оцінки симптомів і підтримки лікарів у прийнятті рішень.
Визначено стратегічні й операційні цілі, що орієнтовані на підвищення доступності
медичної допомоги, зменшення навантаження на лікарів та інтеграцію з
національною системою eHealth.
Концепція продукту охоплює структуру архітектури, логіку обробки медичних
даних, застосування онтологій та механізмів Explainable AI, а також інтеграцію з
74
МІС та електронною медичною картою пацієнта. Подана схема демонструє
взаємозв’язок ключових модулів і послідовність роботи системи.
Розглянуто життєвий цикл стартапу — від ініціації та розробки MVP до
пілотування, масштабування та зрілої експлуатації з урахуванням вимог регуляторів
і норм захисту даних.
У підсумку розділ формує узагальнене бачення «МедОгляд AI» як цілісного
eHealth-рішення, що поєднує технологічні інновації, регуляторну відповідність і
потреби користувачів, закладаючи основу для проєктування системної архітектури.
75
3 ПАНУВАННЯ ТА УПРАВЛІННЯ СТАРТАПОМ
3.1 Управління змістом стартапу
Управління змістом стартапу — це впорядкований та послідовний комплекс
дій, спрямованих на визначення, уточнення, структурування й подальший контроль
усього обсягу робіт, функцій та результатів, необхідних для створення продукту і
досягнення стратегічних цілей стартапу. Цей напрям є одним із центральних у
системі проєктного менеджменту, адже саме він забезпечує узгодженість між
планованим результатом і реальною діяльністю команди. Правильно організоване
управління змістом гарантує, що команда виконує лише ті завдання, які
безпосередньо відповідають місії стартапу, запитам користувачів, інтересам
інвесторів та вимогам ринку.
У середовищі стартапів управління змістом відіграє особливо важливу роль.
Продукти інноваційних команд створюються в умовах нестачі ресурсів, високої
невизначеності, постійних змін та необхідності швидко реагувати на зворотний
зв’язок. Саме тому проєкт повинен мати чітко визначені межі: що саме
розробляється, які функції є обов’язковими, яким має бути фінальний результат і за
якими критеріями його оцінюватимуть.
Готовий програмний продукт має забезпечити постійну комунікацію лікаря з
пацієнтом, застосувавши штучний інтелект для вирішення питань та зменшення
навантаження на лікаря. У таблиці 3.1 наведено високорівневі вимоги до кінцевого
результату.
Сутність управління змістом полягає в низці процесів, що дають змогу
сформувати цілісне бачення продукту та етапності його створення. Передусім
визначається кінцевий результат: наприклад, у стартапі «МедОгляд AI» ним є
мобільний застосунок для комунікації лікаря з пацієнтом з використанням
технологій штучного інтелекту. Далі встановлюються вимоги до функціональності
продукту — зокрема, у матеріалах проєкту окреслені ключові компоненти: чат,
76
модулі реєстрації, база даних, елементи AI-аналітики, система оплат та інші
необхідні функції.
Таблиця 3.1 — Високорівневі вимоги до кінцевого результату проєкту
Критерії
№ Вимога Суть вимоги Очікуваний результат
приймання
Створення повноцінного Функціональний Застосунок успішно
Розроблення програмного продукту з мобільний застосунок, встановлюється,
1 мобільного базовими модулями, доступний для запускається та коректно
застосунку навігацією, дизайном та встановлення лікарями працює на Android/iOS
користувацькою логікою та пацієнтами без критичних помилок
Забезпечення Повноцінний Користувачі можуть
можливості обміну двосторонній чат з надсилати/отримувати
Створення
повідомленнями та історією повідомлень та повідомлення; сервер
логіки
2 файлами між оповіщеннями зберігає історію;
комунікації
користувачами повідомлення
«лікар–пацієнт»
доставляються без
затримок
Навчання Реалізація AI-модулів AI надає автоматичні Точність моделей ≥ 85%;
штучного для аналізу симптомів, відповіді на типові відповіді AI релевантні;
3 інтелекту для формування попередніх запити, визначає рівень рекомендації
обробки відповідей та ризику та за потреби відповідають медичним
звернень рекомендацій направляє до лікаря протоколам
Створення облікового Робочий профіль лікаря Лікар може пройти
запису медичних з валідацією особистих реєстрацію, підтвердити
Реєстрація працівників із та професійних даних особу, отримати доступ
4
лікарів підтвердженням до кабінету та
професійних даних інструментів
консультації
Забезпечення Особистий кабінет Пацієнт успішно
Реєстрація можливості пацієнтам пацієнта з прив’язкою реєструється, система
пацієнтів та їх створювати акаунт і до лікаря, доступом до прив’язує його до лікаря;
5
прив’язка до бути закріпленими за історії запитів та дані відображаються
лікаря певним лікарем або профілю коректно
клінікою
Забезпечення Інтегрована платіжна Транзакції успішно
можливості оплати система з підтримкою проводяться; користувач
Реалізація
6 консультацій, підписок кількох методів оплати отримує підтвердження
системи оплат
чи додаткових сервісів оплати; дані передаються
безпечно
Наступним етапом стає декомпозиція продукту на структурні частини.
На рисунку 3.1 подано поділ продукту на дизайн, функціональні модулі, бренд,
сховища даних, елементи взаємодії та AI-компонент.
77
Рисунок 3.1 – Декомпозиція кінцевого результату
На основі цього формується структура декомпозиції робіт (СДР), що охоплює
всі необхідні етапи — від збору команди та архітектурного проєктування до
розроблення бекенду, UI/UX, тестування та релізу (таблиця 3.2). Водночас важливим
завданням є контроль змісту, що дозволяє уникати неконтрольованого розширення
функцій і захищає проєкт від зайвих витрат.
78
Таблиця 3.2 – Декомпозиція робіт стартапу
№ 1-го № 2-го № 3-го Оцінка
Назва задачі
рівня рівня рівня тривалості
Розробка мобільного
1 223 дні
застосунку «MedOglad AI»
1.1 Ініціація 41 день
1.1.1 Формування команди 9 днів
1.1.2 Формалізація ідеї 10 днів
1.1.3 Аналіз ринку 5 днів
1.1.4 Бізнес-план та презентація 7 днів
Пошук інвестора /
1.1.5 10 днів
затвердження
1.2 Планування 25 днів
1.2.1 Планування якості та ризиків 4 дні
1.2.2 Планування ресурсів і бюджету 5 днів
1.2.3 Затвердження планів 3 дні
1.3 Реалізація 146 днів
Реєстрація ФОП та юридична
1.3.1 5 днів
підготовка
Проектування архітектури
1.3.2 30 днів
додатку
1.3.3 Розробка бекенд-модуля 40 днів
Розробка фронтенд-мобільного
1.3.4 40 днів
інтерфейсу
Інтеграція модулів і DevOps-
1.3.5 15 днів
налаштування
1.3.6 Data Science моделі та AI-логіка 20 днів
UI/UX-дизайн та
1.3.7 10 днів
прототипування
1.3.8 Тестування (авто + мануальне) 15 днів
1.3.9 Підготовка даних та контенту 7 днів
1.3.10 Маркетинг та рекламні банери 10 днів
1.3.11 Запуск у PlayMarket / AppStore 3 дні
1.4 Завершення 11 днів
Публікація / розміщення в
1.4.1 1 день
мережі
Архівація та передача
1.4.2 2 дні
документації
1.4.3 Розпуск команди / звітність 2 дні
79
Продовження таблиці 3.2
№ 1-го № 2-го № 3-го Оцінка
Назва задачі
рівня рівня рівня тривалості
Аналіз післярелізних
1.4.4 3 дні
результатів
1.4.5 Підтримка та моніторинг 3 дні
1.4.6 Проєкт закритий —
Система управління змістом передбачає також визначення бачення та користі
майбутнього продукту. Формується місія та очікувана цінність для різних груп
користувачів. У прикладі «МедОгляд AI» місія полягає в забезпеченні доступної
дистанційної взаємодії пацієнтів і лікарів, а ключова цінність — у зменшенні
навантаження на медичних працівників та підвищенні оперативності консультацій.
Важливо й те, що кінцевий результат фіксується у формі продуктової концепції —
тобто опису того, яким має бути готовий застосунок, які проблеми він розв’язує і які
функції забезпечує.
Після цього здійснюється збір і формалізація вимог від усіх зацікавлених
сторін: пацієнтів, лікарів, інвесторів, команди, ліцензіарів і регуляторних органів.
Окремі вимоги пов’язані із захистом даних, масштабованістю, стабільністю
застосунку та обов’язковими функціями медичної аналітики.
Для забезпечення повної прозорості планування та контролю робіт у межах
управління змістом проєкту формується сітьова діаграма, яка відображає логічні
зв’язки, залежності та послідовність виконання основних етапів. Сіткова модель
дозволяє не лише структурувати роботи відповідно до СДР, а й визначити критичний
шлях, оцінити тривалість усього проєкту та виявити можливі резерви часу. Це
особливо важливо для стартапу «МедОгляд AI», де тривалість етапів, їх
послідовність і своєчасність виконання мають прямий вплив на фінальний результат
розроблення мобільного застосунку.
Побудова діаграми ґрунтується на деталізованому розподілі робіт за фази
проєкту — ініціації, планування, реалізації та завершення — із зазначеними
критеріями переходу між ними (таблиця 3.2) і загальною оцінкою тривалості кожної
фази.
Рисунок 3.2 – Сітьова діаграма стартапу
Такий підхід дає можливість візуально відобразити взаємозалежності між
задачами (наприклад, формування команди, проектування архітектури, розробка
бекенд- та фронтенд-модулів, тестування та публікація застосунку) та визначити
роботи, які впливають на загальну тривалість проєкту.
Сітьова діаграма є важливим інструментом у процесі управління змістом,
оскільки допомагає координувати дії команди, оптимізувати розподіл ресурсів і
своєчасно виявляти ризики, пов’язані з можливими затримками. У контексті
стартапу, де команді необхідно працювати з високою швидкістю та гнучкістю,
сіткова модель стає основою для контролю ходу реалізації та досягнення
поставлених результатів у визначені строки.
Узгодження змісту із зацікавленими сторонами здійснюється через
застосування матриць впливу й інтересів. Такий підхід дає змогу зрозуміти, які саме
вимоги є пріоритетними, хто впливає на рішення щодо продукту та які потреби
мають бути враховані під час планування робіт.
Контроль змісту супроводжує проєкт протягом усього життєвого циклу. Він
охоплює перевірку відповідності виконаних робіт запланованому змісту, аналіз
потреби у змінах, усунення нерелевантних завдань і фіксацію необхідних коригувань
через формальні запити на зміни.
Значення управління змістом у стартапі є особливо велике. Воно допомагає
уникнути невиправданих витрат часу і бюджету, формує можливість створити
мінімально життєздатний продукт (MVP), дозволяє підтримувати пріоритети у
ситуаціях ринкової невизначеності, забезпечує прозорість для інвесторів і створює
чіткі очікування для команди. Усі ці аспекти визначають успішність реалізації
проєкту та забезпечують можливість створення конкурентоспроможного рішення.
У підсумку управління змістом стартапу виступає ключовою складовою
успішної реалізації інноваційного продукту. Воно встановлює чіткі межі майбутньої
системи, допомагає організувати роботу команди та створює передумови для того,
щоб кінцевий результат відповідав визначеним вимогам і очікуванням користувачів.
На прикладі «МедОгляд AI» видно, що поєднання формалізації вимог, структурного
аналізу, декомпозиції результату, деталізації робіт і системного контролю дозволяє
82
розробити життєздатний та практично корисний продукт у сфері eHealth,
оптимізувавши ресурси та мінімізувавши ризики.
3.2 Побудова складу команди стартапу та розподіл відповідальностей
Формування команди стартапу є одним із фундаментальних етапів управління
проєктом, оскільки саме від правильно підібраних ролей, компетенцій та ефективної
взаємодії залежить здатність стартапу створити конкурентоспроможний продукт у
стислий термін. Для інноваційних технологічних проєктів, таких як «МедОгляд AI»,
структура команди повинна забезпечувати повний цикл розробки: від бізнес-ідеї та
медичної експертизи — до програмної реалізації, тестування та впровадження. В
умовах високої динаміки ринку eHealth і високих вимог до якості застосунків, що
опрацьовують персональні медичні дані, формування компетентної команди є
критичним чинником успіху.
Команда стартапу зазвичай вибудовується на принципах
кросфункціональності, гнучкості ролей і мінімально необхідного складу, що
відповідає підходам Agile, Scrum та Lean Startup. Це означає, що кожен учасник не
лише виконує свою основну роль, а й бере участь у суміжних процесах,
забезпечуючи швидку командну взаємодію й адаптацію до змін. У проєкті
«МедОгляд AI» команда включає дев’ять ключових категорій учасників, які
охоплюють як технічні й інженерні компетенції, так і управлінські, аналітичні та
клієнтські напрями. Згідно з даними файлів практичних робіт, загальна кількість
учасників становить 29 осіб, що дозволяє розподілити обов’язки між спеціалістами
різного рівня кваліфікації та забезпечити redundancy у критичних зонах, таких як
Back-End, Front-End та QA. Для узагальнення склад команди подано в таблиці 3.3.
Правильний підбір компетенцій дає змогу покрити основні процеси
розроблення мобільного застосунку, включно з архітектурою бекенду,
користувацьким інтерфейсом, інфраструктурою DevOps, тестуванням, медичною
експертизою та побудовою моделей штучного інтелекту. Усі ці елементи є
83
нерозривними для створення телемедичного рішення, що відповідає вимогам GDPR,
HIPAA і медичних протоколів, про що зазначено у вихідних матеріалах проєкту.
Таблиця 3.3 – Склад команди стартапу «МедОгляд AI»
Рівні спеціалістів
№ Роль / команда Кількість
(Lead/Senior/Middle/Junior)
1 Project Manager 1 Lead
2 Back-End Engineers 6 1 Lead, 2 Senior, 2 Middle, 1 Junior
3 Front-End Engineers 5 1 Lead, 2 Senior, 2 Middle
4 DevOps Engineers 3 1 Lead, 2 Senior
5 Data Science 3 1 Lead, 2 Senior
6 QA Engineers 7 1 Lead, 3 Senior, 2 Middle, 1 Junior
7 Medical Engineers 3 3 Middle
8 HR Manager 1 Middle
9 Product Owner / Ініціатор 1 Lead
Для забезпечення ефективної роботи команда має чітко визначені функції й
відповідальність кожного учасника. Узагальнений опис ролей подано в таблиці 3.4.
Таблиця 3.4 – Ключові ролі та їх відповідальність
Основні
Роль Відповідальність
функції
Project Координація робіт, планування, Виконання проєкту в термін,
Manager управління ризиками, бюджетом, якість результату, узгодження
комунікаціями рішень
Back-End Архітектура сервера, API, бази Стабільна робота бекенду,
команда даних, безпека інтеграція всіх модулів
Front-End Інтерфейс мобільного застосунку, Зручність, доступність та
команда UX-сценарії продуктивність UI
DevOps Сервери, CI/CD, інфраструктура,
Безперебійна робота сервісу
релізи
Data Science ML-моделі, аналітика, обробка Точність і коректність AI-
медичних даних рекомендацій
QA Мануальне й автоматизоване Відсутність критичних дефектів,
тестування стабільність продукту
84
Продовження таблиці 3.4
Основні
Роль Відповідальність
функції
Medical Медична перевірка, клінічні Медична валідність продукту
Engineers протоколи, тестування сценаріїв
HR Manager Підбір персоналу, адаптація, Укомплектованість та ефективна
підтримка команди взаємодія команди
Product Формування бачення продукту, Цінність продукту та
Owner затвердження функцій відповідність ринку
Щоб забезпечити прозорість взаємодії між різними ролями та уникнути
дублювання обов’язків, у стартапі застосовується матриця RACI — інструмент,
рекомендований PMBOK та ISO 21502, що дозволяє розподілити відповідальність за
ключові завдання (Responsible, Accountable, Consulted, Informed). Для проєкту
«МедОгляд AI» така матриця побудована на основі високорівневих робіт СДР
(структури декомпозиції робіт) та специфіки ролей у команді (таблиця 3.5).
Таблиця 3.5 – Матриця відповідальності RACI
Dev
Завдання PM BE FE QA DS ME HR
Ops
Збір і формалізація вимог A I I I C I C I
Проєктування архітектури C A/R I I I C I I
Розробка бекенд-модуля I A/R I C I I I I
Розробка фронтенд-
I I A/R C I I I I
інтерфейсу
Побудова AI-моделей I I I C A/R I C I
Налаштування
I C I C I A/R I I
інфраструктури
Тестування продукту C I I A/R I C I I
Формування команди A I I I I I I R
Запуск у Google Play /
A C C C C R I I
AppStore
85
Завдяки чітко визначеним ролям, обов’язкам та структурі взаємодії команда
стартапу здатна працювати злагоджено навіть у ситуаціях постійної зміни вимог,
необхідності швидкого прототипування та високої відповідальності перед кінцевими
користувачами — лікарями та пацієнтами. Такий підхід не лише підвищує
продуктивність команди, а й забезпечує прозорість процесів, мінімізує ризики,
сприяє швидшому ухваленню рішень і формує передумови для успішного
масштабування стартапу.
3.3 Календарне планування стартапу
Календарний план стартапу створення мобільного застосунку для медичних
працівників та пацієнтів:
Проєкт триває 233 дны.
З них:
Ініціація – 41 день.
Планування – 25 днів.
Реалізація – 146 днів.
Завершення – 11 днів.
Для наочного відображення тривалості та послідовності робіт було
підготовлено діаграму Ганта та календарний план проєкту, подані на рис. 3.3 – 3.6.
Рисунок 3.3 – Календарний план стартапу в ProjectLibre (Перша частина)
Рисунок 3.4 – Календарний план стартапу в ProjectLibre (Друга частина)
Рисунок 3.5 – Діаграма Ганта стартапу в ProjectLibre (Початок)
Рисунок 3.6 – Діаграма Ганта стартапу в ProjectLibre (Закінчення)
3.4 Планування ресурсів та вартості стартапу
Планування бюджету є одним з центральних процесів управління проєктом,
оскільки воно визначає фінансові межі розробки, дозволяє прогнозувати
навантаження на ресурси та забезпечує контроль витрат на всіх етапах реалізації. В
умовах стартапу, де фінансування обмежене, а ринкова невизначеність висока,
особливо важливим є точне визначення обсягів інвестицій, розподіл вартості між
фазами та формування фінансових резервів на випадок ризиків. Бюджет проєкту
«МедОгляд AI» був сформований відповідно до структури робіт (СДР), кадрового
складу, оцінок тривалості завдань і прогнозованих потреб у матеріальних та
операційних ресурсах.
Загальна вартість проєкту становить 607 200 $, що охоплює весь життєвий
цикл — від ініціації та планування до розробки, публікації застосунку та
післярелізної підтримки. Це фінансування включає витрати на персонал, хмарні
сервіси, програмне забезпечення, офісну інфраструктуру, маркетинг і додаткові
операційні потреби. Структура бюджету відображає пріоритети проєкту:
домінуючими є витрати на людські ресурси (понад 85 % загальної суми), що
характерно для сучасних ІТ-стартапів.
Бюджет проєкту формується за методом bottom-up, який передбачає
оцінювання вартості кожної задачі, ролі та статті витрат окремо, а потім — їх
об’єднання в загальний фінансовий план. Такий підхід дає змогу досягти
максимальної точності та забезпечити кореляцію між бюджетом і реальним обсягом
робіт.
Для проєкту були враховані:
тривалість кожного завдання (від 1 до 40 днів),
кількість задіяних фахівців,
рівень кваліфікації (Lead, Senior, Middle, Junior),
зарплати учасників,
офісні та зовнішні витрати,
91
річні та місячні ліцензійні платежі,
маркетингові витрати,
післярелізні витрати та підтримка.
Унаслідок цього бюджет має детальну структуру, що дозволяє здійснювати
контроль на кожній фазі (таблиця 3.6).
Таблиця 3.6 – СДР проєкту (після оцінки вартості)
№ 1-го № 2-го № 3-го Оцінка Оцінка
Назва задачі Ресурси
рівня рівня рівня тривалості вартості
Розробка мобільного
1 223 дні — —
застосунку “MedOglad AI”
1.1 Ініціація проєкту 41 день PM, HR 135 000 $
1.1.1 Формування команди 9 днів PM, HR 10 000 $
1.1.2 Формалізація ідеї 10 днів PM 5 000 $
1.1.3 Аналіз ринку 5 днів DS 3 000 $
1.1.4 Бізнес-план і презентація 7 днів PM, FA 7 000 $
Пошук інвестора /
1.1.5 10 днів PM 7 000 $
затвердження
PM, QA,
1.2 Планування 25 днів 82 000 $
FA
Планування якості та
1.2.1 4 дні QA, PM 4 000 $
ризиків
Планування ресурсів і
1.2.2 5 днів PM, FA 8 000 $
бюджету
1.2.3 Затвердження планів 3 дні PM 2 000 $
уся
1.3 Реалізація 146 днів 481 000 $
команда
Реєстрація ФОП / юр.
1.3.1 5 днів PM 2 000 $
підготовка
Проєктування архітектури BE Lead,
1.3.2 30 днів 20 000 $
додатку DevOps
1.3.3 Розробка бекенд-модуля 40 днів BE team 120 000 $
Розробка фронтенд-
1.3.4 40 днів FE team 100 000 $
інтерфейсу
Інтеграція модулів і
1.3.5 15 днів DevOps 25 000 $
DevOps-налаштування
Data Science моделі та AI-
1.3.6 20 днів DS team 60 000 $
логіка
92
Продовження таблиці 3.6
№ 1-го № 2-го № 3-го Оцінка Оцінка
Назва задачі Ресурси
рівня рівня рівня тривалості вартості
UI/UX-дизайн і FE,
1.3.7 10 днів 10 000 $
прототипування Design
Тестування (авто +
1.3.8 15 днів QA team 25 000 $
мануальне)
Підготовка даних і
1.3.9 7 днів DS, ME 5 000 $
контенту
PM,
1.3.10 Маркетинг та банери 10 днів 7 000 $
Design
Публікація у PlayMarket / PM,
1.3.11 3 дні 3 000 $
AppStore DevOps
PM, FA,
1.4 Завершення 11 днів 36 000 $
HR
Розміщення застосунку в
1.4.1 1 день DevOps 2 000 $
мережі
1.4.2 Архівація документації 2 дні PM 1 000 $
Розпуск команди /
1.4.3 2 дні HR, PM 1 000 $
звітність
Аналіз післярелізних
1.4.4 3 дні PM, FA 2 000 $
результатів
QA,
1.4.5 Підтримка та моніторинг 3 дні 7 000 $
DevOps
Людські ресурси становлять основу програми проєкту, адже саме командна
робота формує інфраструктуру, логіку, інтерфейс та AI-компоненти застосунку.
Загальна команда налічує 29 осіб, серед яких програмісти, аналітики, DevOps, Data
Science фахівці, тестувальники, медичні інженери та менеджери (таблиця 3.7).
Таблиця 3.7 – Місячні витрати на персонал
Місячні
№ Команда Кількість
витрати, $
1 Back-End (6 осіб) 1 Lead, 2 Senior, 2 Middle, 1 Junior 16 000 $
2 Front-End (5 осіб) 1 Lead, 2 Senior, 2 Middle 13 900 $
3 DevOps (3 осіб) 1 Lead, 2 Senior 9 600 $
4 Data Science (3 осіб) 1 Lead, 2 Senior 9 900 $
5 QA (7 осіб) 1 Lead, 3 Senior, 2 Middle, 1 Junior 12 600 $
93
Продовження таблиці 3.7
Місячні
№ Команда Кількість
витрати, $
Medical Engineers (3
6 3 Middle 5 100 $
осіб)
7 Project Manager 1 2 500 $
8 HR Manager 1 1 700 $
Місячні витрати на персонал: 71 300 $.
На основі тривалості етапів (10 місяців активної розробки та 2 місяці
підтримки) загальні витрати на персонал становлять близько: ~ 570 000 $.
Це відповідає світовій практиці: в стартапах ІТ-сектору людський капітал
становить приблизно 80–90 % бюджету.
Окрім людських ресурсів, проєкт потребує забезпечення матеріально-технічної
бази: офісу, обладнання, хмарних сервісів, ліцензій та інфраструктури (таблиця 3.8).
Таблиця 3.8 – Матеріальні ресурси
Вартість,
№ Ресурс
$/рік
1 Програмне забезпечення / ліцензії 4 000 $/рік
2 Офіс 2 000 $/міс
3 Інтернет 50 $/міс
4 Комунальні послуги 75 $/міс
5 Прибирання 300 $/міс
6 Додаткові витрати (чай, кава, корпоративи) 5 000 $/рік
У розрахунку на рік матеріальні витрати складають приблизно: ~ 36 000 $.
Це включає базові інфраструктурні потреби та підтримку комфортних умов
роботи команди.
Бюджет проєкту логічно узгоджується з його структурою робіт.
Етап 1. Ініціація (41 день).
Потребує участі PM, HR та Data Science аналітиків.
Витрати: ~ 10 % від загального бюджету.
94
Включає: формування команди, аналіз ринку, бізнес-план, підготовку
презентацій та узгодження інвестицій.
Етап 2. Планування (25 днів).
Задіяні PM, QA і фінансові фахівці.
Витрати: ~ 6 %.
Охоплює планування якості, ризиків, бюджету, ресурсів, структури робіт.
Етап 3. Реалізація (146 днів).
Наймасштабніший блок — працюють всі 29 учасників.
Витрати: ~ 75 %.
Сюди належать:
розробка архітектури,
створення бекенд- і фронтенд-модулів,
AI-моделювання,
дизайн UI/UX,
DevOps-інфраструктура,
тестування,
створення медичного контенту,
маркетинг і підготовка релізу.
Етап 4. Завершення (11 днів).
Участь беруть PM, DevOps, HR, QA.
Витрати: ~ 3–4 %.
Включає розміщення додатку, архівацію документації, звітність та первинний
моніторинг.
Проєкт має низку потенційних ризикових факторів, пов’язаних з:
можливим збільшенням тривалості розробки,
додатковими вимогами до AI-алгоритмів,
необхідністю розширення інфраструктури,
появою критичних дефектів на етапах тестування,
вимогами регуляторів у сфері медицини,
95
інтеграцією з медичними системами.
Для їх покриття передбачено резерв на непередбачені витрати:
10–15 % бюджету (≈ 60 000–90 000 $).
Це дозволяє підтримувати фінансову стабільність навіть у разі коригування
функціоналу чи збільшення обсягів робіт.
У таблиці 3.9 наведено узагальнення бюджету стартапу.
Таблиця 3.9 – Бюджет стартапу у відсотковому співвідношенні:
Частка
№ Стаття витрат Сума
бюджету
1 Людські ресурси 85–88 % ~ 530 000–560 000 $
2 Матеріальні та офісні витрати 6–7 % ~ 36 000 $
3 Ліцензії та програмне забезпечення 1 % ~ 4 000 $
4 Маркетинг та публікація 2–3 % ~ 12 000–18 000 $
5 Резерв на ризики 10–15 % ~ 60 000–90 000 $
Підсумкова вартість проєкту: ≈ 607 200 $.
Планування бюджету проєкту «МедОгляд AI» демонструє комплексний і добре
структурований підхід до формування фінансової моделі стартапу. Завдяки
поєднанню деталізованої оцінки людських та матеріальних ресурсів, розподілу
витрат за фазами, застосування методу bottom-up і формування резервів на ризики
створено бюджет, який відповідає реальним потребам високотехнологічного eHealth-
продукту. Такий підхід забезпечує прозорість, фінансову стійкість і можливість
масштабування рішення у майбутньому.
3.5 Управління якістю стартапу
Управління якістю в стартапі «МедОгляд AI» є ключовим елементом
організації всієї проєктної діяльності, оскільки продукт належить до сфери eHealth
та взаємодіє з персональними медичними даними, що потребує підвищеної точності,
безпеки та відповідності галузевим нормативам. Якість у цьому проєкті
розглядається як комплекс взаємопов’язаних процесів, які забезпечують стабільність
96
функціонування застосунку, достовірність аналітичних результатів та комфортну
взаємодію користувачів з системою. Українські дослідження вказують, що
системний підхід до управління якістю є одним з основних чинників успіху
високотехнологічних проєктів, де критично важливими є надійність та
передбачуваність роботи програмних систем [40].
Для забезпечення багаторівневого контролю якості на початкових етапах було
сформовано критерії очікуваної якості, які визначають параметри, за якими
оцінюється відповідність програмного продукту вимогам та стандартам. До них
належать: точність алгоритмів штучного інтелекту, продуктивність бекенд-
компонентів, стабільність інтерфейсу, захист персональних даних, відповідність
рекомендацій клінічним протоколам, а також загальна зручність використання.
Щоб систематизувати вимоги та забезпечити прозорий контроль на різних
етапах розроблення, було сформовано матрицю критеріїв якості, що подано в
таблиці 3.10.
Таблиця 3.10 – Критерії якості продукту «МедОгляд AI»
Критерії
№ Суть контролю Очікуваний результат
якості
Функціональна Коректність роботи Система працює стабільно без
1 якість модулів (чат, кабінет критичних помилок
лікаря, AI-відповіді)
Архітектурна Продуктивність API, Застосунок витримує одночасні
2 якість оптимізація запитів, запити користувачів
масштабованість
Якість даних Точність AI-моделей, Рекомендації відповідають
3
чистота датасетів визначеним медичним нормам
Інтерфейс та Зручність навігації, Користувач швидко знаходить
4 UX доступність, потрібний функціонал
адаптивність
Інформаційна Захист персональних Повна відповідність політикам
5
безпека даних, шифрування GDPR/HIPAA
Застосування цієї матриці дозволяє структурувати очікування стейкхолдерів і
перетворити загальні вимоги до якості на конкретні контрольовані параметри.
97
Наступним блоком управління якістю є система тестування, яка охоплює
модульні, інтеграційні, системні та регресійні перевірки. Тестування є безперервним
процесом, інтегрованим у всі спринти. Українські дослідження зазначають, що
якісно вибудувана система тестування знижує частоту дефектів і підвищує зрілість
розробки, особливо в комплексних ІТ-проєктах [41; 43].
У межах проєкту була створена таблиця 3.11 узагальнення методів тестування,
наведена нижче.
Таблиця 3.11 – Методи забезпечення якості і testing-процедури
Вид
№ Що перевіряється Виконавці Очікуваний результат
тестування
Правильність роботи Відсутність локальних
QA, BE,
1 Модульне окремих функцій бекенду помилок
FE
та фронтенду
Взаємодія між API, AI- QA, Узгодженість роботи
2 Інтеграційне
модулем, базою даних DevOps компонентів
Робота продукту в цілому Стабільність застосунку
3 Системне QA
під навантаженням
Помилки після змін та Відсутність повторних
4 Регресійне QA
оновлень дефектів
Точність моделей, медична Модель працює у межах
AI-
5 валідність, відсутність DS, ME клінічної норми
тестування
упередженості
Використання різних рівнів тестування дозволяє охопити повний
технологічний цикл — від окремих модулів до комплексної перевірки застосунку,
включно з оцінкою AI-алгоритмів, що особливо важливо для медичних систем [44].
Окрему роль в управлінні якістю відіграє медична експертиза, яка забезпечує
перевірку відповідності AI-відповідей, рекомендацій і логіки поведінки системи
клінічним нормам та стандартам. Ця функція реалізується командою медичних
інженерів, які аналізують кейси, перевіряють коректність формулювань, оцінюють
ризикованість запропонованих алгоритмів. В українських джерелах наголошується
на важливості залучення медичних фахівців до оцінки ІТ-рішень у галузі охорони
98
здоров’я, оскільки програмні системи не можуть оцінювати медичний контекст
самостійно [42; 44].
Щоб інтегрувати медичні та технічні вимоги, у проєкті сформовано таблицю
3.12 контролю медичної якості, що подано нижче.
Таблиця 3.12 – Контроль медичної якості в eHealth-проєкті
Напрям Відповідал
№ Зміст Результат
перевірки ьні
Перевірка AI-логіка узгоджена з
Відповідність сценаріїв клінічними нормами
Medical
1 клінічним взаємодії, AI-
engineers
протоколам відповідей і
трактувань
Виявлення Medical Виявлені ризики усунені
2 Аналіз ризиків небезпечних engineers,
рекомендацій DS
Медична Стандартизований медичний
Перевірка
3 коректність ME, PM словник
термінології
термінів
Порівняння Досягнення прийнятної
Точність результатів AI з точності (≥85%)
4 DS
моделей реальними
кейсами
Інтеграція медичної експертизи в систему управління якістю забезпечує
відповідність продукту вимогам галузі та мінімізує ризики для користувачів.
Забезпечення якості доповнюється циклом вдосконалення, який включає
аналіз дефектів, колективні ретроспективи після спринтів, обговорення проблемних
сценаріїв, покращення технічної документації та оновлення модулів. Такий підхід
узгоджений з українською науковою традицією використання циклів покращення
якості у виробничих і програмних середовищах, що підтримує ефективність
командної роботи та стійкість продукту [40].
Управління якістю в проєкті «МедОгляд AI» побудоване як багаторівнева
система, що охоплює технічні, процедурні, клінічні та експлуатаційні аспекти
роботи продукту. Вона включає чітко визначені критерії якості, узгоджені процеси
99
тестування, медичну валідацію, структуровану роботу з помилками та механізми
безперервного вдосконалення. Такий підхід забезпечує надійність і безпечність
продукту, що є обов’язковою передумовою для виходу на ринок цифрових медичних
рішень.
3.6 Управління ризиками стартапу
Управління ризиками у проєкті «МедОгляд AI» розглядається як
структурована система прогнозування, виявлення та контролю потенційних загроз,
що можуть вплинути на строки, бюджет, функціональність і безпеку цифрового
медичного продукту. У дослідженнях українських авторів підкреслюється, що
найважливішим аспектом ризик-менеджменту в ІТ-проєктах є системність,
міждисциплінарність та неперервність моніторингу [46]. Особливо це стосується
галузі eHealth, де ризики мають гібридну природу — технічну, медичну, правову,
кадрову та ринкову.
Для формування цілісної системи управління ризиками у проєкті було
проаналізовано всі етапи реалізації, структуру робіт, ролі команди, вимоги до AI-
модулів та регуляторні обмеження. У результаті виділено 12 основних ризиків, які
мають найбільший потенційний вплив.
1. Технічний ризик нестабільності роботи бекенд-архітектури.
Цей ризик виникає через потенційну надмірність запитів, недостатню
оптимізацію API або помилки у мікросервісній архітектурі. Наслідками можуть
стати затримки відповіді, недоступність сервісу та скарги користувачів. Для
мінімізації застосовуються профілювання продуктивності, оптимізація бази даних та
тестування під навантаженням.
2. Некоректна робота або «дрейф» моделей штучного інтелекту.
Моделі машинного навчання можуть втрачати точність через зміну структури
даних, недостатню кількість прикладів або недосконалість аналітичних алгоритмів.
Це створює ризик отримання некоректних відповідей, що є критично небезпечним у
100
медичній сфері. Українські автори наголошують, що ризики AI-систем потрібно
оцінювати окремо від загальних технічних ризиків [48].
3. Ризик отримання некоректних медичних рекомендацій.
Навіть за стабільної роботи AI виникає ймовірність помилкової інтерпретації
симптомів або невідповідності рекомендацій клінічним протоколам. Це може стати
підставою для юридичних претензій та втрати довіри користувачів. Для зменшення
ризику передбачено подвійний медичний аудит та перевірку сценаріїв лікарями-
експертами.
4. Ризики інформаційної безпеки та витоку медичних даних.
Витік конфіденційних медичних даних є одним з найризикованіших сценаріїв,
адже стосується чутливої інформації. Порушення GDPR/HIPAA може призвести до
штрафів та блокування сервісу. Для зниження ризику впроваджено багаторівневе
шифрування, контроль доступу та журналювання дій користувачів.
5. Порушення правових вимог регуляторів.
Медичні застосунки потребують відповідності міжнародним стандартам, а
також дотримання локального регулювання. Помилки у юридичній підготовці
можуть ускладнити випуск продукту на ринок. Дослідження [49] підкреслюють
важливість юридичних аудиторських перевірок для стартапів.
6. Ризик недостатньої кількості даних для навчання AI-моделей.
Якість аналітики напряму залежить від достатнього й коректного набору
даних. Ризик полягає у можливому обмеженні доступу до якісних медичних
датасетів. Для мінімізації плануються партнерства з клініками та використання
анонімізованих наборів даних.
7. Ризик затримки розробки через нестачу технічних ресурсів.
Перевантаження команди, нерівномірний розподіл задач або недостатня
кількість кваліфікованих розробників можуть подовжити строки проєкту. Для
зменшення ризику використовують гнучке планування, контроль завантаження
фахівців і можливе залучення зовнішніх розробників.
8. Ризик плинності кадрів.
101
У стартапах з високою конкуренцією на ринку праці відтік ключових
спеціалістів може суттєво вплинути на темпи розроблення. Для управління ризиком
формуються резерви на заміну фахівців, зберігаються записи знань (knowledge base)
та передбачено HR-план адаптації.
9. Ризик появи критичних помилок після релізу.
Складність системи створює можливість появи дефектів після випуску
застосунку. У роботах українських дослідників [50] зазначено, що післярелізний
контроль є обов’язковим елементом управління ризиками в ІТ-проєктах. Для
мінімізації ризику передбачено моніторинг роботи сервісу та швидкі гарячі
оновлення (hotfixes).
10. Ринковий ризик недостатньої готовності користувачів до AI-інструментів.
Медична спільнота може сприймати AI з обережністю, що вплине на темпи
зростання застосунку. Для мінімізації ризику заплановано масштабування в кілька
етапів, демонстраційні презентації для медичних установ та A/B-тестування.
11. Фінансовий ризик недостатності інвестицій на пізніх фазах.
Стартапи часто стикаються з тим, що на етапі масштабування витрати
зростають. Якщо прогнозована підтримка інвестора не буде отримана, проєкт може
втратити темп розвитку. Запобіжним заходом є створення резервного бюджету,
передбаченого на рівні 10–15 % загальної суми.
12. Ризик проблем із публікацією застосунку в PlayMarket/AppStore.
Регулятори мобільних магазинів особливо суворі до медичних застосунків,
тому можливі затримки або вимоги до доопрацювання. Ризик мінімізується
дотриманням їхніх політик, підготовкою повного пакета документації та попереднім
аудитом.
Наведені ризики систематизовано у таблиці 3.13.
Таблиця 3.13 – Основні ризики проєкту «МедОгляд AI» з урахуванням ваг впливу та ймовірності
Вага Інтег.
Категорія Ймовірність Хар-ка
№ Опис ризику впливу Хар-ка впливу рівень
ризику (0–0,99) ймовірності
(0–1) ризику*
Нестабільність бекенд-
1 Технічний 0,61 Значний вплив 0,5 Висока 0,305
архітектури
Дрейф моделей, зниження
2 Технічний (AI) 0,81 Критичний вплив 0,5 Висока 0,405
точності
3 Медичний Некоректні рекомендації AI 0,9 Критичний вплив 0,3 Середня 0,270
4 Безпека Витік персональних даних 0,8 Значний вплив 0,3 Середня 0,240
5 Правовий Порушення GDPR/HIPAA 0,75 Значний вплив 0,3 Середня 0,225
Недостатність даних для
6 Data 0,6 Помірний вплив 0,5 Висока 0,300
навчання AI
7 Організаційний Нестача технічних ресурсів 0,55 Помірний вплив 0,5 Висока 0,275
8 Кадровий Плинність ключових фахівців 0,4 Невеликий вплив 0,5 Висока 0,200
Технічний Критичні дефекти після
9 0,7 Значний вплив 0,3 Середня 0,210
(реліз) запуску
Неготовність лікарів
10 Ринковий 0,5 Помірний вплив 0,5 Висока 0,250
працювати з AI
Брак інвестицій на
11 Фінансовий 0,8 Значний вплив 0,3 Середня 0,240
масштабування
Затримка публікації в
12 Операційний 0,41 Помірний вплив 0,5 Висока 0,205
AppStore/Google Play
* Інтегральний рівень ризику = Вага впливу × Ймовірність
1. Шкала впливу (0–1).
Вплив для кожного ризику визначено на основі:
характеру наслідків (стабільність бекенду, безпека, медична точність),
критичності для користувачів,
можливості спричинити проблеми з регуляцией або довірою до
продукту.
2. Шкала ймовірності (0–1).
Оцінювалось за історичними трендами стартапів і складністю етапів:
технічні ризики мають 0,5, бо трапляються часто;
медичні та правові — 0,3, бо зазвичай добре контрольовані;
ринковий ризик — 0,5, адже поведінка користувачів непередбачувана.
3. Інтегральний рівень ризику.
Дає змогу виявити найкритичніші ризики кількісно:
0,405 — дрейф AI-моделей → найвищий ризик,
0,305 — нестабільність бекенду,
0,300 — недостатність даних для AI.
Для того, щоб наочно відобразити як поєднання ймовірності настання ризику
та сили його впливу формує загальний рівень загрози для проєкту, в роботі
використовується матриця ризиків (Таблиця 3.14).
Таблиця 3.14 – Матриця імовірностей та наслідків
Ймовірність /
0-0,2 0,21-0,4 0,41-0,6 0,61-0,8 0,81-1
вплив
0,9 3
0,7 4; 5; 9; 11 2
0,5 1; 6; 7; 10
0,3 8; 12
0,1
104
Така модель дозволяє швидко визначити ризики, що потребують
першочергового втручання, і раціонально розподілити заходи управління відповідно
до їх критичності для розробки медичного застосунку. У матриці так само
застосовано шкалу від 0 до 1 для обох параметрів, де 0 означає мінімальну
ймовірність або вплив, а 1 — максимально можливий рівень значущості ризику для
проєкту.
План реагування на ризики. Реагування ґрунтується на чотирьох стратегічних
підходах: уникнення, мінімізація, перенесення та прийняття. У проєкті «МедОгляд
AI» домінує стратегія мінімізації, що є логічним для інноваційних стартапів, де
усунути ризики повністю неможливо, але можна зменшити їхній вплив за рахунок
процедур контролю та технічних модифікацій. У таблиці 3.15 наведено план
реагування на ключові ризики.
Таблиця 3.15 – План реагування на ключові ризики
№ Ризик Стратегія Заплановані дії Відповідальні
Нестабільність Мінімізація Оптимізація бази даних,
1 BE Lead
бекенду рев’ю архітектури
Дрейф AI- Мінімізація Перенавчання моделей,
2 DS team
моделей моніторинг точності
Медичні помилки Уникнення + Подвійна медична
3 ME
мінімізація експертиза
Витік даних Перенесення Використання
4 сертифікованих сервісів DevOps
безпеки
Порушення Перенесення Юридичний аудит, аудит
5 PM, Legal
GDPR/HIPAA зберігання даних
Брак даних Мінімізація Партнерство з клініками,
6 DS
збір синтетичних даних
Нестача ресурсів Уникнення Балансування
7 PM
навантаження, аутсорс
Плинність кадрів Мінімізація Knowledge-base, HR-план,
8 HR
мотиваційні програми
Післярелізні Мінімізація Моніторинг логів, швидкі
9 QA, DevOps
дефекти hotfix-цикли
10 Ринкова недовіра Прийняття + A/B-тести, ознайомчі PM,
105
№ Ризик Стратегія Заплановані дії Відповідальні
мінімізація демонстрації Marketing
Брак Прийняття + Пошук додаткових
11 PM
фінансування перенесення інвестицій, резерв 10–15 %
Затримка Мінімізація Попередній аудит
12 публікації відповідності вимогам PM, DevOps
магазинів
Таким чином, отримали структурований і практичний підхід до реагування на
ризики. Особлива увага приділяється технологічним, медичним та регуляторним
ризикам, які мають найвищий можливий вплив на роботу застосунку та репутацію
стартапу, що підтверджено українськими дослідженнями в сфері управління
ризиками ІТ-проєктів [46–50].
Система управління ризиками у проєкті «МедОгляд AI» побудована як
комплексний процес, що охоплює ідентифікацію, аналіз, оцінювання та реагування
на ризики на всіх етапах життєвого циклу. Завдяки впровадженню трирівневої
структури — перелік ризиків → їх оцінювання → план реагування — проєкт
отримує інструментарій для прогнозування та зменшення впливу негативних
факторів. Особливістю цього стартапу є поєднання технічних, медичних і правових
ризиків, що вимагає залучення різнопрофільних команд та постійного моніторингу.
Використання методів risk scoring, превентивних медичних перевірок, юридичних
аудитів та технологічних рев’ю формує стійку систему, спрямовану на підтримку
якості й безпеки цифрового медичного продукту.
Висновки до розділу 3
У третьому розділі сформовано узгоджену основу для організації та
управління проєктом створення мобільного медичного застосунку «МедОгляд AI».
Визначено зміст проєкту, декомпозицію результатів та структуру робіт, що
дозволило окреслити межі продукту і узгодити ключові функції з потребами
користувачів та цільовими показниками стартапу.
106
Аналіз ресурсів показав міждисциплінарний характер проєкту, що потребує
узгодженої роботи технічної команди, фахівців з даних, тестувальників та медичних
експертів. Побудова бюджету та розподіл витрат за етапами забезпечили фінансову
прозорість і можливість контролю навантаження на команду.
У межах управління якістю визначено критерії та підходи, необхідні для
гарантування стабільності архітектури, точності AI-модулів і медичної коректності
рекомендацій. Додатково розглянуто систему тестування як базовий інструмент
підтримання надійності.
Комплексний аналіз ризиків дав змогу визначити найважливіші загрози та
сформувати дієві стратегії реагування. Використання матриць оцінки та плану
реагування підвищило стійкість проєкту до технічних, медичних і організаційних
викликів.
107
4 МОДЕЛЮВАННЯ ВИКОНАННЯ СТАРТАПУ
4.1 Опис моделювання продукту стартапу
Моделювання продукту є ключовим етапом, що забезпечує формування
цілісної архітектури та логіки роботи мобільного застосунку «MedOglad AI», який
створюється як інструмент для безперервної взаємодії між лікарем і пацієнтом,
доповненої можливостями штучного інтелекту. На цьому етапі визначаються функції
системи, її поведінка, межі MVP та вимоги до реалізації, що дозволяє перетворити
концепцію стартапу на структурований технічний проєкт.
Першим кроком моделювання є формування узагальненого профілю продукту.
З огляду на матеріали проєкту, його функціональну спрямованість та обмеження
eHealth-ринку, структуровано визначаються ключові параметри системи (Табл. 4.1).
Таблиця 4.1 – Основні характеристики продукту стартапу
Характеристика Зміст
Назва продукту Мобільний застосунок «MedOglad AI»
Сфера eHealth, дистанційна медицина, AI-підтримка прийняття рішень
застосування
Цільова аудиторія Пацієнти, лікарі, приватні клініки, медичні центри
Основна цінність Автоматизована взаємодія з пацієнтом та первинна оцінка стану
здоров’я
Ключові ML-моделі, CDS (Clinical Decision Support), мобільний
технології інтерфейс, хмарна інфраструктура
Захист даних Відповідність GDPR та HIPAA (на основі матеріалів
HealthPrecision)
Формат продукту Мобільний застосунок (Android/iOS), серверна платформа, AI-
модуль
Узагальнені характеристики окреслюють межі проєкту та задають рамки для
подальшого функціонального моделювання: система має відповідати медичним
стандартам, працювати стабільно в режимі 24/7 та інтегруватися з AI-модулями.
108
Після визначення загальної концепції формується модель функціональності. У
фокусі — взаємодія між пацієнтом, лікарем та системою, у якій AI виконує роль
посередника та помічника. Перелік можливостей ґрунтується на аналізі вимог,
зазначених у практичних роботах, та особливостях MedOglad AI як медичного
застосунку (Таблиця 4.2).
Таблиця 4.2 – Функціональні можливості продукту
Група функцій Опис
Комунікація лікаря з Чат, обмін повідомленнями, надсилання фото/файлів,
пацієнтом рекомендацій лікаря
AI-сервіси Первинна оцінка симптомів, генерація відповідей,
формування рекомендацій (на основі ML та правил)
Медична аналітика Відстеження динаміки, формування ризикових
індикаторів, нагадування
Управління Реєстрація лікаря, пацієнта; прив’язка до клініки; ролі та
користувачами доступи
Обробка медичних Збереження історії звернень, бази рекомендацій,
даних автоматизована ескалація до лікаря
Оплата та монетизація Налаштування тарифів, внутрішні платежі, підписки
Безпека та відповідність
Шифрування, аудит дій, відповідність GDPR/HIPAA
стандартам
Окреслення функціональних можливостей формує ядро системи та
підготовлює основу для відбору функцій, які увійдуть до MVP. Усі можливості
мають відповідати медичним протоколам і стандартам захисту даних, що
узгоджується з міжнародними вимогами.
MVP визначається як мінімально життєздатний набір функцій, який дозволяє
перевірити бізнес-гіпотези, зокрема:
попит на AI-консультації,
ефективність автоматизованої комунікації,
готовність користувачів до формату дистанційного моніторингу.
Формування MVP базується на пріоритетності задач, зазначених у структурі
робіт (СДР) проєкту, та враховує часові й фінансові обмеження eHealth-стартапу
(Таблиця 4.3).
109
Таблиця 4.3 – Основні функції MVP мобільного застосунку
Компонент MVP-функції
Комунікація Базовий чат «пацієнт—лікар»; надсилання текстових
повідомлень
AI-модуль Первинний аналіз симптомів, автоматичні короткі відповіді
Користувацький
Реєстрація пацієнта, лікаря, прив’язка до клініки
профіль
Медичні дані Збір скарг, збереження історії звернень
Нагадування Базові push-сповіщення про прийом ліків/візити
Безпека Авторизація, шифрування, політика конфіденційності
Інтерфейс Мінімалістичний UI для швидкої навігації
MVP сфокусований на функціях, що дозволяють створити реальну цінність
для першої хвилі користувачів і при цьому мінімізують витрати на початкову
розробку. Такий підхід відповідає класичній методології Lean Startup та вимогам
eHealth-індустрії.
Моделювання підтверджує, що продукт має включати кілька взаємопов’язаних
рівнів:
1. Клієнтський шар (мобільний застосунок): UX/UI, чат, профілі,
налаштування.
2. Серверний шар: бекенд-логіка, робота з базами даних, авторизація.
3. AI-рівень: моделі машинного навчання, модуль клінічних правил та
аналітика.
4. Інтеграційний рівень: підключення зовнішніх сервісів, відповідність
HIPAA/GDPR.
5. Адміністративна панель: контроль роботи лікарів, клінік, статистика.
Архітектура продукту демонструє підхід де аналітичний рівень працює поверх
структурованих даних, забезпечуючи персоналізовані рекомендації та автоматичну
ескалацію повідомлень лікарю.
110
4.2 Тестування мобільного застосунку
Тестування мобільного застосунку є одним із ключових етапів життєвого
циклу розробки, що забезпечує відповідність продукту функціональним вимогам,
стандартам якості, вимогам безпеки та очікуванням кінцевих користувачів. У
контексті нашого стартапу «MedOglad AI», де застосунок працює з медичними
даними та функціями підтримки клінічних рішень, процес тестування набуває
особливо високої значущості.
Нижче подано покроковий опис процесу тестування, який
охоплює планування, підготовку середовища, проведення тестів, документування та
аналіз результатів.
1. Планування тестування.
На цьому етапі формуються основні елементи QA-стратегії:
1.1. Визначення обсягу тестування.
Проводиться аналіз вимог (ФТ, НФТ), специфікацій та архітектури застосунку.
Встановлюється, які функції, модулі та платформи охоплюються тестами:
функціональні модулі: чат, реєстрація, AI-модуль, нагадування, історія
звернень;
платформи: Android/iOS, різні розміри екранів;
інтеграції: бекенд-API, хмарні сервіси, AI-модель, push-сповіщення;
вимоги безпеки: автентифікація, шифрування.
1.2. Вибір методів тестування.
Для мобільного застосунку використовуються такі групи тестів:
функціональне тестування;
нефункціональне (продуктивність, навантаження, безпека);
регресійне тестування;
юзабіліті-тестування;
кросплатформне та кросбраузерне тестування;
тестування AI-модуля (валідність відповідей, коректність обробки
симптомів).
111
1.3. Підготовка тестової документації:
Test Plan;
Test Suite;
Test Cases;
Acceptance criteria;
Checklist для критичних функцій;
User Stories + критерії приймання.
Документація формується відповідно до вимог Agile/Scrum, що дозволяє
оновлювати тестові сценарії разом зі змінами у продукті.
2. Підготовка тестового середовища.
2.1. Налаштування тестових інструментів.
Використовуються:
Android Studio, Xcode – емулятори та збірки;
Postman / Swagger – тестування API;
Firebase Test Lab / BrowserStack – мультипристрої;
JMeter / K6 – навантажувальні тести;
OWASP ZAP / Burp Suite – базове тестування безпеки;
CI/CD (GitHub Actions / GitLab CI) – автоматизовані тести та перевірки
збірок.
2.2. Формування тестових облікових записів.
Створюються окремі типи користувачів:
лікар,
пацієнт,
адміністратор клініки,
тестові пацієнти з різними сценаріями.
2.3. Наповнення тестових даних.
Для AI-модуля та історії звернень наповнюються тестові бази:
скарги,
симптоми,
112
відповіді моделі,
типові медичні випадки.
3. Проведення функціонального тестування.
Функціональне тестування охоплює перевірку того, що кожна функція працює
згідно з вимогами.
3.1. Тестування реєстрації та авторизації.
створення акаунту пацієнта/лікаря;
відновлення пароля;
тестування помилкових сценаріїв;
перевірка захисту від brute-force.
3.2. Тестування чату.
надсилання/отримання текстових повідомлень;
обробка вкладень (фото, PDF);
синхронізація повідомлень між пристроями;
offline/online режим.
3.3. Тестування AI-модуля.
коректність розпізнавання симптомів;
генерація відповідей згідно з медичним протоколом;
обробка некоректних запитів;
валідація рекомендацій лікарем (doctor-in-the-loop).
3.4. Тестування аналітики та нагадувань.
генерація push-сповіщень;
стабільність при закритому застосунку;
точність часу сповіщень;
історія нагадувань.
3.5. Тестування медичних даних.
збереження історії звернень;
перевірка формату та доступів до даних;
оновлення та видалення медичних записів.
113
4. Нефункціональне тестування.
Містить оцінку якості, продуктивності, безпеки та юзабіліті.
4.1. Тестування продуктивності
швидкість запуску застосунку;
час відповіді API;
навантаження при багатьох чат-повідомленнях;
поведінка при нестабільному інтернеті.
4.2. Тестування безпеки.
Особливо важливе для eHealth-рішень.
Перевіряється:
шифрування (TLS, зберігання токенів);
SQL Injection, XSS, CSRF;
правильність ролей і доступів (RBAC);
збереження медичних даних за GDPR/HIPAA.
4.3. Юзабіліті-тестування.
Проводиться з тестовими користувачами (пацієнти/лікарі):
інтуїтивність інтерфейсу,
зручність навігації,
доступність шрифтів,
зрозумілість медичних повідомлень.
4.4. Кросплатформне тестування.
Перевіряються різні пристрої:
Android (7–14), iOS (12–17);
смартфони/планшети;
різні роздільності екранів (HD, FHD, QHD).
5. Автоматизоване тестування.
Частина тестів (регресія, API, smoke) автоматизується:
UI-тести – Appium;
API-тести – Postman/Newman;
114
регресійні тестові набори – через CI/CD;
статичний аналіз коду – SonarQube.
Автоматизація дозволяє значно прискорити розгортання нових версій, що є
критичним для стартапу.
6. Документування результатів.
Після кожного циклу тестування команда QA оформлює:
Test Report;
Defect List;
Bug Priority & Severity;
відсоток покриття тестами;
рекомендації щодо поліпшення.
Особливо виділяються помилки, що впливають на медичні дані або роботу AI.
7. Ретест та регресія.
Після виправлення дефектів виконується:
ретест – перевірка конкретного виправлення;
регресія – перевірка, що виправлення не порушило інші функції.
регресія запускається як автоматизовано, так і вручну (для критичних модулів).
8. Завершення тестування та приймання.
Завершальний етап включає:
перевірку всіх acceptance criteria;
проходження smoke-тесту релізної збірки;
підготовку підсумкового звіту;
презентацію результатів команді розробки та замовнику;
підтвердження готовності застосунку до публікації в Store.
Після підтвердження проходження всіх вимог застосунок готовий до
розміщення у Play Market / App Store.
Детальний процес тестування забезпечує контроль над якістю, стабільністю та
безпекою мобільного застосунку, що особливо важливо для медичних систем. У
стартапі «MedOglad AI» QA-процеси охоплюють як базову функціональність (чат,
115
реєстрація, дані), так і специфічні аспекти, такі як тестування AI-модуля, коректність
медичних рекомендацій і відповідність HIPAA/GDPR.
Такий підхід гарантує готовність продукту до реального використання у
медичній практиці, а також забезпечує високу довіру користувачів і медичних
установ.
Завершальний етап тестування охоплює перевірку відповідності застосунку
критеріям приймання, виконання smoke-тесту релізної збірки, підготовку
підсумкового звіту та презентацію результатів команді розробки та замовнику. Після
підтвердження проходження всіх вимог і відсутності блокуючих дефектів застосунок
вважається готовим до розміщення у Play Market або App Store.
Для забезпечення системності тестування використовується таблиця тестових
сценаріїв. Приклад подано в таблиці 4.4.
Таблиця 4.4 – Приклад тестових сценаріїв (Test Cases)
Очікуваний
ID Назва сценарію Попередні умови Кроки перевірки Пріоритет
результат
1. Відкрити
Створено новий
Встановлений застосунок. 2.
акаунт, виконано
Реєстрація застосунок, Обрати
TC-01 авторизацію, High
пацієнта доступ до «Реєстрація». 3.
відкрито головний
інтернету Заповнити дані. 4.
екран.
Підтвердити.
1. Ввести Користувач
Авторизація з Існує
email/пароль. 2. успішно входить у
TC-02 правильними зареєстрований High
Натиснути систему без
даними акаунт
«Увійти». помилок.
1. Ввести email. 2. Відображається
Авторизація з Існує акаунт,
Ввести невірний повідомлення про
TC-03 неправильним пароль введено High
пароль. 3. помилку, доступ не
паролем неправильно
«Увійти». надано.
Повідомлення
Надсилання Авторизований 1. Відкрити чат. 2. відображається у
TC-04 повідомлення в користувач, Ввести текст. 3. стрічці чату, лікар High
чат активний чат «Надіслати». бачить його зі
свого інтерфейсу.
116
Продовження таблиці 4.4
Очікуваний
ID Назва сценарію Попередні умови Кроки перевірки Пріоритет
результат
Вкладення
1. Відкрити чат. 2.
Надсилання надсилається,
Авторизація Прикріпити
TC-05 вкладення відкривається у Medium
виконана фото/файл. 3.
(фото/файл) лікаря без
«Надіслати».
помилок.
AI формує
1. Відкрити AI-
Робота AI- структуровану
Авторизація модуль. 2. Ввести
TC-06 модуля (аналіз відповідь, дані High
виконана симптоми. 3.
симптомів) відображаються
Надіслати.
коректно.
1. Відкрити
Нове нагадування
«Нагадування». 2.
Створення Авторизований створене й
TC-07 Додати Medium
нагадування пацієнт відображається у
нагадування. 3.
списку.
Зберегти.
Користувач
Активне 1. Почекати на час отримує
Отримання push-
TC-08 нагадування в сповіщення. 2. сповіщення, навіть High
сповіщення
системі Перевірити push. якщо застосунок
закрито.
1. Увійти як
Перевірка ролей Доступ обмежено,
пацієнт. 2.
доступу (пацієнт Два різні акаунти відображається
TC-09 Спробувати High
→ дані іншого пацієнтів повідомлення про
відкрити дані
пацієнта) відсутність прав.
іншого профілю.
1. Відкрити Запис успішно
Видалення Авторизація
історію. 2. Обрати видалено, список
TC-10 запису з історії виконана, є Medium
запис. 3. оновлений, дані не
звернень історія
Видалити. доступні надалі.
Сукупність описаних дій забезпечує контроль над якістю, стабільністю та
безпекою мобільного застосунку, що особливо важливо для медичних систем. У
стартапі «MedOglad AI» процес тестування охоплює як базову функціональність —
чат, реєстрацію та роботу з даними — так і специфічні аспекти, пов’язані з AI-
модулем, точністю медичних рекомендацій та відповідністю стандартам
HIPAA/GDPR. Такий підхід гарантує готовність продукту до реального
використання у медичній практиці та забезпечує високий рівень довіри користувачів
і медичних установ.
117
4.3 Управління змінами та комунікаціями під час проєктування
стартапу
Управління змінами та комунікаціями є двома ключовими складовими
проєктного менеджменту, які забезпечують безперервність, узгодженість та
ефективність процесу розробки. У стартапі «MedOglad AI», де залучені
мультидисциплінарні команди (Back-End, Front-End, DevOps, Data Science, QA,
UI/UX, Medical Engineers) та реалізуються високі вимоги до якості й безпеки даних,
ці процеси мають особливо важливе значення. Їхня роль полягає у тому, щоб усі
зацікавлені сторони однаково розуміли поточний стан проєкту, а зміни
впроваджувалися контрольовано, із мінімізацією ризиків і впливу на строки, бюджет
та обсяг робіт.
Управління змінами у процесі проєктування. Процес управління змінами
забезпечує контрольоване внесення коригувань у вимоги, дизайн, архітектуру,
інтерфейси, функціональність або інші елементи продукту. У контексті розробки
«MedOglad AI» зміни можуть виникати внаслідок: уточнення медичних вимог,
оновлення клінічних протоколів, вдосконалення AI-моделі, появи нових стандартів
щодо захисту персональних медичних даних, клієнтських запитів або результатів
тестування.
Механізм управління змінами базується на структурованій процедурі, яка
передбачає подання запиту, аналіз впливу, затвердження та виконання. Усі запити на
зміну фіксуються у системі управління проєктом (Jira/DevOps Board) на основі
Change Request. Кожна зміна має відповідального, опис передумов, очікувані
результати та оцінку рівня впливу на інші модулі.
Аналіз змін включає технічну, економічну та часову оцінку. Команда аналізує,
які компоненти продукту зазнають впливу: API, бази даних, UI, AI-модуль або
системи безпеки. Враховується також, чи спричинить зміна необхідність
перепроєктування певних блоків або повторного тестування. Особливе місце займає
оцінка ризиків — наприклад, зміна у логіці AI-модуля може вплинути на якість
118
клінічних рекомендацій, а зміна у структурі даних може порушити інтеграцію із
зовнішніми медичними сервісами.
Рішення про ухвалення або відхилення змін належить Change Control Board
(CCB), до якого входять менеджер проєкту, технічний директор, лідери розробки та
представники медичного напряму. Ухвалені зміни заносяться до Backlog Sprint’у,
після чого команда оцінює їх у Story Points та визначає пріоритет. Після
впровадження зміна проходить ретест та регресійне тестування, що мінімізує ризик
побічних ефектів.
Контроль змін передбачає ведення журналу змін (Change Log), у якому
фіксується:
опис зміни;
дата створення;
автор;
статус;
ступінь впливу;
рішення CCB;
дата релізу, в який зміну включено.
Завдяки такому підходу команда забезпечує прозорість процесу, запобігає
хаотичному внесенню правок і зберігає контроль над архітектурною цілісністю
продукту.
Управління комунікаціями охоплює систематичне планування, збір, обмін та
зберігання інформації між усіма зацікавленими сторонами. Для стартапу «MedOglad
AI» комунікації мають критичне значення, оскільки команда працює з різними
типами складної інформації: технічної, клінічної, аналітичної, UX/UI та
управлінської.
Базою для управління комунікаціями є Комунікаційний план проєкту, у якому
визначено:
перелік зацікавлених сторін;
формати комунікацій;
119
частоту зустрічей;
канали та інструменти (Slack, Jira, Notion, Google Meet);
правила ескалації проблем;
структуру звітів та відповідальних.
Комунікації поділяються на внутрішні та зовнішні. Внутрішні
комунікації охоплюють взаємодію членів команди, технічні обговорення,
пріоритезацію задач, аналіз вимог і звітування про прогрес. Зовнішні комунікації —
це взаємодія з медичними експертами, замовником, партнерами, ліцензійними
органами або потенційними інвесторами.
Особливе місце займають регулярні скрам-події, що формують основний ритм
комунікацій:
Daily Scrum — щоденні 15-хвилинні мітинги для синхронізації;
Backlog Refinement — уточнення вимог і пріоритетів;
Sprint Planning — планування обсягу робіт на спринт;
Sprint Review — демонстрація результатів зацікавленим сторонам;
Sprint Retrospective — аналіз проблем комунікації і шляхів їх
покращення.
Окремо проводяться кросфункціональні сесії між UI/UX, розробниками та
медичними інженерами, які забезпечують узгодженість рішень з точки зору юзабіліті
та медичної точності. Для складних питань застосовується метод «Design Review» —
об’єднана зустріч BE/FE/AI/QA для прийняття технічних рішень.
Усі знання систематизуються в єдиній базі, що представлена в Notion або
Confluence. Там зберігаються:
технічні специфікації;
архітектурні діаграми;
документація API;
керівництва користувача;
результати тестування;
протоколи зустрічей;
120
рішення CCB щодо змін.
Комунікації також охоплюють взаємодію щодо ризиків. Якщо член команди
виявляє проблему, що може вплинути на строки чи якість, інформація негайно
ескалується через встановлений канал — зазвичай через Project Manager або Slack-
канал #critical-issues. Це дає змогу оперативно реагувати на потенційні відхилення та
мінімізувати їхній вплив.
Для ефективного управління змінами і комунікаціями команда використовує
інструменти:
Jira — task-tracking, журнал змін, контроль статусів;
Slack — оперативна комунікація, тематичні канали (dev, qa, ai, bugs);
Notion / Confluence — централізована база знань;
GitHub / GitLab — Pull Requests, code review, контроль версій;
Figma — спільна робота над дизайном;
Google Meet — синхронні зустрічі, демо та обговорення;
Miro — візуальні діаграми, DFD/UML, мозкові штурми.
Завдяки цьому забезпечується прозорість рішень, доступність інформації та
синхронізація між усіма членами команди.
Управління змінами та комунікаціями у проєктуванні стартапу «MedOglad AI»
формує стабільний, передбачуваний і контрольований процес розробки.
Формалізовані процедури внесення змін дозволяють уникати неконтрольованих
відхилень і зберігати цілісність архітектури та логіки продукту. Ефективна система
комунікацій забезпечує однакове розуміння завдань усіма учасниками команди,
сприяє швидкому вирішенню проблем і мінімізує ризики, пов’язані з неправильними
або несвоєчасними інформаційними обмінами. У результаті команда отримує
узгоджений, прозорий і якісно організований процес, що є критично важливим для
успішної реалізації високотехнологічного медичного застосунку.
121
Висновки до розділу 4
У четвертому розділі було сформовано всебічне уявлення про структуру,
функціональну логіку та внутрішню організацію стартапу «MedOglad AI». Аналіз
ключових сценаріїв використання — внесення симптомів, отримання первинних
рекомендацій, взаємодія з лікарем, збереження та опрацювання медичних даних,
формування нагадувань — підтвердив їхню відповідність запитам цільових
користувачів та специфіці eHealth-середовища. Особливу увагу приділено
визначенню функціональних залежностей між окремими модулями системи, адже
саме вони визначають цілісність користувацького досвіду, якість підтримки
прийняття рішень та стабільність роботи всіх компонентів.
Проведене моделювання дало змогу уточнити межі кожного з етапів обробки
даних, визначити критичні точки, у яких відбувається перехід між модулями, та
оцінити можливі обмеження архітектури. Це дозволило сформулювати більш точні
функціональні вимоги і виявити ті ділянки логіки, що потребують підсилення —
зокрема, роботу з неповними симптомами, маршрутизацію запитів до лікаря,
обробку сценаріїв із підвищеним ризиком для користувача. Такий аналіз заклав
основу для оптимізації взаємодії між компонентами системи, підвищення точності
алгоритмів і зменшення ймовірності помилок на етапах реального використання.
Отримані результати демонструють, що концепція продукту є логічною,
структурно продуманою та орієнтованою на масштабування. Створена модель
системи враховує не лише функціональний аспект, але й вимоги до безпеки,
надійності та відповідності медичним стандартам, що є критичним для рішень у
галузі цифрової медицини. Таким чином, цей розділ забезпечив міцне методичне
підґрунтя для подальших етапів — проєктування, розробки, тестування та
впровадження продукту, роблячи процес переходу до практичної реалізації значно
більш передбачуваним і керованим.
122
ВИСНОВКИ
Виконана кваліфікаційна робота магістра сформувала цілісну концепцію
управління стартапом у сфері цифрової медицини, де поєднуються проєктний
підхід, сучасні технології та вимоги ринку eHealth. У дослідженні послідовно
проаналізовано умови, у яких функціонує галузь, визначено тенденції її розвитку та
специфіку конкурентного середовища. Це дало змогу обґрунтувати перспективність
створення мобільного застосунку, орієнтованого на підтримку дистанційної
взаємодії лікаря з пацієнтом і застосування інструментів штучного інтелекту для
первинного оцінювання стану здоров’я.
На основі дослідження проблематики визначено цілі стартапу, очікування
стейкхолдерів та критерії успішності продукту. Створені дерева проблем і цілей
допомогли структурувати ключові виклики, пов’язані з якістю медичних послуг,
навантаженням на лікарів та потребою пацієнтів у доступних консультаціях.
Подальше моделювання змісту та побудова ієрархічної структури робіт дозволили
сформувати логіку життєвого циклу проєкту — від ініціації й планування до
реалізації, тестування та виходу на ринок.
У процесі роботи виконано комплексне планування ресурсів: визначено склад
команди, описано рольову структуру, сформовано організаційну модель та
розраховано вартість людських і матеріальних ресурсів. На основі цього були
сформовані календарні плани, сітьова модель та бюджет проєкту. Оцінка витрат і
тривалості робіт показала реалістичність фінансової та часової моделей, що є
критично важливим для стартапів у сфері eHealth.
Особлива увага приділена управлінню якістю та ризиками. На основі діаграми
причинно-наслідкових зв’язків визначено ключові параметри якості мобільного
застосунку, включно з точністю AI-модулів, стабільністю роботи системи та
відповідністю вимогам захисту даних. Проведена ідентифікація ризиків дала змогу
оцінити їх можливий вплив і розробити превентивні заходи для їх мінімізації, що
123
підвищує керованість проєкту та знижує невизначеність під час розробки медичного
продукту.
У роботі також простежено взаємозв’язок проєкту зі стейкхолдерами,
визначено їх мотивацію, інтереси та ступінь впливу на ухвалення рішень. Це дало
можливість вибудувати модель комунікацій, що забезпечує узгодженість дій
команди, інвестора, медичних закладів і кінцевих користувачів. Проведений аналіз
ринку та порівняння з існуючими рішеннями показали відсутність повноцінних
аналогів в Україні, що створює додаткові можливості для виходу на національний
ринок та подальшого масштабування.
Сформована стратегія управління стартапом охоплює всі ключові аспекти:
аналіз галузі, визначення вимог і функціоналу, моделювання процесів, ресурсне та
фінансове планування, організацію команди, управління якістю, ризиками та
стейкхолдерами. Отримані результати демонструють, що розроблений застосунок
має потенціал для впровадження в українських медичних закладах, а сама модель
управління може бути адаптована для інших проєктів у сфері охорони здоров’я.
Узагальнюючи, можна стверджувати, що всі поставлені завдання роботи
виконано, а мети — досягнуто. Створена методологія управління стартапом
забезпечує системний підхід до розробки медичного цифрового продукту, дозволяє
оцінити його життєздатність та окреслює шляхи подальшого розвитку.
Запропоновані рішення здатні підвищити ефективність організації медичних послуг,
сприяти цифровій трансформації галузі та забезпечити конкурентні переваги на
ринку eHealth.
124
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. OECD. Health in the Digital Era: Trends and Challenges. Paris: OECD Publishing,
2023.
2. WHO. Global Strategy on Digital Health 2020–2025. Geneva: World Health
Organization, 2021.
3. Statista. Remote Patient Monitoring Market Size 2020–2030. Hamburg: Statista
Research Department, 2023.
4. GSMA. The Mobile Economy: Digital Health Overview. London: GSM
Association, 2022.
5. PwC. AI in Health: Global Market Insights and Forecasts 2024–2030. London:
PricewaterhouseCoopers, 2024.
6. HealthPrecision. Medical Brain Technical Overview: AI-Driven Clinical Decision
Support. New York: HealthPrecision Inc., 2023.
7. Міністерство охорони здоров’я України. Концепція розвитку цифрової
охорони здоров’я в Україні. Київ : МОЗ, 2022.
8. Cardiomo. About the Technology. 2023.
9. ImagineCare. Remote Patient Monitoring Platform Overview. 2023.
10. doc.ua. Офіційний сайт сервісу медичних консультацій. 2024.
11. Liki24. Офіційний сайт сервісу пошуку та доставки ліків. 2024.
12. BetterMe. Global Health & Wellness Platform. 2024.
13. Міністерство охорони здоров’я України. Національна система eHealth:
офіційне керівництво. Київ, 2023.
14. Про схвалення Концепції розвитку електронної охорони здоров’я:
розпорядження Кабінету Міністрів України від 28.12.2020 р. № 1671-р.
Офіційний вебсайт Верховної Ради України.
15. [їМіністерство охорони здоров’я України. Цифрова трансформація охорони
здоров’я України : офіційний вебсайт МОЗ України. URL: moz.gov.ua
125
16. Агенція місцевого економічного розвитку Яворівщини. Діджиталізація
медицини: виклики та переваги. Prostir.UA : громадський простір, аналітичний
портал. 2023.
17. Malakhov, K. S. Insight into the Digital Health System of Ukraine (eHealth):
Trends, Definitions, Standards and Legislative Revisions. Telerehabilitation, 2023,
Vol. 15 (2).
18. Mudge, G. H., Vilenskyi, A., Kumar, U., Kohli, M. The Future of Ukrainian
Healthcare: The Digital Opportunity. Journal of Global Health, 2025, Vol. 15,
03039.
19. Pishta, V. I. Personal Data Protection in m-Health Apps: International Experience
and Prospects, with Reference to Ukraine. Wiadomosci Lekarskie, 2025, 78(1).
20. Kostiuk, I. A. Study of Mobile Applications in the Healthcare Sector: Ukrainian
Experience in Digital Transformation. MSU Journal, 2025.
21. Концепція розвитку електронної охорони здоров’я в Україні : розпорядження
Кабінету Міністрів України від 28.12.2020 № 1671-р. Київ.
22. Міністерство охорони здоров’я України. Електронна система охорони
здоров’я eHealth: офіційні технічні вимоги та стандарти інтеграції. Київ, 2023.
23. Проєкти телемедицини в Україні: аналітичний огляд. Центр громадського
здоров’я України. Київ, 2022.
24. Шиманська В. Цифровізація медичних послуг: інформаційна безпека, ризики
та виклики. Соціально-економічний розвиток регіонів. 2023.
25. Яворівська А. Цифрова взаємодія лікарів та пацієнтів: проблеми
впровадження та користувацький досвід. Український медичний часопис.
2024.
26. Міністерство охорони здоров’я України. Цифрова трансформація охорони
здоров’я України : інформаційні матеріали освітнього курсу МОЗ. Київ, 2023.
27. Міністерство охорони здоров’я України. Інформаційна екосистема
електронної охорони здоров’я України : офіційні методичні матеріали. Київ,
2024.
126
28. Висоцький А. А., Суріков О. О., Василюк-Зайцева С. В. Розвиток штучного
інтелекту в сучасній медицині // Український медичний часопис. 2023. Т. 2,
вип. 154. С. 1–4.
29. Шостакович-Корецька Л. Р. Застосування штучного інтелекту в клінічній
медицині, наукових дослідженнях та освіті в умовах воєнного стану //
Інфекційні хвороби. 2025. Т. 2 (120). С. 71–77.
30. Запорожець Т. В. Цифрові трансформації системи охорони здоров’я в умовах
реформування // Державне управління: удосконалення та розвиток. 2021. №
10. С. 1–5.
31. Центр громадського здоров’я України. Соціальні аспекти розвитку цифрової
медицини: аналітичний звіт. Київ, 2023.
32. НСЗУ. Вимоги до інформаційних систем eHealth та стандарти обробки
медичних даних. Київ, 2022.
33. Бандура А., Куценко О. Етичні, клінічні та правові вимоги до використання
штучного інтелекту у медичній практиці // Український медичний журнал.
2024.
34. IT Ukraine Association. Аналітичний огляд ринку штучного інтелекту та
цифрових медичних сервісів. Київ, 2024.
35. Міністерство охорони здоров’я України. Інформаційна екосистема електронної
охорони здоров’я України. Київ, 2023.
36. ДП «Електронне здоров’я». Електронна система охорони здоров’я (ЕСОЗ):
структура та принципи функціонування. Київ, 2024.
37. Розвиток штучного інтелекту в сучасній медицині // Український медичний
журнал. 2023.
38. Public Health 2025: штучний інтелект у медицині // Аптека.ua. 2025.
39. Штучний інтелект в медицині: чи загрожують інновації правам людини? //
Українська Гельсінська спілка з прав людини. 2024
40. Анохін В. М. Управління якістю програмних систем: методи, моделі та
інструменти : монографія. Київ : КНЕУ, 2020. 312 с.
127
41. Мельник А. О., Гапоненко Т. Є. Особливості забезпечення якості медичних
інформаційних систем. Системи обробки інформації. 2021. № 2. С. 45–52.
42. Бондаренко А. Ф. Методологія забезпечення якості в ІТ-проєктах: практичні
інструменти та підходи. Харків : ХНЕУ, 2019. 198 с.
43. Круглик В. С. Організація тестування та контролю якості в команді
розробників. Вісник НТУ «ХПІ». 2022. № 7. С. 78–85.
44. Гриманчук О. В. Медична експертиза програмних продуктів у сфері eHealth:
вимоги, ризики, стандарти. Львів : ЛНМУ, 2021. 156 с.
128
ДОДАТОК А
Затверджую
Зав. кафедри КНСА,
______________ Юрій ТРИУС
«____»____________2025 р.
УПРАВЛІННЯ СТАРТАПОМ СТВОРЕННЯ МОБІЛЬНОГО ЗАСТОСУНКУ
ДЛЯ МЕДИЧНИХ ПРАЦІВНИКІВ ТА ПАЦІЄНТІВ
Специфікація
482. ЧДТУ. 52412-01
Листів 2
Розробник ____________________ Макота Є.В.
Керівник ____________________ Оксамитна Л.П.
Черкаси – 2025
129
482. ЧДТУ. 52412-01
Позначення Найменування Примітка
Документація
482. ЧДТУ. 52412-02 90 01 Публікація по темі
кваліфікаційної роботи
магістра
130
ДОДАТОК Б
УПРАВЛІННЯ СТАРТАПОМ СТВОРЕННЯ МОБІЛЬНОГО ЗАСТОСУНКУ
ДЛЯ МЕДИЧНИХ ПРАЦІВНИКІВ ТА ПАЦІЄНТІВ
Публікація по темі кваліфікаційної роботи магістра
482.ЧДТУ. 52412-02 90 01
Листів 4
Розробник _____________ Макота Є.В.
Черкаси – 2025
131
132
133