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