CMS-0057-F ir 2027 m. sausio 1 d.: mokėtojų API vidinėse išmokų ir išankstinio leidimo sistemose

Iki 2027 m. sausio 1 d. Medicare Advantage organizacijos ir valstijų Medicaid bei CHIP programos, mokančios už suteiktas paslaugas (fee-for-service), pagal CMS sąveikumo ir išankstinio leidimo galutinę taisyklę (CMS-0057-F) turi turėti veikiančias keturias FHIR API: esamą Patient Access API, išplėstą išankstinio leidimo duomenimis, ir naujas Provider Access, Payer-to-Payer ir Prior Authorization API. Medicaid valdomos priežiūros planai, CHIP valdomos priežiūros subjektai ir Qualified Health Plan teikėjai federalinėse biržose prisijungia nuo pirmojo įkainojimo laikotarpio ar plano metų, prasidedančių tą dieną ar vėliau. 2026 m. spalio 16 d. iki to lieka vienuolika savaičių, ir CMS termino nepakeitė.

Operacinė taisyklės dalis jau galioja. Nuo 2026 m. taisyklės paveikti mokėtojai turi nurodyti konkrečią kiekvieno atmesto išankstinio leidimo priežastį, priimti sprendimus per nustatytus terminus ir skelbti išankstinio leidimo rodiklius.

Jei jūsų išmokų, paslaugų naudojimo valdymo (UM) ir narių sistemas tiekia tiekėjas, kuris šias keturias API pristato, didžiąją dalį kūrimo darbų atlieka tiekėjas. Jūsų dalis yra konfigūracija, skaitmeninės išankstinio leidimo taisyklės, pranešimai nariams ir testavimas su partneriais.

Šis straipsnis skirtas likusiems: planams ir agentūroms, kurių išmokų variklis, UM darbo eiga ar narių duomenys yra jų pačių sistemoje, ar ji sukurta viduje, ar pritaikyta taip, kad nebegalima atnaujinti, ar tai Medicaid Management Information System (MMIS) su dešimtmečius kauptais vietiniais pakeitimais. Tokioms sistemoms API niekas nepristato. Esame inžinieriai, ne teisininkai: aiškiname, ko taisyklė reikalauja iš sistemos, o ne kaip ji taikoma jūsų sutartims.

Datos

Galutinė taisyklė paskelbta Federal Register 2024 m. vasario 8 d. ir įsigaliojo 2024 m. balandžio 8 d. Visoms keturioms API ji nustato tas pačias atitikties datas: „iki 2027 m. sausio 1 d. MA organizacijoms ir valstijų Medicaid bei CHIP FFS programoms; nuo įkainojimo laikotarpio, prasidedančio 2027 m. sausio 1 d. ar vėliau, Medicaid valdomos priežiūros planams ir CHIP valdomos priežiūros subjektams; ir nuo plano metų, prasidedančių 2027 m. sausio 1 d. ar vėliau, QHP teikėjams FFE biržose.“

Taigi Medicaid valdomos priežiūros planas, kurio įkainojimo laikotarpiai prasideda liepos 1 d., turi laiko iki 2027 m. liepos 1 d. Planas su kalendorinių metų sutartimi tokio laiko neturi.

CMS vis dar nurodo tą pačią datą. Jos taisyklės politikos puslapyje, paskutinį kartą keistame 2026 m. spalio 8 d., rašoma, kad „paveikti mokėtojai šios galutinės taisyklės taikomųjų programų sąsajos (API) reikalavimus iš esmės turi įvykdyti iki 2027 m. sausio 1 d.“

2026 m. pareigos, kaip jas formuluoja CMS faktų suvestinė, yra sprendimai „per 72 valandas dėl skubių (t. y. neatidėliotinų) prašymų ir per septynias kalendorines dienas dėl standartinių (t. y. neskubių) prašymų“ (QHP teikėjams biržose šie terminai netaikomi), konkreti kiekvieno atmetimo priežastis ir vieši rodikliai, iš kurių „pirmasis rodiklių rinkinys turi būti pateiktas iki 2026 m. kovo 31 d.“ Patient Access API naudojimo duomenys CMS taip pat teikiami kasmet iki kovo 31 d. Jei kas nors iš to dar neveikia, jūs jau vėluojate, o šios pareigos remiasi tais pačiais duomenimis kaip ir API.

