CMS-0057-F in 1. januar 2027: API-ji plačnikov v lastnih sistemih za zahtevke in predhodne odobritve

Do 1. januarja 2027 morajo organizacije Medicare Advantage (zasebni načrti v okviru Medicare) ter programi Medicaid in CHIP (javno zavarovanje za ljudi z nizkimi dohodki in za otroke) zveznih držav s plačilom po storitvi (fee-for-service, FFS) imeti v delovanju štiri API-je FHIR, ki jih zahteva končna uredba CMS o interoperabilnosti in predhodni odobritvi (CMS Interoperability and Prior Authorization final rule, CMS-0057-F): obstoječi Patient Access API, razširjen s podatki o predhodnih odobritvah, ter nove Provider Access API, Payer-to-Payer API in Prior Authorization API. Načrti Medicaid managed care (upravljane oskrbe), subjekti CHIP managed care in izdajatelji načrtov Qualified Health Plan (QHP) na zveznih zavarovalnih borzah (exchanges) sledijo od svojega prvega tarifnega obdobja (rating period) ali zavarovalnega leta (plan year), ki se začne na ta dan ali pozneje. Na dan 16. oktobra 2026 je do tega roka še enajst tednov in CMS ga ni prestavil.

Operativni del uredbe že velja. Od leta 2026 morajo zavezani plačniki za vsako zavrnjeno predhodno odobritev navesti konkreten razlog, odločati v določenih rokih in objavljati kazalnike predhodnih odobritev.

Če vaši sistemi za zahtevke (claims), upravljanje porabe storitev (utilization management, UM) in zavarovance prihajajo od dobavitelja, ki ponuja te štiri API-je, je večina gradnje njegova naloga. Vaš del so konfiguracija, digitalizirana pravila za predhodno odobritev, obvestila zavarovancem in testiranje s partnerji.

Ta članek je namenjen ostalim: načrtom in agencijam zveznih držav, katerih sistem za obdelavo zahtevkov, potek UM ali podatki o zavarovancih tečejo v sistemu, ki je njihov, bodisi doma razvitem, bodisi prilagojenem tako daleč, da nadgradnje niso več mogoče, bodisi v sistemu Medicaid Management Information System (MMIS, informacijski sistem programa Medicaid zvezne države) z desetletji lokalnih sprememb. Za take sisteme API-jev ne dobavi nihče. Smo inženirji, ne pravniki: članek pojasnjuje, kaj uredba zahteva od sistema, ne pa, kako velja za vaše pogodbe.

Datumi

Končna uredba je bila objavljena v uradnem listu Federal Register 8. februarja 2024 in je začela veljati 8. aprila 2024. Za vsakega od štirih API-jev določa iste roke: „do 1. januarja 2027 za organizacije MA ter programe Medicaid in CHIP FFS zveznih držav; do tarifnega obdobja, ki se začne 1. januarja 2027 ali pozneje, za načrte Medicaid managed care in subjekte CHIP managed care; ter za zavarovalna leta, ki se začnejo 1. januarja 2027 ali pozneje, za izdajatelje QHP na FFE“.

Načrt Medicaid managed care, katerega tarifna obdobja se začnejo 1. julija, ima torej čas do 1. julija 2027. Načrt s pogodbo za koledarsko leto ga nima.

CMS še vedno navaja isti datum. Njegova stran o uredbi, nazadnje spremenjena 8. oktobra 2026, pravi, da „imajo zavezani plačniki predvsem do 1. januarja 2027 čas, da izpolnijo zahteve te končne uredbe glede aplikacijskega programskega vmesnika (API)“.

Obveznosti za leto 2026 so po informativnem listu CMS odločitve „v 72 urah za pospešene (tj. nujne) zahteve in v sedmih koledarskih dneh za standardne (tj. nenujne) zahteve“ (za izdajatelje QHP na borzah ti roki ne veljajo), konkreten razlog za vsako zavrnitev in javni kazalniki, pri čemer je treba „prvi niz kazalnikov sporočiti do 31. marca 2026“. Tudi o uporabi Patient Access API je treba CMS poročati vsako leto do 31. marca. Če kaj od tega še ne deluje, ste že v zamudi, in to temelji na istih podatkih kot API-ji.

