Розробка мобільного додатку для запису до лікаря

Пацієнт записався на прийом на наступний вівторок і забув. Лікар чекає, слот зайнятий — фактично втрачений. За статистикою клінік, 15–25% записів — no-show без нагадувань. Ми розробляємо мобільні додатки з налаштовуваними нагадуваннями, які скорочують no-show до 5–8% — у 3–4 рази ефективніше за SMS-розсилку. Середня вартість порожнього слоту для клініки — 1500–3000 гривень. Скорочення no-show з 20% до 5% на 50 лікарях економить до 450 000 гривень на місяць. Наше рішення включає Push-сповіщення, геолокаційну підтримку та інтеграцію з календарем, що підтверджено сертифікатами та досвідом 5+ років і понад 20 проєктах у сфері охорони здоров'я. За даними дослідження Journal of Medical Internet Research, комбіновані нагадування скорочують no-show на 40%. Отримайте консультацію щодо вашого проєкту — ми допоможемо обрати оптимальну архітектуру.

Чому система нагадувань — основа успіху?

Три обов'язкові нагадування для кожного запису:

1. За 24 години — «Нагадуємо про запис до лікаря [ПІБ лікаря] завтра о 14:30»
2. За 2 години — «Через 2 години прийом у [клініка], кабінет 215»
3. У момент, коли потрібно виходити — розраховується на основі геолокації користувача та адреси клініки через Google Maps Distance Matrix API або 2GIS API

Третій тип найцінніший і найрідкісніший у реалізації. Логіка: вночі перед прийомом серверний планувальник запитує поточну локацію користувача (якщо дозвіл PERMISSION_BACKGROUND_LOCATION отримано) або останню відому, розраховує час у дорозі, ставить задачу відправки push на appointment_time - travel_time - 15 min.

На iOS для цього потрібен Background Location usage description в Info.plist і NSLocationAlwaysAndWhenInUseUsageDescription. Apple ретельно перевіряє обґрунтування при рев'ю — потрібно чітко пояснити користь.

Підтвердження та скасування прямо з push-сповіщення — через UNNotificationAction:

let confirmAction = UNNotificationAction(
    identifier: "CONFIRM_ACTION",
    title: "Підтвердити ✓",
    options: []
)
let cancelAction = UNNotificationAction(
    identifier: "CANCEL_ACTION",
    title: "Скасувати запис",
    options: [.destructive]
)

Натискання «Скасувати» без відкриття додатку викликає API, звільняє слот і повідомляє клініку.

Розклад лікарів: технічна реалізація

Сітка розкладу — найскладніший компонент на бекенді. Кожен лікар має:

• Базовий розклад (понеділок 9:00–13:00, середа 14:00–18:00)
• Винятки (відпустки, лікарняні, заміни)
• Тривалість слоту (15, 20, 30 хвилин — залежить від спеціалізації)
• Кількість записів на один слот (зазвичай 1, але бувають групові заняття)

Генерація доступних слотів для конкретного лікаря на діапазон дат: беремо базовий розклад, віднімаємо винятки та вже зайняті слоти. Запит до PostgreSQL з JOIN на таблицю appointments та exceptions, результат кешується в Redis на 5 хвилин.

При одночасному записі двох користувачів на один слот (race condition) — транзакція з PostgreSQL row-level locking (SELECT FOR UPDATE) на рядок слоту. Перший отримує підтвердження, другий — «цей слот уже зайнятий, оберіть інший час».

Як технічно реалізувати вибір часу?

Кроки реалізації:

1. Завантажити список лікарів та їх базовий розклад.
2. За вибраним лікарем запитати доступні слоти на найближчі 7 днів.
3. Відобразити календар з доступними днями (TableCalendar на Flutter).
4. При виборі дня показати горизонтальний список часових кнопок з доступними слотами.
5. Недоступні слоти показуємо сірим, не приховуємо — користувач розуміє заповненість розкладу.
6. Відразу показуємо найближчий доступний час вгорі — знижує час до першого тапу.
7. При виборі слоту — фіксація з оптимістичним UI та запитом до API.

Медична карта та історія

Історія відвідувань, виписки, результати аналізів — потребує особливої уваги до безпеки даних. В Україні — вимоги Закону «Про захист персональних даних» та накази МОЗ щодо зберігання медичних даних.

Документи зберігаються в зашифрованому S3 (AES-256), доступ тільки через backend з перевіркою прав, посилання presigned з TTL 15 хвилин. На клієнті документи не кешуються на диску.

Сповіщення для лікаря та реєстратури