Vaistams visa tai netaikoma. Kiekviena CMS-0057-F išankstinio leidimo nuostata juos išskiria.

Kam taisyklė taikoma, o kam ne

Taisyklėje jie vadinami paveiktais mokėtojais: Medicare Advantage (MA) organizacijos, valstijų Medicaid ir CHIP fee-for-service (FFS) programos, Medicaid valdomos priežiūros planai, CHIP valdomos priežiūros subjektai ir QHP teikėjai federalinėse biržose (Federally-facilitated Exchanges, FFE). Jos poveikio analizėje suskaičiuotos „365 patronuojančiosios organizacijos, įskaitant valstijų Medicaid ir CHIP agentūras“, kurios „atsako už trijų naujų API įgyvendinimą ir priežiūrą“, ir pažymima, kad „75 procentai šios kategorijos mokėtojų turi mažiau nei 500 darbuotojų“. Daugelis jų yra regioniniai planai be didelės platformos komandos.

Netaikoma, bent jau tiesiogiai:

• Darbdavių planams už šių programų ribų ir Original Medicare. Jų nėra paveiktų mokėtojų sąraše.
• Paslaugų teikėjams. Jų pusė yra Medicare Promoting Interoperability programų Electronic Prior Authorization rodiklis, įgyvendinamas sertifikuotomis EHR technologijomis. FY 2027 IPPS galutinė taisyklė, priimta 2026 m. rugpjūčio 4 d., 2027 m. ligoninėms jį pavertė neprivalomu papildomų balų rodikliu.
• Deleguotiems UM subjektams ir TPA. Jie neturi savų pareigų, tačiau mokėtojo pareigos vykdomos per jų sistemas. Dėl QHP teikėjų taisyklė pakartoja, kad jie „atsako už savo pačių atitiktį ir už visų deleguotų ar tolesnės grandies subjektų atitiktį“.

Išimčių nedaug, ir taip vėlai nė viena daug nepadeda. Valstija gali paprašyti vienkartinio pratęsimo vieneriems metams savo Medicaid ar CHIP FFS programai, tačiau prašymas teikiamas jos Advance Planning Document (APD) ir turi būti „patvirtintas iki atitikties datos“. Valstija, kurioje bent 90 procentų Medicaid gavėjų yra valdomos priežiūros planuose, gali prašyti išimties, o QHP teikėjai gali prašyti biržos padaryti išimtį. Dėl pačių planų CMS rašė: „Pratęsimų ar išimčių MA organizacijoms ar Medicaid valdomos priežiūros planams nesiūlėme.“ Valstijos API kūrimui taip pat gali prašyti 90 procentų padidinto federalinio bendrojo finansavimo, kuris tvirtinamas kiekvienu atveju atskirai per APD.

Ką turi daryti kiekviena API

Visos keturios priklauso nuo vieno dalyko, kurio individualioje sistemoje dažnai trūksta: išankstinio leidimo kaip struktūrizuotų duomenų su būsenų istorija. Sukurkite tai kartą, ir visos keturios iš to skaitys.

Patient Access API: pridėti išankstinius leidimus

Šią API eksploatuojate nuo 2021 m. sausio 1 d. išmokų, susitikimų ir klinikiniams duomenims. Nuo 2027 m. ji taip pat turi perduoti kiekvieną išankstinį leidimą prekėms ir paslaugoms: jo būseną, patvirtinimo ar atmetimo datą, galiojimo pabaigą, patvirtintas prekes ir paslaugas, konkrečią priežastį, jei atmesta, ir susijusius struktūrizuotus paslaugų teikėjo dokumentus. Duomenys turi būti prieinami „ne vėliau kaip per 1 darbo dieną“ nuo prašymo gavimo, atnaujinami per vieną darbo dieną po bet kokio būsenos pasikeitimo ir saugomi, kol leidimas galioja, bei bent metus po paskutinio jo pakeitimo.

UM sistema, kuri sprendimus registruoja laisvo teksto pastabomis arba būseną siunčia tik faksu, be pakeitimų šių duomenų pateikti negali.

