CMS-0057-F и 1 јануари 2027: API за плаќачи врз сопствени системи за обработка на барања и претходни одобренија

До 1 јануари 2027, организациите Medicare Advantage (приватни планови во рамките на Medicare) и програмите fee-for-service на Medicaid и CHIP (здравствено осигурување за деца) во сојузните држави, каде што државата сама ја плаќа секоја услуга, мора да имаат во работа четири FHIR API според конечното правило на CMS за интероперабилност и претходно одобрение (CMS-0057-F): постојниот Patient Access API (за осигурениците), проширен за да носи и податоци за претходните одобренија, и новите Provider Access (за давателите на услуги), Payer-to-Payer (меѓу плаќачите) и Prior Authorization API (за самото претходно одобрение). Плановите Medicaid managed care и субјектите CHIP managed care (приватни планови што овие покритија ги даваат по договор со државата) и издавачите на планови Qualified Health Plan (QHP) на сојузните берзи за осигурување следат од нивниот прв период на пресметка (rating period) или прва година на планот (plan year) што почнува на тој датум или подоцна. На 16 октомври 2026 до тогаш остануваат единаесет недели, а CMS не го поместил датумот.

Оперативната половина од правилото веќе е на сила. Од 2026 засегнатите плаќачи мора да наведат конкретна причина за секое одбиено претходно одобрение, да одлучуваат во утврдени рокови и да објавуваат показатели за претходните одобренија.

Ако вашите системи за барања за надомест (claims), управување со користењето на услугите (utilization management, UM) и евиденција на осигурениците доаѓаат од добавувач што ги испорачува овие четири API, најголемиот дел од изработката е работа на добавувачот. Вашиот дел е конфигурацијата, дигитализираните правила за претходно одобрение, известувањата до осигурениците и тестирањето со партнерите.

Оваа статија е за другите: планови и агенции чиј систем за обработка на барања, работен тек на UM или податоци за осигурениците се наоѓаат во систем што е нивна сопственост, без разлика дали е развиен во куќата, толку прилагоден што повеќе не може да се надградува, или е Medicaid Management Information System (MMIS, информацискиот систем за Medicaid на сојузната држава) со децении локални измени. За такви системи никој не испорачува API. Ние сме инженери, а не правници: ова објаснува што правилото бара од еден систем, а не како се применува на вашите договори.

Датумите

Конечното правило е објавено во Federal Register (службениот весник на САД) на 8 февруари 2024 и стапи на сила на 8 април 2024. За секој од четирите API ги утврдува истите рокови за усогласување: „до 1 јануари 2027 за MA организациите и програмите FFS на Medicaid и CHIP во сојузните држави; до периодот на пресметка што почнува на 1 јануари 2027 или подоцна за плановите Medicaid managed care и субјектите CHIP managed care; и за годините на планот што почнуваат на 1 јануари 2027 или подоцна за издавачите на QHP планови на берзите FFE“.

План Medicaid managed care чии периоди на пресметка почнуваат на 1 јули затоа има време до 1 јули 2027. План со договор по календарска година нема.

CMS сè уште го наведува истиот датум. Неговата страница за правилото, последен пат изменета на 8 октомври 2026, вели дека „засегнатите плаќачи имаат рок главно до 1 јануари 2027 да ги исполнат барањата од ова конечно правило што се однесуваат на апликацискиот програмски интерфејс (API)“.

Обврските за 2026, како што ги наведува информативниот лист на CMS, се одлуки „во рок од 72 часа за забрзани (т.е. итни) барања и седум календарски дена за стандардни (т.е. неитни) барања“ (издавачите на QHP планови на берзите се исклучени од роковите), конкретна причина за секое одбивање и јавни показатели, при што „почетниот сет показатели мора да се пријави до 31 март 2026“. Користењето на Patient Access API исто така се пријавува до CMS секоја година до 31 март. Ако нешто од ова сè уште не работи, веќе доцни, а се потпира на истите податоци како и API-јата.

Лековите се надвор од сето ова. Сите одредби за претходно одобрение во CMS-0057-F ги исклучуваат.

Кој е опфатен, а кој не

Правилото ги нарекува засегнати плаќачи (impacted payers): организациите Medicare Advantage (MA), програмите fee-for-service (FFS) на Medicaid и CHIP во сојузните држави, плановите Medicaid managed care, субјектите CHIP managed care и издавачите на QHP планови на сојузните берзи за осигурување (Federally-facilitated Exchanges, FFEs). Неговата анализа на влијанието брои „365 матични организации, вклучувајќи ги агенциите за Medicaid и CHIP на сојузните држави“, кои „се одговорни за воведување и одржување на три нови API“, и наведува дека „75 проценти од плаќачите во оваа категорија имаат помалку од 500 вработени“. Многу од нив се регионални планови без голем платформски тим.

