Приложение пациента: разработка iOS и Android для частной клиники

Приложение пациента — самый недооценённый IT-продукт частной клиники. Большинство клиник думают о приложении как о «модной фиче для маркетинга», а получают в результате инструмент, который снижает нагрузку на колл-центр на 30-40%, увеличивает повторные обращения на 15-25% и в течение года окупается через прирост приёмов.

Эта статья — для медицинского директора, маркетолога или собственника сети, который рассматривает запуск мобильного приложения. К концу гайда у вас будет ясная картина: что должно быть в приложении, нативно или Flutter, как интегрировать с МИС, сколько занимает разработка, какие требования по ФЗ-152, и где обычно теряют деньги в подобных проектах.

Зачем сети частных клиник своё приложение

Три экономических эффекта, которые повторяются у всех клиник после запуска.

Снижение нагрузки на колл-центр. До запуска приложения 80-90% записей идут через звонок: пациент звонит, оператор открывает МИС, ищет слот, записывает. После приложения 30-40% этих обращений уходят в самообслуживание. Для сети 5 филиалов с потоком 200 звонков в день это +60-80 звонков, освобождающихся для маркетингового обзвона и работы со сложными случаями.

Рост повторных обращений на 15-25%. Пациент с приложением видит историю приёмов, помнит про повторный осмотр через 6 месяцев, легко записывается на профилактическое УЗИ. Без приложения «забывание» — основная причина оттока: пациенту нужно вспомнить, найти телефон клиники, потратить 5-10 минут на звонок.

Конкурентное преимущество в выборе клиники. В Москве и крупных городах пациент при первом обращении сравнивает 2-3 клиники. У одной есть приложение с удобной записью — у двух нет. Это становится критерием выбора, особенно для возрастной группы 25-45 лет.

Окупаемость приложения для сети 3-7 филиалов с бюджетом 3-6 млн ₽ — 8-14 месяцев за счёт прироста приёмов и экономии на колл-центре. Дальше — чистый положительный денежный поток.

Что должно быть в приложении

Реальный набор модулей, который мы видим в современных приложениях частных клиник в России.

Базовый набор (MVP)

Онлайн-запись. Выбор филиала, специализации, врача, даты и времени из свободных слотов. Должна работать офлайн до момента подтверждения — пациент может выбрать всё в метро, нажать «Записать» уже дома. Запись отменяется и переносится в одно касание.

Медкарта и история приёмов. Список предстоящих и прошедших приёмов с заключениями, направлениями, рецептами. Поиск по специализациям и датам. Возможность открыть PDF-документ и переслать врачу или родственнику.

Оплата приёма. Через СберPay, ЮKassa, ЮMoney или встроенный Apple Pay / Google Pay. Оплата до приёма даёт +15-20% к показателю «доходимости» — пациент с оплаченным приёмом приходит чаще, чем с забронированным «на словах».

Push-уведомления. Напоминание за 24 часа («Завтра ваш приём») и за 1-2 часа («Приём через час»). Возможность сразу из уведомления перенести или отменить. Это снижает no-show на 30-40%.

Результаты анализов. PDF с результатами автоматически приходит в приложение, как только готов в лаборатории. Пациент видит push «Результаты УЗИ готовы», открывает приложение, читает заключение.

Расширенные модули

Чат с врачом. Текстовый чат после приёма для уточняющих вопросов (по приказу № 965н — только в рамках наблюдения по установленному диагнозу). Снижает количество звонков в клинику и повышает удовлетворённость.

Телемед-консультация. Видео-приём прямо из приложения. Требует интеграции с телемед-платформой, идентификации через ЕСИА, УКЭП врача на заключения.

Программа лояльности. Бонусы, скидки на повторные приёмы, программа «приведи друга». Окупается через рост LTV пациента.

Семейный аккаунт. Один пациент управляет приёмами семьи: ребёнок, родители, супруг. Снижает входной барьер для записи близких. С точки зрения ФЗ-152 — это отдельные согласия на обработку ПДн каждого члена семьи.

Карта здоровья. Аллергии, хронические заболевания, регулярные препараты, контакты для экстренных случаев. Видна врачу при любом приёме.

Скидки и абонементы. Покупка абонемента на 5/10/20 приёмов со скидкой, программы «check-up в год», семейные тарифы.

iOS, Android и кросс-платформа

Главное технологическое решение — нативная разработка двух приложений или один кросс-платформенный проект на Flutter или React Native.

Нативная разработка. Swift + SwiftUI для iOS, Kotlin + Jetpack Compose для Android. Качество UI и производительность максимальные, доступ ко всем платформенным API сразу. Стоимость — самая высокая: примерно две команды разработки параллельно, общий бюджет 5-8 млн ₽ для типового медицинского приложения.

