CMS-0057-F i 1. januar 2027: API-ji platilaca na sopstvenim sistemima za obradu zahteva i prethodna odobrenja

Do 1. januara 2027. organizacije Medicare Advantage (privatni planovi u okviru Medicare-a) i fee-for-service programi Medicaid-a i CHIP-a (zdravstveno osiguranje dece) u saveznim državama, u kojima država sama plaća svaku uslugu, moraju da imaju u radu četiri FHIR API-ja prema konačnom pravilu CMS-a o interoperabilnosti i prethodnom odobrenju (CMS-0057-F): postojeći Patient Access API (za osiguranike), proširen tako da prenosi i podatke o prethodnim odobrenjima, i nove API-je Provider Access (za pružaoce usluga), Payer-to-Payer (između platilaca) i Prior Authorization (za samo prethodno odobrenje). Medicaid managed care planovi i CHIP managed care subjekti (privatni planovi koji ova pokrića pružaju po ugovoru sa državom) i izdavaoci planova Qualified Health Plan (QHP) na saveznim berzama osiguranja dolaze na red od svog prvog perioda obračuna (rating period) ili prve godine plana (plan year) koja počinje tog dana ili kasnije. Na dan 16. oktobra 2026. do toga je ostalo jedanaest nedelja, a CMS datum nije pomerio.

Operativna polovina pravila već je na snazi. Od 2026. obuhvaćeni platioci moraju da navedu konkretan razlog za svako odbijeno prethodno odobrenje, da odlučuju u propisanim rokovima i da objavljuju pokazatelje o prethodnim odobrenjima.

Ako vaši sistemi za zahteve za naknadu (claims), upravljanje korišćenjem usluga (utilization management, UM) i evidenciju osiguranika dolaze od dobavljača koji isporučuje ova četiri API-ja, najveći deo izrade je na dobavljaču. Vaš deo su konfiguracija, digitalizovana pravila za prethodna odobrenja, obaveštenja osiguranicima i testiranje sa partnerima.

Ovaj tekst je za ostale: planove i agencije čiji se sistem za obradu zahteva, UM tok rada ili podaci o osiguranicima nalaze u sistemu koji sami poseduju, bilo da je razvijen u kući, prilagođen toliko da se više ne može nadograditi ili je to Medicaid Management Information System (MMIS, informacioni sistem Medicaid-a savezne države) sa decenijama lokalnih izmena. Za takve sisteme API-je niko ne isporučuje. Mi smo inženjeri, a ne pravnici: ovde objašnjavamo šta pravilo traži od sistema, a ne kako se primenjuje na vaše ugovore.

Datumi

Konačno pravilo objavljeno je u Federal Registeru (službenom listu SAD) 8. februara 2024. i na snagu je stupilo 8. aprila 2024. Za svaki od četiri API-ja utvrđuje iste rokove za usklađivanje: „do 1. januara 2027. za MA organizacije i FFS programe Medicaid-a i CHIP-a saveznih država; do perioda obračuna koji počinje 1. januara 2027. ili kasnije za Medicaid managed care planove i CHIP managed care subjekte; i za godine plana koje počinju 1. januara 2027. ili kasnije za izdavaoce QHP planova na berzama FFE“.

Medicaid managed care plan čiji periodi obračuna počinju 1. jula zato ima vremena do 1. jula 2027. Plan sa ugovorom po kalendarskoj godini nema.

CMS i dalje navodi isti datum. Njegova stranica o ovom pravilu, poslednji put izmenjena 8. oktobra 2026, kaže da „obuhvaćeni platioci imaju rok uglavnom do 1. januara 2027. da ispune zahteve ovog konačnog pravila koji se odnose na aplikacioni programski interfejs (API)“.