Provider Access API

Tinklo paslaugų teikėjai gali prašyti paciento duomenų: išmokų ir susitikimų be paslaugų teikėjų atsiskaitymų ar išlaidų pasidalijimo, USCDI klinikinių duomenų klasių ir išankstinio leidimo informacijos, už paslaugas nuo 2016 m. sausio 1 d. Mokėtojas atsako per vieną darbo dieną, tačiau tik dėl pacientų, kuriuos priskyrė tam paslaugų teikėjui ir kurie neatsisakė.

Tam reikia trijų dalykų, kurių senoji sistema retai turi. Priskyrimo proceso, siejančio narius su paslaugų teikėjais. Atsisakymo, kurį narys gali bet kada pakeisti, su aiškia kalba parašytais pranešimais prieš pirmąjį naudojimą, per savaitę nuo draudimo pradžios ir kasmet. Ir masinio eksporto, nes tarp privalomų standartų yra FHIR Bulk Data Access paslaugų teikėjui, kuris klausia apie visą savo pacientų sąrašą.

Payer-to-Payer API

Kai prisijungia narys, naujasis mokėtojas paprašo leidimo (šiuo atveju reikia sutikimo) ir per savaitę nuo draudimo pradžios pradeda nustatinėti ankstesnius ir lygiagrečius mokėtojus. Juos nustatęs, jis per savaitę paprašo penkerių metų duomenų: išmokų ir susitikimų be atsiskaitymų ar išlaidų pasidalijimo, USCDI duomenų ir išankstinių leidimų, išskyrus atmestus, su jų nestruktūrizuotais dokumentais. Ankstesnis mokėtojas atsako per vieną darbo dieną. Esant lygiagrečiam draudimui, mainai kartojami bent kas ketvirtį.

Sunkiausia ne siunčiamas atsakymas. Sunkiausia priimti duomenis iš mokėtojų, su kuriais niekada netestavote, ir įtraukti juos į savo nario įrašą, kaip reikalauja taisyklė.

Prior Authorization API

Ši API pasiekia UM branduolį. Ji turi pateikti sąrašą apdraustų prekių ir paslaugų, kurioms reikia išankstinio leidimo, nurodyti kiekvienai reikalingus dokumentus, palaikyti HIPAA reikalavimus atitinkantį prašymą ir atsakymą ir nurodyti, ar mokėtojas patvirtino (su galiojimo pabaigos data), atmetė (su konkrečia priežastimi), ar jam reikia daugiau informacijos.

CMS čia rekomenduoja, bet nereikalauja, trijų Da Vinci įgyvendinimo vadovų: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) ir Prior Authorization Support (PAS). Praktiškai jūsų draudimo taisyklės ir dokumentų klausimynai turi tapti mašininiu būdu skaitomi, o ne likti PDF politikos vadove. WEDI apklausoje mokėtojai „išankstinio leidimo politikos skaitmeninimą“ įvardijo tarp trijų didžiausių iššūkių.

Dėl pačios operacijos HHS mokėtojams paliko laisvės. 2024 m. vasario 28 d. ji paskelbė apie vykdymo užtikrinimo diskreciją: pasak CMS, jos National Standards Group „netaikys HIPAA Administrative Simplification vykdymo užtikrinimo priemonių HIPAA subjektams, kurie elektroniniame FHIR išankstinio leidimo procese nusprendžia nenaudoti X12 278 standarto“. Galite kurti tik FHIR arba FHIR su X12 ir šalia palikti vien X12 operaciją.

Standartai

Privalomi standartai yra HL7 FHIR Release 4.0.1, US Core, SMART App Launch, Bulk Data Access ir OpenID Connect Core; mokėtojai savanoriškai, laikydamiesi sąlygų, gali naudoti atnaujintas versijas. 2024 m. taisyklėje US Core 3.1.1 ir SMART App Launch 1.0.0 nurodyti su galiojimo pabaiga 2026 m. sausio 1 d., todėl nuspręskite, kurioms versijoms kuriate, dar prieš kam nors pradedant rašyti susiejimą.

Kur vidinės sistemos dažniausiai neatitinka