Flutter. Один проект, два бинарных файла (.ipa и .apk). Качество UI на уровне нативного (Flutter рендерит свои виджеты в Canvas, не использует системные элементы — это плюс для брендирования и минус для скорости разработки сложных платформенных интеграций). Бюджет — 3-5 млн ₽ для типового медицинского приложения. Поддержка одним разработчиком вместо двух команд.

React Native. Один проект, ближе к нативным элементам через bridge. Стек привычен фронтенд-разработчикам с React-опытом. Бюджет — 3-4 млн ₽. Менее популярен в России в 2026 году, чем Flutter, из-за более сложной отладки и большего количества зависимостей.

Гибрид (WebView). Веб-приложение в нативной обёртке. Самый дешёвый вариант (1-2 млн ₽), но качество UX заметно ниже, push-уведомления и биометрия работают со скрипом, App Store и Google Play могут отклонить приложение как «по сути сайт». Не рекомендуем для серьёзного медицинского продукта.

Для 90% сетей частных клиник в 2026 году правильный выбор — Flutter. Он даёт качество UI, скорость разработки, единую команду и приемлемую стоимость поддержки. Нативная разработка оправдана только для приложений с тяжёлыми платформенными сценариями: AR-сканирование тела, видеостриминг операций, Bluetooth-устройства (тонометры, глюкометры в режиме реального времени).

Архитектура и интеграция с МИС

Приложение пациента — это, по сути, мобильный клиент к API медицинской информационной системы клиники. Сама МИС остаётся ядром, приложение — это «окошко» для пациента в эту систему.

REST API клиники

Приложение никогда не работает с базой данных МИС напрямую. Только через REST API с защищённой авторизацией (OAuth 2.0 + JWT). Стандартный набор эндпоинтов:

• GET /api/v1/clinics — список филиалов с адресами и графиком работы
• GET /api/v1/schedule?clinic_id=&specialty=&date= — свободные слоты
• POST /api/v1/appointments — создание записи
• DELETE /api/v1/appointments/{id} — отмена записи
• GET /api/v1/appointments?patient_id= — история приёмов
• GET /api/v1/documents/{id} — PDF документа
• POST /api/v1/payments — инициация оплаты приёма
• POST /api/v1/notifications/register — регистрация push-токена

Если МИС не имеет API (типичная ситуация с большинством коробочных решений) — между приложением и МИС ставится middleware-сервис. Он синхронизируется с МИС через её внутренние интерфейсы (импорт-экспорт, очереди, БД-репликация) и предоставляет нормальный REST API для приложения. Middleware обычно занимает 1,5-2 месяца и 1-2 млн ₽.

Подробнее про API МИС — в нашей статье про разработку МИС.

Авторизация пациента

Три популярных способа.

Номер телефона + SMS-код. Самый простой и привычный пациентам. Минус — невозможно гарантировать однозначную идентификацию (один человек может иметь несколько номеров, номер передаётся между людьми).

ЕСИА (Госуслуги). Гарантированная идентификация с СНИЛС, паспортом, полисом ОМС. Обязательна для телемед-приёмов по приказу № 965н. Сложнее в реализации (1-1,5 месяца разработки + регистрация платформы в ЕСИА), но даёт юридическую чистоту.

Биометрия (Face ID / Touch ID) после первичной идентификации. Удобно для повторных входов: первый раз пациент авторизуется через ЕСИА или SMS, далее использует биометрию. Это стандарт для всех серьёзных медицинских приложений.

В реальном проекте обычно делается комбинация: первичная авторизация — SMS-код, для телемед-функций — дополнительная привязка через ЕСИА.

Push-уведомления

iOS — APNs (Apple Push Notification service). Android — FCM (Firebase Cloud Messaging). Для российских клиник FCM связан с Google-сервисами, что создаёт риск отключения. Альтернатива — пуш-сервисы РУ-провайдеров (Pushwoosh, Sendly, OSMI Cards) или собственный сервер push на базе RuStore push API.

Лучший вариант в 2026 году — комбинированная схема: FCM как основной канал, fallback на RuStore push при отсутствии Google Services на устройстве.

ФЗ-152 и защита медицинских данных в мобильном

Медицинские данные относятся к специальной категории ПДн (ст. 10 ФЗ-152), а мобильное приложение — это место, где эти данные оказываются на устройстве пациента. Что должно быть с первого дня:

Канал. TLS 1.2+ с проверкой сертификата. Pinning сертификата в приложении (защита от MITM). Запрет на работу через прокси с подменой сертификатов.

Локальное хранилище. Биометрические данные, токены авторизации, кэш медкарты — в Keychain на iOS, EncryptedSharedPreferences на Android. Никогда не в SharedPreferences или UserDefaults в открытом виде.

Выход из аккаунта. Автоматический выход через 30 минут неактивности. Выход при смене SIM-карты (опционально, по решению клиники). Удалённый выход через кабинет клиники при потере устройства.

