CMS-0057-F ja 1. jaanuar 2027: maksjate API-d omaehitatud nõuete ja eelloa süsteemides

Hiljemalt 1. jaanuariks 2027 peavad Medicare Advantage'i organisatsioonidel ning osariikide Medicaidi ja CHIP-i teenustasupõhistel (fee-for-service) programmidel töötama neli FHIR API-t, mida nõuab CMS-i koostalitlusvõime ja eelloa lõplik määrus (CMS Interoperability and Prior Authorization final rule, CMS-0057-F): olemasolev Patient Access API, mida laiendatakse eelloa andmetega, ning uued Provider Access, Payer-to-Payer ja Prior Authorization API-d. Medicaidi hallatud ravi plaanid (managed care), CHIP-i hallatud ravi üksused ja föderaalsetel börsidel tegutsevad Qualified Health Plan'i väljastajad järgnevad alates esimesest hinnastamisperioodist või plaaniaastast, mis algab sellel kuupäeval või hiljem. 16. oktoobri 2026 seisuga on selleni üksteist nädalat ja CMS ei ole kuupäeva muutnud.

Määruse operatiivne pool kehtib juba. Alates 2026. aastast peavad määrusega hõlmatud maksjad esitama iga tagasi lükatud eelloa kohta konkreetse põhjuse, tegema otsused kindlaksmääratud tähtaegade jooksul ja avaldama eelloa näitajad.

Kui teie nõuete, ravikasutuse halduse (utilization management, UM) ja liikmete süsteemid pärinevad tarnijalt, kes need neli API-t valmis teeb, on suurem osa arendustööst tarnija oma. Teie osa on seadistamine, digitaliseeritud eelloa reeglid, liikmetele saadetavad teated ja testimine partneritega.

See artikkel on ülejäänutele: plaanidele ja asutustele, kelle nõuete mootor, UM-töövoog või liikmeandmed asuvad süsteemis, mis kuulub neile endile, olgu see ise ehitatud, nii palju kohandatud, et uuendused enam ei toimi, või Medicaid Management Information System (MMIS) aastakümnete jooksul tehtud kohalike muudatustega. Nende jaoks ei tee keegi API-sid valmis. Oleme insenerid, mitte juristid: siin selgitame, mida määrus süsteemilt nõuab, mitte seda, kuidas see teie lepingutele kohaldub.

Kuupäevad

Lõplik määrus avaldati Federal Registeris 8. veebruaril 2024 ja jõustus 8. aprillil 2024. Kõigi nelja API puhul seab see samad nõuete täitmise tähtpäevad: „hiljemalt 1. jaanuariks 2027 MA organisatsioonidele ning osariikide Medicaidi ja CHIP-i FFS-programmidele; 1. jaanuaril 2027 või hiljem algavaks hinnastamisperioodiks Medicaidi hallatud ravi plaanidele ja CHIP-i hallatud ravi üksustele; ning 1. jaanuaril 2027 või hiljem algavateks plaaniaastateks FFE-de QHP väljastajatele.“

Medicaidi hallatud ravi plaanil, mille hinnastamisperioodid algavad 1. juulil, on seega aega 1. juulini 2027. Kalendriaasta lepinguga plaanil seda aega ei ole.

CMS annab endiselt sama kuupäeva. Määruse poliitikaleht, mida muudeti viimati 8. oktoobril 2026, ütleb, et „määrusega hõlmatud maksjatel on selle lõpliku määruse rakendusliidese (API) nõuete täitmiseks aega peamiselt 1. jaanuarini 2027“.

2026. aasta kohustused on CMS-i teabelehe sõnastuses järgmised: otsused „72 tunni jooksul kiirendatud (st kiireloomuliste) taotluste puhul ja seitsme kalendripäeva jooksul tavaliste (st mittekiireloomuliste) taotluste puhul“ (börsidel tegutsevatele QHP väljastajatele tähtajad ei kehti), konkreetne põhjus iga tagasilükkamise kohta ning avalikud näitajad, millest „esimene näitajate kogum tuleb esitada hiljemalt 31. märtsiks 2026“. Ka Patient Access API kasutusest antakse CMS-ile aru igal aastal 31. märtsiks. Kui midagi sellest veel ei tööta, olete juba hiljaks jäänud, ja see kasutab samu andmeid nagu API-d.