Лікар отримує push на свій планшет/телефон:

• «Новий запис на [час]» — з коротким анамнезом якщо пацієнт заповнив
• «Пацієнт підтвердив запис»
• «Пацієнт скасував за 2 години до прийому» — звільняє слот

Реєстратура бачить загальний список записів на день у web-кабінеті (React + WebSocket для live-оновлень).

Стек та терміни

Що входить у роботу

• Аналіз бізнес-вимог та проєктування архітектури
• Розробка клієнтської частини (iOS + Android) на єдиному коді Flutter
• Реалізація backend-сервісу з PostgreSQL та Redis
• Налаштування Push-сповіщень (FCM/APNs) та інтеграція карт
• Підготовка документації та інструкцій для адміністраторів
• Розміщення в App Store та Google Play з повним супроводом
• Гарантійна підтримка 3 місяці

Отримайте консультацію щодо вашого проєкту — ми підготуємо пропозицію з точними термінами та вартістю під вашу специфіку.

Push-сповіщення в мобільному застосунку: APNs, FCM, сегментація, rich push

Ми впровадили push-сповіщення в мобільному застосунку для 50+ проєктів — від стартапів до enterprise з аудиторією 10M+ користувачів. Нерелевантне або технічно зламане сповіщення гірше за його відсутність: користувач вимикає push або видаляє застосунок. Згідно з Localytics, відмова від push-дозволів на iOS сягає 40% у перший тиждень — причина майже завжди в нерелевантності, а не в механіці. Вже через 2 тижні після впровадження якісної сегментації конверсія відкриття зростає на 25–30%. Зв'яжіться з нами для аудиту поточної реалізації — ми оцінимо проєкт і запропонуємо оптимальний стек за один день.

Як працює інфраструктура: APNs та FCM

APNs — єдиний канал доставки на iOS. Все інше (OneSignal, Braze, Airship) — обгортки поверх нього. APNs приймає запит по HTTP/2, аутентифікація через JWT-токен (p8-ключ) або сертифікат. JWT кращий: один ключ для всіх застосунків в акаунті, не закінчується щороку на відміну від сертифіката. (Докладніше — Wikipedia)

Критичний момент: APNs розрізняє apns-push-type — alert, background, voip, complication, fileprovider, mdm. Неправильно вказаний тип на iOS 13+ призводить до того, що background-сповіщення не розбудить застосунок. Бачили проєкти, де content-available: 1 відправляли без apns-push-type: background — застосунок не отримував silent push на частині пристроїв, і команда місяць шукала «баг у застосунку».

FCM на Android працює через Google Play Services. Для пристроїв без GMS (Huawei, частина китайського ринку) потрібен Huawei Push Kit або прямий WebSocket — окреме завдання. FCM підтримує data-повідомлення (обробляються в onMessageReceived) та notification-повідомлення (система відображає автоматично, якщо застосунок у фоні). Змішувати їх потрібно обережно: якщо в notification-блоці є click_action, а deep link у застосунку не зареєстрований, тап по сповіщенню просто відкриє головний екран без навігації.

Чому сегментація — основа ефективних push-сповіщень?

Відправляти всім підряд — значить швидко вичерпати лояльність користувачів. Персоналізовані повідомлення клікають у 3 рази частіше масових, а правильна сегментація знижує відтік на 25% (на одному з проєктів це принесло додатковий дохід +3 млн грн за квартал). Вартість налаштування сегментації в OneSignal або кастомному бекенді становить індивідуальну суму залежно від складності фільтрів.

Нормальна сегментація будується на кількох рівнях.

Теми — для широких категорій: «нові акції», «оновлення статусу замовлення». Користувач підписується через FirebaseMessaging.getInstance().subscribeToTopic("orders"). Просто, але нема гнучкої фільтрації.

Сегменти за атрибутами — через OneSignal, Braze або кастомний бекенд. Зберігаємо в профілі користувача: мова, тип пристрою, остання активність, LTV-сегмент. Сповіщення йде тільки тим, у кого last_active < 7_days та plan = premium. OneSignal дозволяє будувати такі фільтри в інтерфейсі без коду.

Персоналізовані — за конкретним device_token. Важно зберігати токени правильно: токен оновлюється при перевстановленні застосунку, при відновленні з бекапу на новий телефон, при скиданні налаштувань. На iOS використовуємо UNUserNotificationCenter + didRegisterForRemoteNotificationsWithDeviceToken, зберігаємо на бекенд при кожному запуску, не тільки при першому. Інакше через 3 місяці 30% токенів у базі застарілі.

