Как Хайди создала готовый к работе ИИ для здравоохранения в глобальном масштабе

При поддержке MongoDB

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

Австралийский стартап в области медицинского ИИ Heidi представляет собой пример успешной модернизации. Его флагманский продукт, Heidi Scribe, теперь автоматизирует значительную часть административной работы, отнимающей время у клиницистов более чем в 190 странах, и поддерживает около 2,7 миллиона взаимодействий с пациентами еженедельно. По словам Ю Лю, сооснователя и технического директора Heidi, этот рост опирается на инфраструктурные решения, принятые за годы до того, как компания вышла на глобальный уровень.

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

Почему развертывание производственного ИИ в здравоохранении архитектурно отличается от других сфер

Для Heidi локализация данных (residency) — это предварительное условие, а не просто функция. Врач в Сиднее, Лондоне, Токио или Денвере работает в рамках различных нормативно-правовых режимов, включая Австралийские принципы конфиденциальности, GDPR, APPI и HIPAA, и данные их пациентов должны храниться в том же регионе.

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

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

Выбор базы данных для интеграции с рабочими процессами ИИ

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

Учитывая эти требования, документная база данных стала для Heidi естественным выбором. MongoDB предоставила команде гибкость для работы с быстро меняющимися данными ИИ без необходимости постоянно перестраивать базовую базу данных.

«Модель составляет, пожалуй, 20% системы, а архитектура данных определяет, выдержат ли остальные 80% реальную клиническую нагрузку», — говорит Лю.

Сеанс AI Scribe — это не просто отдельная порция данных. Это совокупность стенограмм, структурированных заметок, шаблонов, документов, контекста пациента, состояния интеграции с электронными медицинскими картами (EHR) и десятков других связанных артефактов, которые меняются от недели к неделе. MongoDB позволяет данным сеанса храниться вместе в структурах, которые соответствуют реальной работе врачей, и позволяет Heidi развивать эти структуры без заморозки миграций при каждом обновлении продукта.

«MongoDB Atlas выделялась тем, что сочетала в себе мощь документной модели, обеспечивающей бесшовное масштабирование, гибкость и высокую производительность, с встроенными функциями для работы с ИИ, такими как MongoDB Vector Search«, — говорит Лю. «Это означает, что Heidi не нуждается в дополнительной внешней векторной базе данных для расширения своей существующей платформы».

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

«Heidi Scribe преобразует большие объемы медицинских документов в векторные эмбеддинги с помощью LangChain в Atlas, обеспечивая семантический поиск, который напрямую связывает транскрибированные медицинские термины с соответствующими внешними знаниями», — добавляет Лю. «Миграция на Atlas снизила задержку (latency) для ключевых API почти на 33%».

Что требуется от надежной клинической системы RAG

«Извлечение данных (retrieval) — это в первую очередь проблема архитектуры данных, а уже потом проблема ИИ», — говорит Лю. «В потребительском RAG вы ищете данные в открытом интернете и надеетесь на лучшее, в то время как в здравоохранении вы ищете данные в рамках периметра соблюдения нормативных требований (compliance surface)».

Heidi Evidence осуществляет поиск по лицензированным базам клинических знаний, включая таких партнеров, как BMJ Best Practice, NICE CKS и MIMS, с учетом юрисдикции. Британский врач получает рекомендации для Великобритании, а австралийский — австралийские формуляры, поскольку правильный ответ в одной стране может оказаться неправильным в другой.

Эмбеддинги и векторные индексы Heidi хранятся в MongoDB Vector Search в тех же регионально изолированных средах, что и остальные данные. Это означает физическую невозможность пересечения границы локализации данных при поиске, при этом компании не нужно управлять отдельной векторной базой данных со своей собственной системой безопасности и комплаенса. Цитаты представляют собой жесткий контракт, а не предложение подсказки (prompt suggestion), поскольку модель видит только те извлеченные фрагменты, которые уже привязаны к исходным записям.

Региональная изоляция обеспечивает глобальное соответствие требованиям и масштабируемость

«Каждый регион представляет собой полностью изолированное производственное развертывание с собственными кластерами MongoDB Atlas, собственными вычислительными мощностями и собственным ключом», — говорит Лю.

«Именно это позволяет нам прийти в систему здравоохранения США, траст NHS или австралийскую больничную группу и дать четкий ответ о локализации данных, поскольку она обеспечивается на уровне инфраструктуры, а не обещаниями в контракте», — поясняет он. «Запуск нескольких изолированных регионов силами небольшой команды возможен только потому, что уровень базы данных управляем и стабилен. Мы также используем мультиоблачный подход, что означает возможность развернуть новое окружение в другом регионе на базе уже готовых шаблонов».

Эта архитектура наиболее ярко проявила себя в США, где Beth Israel Lahey Health, одна из крупнейших систем здравоохранения Новой Англии, развертывала ИИ-ассистент Heidi после того, как пилотное исследование показало: 74% врачей сообщили о сокращении объема работы с документами вне рабочего времени («pajama time»), а некоммерческая система MaineGeneral Health выбрала Heidi в качестве стратегического партнера в сфере медицинского обслуживания сельского населения.

«Выход на рынок США означал развертывание еще одного региона на уже построенной базе, а не перепроектирование под HIPAA задним числом», — говорит Лю.

Извлеченные уроки и дальнейшие планы

«Репартиционирование большой, горячей, постоянно работающей коллекции — это серьезная инженерная задача, в то время как выбор ключа шардирования в первый день — это вопрос проектирования», — говорит Лю. «Мы делаем эту работу сейчас в партнерстве с MongoDB, но урок для любого разработчика дата-интенсивного продукта на базе ИИ заключается в том, что горизонтальное масштабирование для самых быстро растущих данных — это фундаментальное решение, такое же как и локализация данных».

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

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

Спонсорские статьи — это контент, подготовленный компанией, которая либо платит за публикацию, либо имеет деловые отношения с VentureBeat, и они всегда четко помечены. Для получения дополнительной информации обращайтесь по адресу sales@venturebeat.com.