прототип мобильного приложения Клиники ухо, горло, нос им. проф. Е.Н.Оленевой. подготволен совместно с Claude.ai design и Claude CLI
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 

38 KiB

Приоритеты развития мобильного приложения — встреча 23 апр 2026

Клиника УГН (ЛОР, сурдология, аллергология, хирургия). Цель встречи — определить порядок развития функций: что закрываем как базу для всех пациентов, какие сегменты углубляем и в каком порядке.

1. Контекст и критерии приоритизации

Текущие функции: список врачей, запись на приём, ближайший приём, чат с оператором, профиль, семейный профиль, контакты.

Ключевые факты о потоке

  • 2 из 3 пациентов клиники — повторные. Значительная доля — повторные внутри одного лечения: после первого визита (острое заболевание или обострение хронического) ещё 1–3+ приёма, процедуры, контроль.
  • Бизнес-сегментация (из аналитики клиники) — 10 сегментов, лидеры по выручке: амбулаторный поток (~120 млн), взрослая хирургия «заблокированный нос» (~30 млн), детская аденоидная хирургия (~20–30 млн), сурдология (~20 млн).

Продуктовая логика: что делает приложение

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

Это совпадает с фактом «2 из 3 — повторные» и означает, что:

  • Первичные сценарии в приложении закрываются универсальным минимумом (запись + контакты + цены + AI-помощник, который знает услуги). Нет смысла строить специализированные первичные потоки для каждого из 10 сегментов.
  • Повторные сценарии — специфичны по сегменту и требуют отдельных модулей (бегунок, аудиограмма, АСИТ-дневник и т.п.).
  • Исключения — сегменты, где «первичный в приложении» ≠ «первый визит»: после первого визита пациент уходит, и вернуть его в клинику может только приложение.
    • Сурдология — после визита и демо пациент уходит думать 2–3 месяца о покупке аппарата.
    • Хирургия (FESS, детские аденоиды, вазотомия) — после пред-операционного приёма у хирурга пациент часто уходит думать, решаться ли на операцию вообще. Эти «сомневающиеся» — отдельная работа по возврату. Вторая часть — те, кто решился, уходят в 6-недельную подготовку (бегунок).
    • АСИТ — после назначения впереди 3–5-летний курс, есть сценарии «не начал» и «бросил в первые месяцы».

Три слоя работы

  1. Фаза 1 · Транзакционная база — детерминированные функции для любого пациента: запись, ближайший приём, чат с оператором, план лечения, результаты/медкарта, заказ справок. Без LLM и прямого чата с врачом. Минимум рисков, быстрый запуск.
  2. Фаза 1.5 · Коммуникационная надстройка — чат с медицинским консьержем (дежурным врачом/фельдшером) и AI-помощник в shadow-mode. Отделено от Фазы 1, чтобы регламенты и безопасность не задерживали релиз базы.
  3. Фаза 2 · Сегментные модули — углубление по приоритетным группам сегментов (A → C → B → D).

Критерии приоритета

Критерий Что меряем
Охват Сколько пациентов клиники затронуто (в абсолюте)
Глубина пользы Насколько закрывает реальную боль (есть ли альтернатива без нас)
Частота касаний Как часто функция возвращает пользователя в приложение
Бизнес-эффект Влияние на возвратность, средний чек, удержание, вклад в выручку
Сложность Вторичная ось: усилия (вкл. зависимости от МИС и контента)

2. Текущие функции — утилита и приоритет

🟢 Высокий приоритет (ядро ценности)

Запись на приём — главный транзакционный поток. Экономит 3–8 минут разговора, 24/7, ближайшие окна. Единственная функция, которая приводит новых пациентов через приложение. Усилить: запись из плана лечения в 1 клик (§3), запись из маршрутной карты пред-опа (§4).

Ближайший приём — «что со мной сейчас». Снимает тревогу «когда, куда, к кому». Перед визитом открывается 3–10 раз. Усилить: чек-лист подготовки, маршрут до кабинета, тригеры 24ч/2ч/15мин.

🟡 Средний приоритет (поддержка)

Список врачей / карточка врача — инструмент выбора при первом визите. Повторный пациент почти не открывает. Усилить: соцдоказательства, фильтр «по моему диагнозу».

Чат с оператором — замена звонка в регистратуру. Ограничен одним собеседником. Основное развитие — в §3.

Профиль — точка идентификации. Редко открывается, но критичен для персонализации.

🔴 Низкий приоритет (ниша)

Семейный профиль — высокая польза для 20–30% (родители с детьми, взрослые с пожилыми), становится критичным для сегмента «дети с аденоидами» и «сложные хроники — ЧБД».

