Каждый клиент 1upHealth справился с дедлайном CMS-0057 31 марта 2026 года. Они развернули отчетность через Patient Access API, передали данные об использовании и пошли дальше. Этот дедлайн по CMS оценивал одно: смогли ли вы создать инфраструктуру. Это был справедливый вопрос, и ответом для многих поставщиков решений для обеспечения интероперабельности и их клиентов было «да».
Дедлайн 1 января 2027 года ставит более сложную задачу. Электронная предварительная авторизация (Electronic Prior Authorization), доступ для поставщиков (Provider Access) и обмен данными между плательщиками (Payer-to-Payer Data Exchange) — все они занижаются в штатном режиме, и в отличие от отчетности по Patient Access, ценность этих API определяется не тем, правильно ли вы их создали. Она определяется тем, появится ли кто-то на другом конце.
Это новый вид рисков, и большинство графиков соблюдения требований его не учитывают.
Урок из CMS-9115, который никто не усвоил
Когда стандарт CMS-9115 предписал внедрение оригинального Patient Access API, индустрия усвоила суровый урок: создание инфраструктуры не гарантирует ее внедрения. Уровень использования оставался низким в течение многих лет, главным образом потому, что активация зависела от того, найдет ли отдельный участник стороннее приложение, поймет ли его ценность и сможет ли самостоятельно пройти процедуру авторизации. Плательщики построили трубы. У них практически не было возможности повлиять на то, течет ли по ним вода.
Вот что изменилось на этот раз: стороны на другом конце API по стандарту CMS-0057 — это не отдельные потребители, принимающие единовременные личные решения. Это организации. Группы поставщиков. Системы здравоохранения. Делегированные поставщики услуг управления медицинским обслуживанием (UM). Другие плательщики. Сущности, которых можно идентифицировать, привлечь, подключить и активировать в контролируемые вами сроки.
Другими словами: на этот раз низкий уровень использования — это не то, что случается с плательщиками. Это то, на что они могут повлиять.
Во сколько на самом деле обходится нулевая связность
Стоит задуматься о том, как выглядит ситуация «технически соответствует, функционально не используется» для каждого API, поскольку последствия вовсе не абстрактны:
- API для обмена данными между плательщиками (Payer-to-Payer Data Exchange) без подключенных плательщиков не может извлекать историю предыдущего страхового покрытия для новых участников, а это значит, что программы устранения пробелов в медицинском обслуживании (care gap) начинают работу с нуля при каждом цикле регистрации, что напрямую влияет на показатели HEDIS и корректировки рисков (risk adjustment).
- API электронной предварительной авторизации (Electronic Prior Authorization) без подключения поставщиков не снижает объем предварительных авторизаций, время принятия решений или административную нагрузку. Никакой экономии затрат не происходит, потому что никто не пользуется построенной вами дверью.
- Provider Access API, к которому никто не делает запросы, не передает данные лечащим врачам, не поддерживает координацию медицинской помощи и не дает никаких доказательств клинической пользы.
Большинство медицинских план-ов сейчас движутся к первому типу готовности: техническому соответствию. Подавляющее большинство движется к нему, а не ко второму: реальной связности. Именно на этом разрыве плательщикам следует сосредоточиться в течение следующих 5 месяцев.
CMS-0057 — это веха, а не финишная прямая
Также стоит взглянуть на ситуацию шире, поскольку отношение к 1 января 2027 года как к конечной точке само по себе является ошибкой. Нормативно-правовая база уже простирается далеко за ее пределы.
Например, согласно CMS-0062-P (предлагаемая дата — 1 октября 2027 г.), спецификации FHIR для предварительной авторизации переходят из разряда рекомендаций в разряд обязательных, требования к электронной предварительной авторизации охватывают лекарственные средства, отчетность по конечным точкам в национальном справочнике медицинских работников и услуг (National Healthcare Provider and Services Directory) становится обязательной, а отчетность по электронной предварительной авторизации становится более детализированной.
Плательщики, которые воспринимают CMS-0057 как единичное событие, обнаружат, что им приходится заново нарабатывать те же навыки — создание сети, а не инфраструктуры — для каждого последующего правила.
Главное условие: сеть, а не API
Вот неудобная математика. Упрощенный подход к соблюдению требований CMS-0057 заключается в том, что каждый плательщик подключается напрямую к каждому другому плательщику и каждому поставщику в стране — это тысячи индивидуальных интеграций точка-точка. Ни у одной команды инженеров плательщика нет ресурсов для этого, и ни одна группа поставщиков не хочет поддерживать отдельное подключение для каждого плана, по которому они выставляют счета.
Это и есть реальное узкое место. Не спецификация FHIR. Не создание API. Сеть.
Так что же отличает планы, которые получат реальные данные об использовании к 1 января 2027 года, от тех, у которых будут технически валидные, но функционально пустые конечные точки? Все сводится к короткому списку будничных операционных вопросов.
Мы освещаем эти вопросы и подробно разбираем, как выглядит «готовность» по каждому из них, а также рассказываем, как региональный план Blues, крупный национальный страховщик и небольшой региональный плательщик Medicare подходят к этому по-разному, исходя из своей исходной точки, в полной версии электронной книги «Соответствие требованиям CMS-0057: почему FHIR APIs недостаточно».
Загрузите электронную книгу, чтобы получить полную картину, и свяжитесь с нами, чтобы подробнее обсудить сетевую стратегию, отношения с поставщиками и рабочие процессы участников.
