Metriport привлекла $26 млн — истории болезней соберут из разных систем

Публикация Metriport от 27 августа 2026 года фиксирует привлечение $26 млн: раунд возглавил генеральный партнёр Matrix Ти Джей Паркер, в нём участвовали ARTIS и Y Combinator, а общий объём финансирования компании достиг $28,4 млн.
Деньги предназначены для расширения открытой инфраструктуры, которая получает медицинские записи из разных систем, сопоставляет их с пациентом и приводит к единой модели данных. Результат можно передать через API, загрузить в хранилище или встроить в медицинскую информационную систему, чтобы с ним работали врачи, приложения и ИИ-агенты.
Карточка финансирования CB Insights также датирует раунд 27 августа и указывает сумму $26 млн, но оценивает совокупно привлечённый капитал в $28,9 млн. Поскольку компания раскрыла показатель $28,4 млн, именно он используется как основной; причина расхождения в $0,5 млн публично не объяснена.
Новый капитал расширит уже работающую платформу

Metriport развивает не будущую единую базу историй болезни, а промежуточный инфраструктурный слой между медицинскими источниками и системами клиентов. Компания планирует направить финансирование на масштабирование платформы, а также на машинное обучение, автоматические сводки и возможности для ИИ-агентов.
Платформа подключается к сетям обмена медицинской информацией, больницам, амбулаторным учреждениям, лабораториям и аптекам. Затем она сопоставляет записи с пациентом, извлекает сведения, стандартизирует их, удаляет дубликаты и формирует продольную историю — последовательное представление медицинских событий во времени.
В материале HIT Consultant среди клиентов Metriport названы Amazon One Medical, Sollis Health и Color Health; издание также описывает преобразование разнородных записей в единую модель с доступом через API, хранилище или приложения внутри электронной медицинской карты.
Это уточняет границы формулировки «истории болезней соберут из разных систем». Metriport не создаёт универсальную государственную карту пациента и не получает автоматически все существующие медицинские сведения: она объединяет записи, которые доступны конкретному клиенту через подключённые сети и учреждения.
Единый доступ ещё не делает историю полной

Один API решает проблему подключения, но не гарантирует полноту и клиническую однозначность результата. Больница может вернуть клинический документ, аптека — историю отпуска лекарств, а лаборатория — набор исследований. Эти сведения способны относиться к разным периодам, дублировать друг друга или расходиться по статусу назначения и дате обновления.
Описание Medical API указывает, что согласованные данные возвращаются преимущественно в формате FHIR R4, клинические документы также доступны в C-CDA, а сводки — в PDF. Запросы к сетям обмена, аптекам и лабораториям выполняются асинхронно: приложение получает отдельное уведомление по мере завершения каждого класса источников.
Поэтому первая поступившая часть истории может быть технически корректной, но ещё не окончательной. Система, которая передаёт такие данные врачу или ИИ, должна различать завершённые и продолжающиеся запросы, сохранять дату и происхождение записи, а при расхождениях показывать исходные документы вместо выбора одного значения без объяснения.
Для медицинского ИИ это принципиальное ограничение. Модель может найти нужный фрагмент, сгруппировать события или сократить объём документов, но не способна восстановить обследование, которое не вернул ни один доступный источник. Практически пригодный ответ поэтому отличается от просто удобной сводки наличием ссылок на исходные записи, статуса загрузки и видимых пробелов в истории.
Открытый код не означает открытый доступ к пациентам

Открытость Metriport относится к программной инфраструктуре и логике преобразования данных, а не к самим историям болезни. Возможность изучить код делает обработку проверяемой и снижает зависимость от закрытого посредника, но не отменяет правовых оснований доступа, проверки медицинских организаций и разграничения полномочий внутри их систем.
Для производственного доступа клиент должен действовать от имени охватываемой медицинской организации, иметь идентификатор NPI и использовать данные с допустимой целью лечения. Это контроль на уровне подключения организации; он не заменяет внутренние правила, определяющие, какой сотрудник или сервис может видеть конкретные сведения о пациенте.
Отдельный риск связан с техническими учётными данными. Документация Metriport по ключам API предупреждает, что ключ даёт полный доступ к API, включая разрушительные операции: его следует использовать только в серверных службах, не раскрывать открытым текстом и немедленно отзывать при компрометации. Одновременно могут действовать до двух ключей, что позволяет заменить один другим без остановки запросов.
Из этого следует важное различие: открытый код помогает проверить, как платформа преобразует записи, но сам по себе не доказывает минимальность доступа каждого подключённого приложения. За распределение прав между пользователями и сервисами отвечает также архитектура медицинской организации, которая интегрировала платформу.
Каких данных о развитии Metriport пока нет
Компания не раскрыла оценку бизнеса, распределение нового капитала между подключением источников, базовой инфраструктурой и ИИ-функциями, а также сроки выпуска новых агентных возможностей. В открытых материалах нет и результатов независимой клинической проверки, по которым можно было бы оценить полноту сформированных историй, частоту пропусков или точность автоматических ответов врачу.
На данный момент подтверждены сам раунд и назначение платформы: Metriport уже собирает, нормализует и доставляет записи из разных медицинских систем, а новый капитал должен увеличить масштаб инфраструктуры и развить аналитический слой над ней. Следующей содержательной вехой станут измеримые данные о новых подключениях и о том, насколько сводки для врачей и ИИ сохраняют происхождение сведений, обозначают незавершённые запросы и не скрывают клиническую неопределённость.
Читайте также:
Подпишитесь на рассылку
Получайте свежие новости Web3, AI и криптовалют прямо на вашу почту.