Макеты согласовывали врачи: как мы разрабатывали сервис наблюдения пациентов для МЕДСИ

Привет! Мы — диджитал-продакшен Далее. Сегодня делимся кейсом разработки медицинского сервиса для МЕДСИ, который из MVP превратился в полноценный продукт. Потратили 1500 часов на разработку, еще 300 на аналитику и отловили 189 багов. Все для того, чтобы современные пациенты могли эффективно наблюдаться у врачей и получать индивидуальный план лечения в смартфоне.

МЕДСИ, наш постоянный клиент, пришел к нам с задачей разработать MVP сервиса для контроля здоровья. Своего рода дневник наблюдений для врачей и пациентов, который станет частью платформы МЕДСИ SmartMed. В основе дневника — опросы, которые врач запускает в личном кабинете и отправляет пациенту.

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

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

На основе брифа сформировали техническое задание, декомпозировали отдельные блоки будущего решения, прописывали требования и характеристики и начали проектировать и отрисовывать эскизы.

В процессе работы клиент вошел во вкус. Макеты и функциональность согласовывала не только продуктовая команда со стороны МЕДСИ, но и врачи — одни из конечных пользователи сервиса. Требований и пожеланий становилось больше, продукт из MVP начал превращаться в полноценный сервис.

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

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

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

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

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

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

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

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

Пациенты подключаются к сервису через платформу SmartMed, в личном кабинете им доступны назначения, препараты и опросы, которые назначил врач.

А еще врачам и пациентам в сервисе доступны чаты и планирование онлайн-консультации.

В МЕДСИ есть внутренние стандарты и правила для разработки IT-решений. Они касаются не только используемых языков разработки, но и компонентов. Так, фронтенд сервиса должен был быть написан на Vue.js с использованием библиотек, которые применяются в МЕДСИ.

В дизайне тоже есть свои требования. Несмотря на то, что мы делали предварительную аналитику по дизайну, UX-исследования и с первого раза достаточно точно попали в ожидания клиента, часть элементов пришлось менять в соответствии с правилами МЕДСИ.

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

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

Дневник можно считать самостоятельным приложением, встроенным в микросервисную архитектуру приложения МЕДСИ SmartMed и связанным в нескольких местах с их сервисами.

Изначально Дневник наблюдений планировался как отдельное приложение, который работает через редиректы и лежит не в контуре клиента. Но так как в процессе работы требования изменились, его нужно было интегрировать в инфраструктуру МЕДСИ, соединив его со SmartMed. Причем таким образом, чтобы для пользователей приложения этот переход был бесшовным.

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

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

Поэтому фронт чата для врачей мы дорабатывали, а для пациентов писали с нуля. Далее интегрировали фронт с бэком дневника, который, в свою очередь, инициирует gRPC-запрос в бэкенд МЕДСИ на создание чата. После создания чата нашим бэкендом, фронт связывается непосредственно с сервисом чатов у МЕДСИ и обрабатывает переписку уже на их стороне.

Эти и другие интеграционные требования мы прорабатывали вместе с клиентом. К нам подключился аналитик со стороны МЕДСИ, которая описывала межсервисные интеграции. Это помогло нам не тратить время на исследования сервисов и сразу перейти к поиску решений для интеграций.

Другим клиентским требованием была разработка на Python. Нам предложили использовать темплейт приложения на FastAPI с SQLAlchemy с дополнительными внутренними либами под FastAPI. Но возникли сложности. SQLAlchemy хоть и является неким стандартом, который часто используют с FastAPI, нам работать с ней было неудобно.

Схема релизов тоже заслуживает упоминания. Изначально мы поднимали бэкенд на своих серверах, затем развернули его на препроде в контуре МЕДСИ. На прод клиент выкатывает бэкенд самостоятельно и делает это быстро и без проблем, так как мы учли все требования и особенности инфраструктуры МЕДСИ.

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

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

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

За счет того, что МЕДСИ взяли на себя часть работ по проекту, сроки запуска не сильно пострадали. Продукт действительно стал гораздо сложнее и объемнее относительно запланированного MVP, но не потерял в качестве.

Вера Осолодкина — руководитель проекта

Влад Климанов — Lead backend-разработчик

Даниил Лихачев — Backend-разработчик

Юля Зубова — руководитель отдела аналитики

Яна Марченкова — frontend-разработчица

Валерия Лашко — продуктовый дизайнер

Станислав Репков — QA

Да, тут будет ссылка на наш телеграм-канал :) Вот она.

Публикуем там вакансии, анонсы и просто интересный контент на подумать и поразмышлять.