Obaveze za 2026, kako ih navodi informativni list CMS-a, jesu odluke „u roku od 72 sata za ubrzane (tj. hitne) zahteve i sedam kalendarskih dana za standardne (tj. nehitne) zahteve“ (izdavaoci QHP planova na berzama izuzeti su od ovih rokova), konkretan razlog za svako odbijanje i javni pokazatelji, pri čemu „početni skup pokazatelja mora biti prijavljen do 31. marta 2026“. Korišćenje Patient Access API-ja takođe se prijavljuje CMS-u svake godine do 31. marta. Ako nešto od ovoga još ne radi, već kasni, a oslanja se na iste podatke kao i API-ji.

Lekovi su van svega ovoga. Sve odredbe o prethodnom odobrenju u CMS-0057-F ih izuzimaju.

Na koga se odnosi, a na koga ne

Pravilo ih naziva obuhvaćenim platiocima (impacted payers): organizacije Medicare Advantage (MA), fee-for-service (FFS) programi Medicaid-a i CHIP-a saveznih država, Medicaid managed care planovi, CHIP managed care subjekti i izdavaoci QHP planova na saveznim berzama osiguranja (Federally-facilitated Exchanges, FFEs). Njegova analiza uticaja broji „365 matičnih organizacija, uključujući agencije saveznih država za Medicaid i CHIP“, koje su „odgovorne za uvođenje i održavanje tri nova API-ja“, i navodi da „75 procenata platilaca u ovoj kategoriji ima manje od 500 zaposlenih“. Mnogi su regionalni planovi bez velikog platformskog tima.

Nisu obuhvaćeni, bar ne direktno:

• Planovi poslodavaca van ovih programa i Original Medicare (tradicionalni Medicare koji vodi savezna vlada). Nisu na listi obuhvaćenih platilaca.
• Pružaoci zdravstvenih usluga. Njihova strana je mera Electronic Prior Authorization u Medicare programima Promoting Interoperability, koja se ispunjava sertifikovanom EHR tehnologijom (elektronski zdravstveni karton). Konačno pravilo IPPS (sistem plaćanja bolničkog lečenja u Medicare-u) za fiskalnu 2027. godinu od 4. avgusta 2026. pretvorilo ju je za bolnice u opcionu bonus meru u 2027.
• Subjekti kojima je poveren UM i TPA (administratori treće strane). Nemaju sopstvenu obavezu, ali obaveza platioca prolazi kroz njihove sisteme. Za izdavaoce QHP planova pravilo ponavlja da su „odgovorni za sopstvenu usklađenost i za usklađenost svih delegiranih subjekata ili subjekata niže u lancu“.

Izlaza je malo, a ovako kasno nijedan mnogo ne pomaže. Savezna država može da zatraži jednokratno produženje od godinu dana za svoj FFS program Medicaid-a ili CHIP-a, ali zahtev ide u njen Advance Planning Document (APD, plan kojim država traži savezno finansiranje IT projekta) i mora biti „odobren pre roka za usklađivanje“. Država koja ima najmanje 90 procenata korisnika Medicaid-a u managed care planovima može da zatraži izuzeće, a izdavaoci QHP planova mogu da traže izuzetak od berze. Za same planove CMS je napisao: „Nismo predložili produženja ni izuzeća za MA organizacije ni za Medicaid managed care planove.“ Države za izradu API-ja mogu da traže i uvećano savezno sufinansiranje od 90 procenata, koje se odobrava od slučaja do slučaja kroz APD.

Šta svaki API mora da radi

Sva četiri zavise od jedne stvari koja sistemu po meri često nedostaje: prethodnog odobrenja kao strukturiranih podataka sa istorijom statusa. Napravite to jednom i sva četiri čitaju iz istog izvora.

Patient Access API: dodajte prethodna odobrenja

Ovaj API vodite od 1. januara 2021. za zahteve za naknadu, podatke o pruženim uslugama (encounters) i kliničke podatke. Od 2027. mora da prenosi i svako prethodno odobrenje za proizvode i usluge: njegov status, datum odobrenja ili odbijanja, datum isteka, odobrene proizvode i usluge, konkretan razlog ako je odbijeno i povezanu strukturiranu dokumentaciju pružaoca usluga. Podaci moraju biti dostupni „najkasnije 1 radni dan nakon“ što platilac primi zahtev, ažurirani u roku od jednog radnog dana od svake promene statusa i čuvani dok je odobrenje aktivno i još najmanje godinu dana posle njegove poslednje promene.

