Крайний срок реализации требований к API обмена данными между плательщиками в рамках CMS-0057 — 1 января 2027 года. Говоря техническим языком, большинство медицинских планов, которых касается это правило, идут по графику его соблюдения.
Но вот о чем никто не говорит достаточно громко: наличие соответствующего требованиям API для обмена данными между плательщиками и фактический обмен данными участников — это два совершенно разных результата. Регламент гарантирует только первое.
Требования CMS-0057 к обмену данными между плательщиками: чего не хватает
CMS-0057 была разработана для решения реальной проблемы пациента: когда участник меняет медицинский план, его клиническая история не должна исчезать. Намерение понятно, и польза для пациента реальна.
Чего регламент не сделал, так это не создал инфраструктуру, позволяющую осуществлять этот обмен в необходимых масштабах.
- Не существует общего каталога, где находится API каждого плательщика.
- Не существует требования создавать соединения заранее, есть лишь требование отвечать на поступающие запросы.
- Отсутствует стандарт качества данных, а это значит, что плательщик, отправляющий некорректные или неполные ресурсы FHIR, технически соответствует требованиям.
- И нет общей тестовой среды, поэтому каждое соединение должно организовываться независимо.
В результате тысячи медицинских планов создают решения по одной и той же спецификации, но без общего механизма поиска друг друга, без нейтрального уровня контроля качества и без каких-либо гарантий того, что соответствующая требованиям конечная точка трансформируется в работающий обмен. Эти пробелы — не краевые случаи. Они носят фундаментальный характер, и все последствия ложатся исключительно на тех, у кого нет плана по их устранению.
Сравнение CMS-0057 и CMS-9115: обмен данными между плательщиками в сопоставлении с API доступа для пациентов
API доступа для пациентов в рамках CMS-9115 работают уже много лет при минимальном использовании. Причина проста: уровень внедрения зависел исключительно от того, будут ли отдельные участники самостоятельно подключать свои данные к сторонним приложениям. Планы могли создать конечную точку, но они не могли искусственно сформировать поведение потребителей.
принципиально отличается. На другом конце соединения находится не потребитель, принимающий личное решение. Это организация, которая по закону обязана обмениваться данными об участниках, когда участник дает на это согласие. Это меняет все.
У планов есть прямые рычаги влияния на согласие участников, чего у них никогда не было в случае с доступом для пациентов. Согласие может быть встроено непосредственно в рабочие процессы регистрации и запрашиваться в момент наибольшей вовлеченности участника. То, как и когда план запрашивает согласие — и насколько понятно он объясняет выгоду, — напрямую определяет, какое количество данных о предыдущем покрытии план фактически получает. Согласие участника — это не функция маркетинга. Для обмена данными между плательщиками это операционная задача.
Чего на самом деле стоят данные между плательщиками и какова цена их отсутствия
Для планов Medicare Advantage точность корректировки рисков напрямую зависит от полноты данных об участниках при регистрации. Когда истории предшествующих хронических заболеваний поступают в первый же день, коды HCC фиксируются до того, как будет рассчитан первый показатель риска. Если же они не поступают, сложность состояния участника занижается, и для крупного плана, обрабатывающего десятки тысяч переходов ежегодно, этот разрыв не является погрешностью округления. Он накапливается.
Та же картина наблюдается в отношении показателей HEDIS, рейтингов Star Ratings и эффективности управления медицинским обслуживанием. В каждом случае план, который получает полные истории участников при регистрации, строит работу на прочном фундаменте. План, который их не получает, начинает каждый цикл регистрации с восстановления того, что должно было быть доступно с самого начала.
Разрыв между этими двумя результатами — это не технический вопрос. Это вопрос сетевой инфраструктуры, и на него одна лишь конечная точка FHIR ответить не может.
Создание конечной точки выводит медицинский план только на стартовую линию. То, что происходит после — подключение к другим плательщикам, поддержание этих соединений, обеспечение реальной применимости поступающих данных, — представляет собой постоянную оперативную задачу, которую большинство разработчиков API не решают. Большинство решений от вендоров в этом плане поверхностнее, чем кажутся. Вопросы, обнажающие этот пробел, касаются не функций. Они касаются того, кто отвечает за эту постоянную работу, и у большинства вендоров нет хорошего ответа.
Готовность к CMS-0057: преимущество первопроходца в обмене данными между плательщиками
Вот что делает этот момент стратегически важным: преимущество не накапливается постепенно. Оно приумножается.
План, который подключается сейчас и стимулирует активное согласие участников в период открытой регистрации 2026 года, входит в 2027 год с более богатой продольной картой участника, чем план, который ждет. Два или три цикла регистрации с полными данными о переходе участников означают более точный доход от корректировки рисков, лучшие показатели HEDIS и более высокую удержание участников. Ни одно из этих преимуществ не обнуляется, когда отстающий участник наконец подключается.
Те планы, которые рассматривают обмен данными между плательщиками по стандарту CMS-0057 как стратегическую инвестицию, а не как статью расходов на соответствие требованиям, будут вспоминать этот период как момент, когда функциональная совместимость перестала быть затратами и стала конкурентным преимуществом. Планы, которые видят в этом лишь дедлайн, от которого нужно отмахнуться, потратят последующие годы на то, чтобы догонять остальных.
Что нужно сделать до наступления дедлайна CMS-0057
Мы собрали все наши знания о том, как преодолеть этот разрыв, в новое руководство. Оно включает в себя конкретные вопросы, которые каждый медицинский план должен задать своему вендору или внутренней команде прямо сейчас, фреймворк для оценки того, действительно ли ваше текущее решение устраняет сетевой разрыв, а также реальный пример того, как с этим справился один крупный национальный плательщик.
Если вы серьезно относитесь к обмену данными между плательщиками, вам стоит прочитать это руководство, прежде чем предполагать, что вы полностью защищены. Прочитайте полное руководство: Преодоление разрыва между плательщиками
