Разработка медицинских приложений — это проектирование и разработка мобильных приложений, которые работают с клиническими и личными данными о здоровье: телемедицина и видеоконсультации, платформы ментального здоровья и терапии, личные кабинеты пациента, удалённый мониторинг и велнес-продукты. От обычной разработки она отличается тремя вещами: правила обращения с данными задаёт закон, а не ваша политика конфиденциальности; разрыв связи случается посреди чьей-то консультации, а не посреди ленты; заметная часть ваших пользователей — люди, которым нездоровится, пожилые или те, кто работает с приложением через вспомогательные технологии.

Flutter подходит для медицины, потому что рисует интерфейс сам. Запись на приём, дневник симптомов или экран консультации ведут себя одинаково на iOS и Android из одной кодовой базы — примерно на 30–40% дешевле, чем делать тот же продукт дважды нативно. То, что напрямую касается платформы, — Apple HealthKit и Android Health Connect, Bluetooth-устройства, разрешения на камеру и микрофон, часть видео-SDK — идёт через : это рутина, но это реальная работа.

Какие продукты мы делаем

  • Телемедицина и видеоконсультации — расписание, комната ожидания, живое видео и чат, заметки по сессии и последующее сопровождение
  • Платформы ментального здоровья и терапии — выбор специалиста, регулярные сессии и переписка между приёмами, как в YouMi
  • Личные кабинеты пациента и приложения клиник — записи, результаты, назначения, документы и напоминания поверх существующей медицинской информационной системы
  • Удалённый мониторинг и ведение хронических заболеваний — показатели с носимых и Bluetooth-устройств, динамика, пороговые значения и оповещение врача
  • Велнес, фитнес и приверженность лечению — трекинг привычек и приёма препаратов, где регуляторная нагрузка меньше, а задача удержания сложнее
  • Инструменты для врачей — графики дежурств и обходов, защищённая переписка и быстрая фиксация данных, рассчитанная на работу одной рукой и короткое окно внимания

Кто будет делать ваше медицинское приложение

Две вещи отличают команду, способную сделать медицинское приложение, от команды, которая делала просто приложения.

Живой телемед-продукт, который нас позвали спасать

YouMi — сервис онлайн-консультаций с психологом: пациент выбирает специалиста, записывается и переносит сессии, переписывается с психологом между приёмами. Когда в YouMi LLC обратились к нам, Flutter-приложение уже было в обоих сторах и не справлялось ровно с тем, ради чего существовало: сессии рвались, сообщения в чате не доходили, а утечки памяти в навигационном стеке были такими, что приложение падало при переходах между экранами.

За две недели мы перестроили -слой с полноценным жизненным циклом соединения — автоматическое переподключение, очередь сообщений при смене сети, корректная обработка ошибок, — добавили сквозные статусы доставки, чтобы и пациент, и психолог видели, что сообщение отправлено, доставлено и прочитано, и переписали навигацию на современных API роутинга Flutter.

Именно из-за этого проекта надёжность сессии стоит на этой странице первым пунктом. В телемедицине соединение и есть продукт: консультация, оборвавшаяся на одиннадцатой минуте, — это не «ухудшенный опыт», а несостоявшийся приём, который стоит вам возврата денег, переноса и самого пациента.

Реальное время и защищённая переписка, построенные не в первый раз

Та же задача повторяется во всех наших проектах. Jepta — приложение для соседского общения в Германии, где за каждым чатом и каналом стоит WebSocket-слой; Arcana стримит ответы модели через в чат, который остаётся плавным на тысячах сообщений. Свою позицию по криптографии мы записали, а не просто заявили, — см. Шифрование простыми словами, Как на самом деле работает сквозное шифрование и Ваш SSL pinning, скорее всего, не работает.

Что на самом деле требуют медицинские приложения

В каждом медицинском проекте возникают шесть тем. Вот как мы закрываем каждую.

Сессии, которые переживают реальную сеть

Пациент выходит на консультацию с мобильного интернета, в коридоре, переключаясь с Wi-Fi на LTE посреди разговора. Видео идёт по через SDK провайдера; чат, присутствие и состояние сессии — по . И то и другое оборвётся, и вопрос проектирования не в том, как это предотвратить, а в том, что произойдёт дальше.