Ravimid jäävad sellest kõigest välja. CMS-0057-F iga eelloa säte jätab need kõrvale.

Keda määrus hõlmab ja keda mitte

Määrus nimetab neid hõlmatud maksjateks (impacted payers): Medicare Advantage'i (MA) organisatsioonid, osariikide Medicaidi ja CHIP-i teenustasupõhised (FFS) programmid, Medicaidi hallatud ravi plaanid, CHIP-i hallatud ravi üksused ja QHP väljastajad föderaalselt hallatavatel börsidel (FFE). Mõjuanalüüs loeb kokku „365 emaorganisatsiooni, sealhulgas osariikide Medicaidi ja CHIP-i asutused“, kes „vastutavad kolme uue API rakendamise ja ülalpidamise eest“, ning märgib, et „75 protsendil selle kategooria maksjatest on alla 500 töötaja“. Paljud neist on piirkondlikud plaanid ilma suure platvormimeeskonnata.

Määrus ei hõlma, vähemalt mitte otseselt:

• Tööandjate plaane väljaspool neid programme ja Original Medicare'it. Neid ei ole hõlmatud maksjate nimekirjas.
• Teenuseosutajaid. Nende poolt reguleerib Medicare'i Promoting Interoperability programmide Electronic Prior Authorization näitaja, mida täidetakse sertifitseeritud EHR-tehnoloogia kaudu. 4. augusti 2026 FY 2027 IPPS lõplik määrus muutis selle haiglate jaoks 2027. aastal valikuliseks boonusnäitajaks.
• Delegeeritud UM-üksusi ja kolmandatest isikutest administraatoreid (TPA). Neil ei ole oma kohustust, kuid maksja kohustus kulgeb läbi nende süsteemide. QHP väljastajate puhul kordab määrus, et nad „vastutavad nii enda kui ka kõigi delegeeritud või allavoolu üksuste nõuetele vastavuse eest“.

Väljapääse on vähe ja ükski neist ei aita nii hilja enam palju. Osariik võib oma Medicaidi või CHIP-i FFS-programmi jaoks taotleda ühekordset üheaastast pikendust, kuid taotlus esitatakse tema Advance Planning Documentis (APD) ja see peab olema „heaks kiidetud enne nõuete täitmise tähtpäeva“. Osariik, kus vähemalt 90 % Medicaidi soodustatutest on hallatud ravis, võib taotleda vabastust ja QHP väljastajad võivad börsilt erandit küsida. Plaanide endi kohta kirjutas CMS: „Me ei teinud ettepanekut pikendusteks ega vabastusteks MA organisatsioonidele ega Medicaidi hallatud ravi plaanidele.“ Osariigid saavad API-de ehitamiseks taotleda ka 90 % suurendatud föderaalset kaasrahastamist, mis kiidetakse APD kaudu heaks juhtumipõhiselt.

Mida iga API peab tegema

Kõik neli sõltuvad ühest asjast, mis kohandatud süsteemist sageli puudub: eelluba kui struktureeritud andmed koos olekute ajalooga. Ehitage see üks kord ja kõik neli loevad sealt.

Patient Access API: eellubade lisamine

Seda API-t olete käitanud alates 1. jaanuarist 2021 nõuete, kohtumiste (encounters) ja kliiniliste andmete jaoks. Alates 2027. aastast peab see edastama ka iga toodete ja teenuste eelloa: selle oleku, kuupäeva, mil see kiideti heaks või lükati tagasi, lõppkuupäeva, heakskiidetud tooted ja teenused, tagasilükkamise korral konkreetse põhjuse ning teenuseosutaja seotud struktureeritud dokumentatsiooni. Andmed peavad olema kättesaadavad „hiljemalt 1 tööpäev pärast“ seda, kui maksja taotluse kätte saab, neid tuleb uuendada ühe tööpäeva jooksul pärast iga olekumuutust ning neid tuleb säilitada nii kaua, kuni luba kehtib, ja vähemalt aasta pärast selle viimast muutmist.