UM sistem koji odluke upisuje kao slobodan tekst ili status šalje samo faksom ne može to da napaja bez izmena.

Provider Access API

Pružaoci usluga iz mreže mogu da zatraže podatke pacijenta: zahteve za naknadu i podatke o pruženim uslugama bez isplata pružaocima i učešća u troškovima, klase kliničkih podataka USCDI (američki osnovni skup podataka za interoperabilnost) i informacije o prethodnim odobrenjima, za usluge pružene od 1. januara 2016. Platilac odgovara u roku od jednog radnog dana, ali samo za pacijente koje je pripisao tom pružaocu i koji se nisu odjavili (opt-out).

Za to su potrebne tri stvari koje nasleđeni sistem retko ima. Postupak pripisivanja (attribution) koji povezuje osiguranike sa pružaocima. Odjava koju osiguranik može da promeni u bilo kom trenutku, uz obaveštenja jednostavnim jezikom pre prvog korišćenja, u roku od nedelju dana od početka pokrića i svake godine. I masovni izvoz, jer obavezni standardi uključuju FHIR Bulk Data Access za pružaoca koji traži podatke za sve svoje pacijente odjednom.

Payer-to-Payer API

Kada se osiguranik učlani, novi platilac traži dozvolu (ovde je potrebna izričita saglasnost, opt-in) i u roku od nedelju dana od početka pokrića počinje da utvrđuje prethodne i istovremene platioce. Pošto ih utvrdi, u roku od nedelju dana traži podatke za pet godina: zahteve za naknadu i podatke o pruženim uslugama bez isplata pružaocima i učešća u troškovima, USCDI podatke i prethodna odobrenja osim odbijenih, sa njihovom nestrukturiranom dokumentacijom. Prethodni platilac odgovara u roku od jednog radnog dana. Kod istovremenog pokrića razmena se ponavlja najmanje jednom kvartalno.

Težak deo nije odlazni odgovor. Težak deo je preuzimanje podataka od platilaca sa kojima nikada niste testirali i njihovo uključivanje u zapis o osiguraniku, kako pravilo zahteva.

Prior Authorization API

Ovo je API koji zalazi u samo jezgro UM-a. Mora da navede pokrivene proizvode i usluge za koje je potrebno prethodno odobrenje, da za svaki odredi potrebnu dokumentaciju, da podrži zahtev i odgovor usklađene sa zakonom HIPAA i da kaže da li je platilac odobrio (sa datumom isteka), odbio (sa konkretnim razlogom) ili traži dodatne informacije.

CMS ovde preporučuje, ali ne propisuje, tri Da Vinci vodiča za implementaciju (implementation guides): Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) i Prior Authorization Support (PAS). U praksi vaša pravila pokrića i upitnici za dokumentaciju moraju da postanu mašinski čitljivi, a ne priručnik sa pravilima u PDF-u. Platioci u anketi organizacije WEDI (američko udruženje za elektronsku razmenu podataka u zdravstvu) svrstali su „digitalizaciju pravila za prethodno odobrenje“ među tri najveća izazova.

Kod same transakcije HHS je platiocima ostavio prostor. Dana 28. februara 2024. najavio je da u jednom delu neće sprovoditi propis (enforcement discretion): prema CMS-u, njegova National Standards Group „neće preduzimati mere sprovođenja propisa HIPAA Administrative Simplification protiv subjekata obuhvaćenih HIPAA-om koji odluče da ne koriste standard X12 278 u okviru elektronskog FHIR procesa prethodnog odobrenja“. Možete da gradite samo FHIR ili FHIR uz X12, a paralelno da zadržite i transakciju samo na X12.

Standardi