Контакты — функция «галочка», 1–2 открытия за всё время.

Вывод

Ядро «Запись + Ближайший приём» работает. Слабое место — нет причины открывать приложение между визитами. Это и закрывает джентльменский набор.


3. Джентльменский набор — базовые функции для всех пациентов

Минимум, который должен быть у любого пациента клиники, вне зависимости от диагноза и сегмента. Приоритет до любых сегментных модулей.

Набор сознательно разделён на две подфазы по риску и зависимостям: транзакционная база (детерминированные функции с понятным MVP) и коммуникационная надстройка (LLM и асинхронные каналы, требующие регламентов и безопасности). Это позволяет выпустить базу быстро и безопасно, а надстройку строить поверх уже стабильного фундамента.

Фаза 1 · Транзакционная база

Функции, где пациент что-то получает или делает — без LLM и без диалога. Минимизируют риски, быстрее в запуск, дают те самые «не удалю это приложение»-причины.

Функция Статус Что в ней
Запись на приём есть Запись 24/7, ближайшие окна.
Ближайший приём есть Что, где, когда — снимает тревогу перед визитом.
Чат с оператором есть Справки, переносы, счета, расписание (человеческий канал).
Статьи / база знаний есть (Спринт 1) Уже есть. Источник правды для будущего RAG.
План лечения с приёма нет — фундамент После каждого приёма структурированный чеклист: диагноз, назначения (препарат + доза + курс + календарь), ссылки на процедуры самопомощи (Группа A), контрольный приём, запись на следующий визит в 1 клик. Живой объект с напоминаниями. Источник правды для всех следующих надстроек.
Результаты обследований и медкарта нет Пациент видит свои анализы, аудиограммы, снимки, заключения без звонка в клинику. Статус каждого результата: готов / в работе / годен до [дата]. Критично для Группы C (пред-оп): срок годности анализов виден в одном месте.
Заказ справок и финансовых документов нет Справка для налогового вычета (13%), справки работодателю, копии заключений, счета. Заказ в 1 клик, готовая в приложении или с самовывозом. Снимает нагрузку с администраторов и даёт сильный retention-якорь даже у разовых пациентов.

Фаза 1.5 · Коммуникационная надстройка

Функции, где идёт живой или AI-диалог по поводу лечения. Строятся поверх уже работающей базы (плана лечения, медкарты, статей) и требуют отдельных регламентов — по ответственности, SLA, проверке качества.

Функция Статус Что в ней Ключевой риск
Чат с медицинским консьержем нет Не прямой чат с лечащим врачом. Дежурный врач / фельдшер / медсестра отвечает по протоколам на 80% рутины («можно ли совмещать с X», «нормально ли, что третий день болит», «когда повторно сдать анализ»), эскалирует клинически значимое лечащему. Асинхронно, SLA — X часов в рабочее время. Перегрузка врачей и SLA-хаос, если пустить пациентов напрямую к хирургу. Консьерж-слой — основной буфер. Нужен регламент тарификации/компенсации врачам за эскалированные вопросы.
AI-помощник (RAG 24/7) нет Знает базу знаний клиники, статьи, план лечения пациента, историю приёмов. Объясняет назначение, ищет ответ в статьях, оценивает «норма или срочно» и эскалирует к консьержу/врачу при тревожных признаках. Галлюцинация LLM в медицинском контексте = юридический и репутационный риск. Запускаем в shadow-mode: ответы сначала идут через консьержа для валидации, метрики точности собираются, и только после набора статистики — переход в прямой режим для безопасных категорий вопросов.

Почему это ядро, а не сегмент

  • Работает на 100% пациентов — без разделения по сегменту.
  • Усиливает любое сегментное направление: бегунок, слухопротезирование, АСИТ — всё опирается на план лечения, медкарту и тот же чат-канал.
  • Закрывает главный пробел транзакционной модели — «что делать между визитами».
  • Частично закрывает самый массовый сегмент (амбулаторный + хроники). Полностью закрыть их может только отдельный модуль «Процедуры самопомощи» (Группа A, §4.3) — это первый сегментный модуль после Фазы 1.5.

Порядок работ внутри набора

Фаза 1:

  1. План лечения с приёма — фундамент. Без структурированных назначений не работает ничего поверх (ни AI, ни напоминания, ни процедуры самопомощи).
  2. Результаты / медкарта — следующий retention-якорь.
  3. Заказ справок — быстрый win для большой части пациентов, снимает нагрузку с администраторов.