Zdravila so zunaj vsega tega. Vse določbe CMS-0057-F o predhodni odobritvi jih izključujejo.

Koga zadeva in koga ne

Uredba jih imenuje zavezani plačniki (impacted payers): organizacije Medicare Advantage (MA), programi Medicaid in CHIP fee-for-service (FFS) zveznih držav, načrti Medicaid managed care, subjekti CHIP managed care in izdajatelji QHP na Federally-facilitated Exchanges (FFE, borzah, ki jih upravlja zvezna vlada). Ocena učinka šteje „365 matičnih organizacij, vključno z agencijami Medicaid in CHIP zveznih držav“, ki so „odgovorne za uvedbo in vzdrževanje treh novih API-jev“, in ugotavlja, da „ima 75 odstotkov plačnikov v tej kategoriji manj kot 500 zaposlenih“. Mnogi so regionalni načrti brez velike platformne ekipe.

Niso zajeti, vsaj ne neposredno:

• Načrti delodajalcev zunaj teh programov in Original Medicare (tradicionalni javni Medicare). Ni jih na seznamu zavezanih plačnikov.
• Izvajalci zdravstvenih storitev. Njihova stran je Electronic Prior Authorization measure, merilo v programih Promoting Interoperability v okviru Medicare, ki ga izpolnijo s certificirano tehnologijo EHR. Končna uredba IPPS za proračunsko leto 2027 (o plačilih Medicare za bolnišnično zdravljenje) z dne 4. avgusta 2026 ga je za bolnišnice v letu 2027 spremenila v neobvezno bonusno merilo.
• Subjekti, na katere je prenesen UM, in TPA (zunanji administratorji). Lastnih obveznosti nimajo, a obveznost plačnika teče skozi njihove sisteme. Za izdajatelje QHP uredba ponavlja, da so „odgovorni za lastno skladnost in za skladnost vseh subjektov, na katere so prenesli naloge, ali subjektov nižje v verigi“.

Izhodov je malo in tako pozno nobeden ne pomaga veliko. Zvezna država lahko za svoj program Medicaid ali CHIP FFS zaprosi za enkratno enoletno podaljšanje, vendar zahtevo vloži v okviru dokumenta Advance Planning Document (APD, načrtovalni dokument, s katerim zvezna država pridobi zvezno sofinanciranje informacijskih projektov), zahteva pa mora biti „odobrena pred rokom za skladnost“. Zvezna država, v kateri je vsaj 90 odstotkov upravičencev Medicaid vključenih v managed care, lahko zaprosi za izvzetje, izdajatelji QHP pa lahko borzo zaprosijo za izjemo. O samih načrtih je CMS zapisal: „Podaljšanj ali izvzetij za organizacije MA ali načrte Medicaid managed care nismo predlagali.“ Zvezne države lahko za gradnjo API-jev uveljavljajo tudi 90-odstotno povečano zvezno sofinanciranje, ki se odobri za vsak primer posebej prek APD.

Kaj mora narediti vsak API

Vsi štirje so odvisni od ene stvari, ki sistemom po meri pogosto manjka: predhodne odobritve kot strukturiranih podatkov z zgodovino statusov. Zgradite jo enkrat in vsi štirje berejo iz nje.

Patient Access API: dodajte predhodne odobritve

Ta API imate v delovanju od 1. januarja 2021, za zahtevke, zapise o obravnavah (encounters) in klinične podatke. Od leta 2027 mora vsebovati tudi vsako predhodno odobritev za izdelke in storitve: njen status, datum odobritve ali zavrnitve, datum izteka, odobrene izdelke in storitve, konkreten razlog v primeru zavrnitve ter povezano strukturirano dokumentacijo izvajalca. Podatki morajo biti na voljo „najpozneje 1 delovni dan po tem“, ko plačnik prejme zahtevo, posodobljeni v enem delovnem dnevu po vsaki spremembi statusa in hranjeni, dokler je odobritev aktivna, ter še vsaj leto dni po njeni zadnji spremembi.