Не се опфатени, барем не директно:

• Плановите на работодавачите надвор од овие програми и Original Medicare (традиционалниот Medicare што го води сојузната влада). Не се на списокот на засегнати плаќачи.
• Давателите на здравствени услуги. Нивната страна е мерката Electronic Prior Authorization во програмите Promoting Interoperability на Medicare, која се исполнува со сертифицирана EHR технологија (електронски здравствен картон). Конечното правило IPPS (системот на плаќање за болничко лекување во Medicare) за фискалната 2027 година од 4 август 2026 ја направи опционална бонус-мерка за болниците во 2027.
• Субјектите на кои им е доверен UM и TPA (администратори од трета страна). Немаат сопствена обврска, но обврската на плаќачот минува низ нивните системи. За издавачите на QHP планови правилото повторува дека тие „се одговорни за сопствената усогласеност и за усогласеноста на сите делегирани субјекти или субјекти подолу во синџирот“.

Излези има малку, а толку доцна ниеден не помага многу. Сојузна држава може да побара еднократно продолжување од една година за својата програма FFS на Medicaid или CHIP, но барањето оди во нејзиниот Advance Planning Document (APD, планот со кој државата бара сојузно финансирање за ИТ-проект) и мора да биде „одобрено пред рокот за усогласување“. Држава со најмалку 90 проценти од корисниците на Medicaid во managed care може да побара изземање, а издавачите на QHP планови можат да побараат исклучок од берзата. За самите планови CMS напиша: „Не предложивме продолжувања или изземања за MA организациите или за плановите Medicaid managed care.“ Државите можат да бараат и зголемено сојузно кофинансирање од 90 проценти за изработката на API-јата, кое се одобрува од случај до случај преку APD.

Што мора да прави секој API

Сите четири зависат од едно нешто што често недостига во систем по мерка: претходното одобрение како структурирани податоци со историја на статусите. Изградете го тоа еднаш и сите четири читаат од истиот извор.

Patient Access API: додајте ги претходните одобренија

Овој API го водите од 1 јануари 2021 за барањата за надомест, податоците за дадени услуги (encounters) и клиничките податоци. Од 2027 мора да го носи и секое претходно одобрение за производи и услуги: неговиот статус, датумот на одобрување или одбивање, датумот на истек, одобрените производи и услуги, конкретна причина ако е одбиено и поврзаната структурирана документација од давателот на услуги. Податоците мора да бидат достапни „најдоцна 1 работен ден откако“ плаќачот ќе го прими барањето, ажурирани во рок од еден работен ден по секоја промена на статусот и чувани додека одобрението е активно и уште најмалку една година по неговата последна промена.

UM систем што одлуките ги запишува како слободен текст или статусот го праќа само по факс не може да ги дава тие податоци без измени.

Provider Access API

Давателите на услуги од мрежата можат да побараат податоци за пациент: барања за надомест и податоци за дадени услуги без исплатите кон давателите и без учеството во трошоците, класите клинички податоци на USCDI (американскиот основен сет податоци за интероперабилност) и информации за претходните одобренија, за услуги дадени од 1 јануари 2016. Плаќачот одговара во рок од еден работен ден, но само за пациентите што му ги припишал на тој давател и што не се откажале (opt-out).

За тоа се потребни три работи што наследен систем ретко ги има. Постапка за припишување (attribution) што ги поврзува осигурениците со давателите. Откажување што осигуреникот може да го промени во секое време, со известувања на едноставен јазик пред првото користење, во рок од една недела од почетокот на покритието и секоја година. И масовен извоз, бидејќи задолжителните стандарди го вклучуваат FHIR Bulk Data Access за давател што бара податоци за сите свои пациенти одеднаш.

Payer-to-Payer API

Кога ќе се зачлени осигуреник, новиот плаќач бара дозвола (тука е потребна изречна согласност, opt-in) и во рок од една недела од почетокот на покритието почнува да ги утврдува претходните и истовремените плаќачи. Откако ќе ги утврди, во рок од една недела бара податоци за пет години: барања за надомест и податоци за дадени услуги без исплатите и учеството во трошоците, USCDI податоци и претходните одобренија освен одбиените, со нивната неструктурирана документација. Претходниот плаќач одговара во рок од еден работен ден. Кај истовремено покритие размената се повторува најмалку еднаш квартално.

