Clinio

Продукт: MedTech service с пациентским, врачебным и клиническим контурами.

Роль: продуктовый дизайнер, сценарии, архитектура ролей, интерфейсы, состояния, системный слой.

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

Публичное доказательство: safe hero/source crops, role map, appointment handoff, medcard continuity, consilium flow, source/privacy boundary.

Граница результата: не заявлять clinical outcomes, revenue, retention, appointment conversion и hard launch claim без подтвержденного источника.

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

Главный конфликт был в передаче контекста. Пациент уже рассказал о себе, выбрал врача, прошел сценарий записи или консультации. Врач должен увидеть нужные вводные, а не начинать с пустого экрана. Клиника должна развивать продукт так, чтобы новый сценарий не ломал общую медицинскую историю.

Задача была не в том, чтобы просто нарисовать медицинские модули. Нужно было понять, как контекст переходит между ролями и где продукт должен помнить уже собранную информацию.

Я разложил работу на простой путь:

1. Пациент входит в сценарий и выбирает нужное действие.
2. Запись собирает базовый контекст.
3. Вводные переходят в медкарту и консультацию.
4. Врач работает с подготовленным контекстом.
5. Сложный случай может уйти в консилиум.
6. Итог возвращается в общую медицинскую историю.

Я проектировал пользовательские сценарии, информационную архитектуру, интерфейсы и системный слой продукта. Работал с продуктовой командой, owner, разработкой и медицинскими экспертами, передавал фичи в разработку и участвовал в доводке решений.

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

Здесь важно не писать общими словами про "много экранов". Сильнее показать, как каждая часть держит передачу контекста: кто что вводит, кто что видит дальше и где данные остаются доступными.

Сильная публичная версия Clinio должна показывать не галерею медицинских экранов, а сервисную логику продукта.

Минимальный набор:

1. Ролевая карта: пациент, врач, клиника, консилиум.
2. JTBD-карта: зачем каждая роль входит в продукт.
3. Flow передачи контекста от записи к врачу.
4. Медкарта как рабочая память продукта.
5. Консилиум как пространство совместного решения.
6. SOURCE/REDACTED crop только там, где медицинские данные безопасны.
7. Privacy/source boundary: что показываем, что перерисовываем, что оставляем private-only.

Главная идея была простой: медицинский продукт должен не заставлять пользователя повторять контекст на каждом шаге.

Я проверял это через несколько решений:

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

Для публичного кейса нельзя опираться на медицинские результаты или бизнес-метрики. Поэтому основное доказательство - структура пользовательского пути и source-safe артефакты.

Я показываю путь как передачу контекста:

1. Пациент формулирует запрос.
2. Система собирает первичные данные.
3. Врач получает подготовленный пакет.
4. Медкарта сохраняет историю.
5. Консилиум подключает несколько специалистов.
6. Итог возвращается в общий контур.

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

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

Запись на консультацию - это не только выбор врача и времени. В этом сценарии пациент формулирует проблему, вводит первичные данные, получает подсказки, а врач должен увидеть контекст до начала работы.

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

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

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

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

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

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

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

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

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

До уточнения launch boundary не нужно писать, что платформа была публично запущена с нуля. Безопаснее: была собрана архитектура продукта с нуля и спроектированы ключевые пользовательские контуры.

Я не публикую читаемые медицинские истории, диагнозы, лабораторные значения, имена, фотографии, телефоны, адреса и приватные фрагменты консультаций. Реальные body screens можно использовать только после анонимизации или как приватную основу для redrawn explanatory artifacts.

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

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

• Что именно означает с нуля: MVP, pilot, public release или design delivery.
• Какие body screenshots можно анонимизировать и показывать.
• Какой clinic/admin scope подтвержден источниками.
• Где использовать SOURCE/REDACTED crops, а где только IMAGEGEN-АРТЕФАКТ.
• Нужен ли отдельный generated hero или достаточно 00-hero-cover.png после review.

Этот блок показывает Clinio как систему ролей и передаваемого контекста: от записи и анамнеза до медкарты, врача и консилиума.