Sistem UM, ki odločitve beleži kot opombe v prostem besedilu ali status pošilja le po faksu, tega brez sprememb ne more zagotoviti.

Provider Access API

Izvajalci v mreži lahko zahtevajo podatke o pacientu: zahtevke in zapise o obravnavah brez podatkov o plačilih izvajalcem (remittances) in o deležu, ki ga krije pacient (cost-sharing), razrede kliničnih podatkov USCDI (ameriški nabor osnovnih podatkov za izmenjavo) in podatke o predhodnih odobritvah, za storitve, opravljene od 1. januarja 2016. Plačnik odgovori v enem delovnem dnevu, vendar le za paciente, ki jih je pripisal temu izvajalcu in ki niso izkoristili možnosti zavrnitve (opt-out).

Za to so potrebne tri stvari, ki jih starejši sistem redko ima. Postopek pripisovanja (attribution), ki zavarovance poveže z izvajalci. Možnost zavrnitve, ki jo lahko zavarovanec kadar koli spremeni, z obvestili v preprostem jeziku pred prvo uporabo, v enem tednu od začetka zavarovanja in vsako leto. In množični izvoz, ker zahtevani standardi vključujejo FHIR Bulk Data Access za izvajalca, ki sprašuje o celotnem krogu svojih pacientov.

Payer-to-Payer API

Ko se zavarovanec pridruži, novi plačnik zaprosi za dovoljenje (tu velja privolitev, opt-in) in v enem tednu od začetka zavarovanja začne ugotavljati prejšnje in sočasne plačnike. Ko jih pozna, v enem tednu zahteva podatke za pet let: zahtevke in zapise o obravnavah brez podatkov o plačilih in deležu pacienta, podatke USCDI ter predhodne odobritve razen zavrnjenih, skupaj z njihovo nestrukturirano dokumentacijo. Prejšnji plačnik odgovori v enem delovnem dnevu. Pri sočasnem zavarovanju se izmenjava ponovi vsaj enkrat na četrtletje.

Težava ni odhodni odgovor. Težava je sprejemanje podatkov od plačnikov, s katerimi niste nikoli testirali, in njihovo vključevanje v evidenco zavarovanca, kot zahteva uredba.

Prior Authorization API

To je API, ki seže do jedra UM. Navesti mora zajete izdelke in storitve, ki zahtevajo predhodno odobritev, za vsakega opredeliti zahtevano dokumentacijo, podpirati zahtevo in odgovor v skladu s HIPAA (ameriškim zakonom o standardih elektronskih transakcij in varstvu zdravstvenih podatkov) ter sporočiti, ali je plačnik odobril (z datumom izteka), zavrnil (s konkretnim razlogom) ali potrebuje več informacij.

CMS tu priporoča, a ne zahteva, tri vodnike za implementacijo Da Vinci: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) in Prior Authorization Support (PAS). V praksi morajo vaša pravila kritja in vprašalniki za dokumentacijo postati strojno berljivi, namesto priročnika s pravili v PDF. Plačniki v anketi WEDI (ameriške strokovne organizacije za elektronsko izmenjavo podatkov v zdravstvu) so „digitalizacijo pravil za predhodno odobritev“ uvrstili med tri največje izzive.

Pri sami transakciji je HHS plačnikom pustil prostor. 28. februarja 2024 je napovedal odstop od izvrševanja (enforcement discretion): po navedbah CMS njegova skupina National Standards Group „ne bo uvedla izvršilnih ukrepov po HIPAA Administrative Simplification zoper subjekte, zavezane po HIPAA, ki se odločijo, da standarda X12 278 ne bodo uporabljali kot del elektronskega postopka predhodne odobritve na podlagi FHIR“. Zgradite lahko samo FHIR ali FHIR z X12, poleg tega pa ohranite transakcijo samo z X12.

Standardi