UM-süsteem, mis salvestab otsused vabatekstiliste märkmetena või saadab olekuid ainult faksiga, ei suuda neid andmeid muudatusteta edastada.

Provider Access API

Võrgusisesed teenuseosutajad saavad küsida patsiendi andmeid: nõudeid ja kohtumisi ilma teenuseosutajate tasumisteatiste ja omaosaluseta, USCDI kliiniliste andmete klasse ning eelloa teavet teenuste kohta alates 1. jaanuarist 2016. Maksja vastab ühe tööpäeva jooksul, kuid ainult patsientide kohta, kelle ta on sellele teenuseosutajale omistanud ja kes ei ole loobunud.

Selleks on vaja kolme asja, mida pärandsüsteemis harva leidub. Omistamisprotsessi, mis seob liikmed teenuseosutajatega. Loobumisvõimalust, mida liige saab igal ajal muuta, koos lihtsas keeles teadetega enne esimest kasutamist, nädala jooksul pärast kindlustuskaitse algust ja igal aastal. Ning hulgieksporti, sest nõutavate standardite hulka kuulub FHIR Bulk Data Access teenuseosutajale, kes küsib andmeid terve patsientide nimekirja kohta.

Payer-to-Payer API

Kui liige liitub, küsib uus maksja luba (siin on vaja nõusolekut) ja hakkab nädala jooksul pärast kindlustuskaitse algust välja selgitama eelmisi ja samaaegseid maksjaid. Kui need on teada, küsib ta nädala jooksul viie aasta andmeid: nõuded ja kohtumised ilma tasumisteatiste ja omaosaluseta, USCDI andmed ning eelload (v.a tagasi lükatud) koos nende struktureerimata dokumentatsiooniga. Eelmine maksja vastab ühe tööpäeva jooksul. Samaaegse kindlustuskaitse korral korratakse vahetust vähemalt kord kvartalis.

Raske osa ei ole väljaminev vastus. Raske on võtta vastu andmeid maksjatelt, kellega te pole kunagi testinud, ja lisada need oma liikmekirjesse, nagu määrus nõuab.

Prior Authorization API

See on API, mis ulatub UM-süsteemi tuumani. API peab loetlema kaetud tooted ja teenused, mis nõuavad eelluba, nimetama igaühe jaoks nõutava dokumentatsiooni, toetama HIPAA-nõuetele vastavat taotlust ja vastust ning teatama, kas maksja kiitis heaks (koos lõppkuupäevaga), lükkas tagasi (koos konkreetse põhjusega) või vajab rohkem teavet.

CMS soovitab, kuid ei nõua, siin kolme Da Vinci rakendusjuhendit: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) ja Prior Authorization Support (PAS). Praktikas peavad teie kindlustuskaitse reeglid ja dokumentatsiooniküsimustikud muutuma masinloetavaks, mitte jääma PDF-vormis poliitikakäsiraamatuks. WEDI uuringus nimetasid maksjad „eelloa poliitikate digitaliseerimist“ oma kolme suurima väljakutse hulgas.

Tehingu enda osas andis HHS maksjatele mänguruumi. 28. veebruaril 2024 teatas see täitmise tagamise kaalutlusõigusest: CMS-i sõnul ei võta selle National Standards Group „HIPAA haldusliku lihtsustamise täitemeetmeid HIPAA-ga hõlmatud üksuste suhtes, kes otsustavad elektroonilises FHIR-põhises eelloa protsessis X12 278 standardit mitte kasutada“. Võite ehitada ainult FHIR-põhise lahenduse või FHIR-i koos X12-ga ning hoida kõrval ainult X12-põhist tehingut.

Standardid

Nõutavad standardid on HL7 FHIR Release 4.0.1, US Core, SMART App Launch, Bulk Data Access ja OpenID Connect Core; maksjad võivad tingimustel vabatahtlikult kasutada uuemaid versioone. 2024. aasta määrus loetles US Core 3.1.1 ja SMART App Launch 1.0.0 aegumiskuupäevaga 1. jaanuar 2026, nii et leppige kokku, millise versiooni järgi ehitate, enne kui keegi vastenduse kirjutab.

