Привет! Я — Вера Осолодкина, работаю аккаунт-директором в диджитал-продакшене Далее. Сегодня хочу рассказать о разработке медицинского сервиса для МЕДСИ, который из MVP превратился в полноценный продукт. Это один из самых интересных проектов в моем послужном списке и в целом полезная штука для мониторинга своего здоровья.
Перед моей командой поставили задачу разработать MVP сервиса для контроля здоровья. Своего рода дневник наблюдений для врачей и пациентов. В основе дневника — опросы, которые врач запускает в личном кабинете и отправляет пациенту. С помощью дневника можно отслеживать прогресс лечения, запрашивать обратную связь от пациента при назначении процедур, препаратов, контролировать самочувствие и изменения.
С чего начали
На старте у нас был бриф с верхнеуровневым описанием решения и его функциональных характеристик. Этот бриф мы расширили и уточнили, согласовали с клиентом и пошли на стадию аналитики.
На основе брифа сформировали техническое задание, декомпозировали отдельные блоки будущего решения, прописывали требования и характеристики и начали проектировать и отрисовывать эскизы.
В процессе работы команда МЕДСИ вошла во вкус. Макеты и функциональность согласовывала не только продуктовая команда со стороны МЕДСИ, но и врачи — одни из конечных пользователи сервиса. Требований и пожеланий становилось больше, продукт из MVP начал превращаться в полноценный сервис.
На этапе создания концепции и брифа порой сложно представить конечный результат, тем более, когда работаешь с принципиально новым решением. Понимание, что именно хочется получить на выходе, у клиента складывалось в процессе работы над проектом. Поэтому мы много времени уделяли аналитике, максимально четко прописывали функциональные требования решения, модулей и экранов.
Опросы и админка — главная первичная сущность
Создание прототипов и демо начали с админки. Это логично, потому что в основе сервиса лежит сущность опросов, которая создается и запускается из административной панели.
В системе есть несколько типов вопросов: с выбором одного или нескольких вариантов, открытые, открытые с референсными значениями, вопросы с картинкой, которую подгружает пациент.
Цель опроса — быстро оценить состояние пациента. Поэтому сервис не просто собирает информацию от пациента, но и анализирует. Для удобства аналитики ответам можно присвоить значение (индекс) и выбрать цветовой код.
Опросы создают��я в привязке к диагнозу или к назначению. Например, в случае когда опрос касается не оценки общего состояния, а реакции пациента на препарат.
После того, как мы согласовали функциональность и эскизы админки, перешли к работе над двумя другими сущностями сервиса: врачи и пациенты.
С ростом изменений и расширения функциональности админ-панели, требования к двум другим разделам, «Врачи» и «Пациенты», тоже выросли. Потребовалось больше времени, чтобы их систематизировать, а сроки работы над админкой и так растянулись. Но так как функциональность опросов и общая логика работы всей системы уже была зафиксирована, мы смогли запараллелить процесс аналитики и бэкенд-разработки.
Функциональность для врачей и пациентов
Врачи в сервисе могут добавлять и редактировать списки пациентов, просматривать информацию о них, назначать опросы, устанавливать их длительность и регулярность и анализировать результаты.
Опросы разделяются на опросы качества жизни и общего состояния. Цветовые коды помогают быстро среагировать, если что-то идет не так — отклонения от референсных значений помечаются красным. Результаты доступны в разбивке по датам.
В моду��е сервиса для врача есть не только аналитика по опросам, но и по препаратам и назначениям. Врач может посмотреть результаты исследований, регулярность приема назначенных препаратов.
Пациенты подключаются к сервису через платформу SmartMed, в личном кабинете им доступны назначения, препараты и опросы, которые назначил врач.
Фронтенд-разработка и дизайн
В МЕДСИ есть внутренние стандарты и правила для разработки IT-решений. Они касаются не только используемых языков разработки, но и компонентов. Так, фронтенд сервиса должен был быть написан на Vue.js с использованием библиотек, которые применяются в МЕДСИ.
В дизайне тоже есть свои требования. Несмотря на то, что мы ��елали предварительную аналитику по дизайну, UX-исследования и с первого раза достаточно точно попали в ожидания, часть элементов пришлось менять в соответствии с правилами МЕДСИ.
Например, просто отрисовать раскрывающееся меню мы не могли — нужно было ориентироваться на доступные подобные элементы в библиотеке. Если подходящего элемента нет, но без него не обойтись — мы шли к клиенту, согласовывали эти изменения, а они добавляли в библиотеку дополнительный элемент.
Конечно, это было не просто и трудозатратно, но плюсы такого подхода мы тоже ощутили. Так как проект сильно вырос в объемах относительно первого согласованного брифа, часть задач закрывала команда МЕДСИ: дизайн и разработку фронтенда некоторых элементов. Единый подход к дизайну и разработке упростил взаимодействие между командами, передать ТЗ было проще, чем если бы мы писали сервис по своим стандартам.
Бэкенд и интеграции
Чтобы написать этот раздел, я сходила к нашему разработчику, Дане Лихачеву. Все, что идет дальше, написано с его слов.
Дневник можно считать самостоятельным приложением, встроенным в микросервисную архитектуру приложения МЕДСИ SmartMed и связанным в нескольких местах с их сервисами.
Изначально Дневник наблюдений планировался как отдельное приложение, который работает через редиректы и лежит не в контуре клиента. Но так как в процессе работы требования изменились, его нужно было интегрировать в инфраструктуру МЕДСИ, соединив его со SmartMed. Причем таким образом, чтобы для пользователей приложения этот п��реход был бесшовным.
Чтобы этого достичь, мы использовали аутентификацию через один из сервисов клиента. Эта интеграция была запланирована в финальной части разработки, но архитектурно заложили ее сразу, написав код для валидации.
Кроме привязок пользователей мы делали интеграцию чата с системой МЕДСИ. У клиента существовал бэкенд чата и компоненты, которые можно было использовать на фронте в части приложения для врачей, но не пациентов.
Поэтому фронт чата для врачей мы дорабатывали, а для пациентов писали с нуля. Далее интегрировали фронт с бэком дневника, который, в свою очередь, инициирует gRPC-запрос в бэкенд МЕДСИ на создание чата. После создания чата нашим бэкендом, фронт связывается непосредственно с сервисом чатов у МЕДСИ и обрабатывает переписку уже на их стороне.
Эти и другие интеграционные требования мы прорабатывали вместе с клиентом. К нам подключился аналитик со стороны МЕДСИ, которая описывала межсервисные интеграции. Это помогло нам не тратить время на исследования сервисов и сразу перейти к поиску решений для интеграций.
Другим требованием была разработка на Python. Нам предложили использовать темплейт приложения на FastAPI с SQLAlchemy с дополнительными внутренними либами под FastAPI. Но возникли сложности. SQLAlchemy хоть и является неким стандартом, который часто используют с FastAPI, нам работать с ней было неудобно.
В какой-то момент мы поняли, что разрабатывать на SQLAlchemy будет слишком трудозатратно, да и качество кода было посредственным из-за определенных решений в библиотеке. Поэтому с частью готового кода мы решили переехать на другую ORM, Tortoise ORM. Она вдохновлена DJango ORM, но при этом асинхронная. Пощупав ее вне проекта, мы начали медленно мигрировать.
Сначала просто добавили в проект, затем начали переписывать имеющийся код, и в самом конце окончательно убрав SQLAlchemy с проекта, мы поняли, что не ошиблись. Количество боли, строк кода и времени сократилось раза в два, если не больше, при переходе на Tortoise ORM. Хотя у нас уже и был работающий функционал, перенести его на новую ORM заняло меньше одного дня.
Схема релизов тоже заслуживает упоминания. Изначально мы поднимали бэкенд на своих серверах, затем развернули его на препроде в контуре МЕДСИ. На прод клиент выкатывает бэкенд самостоятельно и делает это быстро и без проблем, так как мы учли все требования и особенности инфраструктуры МЕДСИ.
С учетом этих требований нам также нужно было либо держать репозиторий в гитлабе клиента, чтобы было не очень удобно для команды, либо решать вопрос с автоматизацией контроля версий. Мы выбрали второй вариант. Придумали скрипт, который переносит все изменения из нашего репозитория к команде МЕДСИ, и наоборот.
Что в результате
У нас было много жестких требований к разработке и архитектуре решения. Проект сильно расширился в процессе работы, приходилось быстро перестраиваться и искать способы оптимизации трудозатрат.
Я считаю, что правильным решением с нашей стороны было не стесняться тратить время на аналитику. Благодаря этому мы избежали сложностей, связанных с тем, что клиенту может что-то не понравиться, а прогресс разработки уже такой, что вносить изменения и откатывать очень дорого. С проектами, в которых требований много и они регулярно обновляются такие риски особенно высоки. А значит аналитика становится особенно важной.
Помогла и слаженная работа с командой МЕДСИ. Договариваться приходилось много: из-за изменений в требованиях менялся скоуп работ и наши трудозатраты, нужно было пересматривать часть функционала, что-то сокращать. Нам всегда удавалось прийти к оптимальному решению в таких случаях.
За счет того, что МЕДСИ взяли на себя часть работ по проекту, сроки запуска не сильно пострадали. Продукт действительно стал гораздо сложнее и объемнее относительно запланированного MVP, но зато не потерял в качестве.