Zahtevani standardi so HL7 FHIR Release 4.0.1, US Core, SMART App Launch, Bulk Data Access in OpenID Connect Core; plačniki lahko pod določenimi pogoji prostovoljno uporabljajo novejše različice. Uredba iz leta 2024 je navedla US Core 3.1.1 in SMART App Launch 1.0.0 z datumom izteka 1. januarja 2026, zato določite, na katere različice gradite, preden kdor koli začne pisati preslikavo.

Kje lastni sistemi navadno ne zadoščajo

Glede na to, kar uredba zahteva, so to vrzeli, ki jih je vredno poiskati najprej:

• Predhodna odobritev kot zapis, ne dokument. Status, časovni žigi, kode razlogov za zavrnitev in datum izteka morajo biti polja, zapisana ob spremembi, z zgodovino. Odločitev, poslana po faksu, potrebuje strukturiran dvojnik.
• Pravila kritja. Katere storitve potrebujejo odobritev in kakšno dokumentacijo zahteva vsaka od njih, mora biti zapisano kot podatki, ki jih API lahko posreduje. V mnogih načrtih je to v PDF-jih s pravili in v glavah ocenjevalcev.
• Zahtevki kot FHIR. Zahtevki in zapisi o obravnavah morajo izhajati kot viri FHIR, za izvajalce in druge plačnike brez podatkov o plačilih in deležu pacienta, za zavarovanca pa z njimi.
• Identiteta in zgodovina zavarovanca. Za ujemanje podatkov drugega plačnika z vašim zavarovancem in za iskanje prejšnjih plačnikov novega zavarovanca so potrebni demografski podatki in zgodovina zavarovanja, ki jih morda nimate na enem mestu.
• Stanje privolitev. Zavrnitev (opt-out) za Provider Access in privolitev (opt-in) za Payer-to-Payer: obe je mogoče kadar koli spremeniti in obe se preverita pri vsaki zahtevi. Zvezna država mora privolitev upravičenca posredovati tudi načrtom Medicaid managed care te osebe.
• Rok enega delovnega dneva. Nočna paketna obdelava na velikem računalniku (mainframe) za nekatere podatke zadošča, za druge je prepočasna. Merite čas od odločitve do API, ne le tega, ali API odgovarja.
• Zunanji dobavitelji s prenesenimi nalogami. Če odločitve sprejema zunanji dobavitelj UM, morajo njegovi podatki do vas priti pravočasno za vašo obveznost enega delovnega dneva. Anketa WEDI iz februarja 2026 je med izzivi plačnikov na prvo mesto postavila „tretje osebe s prenesenimi nalogami, ki se spopadajo s težavami pri povezovanju z različnimi sistemi“.

Kako daleč je panoga

Anketa WEDI iz februarja 2026, objavljena 10. marca 2026, je pokazala, da pri zahtevah za API-je „10 % še ni začelo dela“, v primerjavi s 33 % oktobra 2025. Poročala je tudi o „opaznem povečanju ocenjenih stroškov nad 5 milijonov dolarjev s 15 % (okt. ’25) na 25 % (febr. ’26)“. Vzorec je majhen: 86 odgovorov, od tega 52 % od plačnikov. Berite ga kot signal, ne kot popis.

Enajsttedenski načrt do 1. januarja 2027

Od sredine oktobra ima organizacija MA ali program FFS zvezne države približno enajst tednov. To ni dovolj, da bi iz nič zgradili štiri API-je, zato načrt govori o vrstnem redu in o tem, kaj lahko pokažete prvi dan.

