Clinio: сервис для пациентов, врачей и клиники

Clinio — MedTech-сервис, где пациентский и врачебный контуры сходятся вокруг записи, консультаций, чата, медкарты, вопросов врачам, рекомендаций, консилиумов и закрытого клуба.

Сложность была не в одном красивом flow, а в ролевой архитектуре. Пациент, врач и clinic-facing контур смотрят на одну медицинскую историю из разных сценариев, но продукт должен читаться как одна система.

Визуальный слой кейса теперь опирается на рабочие экраны: запись, медкарту и консилиум. Процессные карты остаются рядом как рабочие материалы, но не заменяют сам продукт.

Локальные экраны могли закрывать свои задачи, но сквозная логика между ролями легко расползалась. Запись, анамнез, консультация, рекомендации и медкарта должны передавать один контекст, а не жить как отдельные интерфейсные куски.

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

Моя зона была не в UI-polish отдельных экранов. Я собирал продуктовую архитектуру: ролевые контуры, IA, ключевые сценарии пациента и врача, внешние страницы и связи между модулями.

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

В этом кейсе артефакты лучше читать сверху вниз: сначала карта ролей и общих сущностей, затем handoff пациента к врачу, затем медкарта и consilium workflow. Так видно продуктовую архитектуру, а не просто набор MedTech-экранов.

Главный сдвиг: продукт стал собираться вокруг ролей, общих сущностей и переходов между сценариями. Пациентский контур — запись, вопросы, медкарта, кошелёк. Врачебный — консультации, консилиумы, настройки, закрытый клуб. Clinic-facing контур в публичной версии показан как product framing, без неподтвержденных admin operations.

Важнее были не отдельные модули, а связи между ними: запись → анамнез → консультация → рекомендации → история в медкарте; вопрос → ответы → выбор врача; консилиум → обсуждение → заключения.

Пациент выбирает врача и записывается через короткую форму. Бот собирает анамнез и передаёт его врачу до начала консультации. Дальше врач прикладывает рекомендации и отправляет заключение прямо в чате.

Здесь важно было сделать входной шаг коротким и при этом не потерять медицинский контекст до старта консультации. Это workflow evidence, не claim про conversion или clinical result.

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

Медкарта спроектирована не как визуальный архив документов, а как рабочий hub истории пациента. Главное — информационная архитектура: разделы, функциональные блоки, динамика по анализам и связь с рекомендациями.

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

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

Помимо записи, медкарты и консилиумов в продукте проработаны: вопросы врачам (discovery + платное продвижение + выбор специалиста), кошелёк (платежи, вывод средств, бонусы для пациента и врача), рабочее место врача (управление приёмами + контекст пациента + заключение в одном workflow), настройки врача (внутренние данные + публичный профиль для пациентов) и закрытый клуб (внутренняя соцсеть для врачей с контентом и монетизацией).

В этой версии кейса они упомянуты обзорно, чтобы не превращать историю в каталог экранов. Основной proof остается в role architecture, appointment handoff, medcard hub, consilium workflow и design-system layer.

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

Токены, компоненты, состояния и UI-гайды помогали масштабировать роли и сценарии без ручного пересоздания логики в каждом модуле. Это proof системного лидерства, а не claim про скорость разработки или бизнес-метрики.

Public source говорит, что продукт был спроектирован и запущен с нуля, но не уточняет тип запуска: MVP, public release, pilot или design delivery. Поэтому в публичной версии это directional source signal, а не измеримый product outcome.

Сильная часть кейса — то, что пациентский, врачебный и clinic-facing контуры собраны в понятную архитектуру, а дизайн-система стала инфраструктурой для роста сценариев. Clinical outcomes, conversion, retention, revenue и operational metrics не заявляются.