Pagal tai, ko reikalauja taisyklė, pirmiausia ieškokite šių spragų:

• Išankstinis leidimas kaip įrašas, o ne dokumentas. Būsena, laiko žymos, atmetimo priežasčių kodai ir galiojimo pabaigos data turi būti laukai, įrašomi jiems pasikeitus, su istorija. Faksu išsiųstam sprendimui reikia struktūrizuoto dvynio.
• Draudimo taisyklės. Kurioms paslaugoms reikia leidimo ir kokių dokumentų reikia kiekvienai, turi būti duomenys, kuriuos API gali pateikti. Daugelyje planų tai yra politikos PDF failuose ir vertintojų galvose.
• Išmokos kaip FHIR. Išmokos ir susitikimai turi būti pateikiami kaip FHIR ištekliai, paslaugų teikėjams ir kitiems mokėtojams pašalinus atsiskaitymus ir išlaidų pasidalijimą, bet paliekant juos nariui.
• Nario tapatybė ir istorija. Kito mokėtojo duomenims susieti su jūsų nariu ir naujo nario ankstesniems mokėtojams rasti reikia demografinių duomenų ir draudimo istorijos, kurių galbūt nelaikote vienoje vietoje.
• Sutikimo būsena. Atsisakymas Provider Access atveju ir sutikimas Payer-to-Payer atveju, kiekvienas keičiamas bet kada ir tikrinamas kiekvienos užklausos metu. Valstija taip pat turi perduoti gavėjo sutikimą to asmens Medicaid valdomos priežiūros planams.
• Vienos darbo dienos laikrodis. Naktinis pagrindinio kompiuterio paketinis apdorojimas kai kuriems duomenims tinka, kitiems per lėtas. Matuokite laiką nuo sprendimo iki API, o ne tik tai, ar API atsako.
• Deleguoti tiekėjai. Jei sprendimus priima deleguotas UM tiekėjas, jo duomenys turi jus pasiekti laiku, kad įvykdytumėte savo vienos darbo dienos pareigą. WEDI 2026 m. vasario apklausoje „deleguotų trečiųjų šalių sunkumai jungiantis prie skirtingų sistemų“ įvardyti pirmuoju mokėtojų iššūkiu.

Kiek pažengusi pramonė

WEDI 2026 m. vasario apklausa, paskelbta 2026 m. kovo 10 d., nustatė, kad API reikalavimų atžvilgiu „10 % dar nepradėjo darbų“, palyginti su 33 % 2025 m. spalį. Ji taip pat nurodė „pastebimai išaugusią dalį, kurių numatomos išlaidos viršija 5 mln. JAV dolerių: nuo 15 % (2025 m. spalis) iki 25 % (2026 m. vasaris)“. Imtis nedidelė: 86 atsakymai, iš jų 52 % mokėtojų. Vertinkite tai kaip signalą, o ne surašymą.

Vienuolikos savaičių planas iki 2027 m. sausio 1 d.

Nuo spalio vidurio MA organizacija ar valstijos FFS programa turi maždaug vienuolika savaičių. To nepakanka sukurti keturias API nuo nulio, todėl planas yra apie seką ir apie tai, ką galėsite parodyti pirmąją dieną.