1. Ta teden: potrdite svoj rok in izhodišče. 1. januar ali poznejše tarifno obdobje oziroma zavarovalno leto? Naštejte, kar že deluje: Patient Access API in Provider Directory API, kazalnike za leto 2026, razloge za zavrnitve.
2. Od 1. do 2. tedna: vsak podatkovni element povežite z njegovim virom. Za vsak API zapišite, kateri sistem danes hrani podatke (zahtevki, UM, vpis zavarovancev, mreža izvajalcev, klinični podatki) in kako sveži so.
3. Od 1. do 3. tedna: odločite, kje bo plast FHIR. Strežnik FHIR ali fasada pred podedovanimi sistemi, ki jo napajajo dogodki sprememb ali pogosti izvlečki, je običajno hitrejša pot, kot naučiti osrednji sistem govoriti FHIR. Čas gre za preslikavo in podatkovne tokove.
4. Od 2. do 7. tedna: najprej zgradite skupne dele. Zapis predhodne odobritve, privolitve in pripisovanje, ujemanje zavarovancev. Od njih so odvisni vsi štirje API-ji.
5. Od 4. do 9. tedna: zgradite API-je. Dopolnitve Patient Access, Provider Access z množičnim izvozom, Payer-to-Payer v obe smeri in Prior Authorization API z naloženimi pravili kritja.
6. Od 8. do 11. tedna: testirajte z resničnimi partnerji. Dobavitelj EHR izvajalca, drug plačnik, vaš zunanji dobavitelj UM. Preizkusite spremembe privolitev, zavrnitev z razlogom in spremembo statusa, ki doseže zavarovanca v enem delovnem dnevu.
7. 1. januar 2027: zaženite in merite. Od prvega dne spremljajte zakasnitve glede na pravila enega delovnega dneva in vodite datiran seznam tega, kar še ni dokončano.

Če enajst tednov ni dovolj, to zdaj, ne decembra, predstavite oddelku za skladnost in pravnim svetovalcem, skupaj z načrtom, ki pokaže, kaj bo delovalo 1. januarja in kaj sledi pozneje ter kdaj.

Načrt Medicaid managed care s tarifnim obdobjem od 1. julija 2027 ali izdajatelj QHP s poznejšim zavarovalnim letom lahko sledi istim korakom z več časa. Vseeno začnite zdaj: plačniki in izvajalci, s katerimi boste testirali, začnejo delovati 1. januarja.

Kaj se še lahko spremeni

CMS-0062-P. 14. aprila 2026 je CMS objavil predlog nadaljnje uredbe. Ta bi trenutno priporočene vodnike za implementacijo naredila obvezne od 1. oktobra 2027, od istega datuma vključila zdravila v elektronsko predhodno odobritev, HHS pa bi FHIR sprejel kot standard HIPAA za transakcije predhodne odobritve namesto X12 278. O obstoječih rokih pravi: „Ta predlog teh rokov za skladnost ne bi spremenil.“ Pripombe so bile mogoče do 15. junija 2026, do 16. oktobra 2026 pa v uradnem listu Federal Register ni bila objavljena nobena končna uredba. Gradite po uredbi iz leta 2024, različice vodnikov pa hranite na enem nastavljivem mestu.

Različice. Vodniki Da Vinci se nenehno spreminjajo. Končna uredba IPPS za proračunsko leto 2027 navaja, da bodo sistemi EHR, certificirani po novih merilih ONC (zveznega urada za zdravstveno informatiko) za predhodno odobritev, „zahtevali uporabo različice 2.2 vodnikov Da Vinci IG“. To so sistemi, s katerimi bo komuniciral vaš Prior Authorization API.

Nič od tega ni razlog za čakanje. Uredba je končna, datumi so v besedilu predpisa in CMS jih je 8. oktobra ponovil.

Kje dobiti pomoč

Delamo na sistemih, ki stojijo za API-ji: preslikavi podatkov o zahtevkih, obravnavah in odobritvah v FHIR, tokovih sprememb iz starejših platform za zahtevke in UM, logiki privolitev in pripisovanja ter testih, ki pokažejo, da se pravila enega delovnega dneva držijo. Naša storitev vzdrževanja podedovanih sistemov je mesto, kjer se to delo začne, ko je osrednji sistem star ali so ljudje, ki so ga zgradili, odšli, in če rok pade sredi zamenjave platforme, si oglejte posodobitev ERP.

Če je vaša platforma za zahtevke ali UM takšna, za katero noben dobavitelj ne bo zagotovil teh API-jev, pišite na office@c9group.dev. Smo inženirji, ne pravniki za zdravstveno pravo: vprašanja obsega in pogodb sodijo k vašim pravnim svetovalcem, mi pa gradimo po njihovem odgovoru.