Сценарии отказа конкретны, и это всегда одни и те же три: сокет переподключился, но не переподписался — приложение выглядит подключённым и ничего не получает; сообщения, отправленные офлайн, теряются вместо того, чтобы встать в очередь; клиент показывает «идёт сессия» уже после того, как сервер её закрыл. Мы считаем статус доставки полноценным элементом интерфейса — отправлено, доставлено, прочитано, ошибка, — потому что в клиническом разговоре «а он это получил?» не косметический вопрос, и тихий сбой хуже видимого.

Данные пациентов и правила, которые ими управляют

У нас нет ни аттестации , ни сертификации , и любой подрядчик, который продаёт сертификат вместо того, чтобы объяснить, как он строит систему, вам что-то продаёт. Обязательства HIPAA лежат на covered entity («подпадающей организации») и его business associates («партнёрах по обработке») — там, где HIPAA вообще применяется, это обычно вы, ваш хостинг-провайдер и ваш видеовендор, по подписанным соглашениям BAA (Business Associate Agreement). Наша работа — построить так, чтобы ваш комплаенс был достижим, а не превращался в переписывание:

  • Учётные данные и токены в iOS Keychain и Android Keystore, а не в shared preferences
  • с пиннингом сертификатов и планом ротации, который не ломает старые клиенты
  • Биометрия или код-пароль на доступ к защищаемым медицинским данным (PHI), а не только на вход в приложение
  • Шифрованное локальное хранилище для всего, что кэшируется на устройстве, с явной политикой хранения и очисткой при выходе
  • Никаких медицинских данных в логах, крэш-репортах и аналитике — самая частая реальная утечка, которую мы находим
  • Минимум данных на устройстве, какой только позволяет продукт: данные, которых на нём не было, невозможно достать из украденного телефона

добавляет свои архитектурные ограничения, а данные о здоровье относятся к особой категории по статье 9, поэтому для их обработки нужно отдельное основание — а если вы опираетесь на согласие, оно должно быть явным и отзываемым. Запрос на удаление должен быть запросом к базе, а не археологической экспедицией, и физическое расположение данных становится проектным решением, а не деталью хостинга. Такие решения принимают в начале — либо платят за них потом.

Приём — это момент времени, а не строка

Это медицинский аналог задачи о денежной арифметике из финтеха. Приём — это момент времени, о котором должны договориться два человека в двух часовых поясах. Сохраните его строкой локального времени — и рано или поздно вы сдвинете консультацию на час, когда между записью и сессией окажется переход на летнее время, или покажете врачу в Берлине слот, который пациент из Лиссабона бронировал совсем на другой час.

Мы храним моменты в UTC, держим рядом исходный часовой пояс там, где этого требует правило отображения, показываем время в локальной зоне каждого участника и осознанно тестируем границы: запись, сделанная до перевода часов, на сессию после него; пациент, который переехал между этими двумя точками; напоминание, которое должно сработать в правильное локальное время на устройстве, сменившем зону после планирования уведомления. Переносы и отмены — та же задача плюс машина состояний, а обработка неявок — место, где собираются граничные случаи.

Данные о здоровье на устройстве

Показатели из Apple HealthKit, Android Health Connect и устройств с Bluetooth Low Energy — тонометров, весов, глюкометров, носимых гаджетов — доходят до Flutter-приложения через platform channels. Часть вендорских SDK поставляется с Flutter-пакетами; чисто нативные требуют обёртки — это понятный объём работы, а не риск, но он должен быть в смете.

Недооценивают обычно разрешения и пропуски в данных. Медицинские разрешения гранулярные, отзываемые и на каждой платформе устроены по-разному; у фоновой доставки свои правила; а синхронизация, рассчитанная на непрерывный поток, покажет бессмыслицу в первый же раз, когда пользователь оставит часы на зарядке на двое суток. Что приложение делает с пропущенными данными — продуктовое решение, и принимать его лучше до того, как построен график.

Доступность, которая здесь не «приятное дополнение»

Медицинскими приложениями пользуются люди со слабым зрением, тремором, потерей слуха, с когнитивной нагрузкой из-за болезни, а также те, кто ухаживает за пациентом и действует от его имени. Это делает доступность функциональным требованием, а не галочкой комплаенса: динамический размер шрифта, при котором вёрстка не разваливается при 200 %, контраст, выживающий в ярко освещённой приёмной, размеры кнопок под неуверенную руку, метки для скринридера на каждом значимом элементе и субтитры к видео.