Биометрия для входа. Face ID, Touch ID, Android Biometric Prompt. Это не «удобство», это требование к специальной категории ПДн.

Защита от скриншотов. На экранах с медкартой и результатами анализов можно блокировать скриншоты (FLAG_SECURE на Android, ScreenshotProtection-функция на iOS). Спорная фича — улучшает соответствие ФЗ-152, но раздражает часть пациентов.

Подробнее про регуляторный слой медицинского IT — в статье про ФЗ-152 в медицине.

Сроки и бюджет

Реальные диапазоны на 2026 год.

Конфигурация	Срок	Бюджет
MVP: запись + история + оплата + push (Flutter, iOS + Android)	3-4 месяца	3-4 млн ₽
Полная версия: + чат + телемед + ЕСИА + лояльность	4-5 месяцев	4-6 млн ₽
Нативная разработка (Swift + Kotlin), полная версия	5-7 месяцев	5-8 млн ₽
Whitelabel-rebrand готового решения	1-2 месяца	1-2 млн ₽
Middleware-сервис между приложением и МИС без API	1,5-2 месяца	1-2 млн ₽
Регулярная поддержка (год)	—	1-1,8 млн ₽
Крупный редизайн под новые гайдлайны (раз в 2 года)	1-2 месяца	0,8-1,5 млн ₽

Что часто недооценивают:

• Регистрация в RuStore. Для гарантированной доступности в РФ приложение должно быть опубликовано в RuStore (помимо App Store и Google Play). Это отдельный процесс с подписанием соглашения и проверкой контента, занимает 2-4 недели.
• Согласия и юридический пакет. Согласие на обработку ПДн, согласие на медицинские данные, политика конфиденциальности, оферта на использование приложения. Делает юрист, занимает 2-3 недели.
• Контент. Описание клиники, специалистов, услуг, цены в приложении должны синхронизироваться с сайтом и МИС. Часто эту работу не закладывают в проект и теряют 3-4 недели на «контентный спринт».

Типичные ошибки запуска

Запуск без МИС-API. Приложение разрабатывается, а МИС не готова отдавать данные. В результате — middleware «на коленке» с риском задержек и потери данных. Правильно: сначала API на стороне МИС, потом приложение.

Игнорирование App Store / Google Play гайдов. Apple и Google имеют особые требования к медицинским приложениям: упоминание HIPAA не для РФ, упоминание ФЗ-152 в политике, специальная страница «Health Data Usage». Без этого приложение отклоняется при ревью — это +2-4 недели к проекту.

Пуш каждый день. Маркетинговые пуши «приходите на check-up» каждый день — гарантированная причина удаления приложения. Один пуш в 2-3 недели максимум, остальное — транзакционные (напоминания о приёме, результаты анализов).

Без офлайн-режима. Пациент в метро открывает приложение посмотреть запись — оно «крутится» 30 секунд и показывает ошибку сети. Кэшируйте список приёмов и документы локально (с шифрованием).

Сложная регистрация (onboarding). 5 экранов, регистрация через ЕСИА, согласия на 3 экранах, потом ещё подтверждение email. 60% пациентов на этом этапе закрывают приложение. Минимум полей на этапе регистрации: телефон + SMS, остальное — постепенно по мере использования.

С чего начать

Сценарий для клиники, которая только думает о запуске приложения.

1. Проверьте, есть ли у вашей МИС REST API. Если нет — закладывайте middleware в проект и +1,5-2 месяца к сроку.
2. Определите MVP. Минимум — запись, история, оплата, push. Остальное — после первых 3-6 месяцев работы и обратной связи от пациентов.
3. Решите: Flutter или нативно. В 90% случаев — Flutter. Нативно — только если нужна работа с Bluetooth-устройствами или сложный платформенный функционал.
4. Подготовьте контент. Описание клиники, специалистов, услуг, цены, фотографии. Это отдельная работа на 3-4 недели.
5. Юридический пакет. Согласия, политика, оферта — у юриста с опытом в медицинском праве.
6. Пилот на 1 филиал. После релиза первый месяц — пилот в одном филиале с разбором обратной связи, потом раскатка на сеть.
7. План регулярных обновлений. Бюджетируйте 80-150 тыс. ₽ в месяц на поддержку и доработки — это норма для сети из 3-7 филиалов.

Приложение пациента — это не маркетинговая фишка, а полноценный IT-продукт, который окупается через рост повторных приёмов и снижение нагрузки на колл-центр. Срок разработки 3-5 месяцев, бюджет 3-6 млн ₽ для типовой сети, окупаемость 8-14 месяцев. Главные риски — отсутствие API у МИС, переусложнённая регистрация и игнорирование требований ФЗ-152 к локальному хранилищу.