Obavezni standardi su HL7 FHIR Release 4.0.1, US Core, SMART App Launch, Bulk Data Access i OpenID Connect Core; platioci mogu dobrovoljno, pod određenim uslovima, da koriste novije verzije. Pravilo iz 2024. navelo je US Core 3.1.1 i SMART App Launch 1.0.0 sa datumom isteka 1. januara 2026, pa odlučite prema kojim verzijama gradite pre nego što iko počne da piše mapiranje.

Gde sopstveni sistemi obično zakazuju

Na osnovu onoga što pravilo traži, ovo su praznine koje treba prvo potražiti:

• Prethodno odobrenje kao zapis, a ne dokument. Status, vremenske oznake, šifre razloga odbijanja i datum isteka moraju biti polja koja se upisuju kada se promene, sa istorijom. Odluka poslata faksom traži strukturirani pandan.
• Pravila pokrića. Koje usluge traže odobrenje i kakva je dokumentacija potrebna za svaku moraju biti podaci koje API može da isporuči. U mnogim planovima to stoji u PDF-ovima sa pravilima i u glavama onih koji pregledaju zahteve.
• Zahtevi za naknadu kao FHIR. Zahtevi za naknadu i podaci o pruženim uslugama moraju da izlaze kao FHIR resursi, bez isplata i učešća u troškovima za pružaoce i druge platioce, ali sa njima za osiguranika.
• Identitet i istorija osiguranika. Za uparivanje podataka drugog platioca sa vašim osiguranikom i za pronalaženje prethodnih platilaca novog osiguranika potrebni su demografski podaci i istorija pokrića koje možda ne držite na jednom mestu.
• Stanje saglasnosti. Odjava (opt-out) za Provider Access i saglasnost (opt-in) za Payer-to-Payer, obe promenljive u svakom trenutku i proverene pri svakom zahtevu. Savezna država mora i da prosledi saglasnost korisnika njegovim Medicaid managed care planovima.
• Rok od jednog radnog dana. Noćna batch obrada na mejnfrejmu dovoljna je za neke podatke, a za druge je prespora. Merite vreme od odluke do API-ja, a ne samo da li API odgovara.
• Delegirani dobavljači. Ako odluke donosi dobavljač kome ste poverili UM, njegovi podaci moraju da stignu do vas na vreme za vašu obavezu od jednog radnog dana. Anketa WEDI-ja iz februara 2026. stavila je „delegirane treće strane koje imaju teškoće u povezivanju sa različitim sistemima“ na prvo mesto među izazovima platilaca.

Koliko je industrija odmakla

Anketa WEDI-ja iz februara 2026, objavljena 10. marta 2026, pokazala je da za zahteve u vezi sa API-jima „10% još nije počelo sa radom“, naspram 33% u oktobru 2025. Navela je i „primetan porast procenjenih troškova većih od 5 miliona dolara, sa 15% (okt. ’25) na 25% (feb. ’26)“. Uzorak je mali: 86 odgovora, od kojih 52% od platilaca. Čitajte to kao signal, a ne kao popis.

Plan od jedanaest nedelja do 1. januara 2027

Od sredine oktobra MA organizacija ili FFS program savezne države ima oko jedanaest nedelja. To nije dovoljno da se četiri API-ja naprave od nule, pa je plan pitanje redosleda i onoga što možete da pokažete prvog dana.