1. Šią savaitę: patvirtinkite savo datą ir atskaitos tašką. Sausio 1 d. ar vėlesnis įkainojimo laikotarpis arba plano metai? Išvardykite, kas jau veikia: Patient Access ir Provider Directory API, 2026 m. rodikliai, atmetimo priežastys.
2. 1 ir 2 savaitės: susiekite kiekvieną duomenų elementą su jo šaltiniu. Kiekvienai API užsirašykite, kuri sistema šiandien laiko duomenis (išmokos, UM, registracija, paslaugų teikėjų tinklas, klinikiniai) ir kiek jie švieži.
3. Nuo 1 iki 3 savaitės: nuspręskite, kur bus FHIR sluoksnis. FHIR serveris ar fasadas prieš senąsias sistemas, maitinamas pakeitimų įvykiais ar dažnais išrašais, paprastai greitesnis nei mokyti pagrindinę sistemą kalbėti FHIR. Daugiausia laiko atima susiejimas ir duomenų srautai.
4. Nuo 2 iki 7 savaitės: pirmiausia sukurkite bendras dalis. Išankstinio leidimo įrašą, sutikimą ir priskyrimą, narių susiejimą. Nuo jų priklauso visos keturios API.
5. Nuo 4 iki 9 savaitės: sukurkite API. Patient Access papildymus, Provider Access su masiniu eksportu, Payer-to-Payer abiem kryptimis ir Prior Authorization API su įkeltomis draudimo taisyklėmis.
6. Nuo 8 iki 11 savaitės: testuokite su tikrais partneriais. Paslaugų teikėjo EHR tiekėju, kitu mokėtoju, savo deleguotu UM tiekėju. Patikrinkite sutikimo pakeitimus, atmetimą su priežastimi ir būsenos pasikeitimą, kuris pasiekia narį per darbo dieną.
7. 2027 m. sausio 1 d.: paleiskite ir matuokite. Nuo pirmos dienos stebėkite delsą pagal vienos darbo dienos taisykles ir veskite datuotą sąrašą to, kas nebaigta.

Jei vienuolikos savaičių nepakanka, kreipkitės į savo atitikties komandą ir teisininkus dabar, o ne gruodį, su planu, kuriame matyti, kas veiks sausio 1 d. ir kas bus vėliau bei kada.

Medicaid valdomos priežiūros planas, kurio įkainojimo laikotarpis prasideda 2027 m. liepos 1 d., ar QHP teikėjas su vėlesniais plano metais gali eiti tais pačiais žingsniais turėdamas daugiau laiko. Vis tiek pradėkite dabar: mokėtojai ir paslaugų teikėjai, su kuriais testuosite, pradeda veikti sausio 1 d.

Kas dar gali pasikeisti

CMS-0062-P. 2026 m. balandžio 14 d. CMS paskelbė siūlomą tolesnę taisyklę. Ji nuo 2027 m. spalio 1 d. padarytų privalomais šiuo metu rekomenduojamus įgyvendinimo vadovus, nuo tos pačios dienos įtrauktų vaistus į elektroninį išankstinį leidimą, o HHS vietoj X12 278 priimtų FHIR kaip HIPAA standartą išankstinio leidimo operacijoms. Dėl esamų terminų joje rašoma: „Šis pasiūlymas tų atitikties datų nepakeistų.“ Pastabų teikimas baigėsi 2026 m. birželio 15 d., o 2026 m. spalio 16 d. Federal Register galutinė taisyklė dar nepaskelbta. Kurkite pagal 2024 m. taisyklę, o vadovų versijas laikykite vienoje konfigūruojamoje vietoje.

Versijos. Da Vinci vadovai nuolat keičiasi. FY 2027 IPPS galutinėje taisyklėje pažymima, kad pagal naujus ONC išankstinio leidimo kriterijus sertifikuotoms EHR sistemoms „reikės naudoti Da Vinci IG 2.2 versiją“. Būtent su šiomis sistemomis kalbėsis jūsų Prior Authorization API.

Nė viena iš šių aplinkybių nėra priežastis laukti. Taisyklė galutinė, datos įrašytos reglamento tekste, o CMS jas pakartojo spalio 8 d.

Kur gauti pagalbos

Dirbame su sistemomis, esančiomis už API: išmokų, susitikimų ir leidimų duomenų susiejimu su FHIR, pakeitimų srautais iš senesnių išmokų ir UM platformų, sutikimo ir priskyrimo logika bei testais, rodančiais, kad vienos darbo dienos taisyklės laikomasi. Mūsų senųjų sistemų priežiūros paslauga yra tai, nuo ko pradedama, kai pagrindinė sistema sena arba ją sukūrę žmonės išėjo, o jei terminas sutampa su platformos keitimu, žr. ERP modernizavimą.

Jei jūsų išmokų ar UM platforma yra tokia, kuriai joks tiekėjas šių API nepristatys, rašykite adresu office@c9group.dev. Esame inžinieriai, ne sveikatos priežiūros teisės specialistai: taikymo srities ir sutarčių klausimai priklauso jūsų teisininkams, o mes kuriame pagal jų atsakymą.