Легко предположить, что FHIR-эндпоинт любого поставщика может удовлетворить требования текущего года; и для демонстрации это часто верно. Но это лишь минимальное требование, а не конкурентное преимущество. Вопрос, который действительно разделяет поставщиков (и который большинство покупателей не догадываются задать, пока не подпишут контракт), заключается в том, что находится под этим эндпоинтом. Потому что то, что находится под ним, определяет, покупаете ли вы фундамент или арендуете фасад.
Это различие сводится к архитектуре. И именно поэтому мы создали 1up Platform как lakehouse, а не как более привычную комбинацию реляционного хранилища данных с прикрученным сверху API для обеспечения соответствия требованиям.
От хранилища данных к Lakehouse: 30-летний обходной путь, прежде чем здравоохранение получило то, что ему нужно
1990-е годы подарили нам реляционные базы данных. Строки, столбцы, фиксированные схемы, соединения. Они были (и остаются!) превосходны в одном: быстрые, надежные запросы к структурированным данным, которые идеально и аккуратно помещаются в таблицы. Подвох в том, что схема должна быть определена до того, как появятся данные. Это нормально для главной бухгалтерской книги. Но это губительно для экосистемы здравоохранения, где каждая EHR, каждый плательщик и каждая государственная программа Medicaid форматируют данные немного по-разному.
2000-е годы подарили нам NoSQL, созданный для обработки данных, которые не хотели «сидеть» в строках и столбцах (документы, пары ключ-значение, гибкие структуры…). Это решило проблему жесткости, но часто ценой управления и производительности запросов, от которых зависят регулируемые отрасли.
2010-е годы подарили нам озеро данных (data lake); дешевое, эластичное хранилище, которое принимало все, что вы в него отправляли, структурированное или нет. Наконец-то появилось место для потоков HL7, плоских файлов и пользовательских форматов, которые никогда не вписывались в модель хранилища. Но озеро без организации — это просто очень большая коробка с немаркированными коробками. Хранить данные стало проще, но использовать их по-прежнему было трудно.
Lakehouse — это то, что получается, когда вы перестаете довольствоваться архитектурой, созданной для других отраслей. Это не компромисс между озером и хранилищем. Это то, что вы получаете, когда отказываетесь принимать слабые стороны любого из них или идти на компромисс в отношении сильных сторон: доступность и гибкость озера, структура и надежность хранилища, управление, встроенное изначально, а не добавленное в качестве запоздалой мысли.
Большая часть рынка интероперабельности данных в здравоохранении так и не развила свою архитектуру
Многие поставщики решений по интероперабельности все еще используют какую-то версию первой эры: реляционное ядро с уровнем трансляции FHIR перед ним, генерирующее соответствующий требованиям вывод, не меняя того, что происходит внутри. Это позволяет вам пройти текущую проверку на соответствие требованиям. Это не дает вам ничего пригодного для повторного использования и масштабируемого, когда появится следующее постановление или когда вы захотите сделать что-то с данными помимо сценария использования для соответствия требованиям, для которого вы изначально покупали инструмент.
Мы намеренно строили иначе. 1up Platform — это lakehouse; достаточно гибкий, чтобы принимать данные здравоохранения в любом формате, в котором они фактически поступают, и достаточно управляемый, чтобы сделать эти данные пригодными для использования, а не просто хранить их. В этом разница между поставщиком, который может ответить на сегодняшнее требование, и тем, чей фундамент построен так, чтобы продолжать отвечать по мере изменения требований.
Архитектура Lakehouse от 1up становится реальным преимуществом в тот момент, когда меняется правило
Масштабируемость встроена в каждый уровень нашей фундаментальной модели. Apache Iceberg дает каждой таблице полную историю версий: каждая схема, каждое состояние, извлекаемые в любой момент времени. Trino отделяет вычислительные ресурсы запросов от хранилища, поэтому инструменты BI, аналитика, API и рабочие нагрузки ИИ могут обращаться к одним и тем же управляемым данным без создания дублирующих копий. А поскольку вычислительные мощности и хранилище масштабируются независимо, производительность API не снижается по мере роста использования. Уровень оркестрации, работающий по всему конвейеру, выявляет отклонения и проблемы с качеством данных до того, как они станут результатами аудита, а не после.
Именно здесь архитектурное преимущество превращается в бизнес-преимущество. Требования CMS к интероперабельности не стоят на месте. Спецификации дополняются, руководства по внедрению обновляются, сроки сдвигаются. Поставщик, чья платформа может представлять ваши данные только в том виде, в котором они выглядят сейчас, — это поставщик, которому приходится суетиться (и часто просить вас помочь профинансировать переделку) каждый раз, когда меняются правила. Поскольку наша платформа спроектирована с учетом версионности, адаптация к новому требованию — это возможность, которая у нас уже есть, а не проект, который мы должны продать вам отдельно.
Это принципиально другие отношения с поставщиком. Это разница между покупкой соответствия требованиям как разового результата и покупкой партнера, который берет на себя регуляторные изменения как часть платформы, за которую вы уже платите.
Соответствие требованиям CMS — это только начало того, что поддерживает этот фундамент. 1up Clinical Connect и будущие инновации работают на одних и тех же стандартизированных, версионированных данных без необходимости запуска второго проекта по приему данных для каждого из них. Архитектура не сбрасывается с каждым новым сценарием использования.
Одна платформа данных о здоровье, а не растущий стек точечных решений
Вот часть, которая наиболее важна для совокупной стоимости владения и консолидации поставщиков. Поскольку мы стандартизируем данные один раз в общую модель, этот же фундамент обеспечивает работу всего последующего (API доступа пациентов и провайдеров, обмен данными между плательщиками, рабочие процессы электронной предварительной авторизации, а также аналитика и отчетность по качеству) без перестройки конвейера для каждого из них.
Сравните это с более распространенным путем: поставщик для обеспечения соответствия текущему мандату, отдельный поставщик аналитики, когда вы хотите что-то сделать с данными, и еще одно точечное решение, когда появляется следующее постановление, каждое со своей интеграцией, своим контрактом и своей моделью данных, которая не взаимодействует с другими. Это не просто дороже. Это медленнее каждый раз, когда появляется что-то новое, потому что ни один из этих инструментов не был создан для использования общего фундамента.
С 1upHealth инвестиции в прием данных, которые вы делаете один раз, продолжают окупаться. Каждый новый результат работает на инфраструктуре, которой вы уже владеете.
Что произойдет через восемнадцать месяцев: будущее интероперабельности
Демонстрация любого поставщика будет выглядеть одинаково. Настоящее испытание наступит позже: появится новое правило или вы захотите создать что-то, о чем в RFP не упоминалось. Спросите, что находится под API. Архитектуру трудно подделать, и именно поэтому 1upHealth создана, чтобы стать последним поставщиком интероперабельности, которого вам придется оценивать, а не первым в растущем стеке.
Готовы увидеть разницу, которую дает архитектура? Запросите демо, и мы покажем вам, что на самом деле находится под эндпоинтом.