1. Ove nedelje: potvrdite svoj datum i polaznu tačku. Da li je to 1. januar ili kasniji period obračuna, odnosno godina plana? Popišite šta već radi: Patient Access i Provider Directory API-ji, pokazatelji za 2026, razlozi odbijanja.
2. 1. i 2. nedelja: povežite svaki podatak sa njegovim izvorom. Za svaki API zapišite koji sistem danas drži podatke (zahtevi za naknadu, UM, upis osiguranika, mreža pružalaca, klinički podaci) i koliko su sveži.
3. Od 1. do 3. nedelje: odlučite gde će biti FHIR sloj. FHIR server ili fasada ispred nasleđenih sistema, koju napajaju događaji o promenama ili česti izvozi, obično je brži put od toga da osnovni sistem naučite da govori FHIR. Vreme odlazi na mapiranje i tokove podataka.
4. Od 2. do 7. nedelje: prvo napravite zajedničke delove. Zapis o prethodnom odobrenju, saglasnosti i pripisivanje, uparivanje osiguranika. Od njih zavise sva četiri API-ja.
5. Od 4. do 9. nedelje: napravite API-je. Dopune za Patient Access, Provider Access sa masovnim izvozom, Payer-to-Payer u oba smera i Prior Authorization API sa učitanim pravilima pokrića.
6. Od 8. do 11. nedelje: testirajte sa stvarnim partnerima. Dobavljač EHR sistema nekog pružaoca, drugi platilac, vaš delegirani UM dobavljač. Testirajte promene saglasnosti, odbijanje sa razlogom i promenu statusa koja stiže do osiguranika u roku od jednog radnog dana.
7. 1. januar 2027: pustite sistem u rad i merite. Od prvog dana pratite latenciju u odnosu na rokove od jednog radnog dana i vodite datiranu listu onoga što nije završeno.

Ako jedanaest nedelja nije dovoljno, recite to timu za usklađenost i pravnicima sada, a ne u decembru, uz plan koji pokazuje šta će raditi 1. januara, a šta i kada sledi posle.

Medicaid managed care plan čiji period obračuna počinje 1. jula 2027. ili izdavalac QHP plana sa kasnijom godinom plana može da prati iste korake sa više vremena. Ipak počnite sada: platioci i pružaoci sa kojima ćete testirati počinju sa radom 1. januara.

Šta se još može promeniti

CMS-0062-P. CMS je 14. aprila 2026. objavio predlog novog pravila koje se nadovezuje na ovo. Ono bi trenutno preporučene vodiče za implementaciju učinilo obaveznim od 1. oktobra 2027, od istog datuma bi uvelo lekove u elektronsko prethodno odobrenje, a HHS bi usvojio FHIR kao HIPAA standard za transakcije prethodnog odobrenja umesto X12 278. O postojećim rokovima kaže: „Ovaj predlog ne bi promenio te rokove za usklađivanje.“ Rok za komentare istekao je 15. juna 2026, a do 16. oktobra 2026. konačno pravilo nije objavljeno u Federal Registeru. Gradite prema pravilu iz 2024. i držite verzije vodiča na jednom mestu koje se može konfigurisati.

Verzije. Da Vinci vodiči se i dalje menjaju. Konačno pravilo IPPS za fiskalnu 2027. navodi da će EHR sistemi sertifikovani prema novim kriterijumima ONC-a (savezne kancelarije za zdravstvene informacione tehnologije) za prethodno odobrenje „zahtevati korišćenje verzije 2.2 Da Vinci vodiča za implementaciju“. Upravo sa tim sistemima će razgovarati vaš Prior Authorization API.

Ništa od toga nije razlog za čekanje. Pravilo je konačno, datumi su u tekstu propisa, a CMS ih je ponovio 8. oktobra.

Gde potražiti pomoć

Radimo na sistemima iza API-ja: FHIR mapiranje podataka o zahtevima za naknadu, pruženim uslugama i odobrenjima, tokovi promena iz starijih platformi za zahteve i UM, logika saglasnosti i pripisivanja i testovi koji pokazuju da se rokovi od jednog radnog dana poštuju. Kada je osnovni sistem star ili su ljudi koji su ga napravili otišli, taj posao počinje kroz našu uslugu održavanja nasleđenih sistema, a ako rok padne usred zamene platforme, pogledajte modernizaciju ERP-a.

Ako je vaša platforma za zahteve za naknadu ili UM takva da joj nijedan dobavljač neće isporučiti ove API-je, pišite na office@c9group.dev. Mi smo inženjeri, a ne pravnici za zdravstvo: pitanja obuhvata i ugovora pripadaju vašim pravnicima, a mi gradimo prema njihovom odgovoru.