Фаза 1.5 (после стабилизации Фазы 1): 4. Чат с медицинским консьержем — инфраструктура канала + регламент ответов. 5. AI-помощник на RAG (shadow-mode) — сначала ответы валидируются консьержем, потом постепенный переход в прямой режим для безопасных категорий.

Критическая зависимость от МИС

«План лечения» — это структурированные данные (препарат, доза, частота, курс, процедура). Два сценария:

  • МИС отдаёт назначения по API структурированно — план лечения собирается автоматически из данных приёма. Предпочтительно.
  • МИС отдаёт только PDF-заключение — план лечения MVP стартует с ручного ввода врачом в виджет (шаблоны по нозологиям + чеклисты + автоподстановка из предыдущего приёма). Интеграция с МИС — отдельной задачей позже.

Ответ на этот вопрос определяет сроки и стоимость Фазы 1. Добавлен в §6 как первоочередной.


4. Сегменты пациентов через призму приложения

4.1. Фундаментальное деление: первичный vs повторный

Линза Первичный в приложении Повторный в приложении
Главный job «Куда мне обратиться и как записаться» «Что мне делать сейчас по моему лечению»
Источник Попадает через сайт/рекламу/сарафан Приложение уже установлено, уведомление/сам открывает
Частота открытия 1–3 раза до визита Ежедневно в активном эпизоде
Что нужно в приложении Базовый минимум (запись, цены, контакты, врачи) Специализированный модуль сегмента
Приоритет развития Низкий (веб и реклама работают лучше) ● Высокий (2/3 потока)

Ключевое следствие. Специализированных «первичных» модулей под каждый сегмент строить не нужно. Исключения — сегменты, где «после первого визита» начинается длинный путь: сурдология, хирургия, АСИТ. Там «первичный» в терминах клиники ≠ «первичный» в терминах приложения.

4.2. Матрица 10 сегментов × первичный / повторный

Из 10 сегментов бизнес-аналитики выделяем: объём × чек × что нужно в приложении для первичного × что нужно для повторного × итоговый приоритет приложения.

# Сегмент (из аналитики) Объём / Вклад Первичный в приложении Повторный в приложении (главная работа) Приоритет в App
1 Взрослые «заблокированный нос» (полипы, перегородка, FESS) 300 оп/год · 100т · 30 млн Джентльменский + материалы о методах (FESS/лазер), кейсы пациентов, калькулятор, возвратные push для сомневающихся после пред-оп приёма Пред-оп бегунок (6 нед) → восстановление → контроль 3/6/12 мес Высокий (Группа C)
2 Амбулаторный поток (острые и хроники ЛОР) Тысячи/мес · 120 млн Джентльменский План лечения + эпизод лечения + дневник симптомов (§3) + модуль процедур самопомощи: библиотека техник (промывание носа физраствором, полоскание горла, ингаляции), напоминания, трекер комплаенса Высший (Группа A — отдельный модуль)
3 Родители детей с аденоидами 400–500 оп/год · 60т · 20–30 млн Джентльменский + семейный профиль + подготовка ребёнка + материалы «нужна ли операция» и возврат сомневающихся родителей Пред-оп бегунок (детская версия) → восстановление. Далее — редко. Высокий (Группа C)
4 Потеря слуха (сурдология) 20 млн/год Нестандартный первичный: аудиограмма в профиле, аудио-демо, каталог моделей, калькулятор, шеринг близкому, возвратные push Паспорт аппарата, сервисный календарь, расходники, калибровка раз в год, дневник адаптации Высокий (Группа B — уникальный модуль)
5 Сложные хроники (иммунология/аллергология, ЧБД) Высокий, часть 120 млн · длинный LTV Джентльменский + семейный (ЧБД) + запись на консилиум Модуль процедур самопомощи (Группа A): промывания, полоскания, ингаляции у ЧБД. Плюс специализация: АСИТ-трекер (дневник симптомов + пыльцевой календарь + навигатор побочки) Высокий (Группа A + Группа D)
6 Зависимость от капель (вазотомия) Высокий объём · входной в хирургию Джентльменский + материалы «как слезть с капель» + возврат сомневающихся после пред-оп приёма Пред-оп бегунок (компактная версия) → восстановление Высокий (Группа C)
7 Пульмонология (кашель/астма) Средний · сезонный Джентльменский Дневник астмы, напоминания об ингаляторах, контроль триггеров (пересекается с АСИТ) Средний (частично Группа D)
8 Социально активные храпуны Низкий · высокая платёжеспособность Джентльменский + образовательный контент о сомнологии Сомнологический чек-up, СИПАП-трекер (если назначен) Низкий
9 Фониатрия (голос) Очень низкий · срочный Джентльменский + срочная запись Короткое окно, низкая повторность Низкий
10 Check-up и Второе мнение Единичный · высокая маржа Джентльменский + позиционирование бренда Оленевой Разовая услуга, минимальная повторность Низкий