Тешкиот дел не е излезниот одговор. Тешко е да се примаат податоци од плаќачи со кои никогаш не сте тестирале и да се вклучат во записот за осигуреникот, како што бара правилото.

Prior Authorization API

Ова е API-то што навлегува во самото јадро на UM. Мора да ги наведе покриените производи и услуги за кои е потребно претходно одобрение, за секој да ја определи потребната документација, да поддржи барање и одговор усогласени со законот HIPAA и да каже дали плаќачот одобрил (со датумот на истек), одбил (со конкретна причина) или бара дополнителни информации.

CMS тука препорачува, но не бара, три Da Vinci водичи за имплементација (implementation guides): Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) и Prior Authorization Support (PAS). Во пракса, вашите правила за покритие и прашалниците за документација мора да станат машински читливи, а не прирачник со правила во PDF. Плаќачите во анкетата на WEDI (американското здружение за електронска размена на податоци во здравството) ја ставија „дигитализацијата на правилата за претходно одобрение“ меѓу трите најголеми предизвици.

Кај самата трансакција HHS им остави простор на плаќачите. На 28 февруари 2024 најави дека во еден дел нема да го спроведува прописот (enforcement discretion): според CMS, неговата National Standards Group „нема да презема мерки за спроведување на HIPAA Administrative Simplification против субјектите опфатени со HIPAA што ќе одлучат да не го користат стандардот X12 278 како дел од електронски FHIR процес за претходно одобрение“. Може да градите само FHIR или FHIR со X12, а паралелно да задржите и трансакција само на X12.

Стандардите

Задолжителните стандарди се HL7 FHIR Release 4.0.1, US Core, SMART App Launch, Bulk Data Access и OpenID Connect Core; плаќачите можат доброволно, под одредени услови, да користат понови верзии. Правилото од 2024 ги наведе US Core 3.1.1 и SMART App Launch 1.0.0 со датум на истек 1 јануари 2026, па одлучете според кои верзии градите пред некој да почне да го пишува мапирањето.

Каде сопствените системи обично подбаруваат

Според тоа што го бара правилото, ова се празнините што треба прво да ги побарате:

• Претходното одобрение како запис, а не документ. Статусот, временските ознаки, шифрите на причините за одбивање и датумот на истек треба да бидат полиња што се запишуваат кога се менуваат, со историја. Одлука испратена по факс бара структуриран двојник.
• Правилата за покритие. Кои услуги бараат одобрение и каква документација е потребна за секоја мора да бидат податоци што API може да ги испорача. Во многу планови тоа стои во PDF-документи со правила и во главите на оние што ги прегледуваат барањата.
• Барањата за надомест како FHIR. Барањата за надомест и податоците за дадени услуги мора да излегуваат како FHIR ресурси, без исплатите и учеството во трошоците за давателите и другите плаќачи, но со нив за осигуреникот.
• Идентитетот и историјата на осигуреникот. За да ги споите податоците на друг плаќач со вашиот осигуреник и да ги најдете претходните плаќачи на нов осигуреник, потребни се демографски податоци и историја на покритието што можеби не ги чувате на едно место.
• Состојбата на согласноста. Откажување (opt-out) за Provider Access и согласност (opt-in) за Payer-to-Payer, двете променливи во секое време и проверувани при секое барање. Сојузната држава мора и да ја пренесе согласноста на корисникот до неговите планови Medicaid managed care.
• Рокот од еден работен ден. Ноќна batch-обработка на мејнфрејм е доволна за некои податоци, а за други е премногу бавна. Мерете го времето од одлуката до API, а не само дали API одговара.
• Делегираните добавувачи. Ако одлуките ги носи добавувач на кој сте му го довериле UM, неговите податоци мора да стигнат до вас навреме за вашата обврска од еден работен ден. Анкетата на WEDI од февруари 2026 ги стави „делегираните трети страни што имаат тешкотии со поврзувањето со различни системи“ на прво место меѓу предизвиците на плаќачите.

Колку напредувала индустријата

Анкетата на WEDI од февруари 2026, објавена на 10 март 2026, покажа дека за барањата поврзани со API „10% сè уште не ја започнале својата работа“, наспроти 33% во октомври 2025. Наведе и „забележлив пораст на проценетите трошоци над 5 милиони долари, од 15% (окт. ’25) на 25% (фев. ’26)“. Примерокот е мал: 86 одговори, од кои 52% од плаќачи. Читајте го како сигнал, а не како попис.

