Разработка ПО
Менеджмент
Для компаний
Для стартапов
Архитектура ПО
Літа-доктор - это кабинет семейного врача и онколога, который позволяет вести профилактику пациентов (пока что только по схемам ВОЗ тестов онкологии, но в будущем будут внедрены и другие). Эта система является продолжением приложения и третьим продуктом компании ТОВ Літа Хелз. СТарт данного софта был дан на хакатоне от Гарварда в апреле 2024 года.
Как мы собрали medical MVP за 3 дня на хакатоне Harvard
Это был не просто хакатон с небольшим недосыпом =). Это был Harvard Health Systems Innovation Lab Hackathon 2024 — международное healthtech-событие, где команды за считанные дни должны были придумать, спроектировать, собрать и защитить новый продукт для медицины.
Наша команда пошла в трек онкологии и за 3 дня собрала не просто красивую идею, а рабочий вертикальный срез продукта (то есть не макет ради макета, а живой кусок системы от интерфейса до логики и данных). Мы успели пройти продуктологию, аналитику, медицинскую доменную экспертизу, UX/UI-дизайн, фронтенд, бекенд, базу данных, инфраструктуру и упаковку проекта в презентацию и английский питч. Для хакатона это уже не sprint, а маленькая хирургическая операция над хаосом =).
Сам хакатон был действительно масштабным. Глобально он проходил как часть инициативы Harvard HSIL, а украинский хаб работал в Киеве вместе с международной программой. В зале были медики, founders, разработчики, исследователи, менторы, представители health-среды и люди, которые умеют задавать очень неприятные, но очень полезные вопросы. И это прекрасно: именно так хорошие идеи перестают быть милыми фантазиями и начинают походить на продукт.
На сцене выступали спикеры из разных стран, параллельно шли включения с другими городами и хабами, а команды бегали между менторами, гипотезами, ноутбуками и кофе-машиной, словно это распределённая система (distributed system — когда много частей должны синхронно работать вместе и не развалиться).
Снаружи всё выглядело как эффектный питч. Внутри это была очень взрослая работа: утром ты обсуждаешь медицинскую логику, днём проектируешь сущности и роли, вечером чинишь поток данных, а ночью переписываешь слайды так, будто всю жизнь мечтал стать одновременно архитектором, аналитиком и стендап-комиком.
В течение трёх дней мы делали новый софт, собирали презентации, тренировали английский питч и ходили по менторам за критикой. Нам подсказывали, где бизнес-модель хрупкая, где UX слишком академичный, где нужно упростить сценарий для врача, а где — наоборот — сделать систему строже. В итоге вышло именно то, ради чего и существуют хорошие хакатоны: не набор экранов, а продукт, который выглядит как начало серьёзной медицинской платформы.
По реакции судей было видно, что наш проект воспринимался не как сырая идея под инвестиции, а как решение, у которого уже есть продуктовая логика, понятный сценарий использования и архитектурный скелет. И это справедливо: когда у тебя есть доменная экспертиза, нормальная аналитика и сильная инженерная сборка, даже MVP начинает выглядеть так, будто у него уже есть трекшн.
Кстати, если вам близок подход не давайте-быстро-накодим, а сначала-разберёмся-и-соберём-нормальную-систему, посмотрите как мы подходим к проектированию, этапам работ и архитектуре продуктов. Там как раз про ту часть разработки, которую обычно не видно на слайдах, но именно она потом спасает бюджет, сроки и нервную систему.
Ниже — несколько видео с хакатона и живой атмосферы события.
Что именно мы сделали
В рамках хакатона мы собрали интерфейс и логику кабинета врача, который интегрирован с пациентским приложением. Если кратко, это healthtech-система для профилактической онкологии, где врач видит пациента, его тесты, результаты, факторы риска и рекомендации, а доступ к данным управляется самим пациентом.
То есть перед нами была не абстрактная CRM с белыми карточками и синими кнопками, а медицинский кабинет с очень чувствительной логикой: роль врача, роль пациента, разграничение прав доступа, хранение и отображение тестов, интерпретация ответов по медицинским алгоритмам и безопасная передача данных между сторонами. В терминах архитектуры это уже не лендинг и не личный кабинет интернет-магазина. Это маленькая клиническая информационная система.
Если вам интересна более широкая тема проектирования медицинских систем и интеграции с государственным медконтуром, у нас есть отдельный кейс про проектирование МИС по eHealth. Там хорошо видно, насколько быстро медицина превращает разработку из просто кода в инженерную дисциплину с кучей ограничений, стандартов и нюансов.
Как работает кабинет врача
Врач на своём рабочем месте видит список пациентов — но только тех, которые сами передали ему доступ через приложение. Это важный момент: мы сразу строили систему не по принципу врач видит всё, потому что он врач, а по принципу consent-based access (доступ по разрешению пациента). Для медицины это не декоративная фича, а фундамент доверия и юридической аккуратности.
Мы сознательно сделали крупную типографику, большие отступы и визуально чистые карточки. Потому что врач в реальной жизни должен думать о пациенте, а не разгадывать ребус из мелких цифр, десяти таблиц и тридцати кнопок на одном экране. Хороший медицинский интерфейс должен не кричать, а помогать.
В профиле врачу генерируется уникальный идентификатор. Его можно передать пациенту для связи внутри системы. Также врач может загрузить фото и обновить свои данные. Это простая, но важная часть онбординга: чем меньше трения на входе, тем выше шанс, что инструментом будут реально пользоваться, а не героически игнорировать.
Далее врач открывает конкретного пациента и получает доступ к его данным и истории профилактических тестов. И вот здесь начинается самая интересная часть. Обычно при смене врача или клиники история пациента распадается как плохо склеенная керамика: куски данных остаются в разных местах, что-то теряется, что-то недоступно, что-то лежит в бумаге, что-то в голове у администратора. Мы строили систему наоборот — так, чтобы история обследований не исчезала вместе со сменой кабинета, клиники или человека в халате.
Врач может просматривать все тесты, к которым пациент дал доступ, включая исторические данные. Это особенно ценно в профилактике и онкологии: контекст прошлого часто важен не меньше текущего состояния. Поиск по датам, параметрам и типам тестов здесь уже не удобство ради удобства, а инструмент клинической навигации.
Для каждого теста врач видит слева вопросы и ответы пациента. Сами тесты построены на основе медицинских алгоритмов и логических веток — по сути это rule engine (движок правил, который выбирает следующий вопрос и итоговые выводы по набору условий). Такие схемы легко выглядят простыми снаружи и удивительно коварными внутри: один ответ меняет не только текущий экран, но и всю логику следующего маршрута пользователя.
Эта механика более подробно раскрыта в отдельном кейсе про приложение Лита и конструктор онкологических тестов, потому что сам движок тестирования — это самостоятельный продукт со своей логикой, сценариями и медицинской валидностью. В данном кейсе мы фокусируемся именно на кабинете врача и связке врач ↔ пациент ↔ результаты.
В правой колонке система показывает результаты и рекомендации, сформированные на основе ответов и тех самых медицинских алгоритмов. Это не магия и не генеративное шаманство, а воспроизводимая логика: одинаковые входные данные должны приводить к одинаковому базовому выводу. Да, врач может скорректировать интерпретацию с учётом внесистемных факторов, но сама система закрывает рутинную часть анализа и формирует структурированный текст по факторам риска, приоритетам и профилактическим шагам.
Для врача это полезно сразу в двух плоскостях. Во-первых, ускоряется принятие рутинных решений по профилактике. Во-вторых, появляется структурированный материал для обязательной отчётности по проведённым профилактическим мероприятиям. То есть система одновременно поддерживает клиническую работу и административный контур — а это в медицине редкая роскошь.
Вход без лишней боли
В кабинет врача можно войти классическим способом через логин и пароль, а можно через Google или Facebook. Это уже стандартный OAuth-вход (механизм, когда часть проверки личности берёт на себя внешний провайдер), который снижает трение при авторизации и уменьшает число брошенных входов.
Как пациент добавляет врача
Связка между пациентским приложением и кабинетом врача реализована через раздел Добавить врача. Пациент вводит идентификатор врача и самостоятельно решает, кому именно открыть доступ. Это тот случай, когда UX напрямую обслуживает privacy-by-design (подход, при котором приватность вшивается в продукт с самого начала, а не прикручивается потом на скотч).
После подтверждения врач видит историю тестов пациента в своём кабинете. Никакой магии, никакого доступа по умолчанию, никакого медицинского телепатического поля. Только явное действие пациента и прозрачная модель передачи прав. Для чувствительных медицинских данных это, мягко говоря, правильный путь.
Как пациент видит свои результаты
Со стороны пациента всё тоже предельно понятно. Он может посмотреть результаты теста, изучить рекомендации и при необходимости обратиться к своему семейному врачу. Мы даём материалы для самостоятельного ознакомления, хотя, конечно, не призываем людей играть в домашний медицинский консилиум без профильного образования.
Также пользователь может получить полный план профилактики, который формируется системой и дополнительно проверяется живым врачом. Это важная идея продукта: не заменить врача кнопкой, а убрать рутину, структурировать данные и помочь обеим сторонам быстрее дойти до полезного действия.
Что показывает этот кейс
Этот кейс хорошо показывает, как выглядит настоящая быстрая разработка в healthtech. Не та, где за ночь рисуют три экрана и называют это инновацией, а та, где за очень короткое время собирают работающую продуктовую связку: роль пациента, роль врача, права доступа, алгоритмы тестов, результаты, рекомендации, авторизацию и понятный интерфейс.
Именно поэтому судьи и отреагировали на наш питч как на что-то слишком взрослое для обычного хакатона. Когда команда умеет соединять доменную экспертизу, системный анализ и software architecture (архитектуру ПО — то есть заранее продуманную конструкцию системы, а не хаотичный набор экранов и таблиц), результат начинает выглядеть как бизнес, а не как студенческая самодеятельность.
А если у вас уже есть идея медицинского продукта, кабинета врача, patient app, MIS, B2B-платформы для клиник или сложного healthtech-сервиса, посмотрите наш подход к проектированию и запуску таких систем. Там есть о компании, принципы работы, этапы, отзывы и возможность оставить заявку на бесплатную консультацию. Без магии, зато с аналитикой, архитектурой и взрослыми вопросами на старте =).