Это всё чаще ещё и юридический вопрос. Европейский акт о доступности применяется к целому ряду потребительских цифровых услуг в ЕС с июня 2025 года, а на федеральные госзакупки в США распространяются требования Section 508 — попадает ли конкретный продукт под них — вопрос к вашим юристам, но инженерный ответ в обоих случаях один. Flutter кормит API доступности обеих платформ из дерева, которое строит виджет Semantics, так что это достижимо; просто эту работу нужно закладывать, а не обнаруживать в конце.

Ревью в сторах, которое здесь строже, чем вы ожидаете

Apple проверяет медицинские приложения по пункту 1.4.1 гайдлайнов App Review и может запросить методологию и регуляторные разрешения для любого клинического утверждения. У Google Play своя политика для health-приложений с отдельными декларациями, а у телемедицины и выписки рецептов — требования, различающиеся по странам. Это не повод не запускаться, но повод определить три вещи до того, как функцию начнут делать: что именно приложение утверждает, кто подтверждает это утверждение и в каких странах выходит приложение. Команды, которые узнают об этом на сабмите, теряют недели.

Почему Flutter для медицины

Честный аргумент за Flutter здесь:

ТребованиеКак это решает Flutter
iOS и Android одной командойОдна кодовая база, примерно на 30–40% дешевле двух нативных разработок
Одинаковый клинический интерфейс на всех устройствахFlutter рисует свои пиксели, поэтому запись на приём или экран консультации выглядят одинаково на обеих платформах
Надёжные видео- и чат-сессииSDK для WebRTC и WebSocket доступны; надёжность обеспечивается продуманным переподключением, а не фреймворком
Платформенные примитивы безопасностиKeychain, Keystore и биометрия доступны через platform channels
HealthKit и Health ConnectДоступны через platform channels; для типовых сценариев есть проверенные пакеты сообщества
ДоступностьAPI доступности обеих платформ питаются от дерева Semantics, а динамический шрифт и контраст решаются в дизайн-системе

Экономия — это не скидка на инженерию, а снятие дублирующей работы: один сценарий записи, один сценарий согласия, один набор клинических экранов, которые тестируют дважды, а не строят дважды.

Где нативная разработка всё ещё выигрывает: если ваш продукт по сути обёртка вокруг платформенной возможности — глубокий сценарий на Apple Watch или интеграция с устройством, существующая только как iOS-фреймворк, — преимущество кроссплатформенности схлопывается, и честным ответом может быть нативная разработка. Мы скажем, когда это так. Общая страница услуги — разработка на Flutter.

Как мы работаем

Проект с фиксированным объёмом. Мы отвечаем за поставку целиком — дискавери, архитектура, разработка, подача в сторы. Подходит, когда вы хотите передать определённый объём и иметь команду, отвечающую за результат. Как это выглядит по неделям, описано в нашем процессе разработки.

Staff augmentation. Наши инженеры входят в вашу команду, в ваш репозиторий и ваши спринты, под вашим управлением. Подходит, когда у вас уже есть инженерное руководство и нужны дополнительные Flutter-разработчики — см. расширение команды и наш гайд по найму Flutter-разработчиков, где честно сказано, когда не стоит брать нас.

Спасение и стабилизация. Иногда приложение уже существует и разваливается в проде — именно так начался проект YouMi. Такая работа оценивается по симптомам, а не по списку фич.

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

Частые вопросы

Вопросы, которые чаще всего задают команды, делающие медицинские и телемедицинские продукты на Flutter.