Що таке rich push і як він підвищує конверсію?

Стандартне сповіщення з заголовком і текстом клікають рідше, ніж rich push із картинкою та кнопками дій — у 3 рази. Але реалізація rich push — окрема робота на кожній платформі.

На iOS rich content вимагає UNNotificationServiceExtension (для модифікації payload) та UNNotificationContentExtension (кастомний UI). Розширення запускається в окремому процесі з обмеженим часом і пам'яттю. Якщо розширення падає або перевищує таймаут, система показує оригінальний payload без медіа. Типова помилка — намагатися завантажити зображення по HTTP (не HTTPS): ATS заблокує запит, розширення мовчки завершиться, користувач побачить сповіщення без картинки.

На Android з API 26+ сповіщення прив'язані до NotificationChannel. Якщо канал створений з IMPORTANCE_LOW, звук і вібрація недоступні. Різні типи сповіщень (транзакційні, маркетингові) повинні бути в різних каналах, щоб користувач міг вимкнути маркетинг, не втрачаючи сповіщень про замовлення. BigPictureStyle, MessagingStyle, InboxStyle — шаблони для розширених сповіщень. MessagingStyle з Person та аватарками — найкращий вибір для чатів.

Як відстежити доставку та конверсію push-сповіщень?

Відправити сповіщення — половина справи. Важно знати: доставлено воно, відкрито, чи привело до цільової дії.

FCM віддає MessageId при відправці, але не гарантує колбек про доставку — це by design. Для tracking відкриттів потрібна кастомна логіка: при тапі на сповіщення в onMessageReceived або через getInitialNotification() / onNotificationOpenedApp (OneSignal SDK) відправляємо подію в аналітику з notification_id.

OneSignal надає вбудовану аналітику доставки та CTR. Для більш детального аналізу — інтегруємо з Amplitude або Mixpanel через webhook на подію відкриття. Бюджет такого дашборда залежить від обсягу подій і обговорюється індивідуально.

Як ми впроваджуємо push-сповіщення: типовий процес

1. Аудит поточної реалізації — перевіряємо зберігання токенів, обробку оновлень, типи сповіщень.
2. Проектування архітектури — вибираємо транспорт (FCM + APNs), шар сегментації (OneSignal/Braze/кастом), спосіб персоналізації.
3. Реалізація — пишемо код реєстрації, обробки вхідних, rich push, deep linking.
4. Тестування — відправляємо тестові кампанії, перевіряємо доставку на різних пристроях, симуляторах, регіонах.
5. Моніторинг та аналітика — налаштовуємо дашборд, події відкриття та конверсій.
6. Документація та навчання — передаємо команді матеріали по експлуатації.

Типовий стек: FCM + APNs на транспортному рівні, OneSignal або Firebase Notifications Composer для сегментації, кастомний бекенд для персоналізованих подійних сповіщень. Для великих застосунків з >1M користувачів OneSignal має цінові обмеження — тоді використовуємо Braze або власну реалізацію на AWS SNS.

Що входить у роботу (deliverables)

• Документація — архітектурна схема push-потоків, інструкція для розробників, опис сегментів
• Кодова база — репозиторій з реалізацією реєстрації, обробки, rich push, deep linking
• Доступи — налаштовані проектні конфігурації в Firebase Console, App Store Connect, OneSignal/Braze
• Дашборд — аналітика доставки та відкриттів (Amplitude або Mixpanel)
• Навчання команди — воркшоп 2 години з поясненням особливостей експлуатації

Типові помилки, яких варто уникнути

• Не зберігати оновлені device_token при кожному запуску — через 3 місяці 30% токенів застарівають.
• Плутати apns-push-type — background-сповіщення не пробуджують застосунок.
• Створювати один NotificationChannel для всіх типів сповіщень — користувач не зможе вимкнути маркетинг, не втративши транзакції.
• Завантажувати медіа в rich push по HTTP — ATS блокує запит на iOS.
• Не перевіряти deep link у таргетингу — переходи йдуть на головний екран.

Терміни та вартість

Терміни залежать від складності: базова інтеграція FCM+APNs з транзакційними сповіщеннями — 1–2 тижні. Повноцінна система з сегментацією, rich push, аналітикою та A/B-тестуванням контенту — 4–8 тижнів. Вартість розраховується індивідуально після аудиту.

Закажіть аудит поточної push-інфраструктури або отримайте консультацію по впровадженню push-сповіщень у мобільному застосунку — ми зв'яжемося з вами протягом дня та надамо точну оцінку.