План од единаесет недели до 1 јануари 2027

Од средината на октомври, MA организација или програма FFS на сојузна држава има околу единаесет недели. Тоа не е доволно за четири API да се изградат од нула, па планот е прашање на редослед и на тоа што можете да покажете првиот ден.

1. Оваа недела: потврдете го својот датум и почетната точка. Дали е тоа 1 јануари или подоцнежен период на пресметка, односно година на планот? Наведете што веќе работи: Patient Access и Provider Directory API, показателите за 2026, причините за одбивање.
2. Недели 1 и 2: поврзете го секој податок со неговиот извор. За секој API запишете кој систем денес ги чува податоците (барања за надомест, UM, запишување осигуреници, мрежа на даватели, клинички податоци) и колку се свежи.
3. Од недела 1 до недела 3: одлучете каде ќе биде FHIR слојот. FHIR сервер или фасада пред наследените системи, што ја полнат настани за промени или чести извози, обично е побрз пат отколку основниот систем да го научите да зборува FHIR. Времето оди на мапирањето и на доводите на податоци.
4. Од недела 2 до недела 7: прво изградете ги заедничките делови. Записот за претходно одобрение, согласноста и припишувањето, спојувањето на осигурениците. Од нив зависат сите четири API.
5. Од недела 4 до недела 9: изградете ги API-јата. Дополнувањата на Patient Access, Provider Access со масовен извоз, Payer-to-Payer во двете насоки и Prior Authorization API со вчитани правила за покритие.
6. Од недела 8 до недела 11: тестирајте со вистински партнери. Добавувачот на EHR систем на некој давател, друг плаќач, вашиот делегиран UM добавувач. Тестирајте промени на согласноста, одбивање со причина и промена на статусот што стигнува до осигуреникот во рок од еден работен ден.
7. 1 јануари 2027: пуштете го системот во работа и мерете. Од првиот ден следете ја латенцијата во однос на роковите од еден работен ден и водете датиран список на она што не е завршено.

Ако единаесет недели не се доволни, кажете им го тоа на тимот за усогласеност и на правниците сега, а не во декември, со план што покажува што ќе работи на 1 јануари, а што и кога следи потоа.

План Medicaid managed care со период на пресметка од 1 јули 2027 или издавач на QHP план со подоцнежна година на планот може да ги следи истите чекори со повеќе време. Сепак почнете сега: плаќачите и давателите со кои ќе тестирате почнуваат со работа на 1 јануари.

Што уште може да се промени

CMS-0062-P. На 14 април 2026 CMS објави предлог на ново правило што се надоврзува на ова. Тоа би ги направило сега препорачаните водичи за имплементација задолжителни од 1 октомври 2027, од истиот датум би ги вклучило лековите во електронското претходно одобрение, а HHS би го усвоил FHIR како стандард според HIPAA за трансакциите за претходно одобрение наместо X12 278. За постојните рокови вели: „Овој предлог не би ги променил тие рокови за усогласување.“ Рокот за коментари истече на 15 јуни 2026, а до 16 октомври 2026 во Federal Register не е објавено конечно правило. Градете според правилото од 2024 и чувајте ги верзиите на водичите на едно место што може да се конфигурира.

Верзиите. Водичите Da Vinci постојано се менуваат. Конечното правило IPPS за фискалната 2027 наведува дека EHR системите сертифицирани според новите критериуми на ONC (сојузната канцеларија за здравствени информациски технологии) за претходно одобрение „ќе бараат користење на верзијата 2.2 од водичите за имплементација Da Vinci“. Токму со тие системи ќе разговара вашиот Prior Authorization API.

Ништо од ова не е причина за чекање. Правилото е конечно, датумите се во текстот на прописот, а CMS ги повтори на 8 октомври.

Каде да побарате помош

Работиме на системите зад API-јата: FHIR мапирање на податоците за барањата за надомест, дадените услуги и одобренијата, доводи на промени од постарите платформи за барања и UM, логика за согласноста и припишувањето и тестови што покажуваат дека роковите од еден работен ден се почитуваат. Кога основниот систем е стар или луѓето што го изградија заминале, таа работа почнува со нашата услуга за одржување наследени системи, а ако рокот падне среде замена на платформата, погледнете ја модернизацијата на ERP.

Ако вашата платформа за барања за надомест или UM е таква за која ниеден добавувач нема да ги испорача овие API, пишете ни на office@c9group.dev. Ние сме инженери, а не правници за здравство: прашањата за опфатот и договорите им припаѓаат на вашите правници, а ние градиме според нивниот одговор.