Создаем медицинский консьерж-сервис, учитывающий нюансы страхования в США

Jiseki Health — это медицинский консьерж-сервис, который помогает клиентам следить за своим здоровьем и улучшать качество жизни. Продукт может подключаться к разным сервисам и маркетплейсам, чтобы оказывать помощь клиентам социальных, медицинских и страховых служб. Консультанты Jiseki, например, могут общаться с клиентами страховых компаний в чатах поддержки или по телефону и предлагать им медицинскую помощь, доставку продуктов или заказ нужных услуг. Среди основных клиентов этого стартапа — известный американский производитель электромобилей и крупные американские страховые компании.

Jiseki — первый и единственный поставщик услуг по принципу «Whole-Person Care». С точки зрения этого принципа любые проблемы человека (медицинские или социальные) должны рассматриваться как совокупность физических и личных параметров. В России аналогом такого подхода является сбор социального анамнеза или анамнеза жизни пациента.

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

А по методологии «Whole-Person Care» он должен выяснить у пациента обстоятельства жизни, эмоциональное состояние, нюансы ежедневной рутины. В таком случае случайная фраза о неудобном рабочем месте и куче невыполненных задач может стать сигналом о том, что проблема в позвоночнике, а головная боль — лишь симптом. Лечение в таком случае также может включать рекомендации по изменению образа жизни, а не только лекарства.

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

Задача

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

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

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

Создание движка правил

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

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

• Какой-то поставщик медицинских услуг решает, что все их пользователи, отвечающие определённым требованиями и живущие в определённом месте, должны подписаться на регулярную проверку здоровья.
• Затем эпидемиолог использует разработанный нами механизм для автоматического ввода данных и установления правил, определяющих эту группу пациентов.
• После чего в компании ставят задачу — отправить СМС всем женщинам 20–35 лет, работающим в определённой компании. А в этом напоминании говорится, что они должны записаться на осмотр в течение 7 дней.
• Сервис выполняет все указанные правила и действия, а пациенты автоматически получают полезные сообщения/уведомления. Входные данные — это в основном беседы, но в будущем можно будет вводить заметки, оценки, электронные медицинские карты, результаты исследований из лабораторий, информацию о рецептах, а также некоторые демографические и финансовые данные.

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

API-ориентированная архитектура

Несмотря на то, что разработка брокера сообщений казалась довольно простой, была пара сложных нюансов, в основном связанных с API.

Например, мы должны были сделать все данные электронных медицинских карт доступными через REST API. Но единственным доступным для экспорта форматом данных был HL7, так что нам пришлось оптимизировать процесс обмена данными с HL7 API. Используя HL7 FHIR API, мы преобразовали формат данных в подходящий для механизма обмена сообщениями.

Движок правил отправляет запрос через REST API к сервису, чтобы отправить сообщение пользователю. Сам по себе он не подключён к СМС-провайдеру или мессенджеру.

Выполнение правила включает в себя несколько вызовов API в. момент, когда правило оценивается как истинное. Например, если механизм обмена сообщениями отправляет сообщение «Спасибо за заполнение нашего опроса. Мы скоро свяжемся с вами», то он также отправляет вызов API для помещения пользователя в список приоритетов (в панели инструментов агента) и создает предупреждение для агента.

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

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

Планирование событий

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

Технологический стек

Сервис реализован с использованием Python, а REST API для клиента написано на Django + DRF. Airflow, вместе с Celery + Redis, используется для выполнения задач и планирования правил. Интерфейс администратора создан с помощью Django, для хранения данных используется Postgresql, а DynamoDB организует взаимодействие между компонентами сервиса. Развертывание было реализовано с использованием Docker + Docker Compose для локальной разработки, а Kubernetes в качестве рабочей инфраструктуры.

Систему нужно было обернуть в простой интерфейс, который позволял бы пользователям в компаниях устанавливать правила обмена сообщениями и управлять ими, поэтому мы сделали интерфейс управления приложением на React.

Используя React и Typescript, мы разработали приложение для управления правилами клиентских уведомлений. В этом приложении мы не использовали глобальное состояние, вместо этого использовался глобальный кэш с React Query. Это позволило нам упростить архитектуру приложения и значительно сократить объем кода для взаимодействия с сервером.

Соответствие правилам HIPAA

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

Что получилось в итоге?

Мы полностью разработали первую версию продукта, проработали бизнес-требования, спроектировали интерфейс и сформировали архитектуру сервиса.

Когда сервис будет запущен, Jiseki ожидает, пользовательскую базу в 40 000 — 60 000 человек. Компания, по сути, хочет постоянно проводить продуктовые исследования и определять, что работает, а что — нет: пробовать разные паттерны взаимодействия с пациентами, измерения результатов. План состоит в том, чтобы сузить сферу применения правил. В первой версии, которую мы разработали, они универсальны, но в более поздних версиях правила будут сложнее и точнее, будут отличаться для каждого человека, основываясь на определенной статистике и моделях ИИ.

Постоянная цель Jiseki Health — лучше понимать своих клиентов и приспосабливать службы к их специфическим потребностям. Команда Evrone будет рада продолжить внедрение новых услуг и решений, чтобы помочь Jiseki делать такой гуманистично-ориентированный продукт.

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