Kus omaehitatud süsteemid tavaliselt puudu jäävad

Määruse nõuete põhjal tasub esmalt otsida järgmisi lünki:

• Eelluba kui kirje, mitte dokument. Olek, ajatemplid, tagasilükkamise põhjuse koodid ja lõppkuupäev peavad olema väljad, mis kirjutatakse muutumise hetkel ja millel on ajalugu. Faksiga saadetud otsusel peab olema struktureeritud kaksik.
• Kindlustuskaitse reeglid. See, millised teenused vajavad luba ja millist dokumentatsiooni igaüks nõuab, peab olema andmed, mida API saab edastada. Paljudes plaanides elab see poliitika-PDF-ides ja hindajate peades.
• Nõuded FHIR-vormingus. Nõuded ja kohtumised peavad väljuma FHIR-ressurssidena, nii et teenuseosutajate ja teiste maksjate jaoks on tasumisteatised ja omaosalus eemaldatud, liikme jaoks aga alles jäetud.
• Liikme identiteet ja ajalugu. Teise maksja andmete sobitamiseks teie liikmega ja uue liikme eelmiste maksjate leidmiseks on vaja demograafilisi andmeid ja kindlustuskaitse ajalugu, mida te ei pruugi ühes kohas hoida.
• Nõusoleku olek. Provider Accessi puhul loobumine ja Payer-to-Payeri puhul nõusolek, kumbki igal ajal muudetav ja iga päringu juures kontrollitav. Osariik peab ka soodustatu nõusoleku edastama selle inimese Medicaidi hallatud ravi plaanidele.
• Ühe tööpäeva tähtaeg. Öine suurarvuti pakktöötlus sobib mõne andme jaoks ja on teiste jaoks liiga aeglane. Mõõtke aega otsusest API-ni, mitte ainult seda, kas API vastab.
• Delegeeritud tarnijad. Kui otsuseid teeb delegeeritud UM-tarnija, peavad tema andmed jõudma teieni õigel ajal, et täita teie ühe tööpäeva kohustust. WEDI 2026. aasta veebruari uuring pani maksjate väljakutsete esikohale „delegeeritud kolmandad osapooled, kellel on raskusi erinevate süsteemidega ühendumisel“.

Kui kaugel valdkond on

WEDI 2026. aasta veebruari uuring, mis avaldati 10. märtsil 2026, leidis, et API nõuete osas „10 % ei ole oma tööga veel alustanud“, võrreldes 33 %-ga 2025. aasta oktoobris. Samuti teatas see „märgatavast kasvust nende osas, kelle hinnangulised kulud ületavad 5 miljonit dollarit: 15 %-lt (okt 2025) 25 %-ni (veebr 2026)“. Valim on väike: 86 vastust, millest 52 % maksjatelt. Lugege seda signaalina, mitte loendusena.

Üheteistkümne nädala plaan kuni 1. jaanuarini 2027

Oktoobri keskpaigast on MA organisatsioonil või osariigi FFS-programmil umbes üksteist nädalat. Sellest ei piisa nelja API nullist ehitamiseks, nii et plaan on järjekorra ja selle kohta, mida saate esimesel päeval näidata.