Да. Flutter хорошо подходит для медицинских приложений, потому что рисует интерфейс сам: запись на приём, экран консультации и дневник симптомов ведут себя одинаково на iOS и Android из одной кодовой базы, обычно на 30–40 процентов дешевле двух нативных приложений. Он компилируется в нативный код, поэтому экран консультации остаётся плавным, пока поверх него идут видео и чат, а API доступности обеих платформ питаются от дерева, которое строит виджет Semantics, — в медицине это важнее, чем в большинстве категорий. Компромисс в том, что платформенные возможности вроде HealthKit, Health Connect, Bluetooth-устройств и части видео-SDK доступны через platform channels, а не напрямую: это рутинная, но реальная инженерная работа.
Да — ровно в той же мере, в какой это может любое приложение. Соответствие HIPAA — свойство вашей организации и вашего обращения с данными, а не UI-фреймворка, и обязательства лежат на covered entity и его business associates по подписанным соглашениям BAA: там, где HIPAA вообще применяется, это обычно вы, ваш хостинг и ваш видеовендор. Для технических мер Flutter использует те же платформенные примитивы, что и нативное приложение: iOS Keychain, Android Keystore, биометрические API и TLS с пиннингом сертификатов. Безопасность медицинского приложения определяется дисциплиной реализации. На практике мы находим одни и те же провалы: медицинские данные в логах и крэш-репортах, учётные данные в небезопасном хранилище и лишнее кэширование на устройстве — и все три встречаются в нативных кодовых базах не реже.
Через SDK провайдера WebRTC, а не через собственный стек WebRTC: медиатранспорт, TURN-инфраструктура и согласование кодеков — не то, куда медицинскому продукту стоит вкладывать инженерный бюджет. На качество на самом деле влияет то, что происходит вокруг звонка: комната ожидания, которая объясняет обеим сторонам, что происходит; обработка разрешений на камеру и микрофон, которая восстанавливается, если пользователь сначала отказал, а потом передумал; и поведение при смене сети посреди сессии. Консультация, оборвавшаяся на одиннадцатой минуте, — это несостоявшийся приём, поэтому переподключение проектируется с самого начала, а не добавляется после жалобы.
Да, через platform channels, и для типовых сценариев уже есть проверенные пакеты сообщества. Трудозатраты редко приходятся на само чтение. Они приходятся на разрешения — гранулярные, отзываемые и устроенные по-разному на каждой платформе, — на правила фоновой доставки и на то, что приложение делает с пропусками в данных: пользователю, оставившему часы на зарядке на двое суток, иначе покажут график, из которого следует клинически неверный вывод. Как отображать пропуски — продуктовое решение, которое стоит принять до того, как построен график.
Сфокусированный первый релиз с аккаунтами, записью и одним каналом консультаций обычно занимает три-пять месяцев разработки. Полноценная телемед-платформа с видео, отдельными приложениями для врача и пациента, интеграциями в существующую медицинскую информационную систему и данными с медицинских устройств идёт дольше, потому что сроки определяются сторонними интеграциями, решениями по комплаенсу и ревью в сторах больше, чем работой над интерфейсом. Как объём, бэкенд, интеграции и комплаенс складываются в итоговую цифру, разобрано в нашем гайде по стоимости разработки на Flutter.
Нет, и стоит с подозрением относиться к любому подрядчику, который продаёт сертификат вместо того, чтобы объяснить, как он строит систему. У HIPAA вообще нет схемы сертификации — есть аттестация и аудит на соответствие требованиям HIPAA, и относятся они к организации, обрабатывающей данные, а не к подрядчику, который пишет приложение. Мы даём архитектуру, которая держит медицинские данные вне логов, аналитики и лишнего локального хранилища, хранит учётные данные в аппаратно защищённых платформенных хранилищах и делает запрос на удаление по GDPR запросом к базе, а не раскопками, — чтобы ваш комплаенс был достижим, а не превращался в переписывание.
Из-за того, кто ими пользуется. Среди пользователей медицинского приложения — люди со слабым зрением, тремором, потерей слуха и когнитивной нагрузкой от болезни, а также те, кто ухаживает за пациентом и действует от его имени. Динамический шрифт, выдерживающий 200 процентов, контраст, работающий в ярко освещённой приёмной, размеры кнопок под неуверенную руку и метки для скринридера на каждом значимом элементе — это функциональные требования, а не галочка комплаенса. Есть и юридическое измерение: Европейский акт о доступности применяется к ряду потребительских цифровых услуг в ЕС с июня 2025 года, а на федеральные госзакупки в США распространяются требования Section 508, но инженерный ответ один и тот же — попадает ваш продукт под них или нет.

Разбор стоимости — в статье Стоимость разработки Flutter-приложения в 2026 году, а как выглядит выпущенный телемед-продукт на Flutter — в кейсе YouMi.