4.3. Четыре группы сегментов для повторных

Группа A. Амбулаторный поток + хроники — процедуры самопомощи — сегменты 2 + 5 (повторная часть). Самый массовый сегмент × ежедневная повторность.

Джентльменский набор (план лечения + чат с врачом + AI) закрывает коммуникацию и напоминания, но не закрывает саму регулярную работу пациента между приёмами:

  • Промывание носа физраствором (при хр. рините, синусите, после операций)
  • Полоскание горла (при хр. тонзиллите)
  • Ингаляции
  • Гимнастика слуховой трубы (при евстахиите)
  • Голосовые упражнения (фониатрия)
  • Туалет уха (при хр. отите)

Что нужно в модуле:

  • Библиотека техник — короткие видео и пошаговые инструкции «как правильно». Ошибки в технике (сильный напор при промывании, не тот раствор) — частая причина, почему «не помогает».
  • Напоминания — утро/вечер по схеме, привязаны к плану лечения.
  • Трекер комплаенса — ежедневные отметки, стрики, сводка «сколько дней подряд».
  • Дневник симптомов в связке — «промываю 5 дней, насморк уменьшился с 4 до 2» — главный мотиватор продолжать.
  • Сводка для врача — перед контрольным приёмом врач видит, что пациент делал, как часто, с какой динамикой симптомов.

Это отдельный модуль, не продолжение Фазы 1. Он опирается на план лечения как на источник назначений, но требует собственного контента (библиотека техник) и UX (трекер).

Группа B. Сурдология — сегмент 4. Уникальный набор функций (аудиограмма, аудио-демо, каталог, паспорт аппарата). Пожизненная повторность. Высокий чек. Отдельный модуль, не пересекается с другими.

Группа C. Пред-операционная подготовка + восстановление — сегменты 1 + 3 + 6 (одна механика для трёх сегментов). Две фазы, как у Группы B:

  • Кандидаты на операцию — после пред-оп приёма ушли «думать». Возврат через материалы, кейсы пациентов, чат с хирургом, возвратные push-триггеры (3/7/21 день), прозрачность по цене/рассрочке.
  • Решившиеся — бегунок → чек-лист дня операции → операция → восстановление. Окно 6–12 недель.

Один модуль закрывает три сегмента бизнес-аналитики (FESS, детские аденоиды, вазотомия).

Группа D. АСИТ + контроль астмы — часть сегмента 5 + сегмент 7. Ежедневный трекер, дневник симптомов, навигатор побочки. Самый сложный, требует верификации врачом.

4.4. Что остаётся за кадром

Сегменты 8 (храпуны), 9 (фониатрия), 10 (check-up) — низкая повторность и/или низкий охват. Закрываются базовым джентльменским набором, специализированных модулей в ближайшем горизонте не требуют.


5. Порядок внедрения

Фаза 1. Транзакционная база (§3)

План лечения → Результаты / медкарта → Заказ справок.

Эффект: пациент видит свои назначения, результаты и может получить документы без звонка в клинику. Это и есть базовые retention-якоря: «не удалю это приложение». Массовый амбулаторный + хроники покрыты в части информирования и документов.

Критический параметр сроков — структурированность назначений в МИС (см. §6 вопрос 1). От этого зависит, собирается ли план лечения автоматически или врач заполняет его вручную в виджете.

Фаза 1.5. Коммуникационная надстройка (§3)

Чат с медицинским консьержем → AI-помощник (shadow-mode).

Зачем отдельная подфаза: эти функции несут организационные и юридические риски (SLA, выгорание врачей, галлюцинации LLM) и могут надолго задержать релиз, если класть в Фазу 1. Выделение в 1.5 позволяет: собрать транзакционную базу быстро и безопасно, отработать регламент консьержа отдельно, запустить AI сначала под валидацией человека.

Фаза 2. Сегментные модули — порядок

Рекомендуемая последовательность:

1. Группа A (Процедуры самопомощи хроников) — первым

  • Самый массовый охват — тысячи пациентов в месяц (сегмент 2 + 5).
  • Напрямую опирается на план лечения из Фазы 1 — продолжение той же инфраструктуры.
  • Средняя сложность: контент (видео-инструкции, 10–15 техник) + простой трекер + дневник симптомов.
  • Бизнес-эффект: рост комплаенса → меньше обострений → меньше экстренных приёмов и операций, на которые хроники срываются, когда дома не помогает.
  • Эффект заметен пациенту сразу — ежедневная польза.