1. Sel nädalal: kinnitage oma kuupäev ja lähtepunkt. Kas 1. jaanuar või hilisem hinnastamisperiood või plaaniaasta? Loetlege, mis juba töötab: Patient Access ja Provider Directory API-d, 2026. aasta näitajad, tagasilükkamise põhjused.
2. Nädalad 1 kuni 2: siduge iga andmeelement selle allikaga. Kirjutage iga API kohta üles, milline süsteem andmeid täna hoiab (nõuded, UM, liikmearvestus, teenuseosutajate võrgustik, kliinilised andmed) ja kui värsked need on.
3. Nädalad 1 kuni 3: otsustage, kus FHIR-kiht asub. FHIR-server või fassaad pärandsüsteemide ees, mida toidavad muutussündmused või sagedased väljavõtted, on tavaliselt kiirem kui tuumsüsteemile FHIR-i õpetamine. Aeg kulub vastendusele ja andmevoogudele.
4. Nädalad 2 kuni 7: ehitage esmalt jagatud osad. Eelloa kirje, nõusolek ja omistamine, liikmete sobitamine. Kõik neli API-t sõltuvad neist.
5. Nädalad 4 kuni 9: ehitage API-d. Patient Accessi täiendused, Provider Access koos hulgiekspordiga, Payer-to-Payer mõlemas suunas ja Prior Authorization API koos laaditud kindlustuskaitse reeglitega.
6. Nädalad 8 kuni 11: testige päris partneritega. Teenuseosutaja EHR-tarnija, teine maksja, teie delegeeritud UM-tarnija. Testige nõusoleku muutmist, tagasilükkamist koos põhjusega ja olekumuutust, mis jõuab liikmeni ühe tööpäeva jooksul.
7. 1. jaanuar 2027: käivitage ja mõõtke. Jälgige esimesest päevast latentsust ühe tööpäeva reeglite suhtes ja pidage kuupäevastatud nimekirja sellest, mis on veel lõpetamata.

Kui üheteistkümnest nädalast ei piisa, viige see oma vastavusmeeskonna ja õigusnõustaja ette kohe, mitte detsembris, koos plaaniga, mis näitab, mis töötab 1. jaanuaril ja mis järgneb millal.

Medicaidi hallatud ravi plaan, mille hinnastamisperiood algab 1. juulil 2027, või QHP väljastaja hilisema plaaniaastaga saab samu samme järgida rohkema ajavaruga. Alustage siiski kohe: maksjad ja teenuseosutajad, kellega te testite, lähevad käiku 1. jaanuaril.

Mis võib veel muutuda

CMS-0062-P. CMS avaldas 14. aprillil 2026 järgmääruse eelnõu. See muudaks praegu soovitatavad rakendusjuhendid kohustuslikuks alates 1. oktoobrist 2027, lisaks samast kuupäevast ravimid elektroonilisse eelloa protsessi ning laseks HHS-il võtta X12 278 asemel FHIR-i HIPAA standardiks eelloa tehingute jaoks. Olemasolevate tähtpäevade kohta ütleb see: „See ettepanek ei muudaks neid nõuete täitmise tähtpäevi.“ Kommentaaride esitamine lõppes 15. juunil 2026 ja 16. oktoobri 2026 seisuga ei ole Federal Registeris lõplikku määrust ilmunud. Ehitage 2024. aasta määruse järgi ja hoidke juhendite versioonid ühes seadistatavas kohas.

Versioonid. Da Vinci juhendid muutuvad pidevalt. FY 2027 IPPS lõplik määrus märgib, et EHR-id, mis on sertifitseeritud ONC uute eelloa kriteeriumide järgi, „peavad kasutama Da Vinci rakendusjuhendite versiooni 2.2“. Just nende süsteemidega hakkab teie Prior Authorization API suhtlema.

Miski sellest ei ole põhjus oodata. Määrus on lõplik, kuupäevad on määruse tekstis ja CMS kordas neid 8. oktoobril.

Kust abi saada

Töötame süsteemidega, mis on API-de taga: nõuete, kohtumiste ja lubade andmete FHIR-vastendus, muudatuste vood vanematest nõuete ja UM-platvormidest, nõusoleku ja omistamise loogika ning testid, mis näitavad, et ühe tööpäeva reeglid peavad. Meie pärandsüsteemide hoolduse teenus on koht, kust see algab, kui tuumsüsteem on vana või selle ehitanud inimesed on lahkunud, ning kui tähtaeg langeb keset platvormi vahetust, vaadake ERP moderniseerimist.

Kui teie nõuete või UM-platvormi jaoks ei tee ükski tarnija neid API-sid valmis, kirjutage aadressil office@c9group.dev. Oleme insenerid, mitte tervishoiuõiguse juristid: kohaldamisala ja lepingute küsimused kuuluvad teie õigusnõustajale ning meie ehitame nende vastuse järgi.