Разработка мобильного приложения для записи к врачу

Пациент записался на приём на следующий вторник и забыл. Врач ждёт, слот занят — фактически потерян. По статистике клиник, 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.

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

История посещений, выписки, результаты анализов — требует особого внимания к безопасности данных. В России — требования 152-ФЗ и приказы Минздрава по хранению медицинских данных.

Документы хранятся в зашифрованном 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 или кастомном бэкенде составляет от 100 000 до 250 000 рублей в зависимости от сложности фильтров.

Нормальная сегментация строится на нескольких уровнях.

Топики — для широких категорий: «новые акции», «обновления статуса заказа». Пользователь подписывается через 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 на событие открытия. Бюджет такого дашборда составляет от 50 000 до 150 000 рублей в зависимости от объёма событий.

Как мы внедряем 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.

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