2. Группа C (Пред-операционная подготовка) — вторым

  • Закрывает 3 сегмента (1, 3, 6) одним модулем.
  • Быстрый MVP — маршрутная карта с чекбоксами, сроки годности, автозапись. Восстановление уже есть в прототипе.
  • Прямой измеримый бизнес-эффект: снижение переносов операций из-за просроченных анализов + возврат сомневающихся кандидатов на операцию.
  • Вклад сегментов в выручку: ~50–60 млн (хирургия), плюс косвенно вазотомия как конвертер в большую хирургию.

3. Группа B (Сурдология) — третьим

  • Изолированный сегмент с уникальными функциями.
  • Пожизненное удержание × высокий чек × растущий рынок (старение).
  • Две половины: возврат кандидатов после демо (высокая конверсия в деньги) + обслуживание после покупки (лояльность и LTV).
  • Можно запускать параллельно с C после Фазы 1, если есть ресурс.

4. Группа D (АСИТ + астма) — четвёртым

  • Самая высокая глубина пользы (влияет на медисход), но самая высокая ответственность.
  • Требует верификации контента аллергологом/пульмонологом клиники.
  • Можно начать готовить контент и интеграции параллельно с A/C/B, выпустить позже.

Что не берём в план сейчас

  • Храпуны (8), фониатрия (9), check-up (10) — специализированных модулей в горизонте планирования не делаем.
  • Отдельные «первичные» модули под сегменты — не делаем. Первичный путь = джентльменский набор + базовые функции (запись, врачи, цены, контакты), которые уже есть.

Что нужно сделать вне Фаз, уже сейчас

  • Добавить аллерголога-иммунолога в список врачей (есть специализация, нет конкретного врача в данных). Предусловие для Группы D.

6. Вопросы к обсуждению на встрече

Первоочередной (определяет сроки Фазы 1):

  1. МИС и структурированные назначения. Отдаёт ли МИС по API назначения структурированно (препарат, доза, частота, курс) или только PDF-заключением? От этого зависит: план лечения собирается автоматически или врач заполняет вручную в виджете. Там же: API для результатов анализов, сроков годности, расписания.

По процессам клиники:

  1. Медицинский консьерж — кто в роли? Дежурный врач / фельдшер / медсестра? Кто держит SLA? Как компенсируется эскалация вопроса лечащему врачу?
  2. SLA чата — целевое время ответа в рабочее время (1ч / 4ч / день)?
  3. Справки и финдокументы — текущий процесс заказа через администратора; что готовы автоматизировать в первую очередь (ФНС-справка, выписки, счета)?

По метрикам (для оценки эффекта):

  1. Подтвердить «2 из 3 — повторные» — уникальные пациенты в год или визиты? Меняет оценку охвата Группы A.
  2. Процент повторных, не доходящих до контроля — метрика успеха Фазы 1.
  3. Сурдология — кандидатов/мес, % возврата за аппаратом. От этого зависит приоритет Группы B.
  4. Переносы операций — частая причина просроченные анализы? Усиливает Группу C.

По ресурсам Фазы 1.5 и 2:

  1. Готов ли аллерголог верифицировать контент для АСИТ-трекера? Без этого D не запускаем.
  2. База знаний / статьи — достаточно ли материала для RAG или формировать отдельно?
  3. Политика по AI shadow-mode: кто утверждает категории вопросов для постепенного перевода в прямой режим?

Приложение. Короткая сводка для слайда

Что предлагаем:

  1. Фаза 1 — транзакционная база для всех: план лечения, результаты/медкарта, заказ справок + уже существующие запись, ближайший приём, чат с оператором, статьи. Быстрый MVP, минимум рисков.
  2. Фаза 1.5 — коммуникационная надстройка: чат с медицинским консьержем (не прямой с врачом) и AI-помощник в shadow-mode. Запускается после стабилизации базы.
  3. Фаза 2 — четыре сегментных модуля в порядке: A (процедуры самопомощи хроников — массовый) → C (пред-оп подготовка — 3 сегмента разом) → B (сурдология — высокий чек) → D (АСИТ + астма — с верификацией врачом).
  4. Первичные в приложении = базовый минимум, который уже есть. Новых первичных модулей не строим — они приходят через веб. Исключения — сегменты, где после первого визита пациент «уходит думать»: сурдология, хирургия, АСИТ.