CMS-0057-F un 2027. gada 1. janvāris: maksātāju API pašu izstrādātās atlīdzību un iepriekšējo atļauju sistēmās

Līdz 2027. gada 1. janvārim Medicare Advantage organizācijām un štatu Medicaid un CHIP programmām ar apmaksu par pakalpojumu (fee-for-service) saskaņā ar CMS galīgo noteikumu par sadarbspēju un iepriekšējām atļaujām (CMS-0057-F) jādarbina četras FHIR API: esošā Patient Access API, kas paplašināta ar iepriekšējo atļauju datiem, un jaunās Provider Access, Payer-to-Payer un Prior Authorization API. Medicaid pārvaldītās aprūpes plāni, CHIP pārvaldītās aprūpes vienības un kvalificēto veselības plānu (QHP) izdevēji federālajās biržās tām seko no pirmā tarifu perioda vai plāna gada, kas sākas šajā datumā vai pēc tā. 2026. gada 16. oktobrī līdz tam ir atlikušas vienpadsmit nedēļas, un CMS šo termiņu nav pārcēlis.

Noteikuma operatīvā daļa jau ir spēkā. Kopš 2026. gada attiecīgajiem maksātājiem katram atteikumam iepriekšējas atļaujas pieprasījumā jānorāda konkrēts iemesls, lēmumi jāpieņem noteiktos termiņos un jāpublicē iepriekšējo atļauju rādītāji.

Ja jūsu atlīdzību, izmantošanas pārvaldības (UM) un dalībnieku sistēmas nāk no piegādātāja, kas piegādā šīs četras API, lielākā daļa izstrādes ir piegādātāja ziņā. Jūsu daļa ir konfigurācija, digitalizēti iepriekšējo atļauju noteikumi, paziņojumi dalībniekiem un testēšana ar partneriem.

Šis raksts ir pārējiem: plāniem un aģentūrām, kuru atlīdzību dzinējs, UM darbplūsma vai dalībnieku dati atrodas pašu sistēmā, vai tā būtu izstrādāta uz vietas, pielāgota tiktāl, ka vairs nav atjaunināma, vai Medicaid pārvaldības informācijas sistēma (MMIS) ar gadu desmitiem uzkrātām vietējām izmaiņām. Šādām sistēmām API neviens nepiegādā. Mēs esam inženieri, nevis juristi: šeit paskaidrots, ko noteikums prasa no sistēmas, nevis kā tas attiecas uz jūsu līgumiem.

Termiņi

Galīgais noteikums tika publicēts Federal Register 2024. gada 8. februārī un stājās spēkā 2024. gada 8. aprīlī. Katrai no četrām API tas nosaka vienus un tos pašus atbilstības termiņus: „līdz 2027. gada 1. janvārim MA organizācijām un štatu Medicaid un CHIP FFS programmām; līdz tarifu periodam, kas sākas 2027. gada 1. janvārī vai vēlāk, Medicaid pārvaldītās aprūpes plāniem un CHIP pārvaldītās aprūpes vienībām; un plāna gadiem, kas sākas 2027. gada 1. janvārī vai vēlāk, QHP izdevējiem FFE.“

Tātad Medicaid pārvaldītās aprūpes plānam, kura tarifu periodi sākas 1. jūlijā, laiks ir līdz 2027. gada 1. jūlijam. Plānam ar kalendārā gada līgumu tāda laika nav.

CMS joprojām min to pašu datumu. Tā noteikuma politikas lapā, kas pēdējo reizi mainīta 2026. gada 8. oktobrī, teikts, ka „attiecīgajiem maksātājiem lietojumprogrammu saskarnes (API) prasības šajā galīgajā noteikumā galvenokārt jāizpilda līdz 2027. gada 1. janvārim“.

2026. gada pienākumi, kā tos formulē CMS faktu lapa, ir lēmumi „72 stundu laikā paātrinātiem (t. i., steidzamiem) pieprasījumiem un septiņu kalendāro dienu laikā standarta (t. i., nesteidzamiem) pieprasījumiem“ (uz QHP izdevējiem biržās termiņi neattiecas), konkrēts iemesls katram atteikumam un publiski rādītāji, no kuriem „sākotnējais rādītāju kopums jāpaziņo līdz 2026. gada 31. martam“. Arī par Patient Access API izmantošanu CMS jāziņo katru gadu līdz 31. martam. Ja kaut kas no tā vēl nedarbojas, tas jau kavējas, un tas izmanto tos pašus datus, ko API.

Zāles nav iekļautas nevienā no šīm prasībām. Visi CMS-0057-F noteikumi par iepriekšējām atļaujām tās izslēdz.

Uz ko tas attiecas un uz ko ne

Noteikums tos sauc par attiecīgajiem maksātājiem: Medicare Advantage (MA) organizācijas, štatu Medicaid un CHIP programmas ar apmaksu par pakalpojumu (FFS), Medicaid pārvaldītās aprūpes plāni, CHIP pārvaldītās aprūpes vienības un QHP izdevēji federāli atbalstītajās biržās (FFE). Tā ietekmes analīzē uzskaitītas „365 mātesorganizācijas, tostarp štatu Medicaid un CHIP aģentūras“, kuras „ir atbildīgas par trīs jaunu API ieviešanu un uzturēšanu“, un norādīts, ka „75 procentiem šīs kategorijas maksātāju ir mazāk nekā 500 darbinieku“. Daudzi ir reģionāli plāni bez lielas platformas komandas.

Neattiecas, vismaz ne tieši:

• Darba devēju plāni ārpus šīm programmām un Original Medicare. Tie nav attiecīgo maksātāju sarakstā.
• Pakalpojumu sniedzēji. Viņu puse ir elektroniskās iepriekšējās atļaujas rādītājs Medicare programmās Promoting Interoperability, ko izpilda ar sertificētu EHR tehnoloģiju. FY 2027 IPPS galīgais noteikums, kas pieņemts 2026. gada 4. augustā, slimnīcām 2027. gadā to padarīja par brīvprātīgu bonusa rādītāju.
• Deleģētās UM vienības un trešās puses administratori (TPA). Tām nav savu pienākumu, taču maksātāja pienākumi tiek izpildīti caur to sistēmām. Attiecībā uz QHP izdevējiem noteikums atkārto, ka tie „ir atbildīgi par savu atbilstību un par jebkuru deleģēto vai pakārtoto vienību atbilstību“.

Izeju ir maz, un tik vēlu neviena īpaši nepalīdz. Štats var lūgt vienreizēju pagarinājumu uz vienu gadu savai Medicaid vai CHIP FFS programmai, taču pieprasījums jāiekļauj tā iepriekšējās plānošanas dokumentā (APD), un tam jābūt „apstiprinātam pirms atbilstības termiņa“. Štats, kurā vismaz 90 procenti Medicaid saņēmēju ir pārvaldītajā aprūpē, var lūgt atbrīvojumu, un QHP izdevēji var lūgt biržai izņēmumu. Par pašiem plāniem CMS rakstīja: „Mēs neierosinājām pagarinājumus vai atbrīvojumus MA organizācijām vai Medicaid pārvaldītās aprūpes plāniem.“ Štati var arī pieprasīt 90 procentu paaugstinātu federālo līdzfinansējumu API izstrādei, ko apstiprina katrā gadījumā atsevišķi, izmantojot APD.

Kas jādara katrai API

Visas četras ir atkarīgas no vienas lietas, kuras pielāgotā sistēmā bieži trūkst: iepriekšējās atļaujas kā strukturētiem datiem ar statusu vēsturi. Izveidojiet to vienreiz, un visas četras lasīs no tā.

Patient Access API: iepriekšējo atļauju pievienošana

Šo API jūs darbināt kopš 2021. gada 1. janvāra atlīdzībām, apmeklējumiem un klīniskajiem datiem. No 2027. gada tajā jābūt arī katrai iepriekšējai atļaujai precēm un pakalpojumiem: tās statusam, datumam, kad tā apstiprināta vai atteikta, beigu datumam, apstiprinātajām precēm un pakalpojumiem, konkrētam iemeslam atteikuma gadījumā un saistītajai strukturētajai pakalpojumu sniedzēja dokumentācijai. Datiem jābūt pieejamiem „ne vēlāk kā 1 darba dienu pēc“ tam, kad maksātājs saņēmis pieprasījumu, jāatjaunina vienas darba dienas laikā pēc jebkuras statusa maiņas un jāglabā, kamēr atļauja ir aktīva, un vismaz gadu pēc tās pēdējās izmaiņas.

UM sistēma, kas lēmumus reģistrē kā brīva teksta piezīmes vai statusu sūta tikai pa faksu, to bez izmaiņām nevar nodrošināt.

Provider Access API

Tīkla pakalpojumu sniedzēji var pieprasīt pacienta datus: atlīdzības un apmeklējumus bez maksājumu paziņojumiem pakalpojumu sniedzējiem un bez pacienta līdzmaksājumiem, USCDI klīnisko datu klases un iepriekšējo atļauju informāciju par pakalpojumu datumiem, sākot no 2016. gada 1. janvāra. Maksātājs atbild vienas darba dienas laikā, bet tikai par pacientiem, kurus tas piesaistījis attiecīgajam pakalpojumu sniedzējam un kuri nav atteikušies.

Tam vajadzīgas trīs lietas, kuru mantotajā sistēmā reti ir. Piesaistes process, kas sasaista dalībniekus ar pakalpojumu sniedzējiem. Atteikšanās iespēja, ko dalībnieks var mainīt jebkurā laikā, ar vienkāršā valodā rakstītiem paziņojumiem pirms pirmās izmantošanas, nedēļas laikā pēc seguma sākuma un katru gadu. Un masveida eksports, jo prasītie standarti ietver FHIR Bulk Data Access gadījumam, kad pakalpojumu sniedzējs vaicā par visu savu pacientu sarakstu.

Payer-to-Payer API

Kad dalībnieks pievienojas, jaunais maksātājs lūdz atļauju (šeit nepieciešama aktīva piekrišana) un nedēļas laikā pēc seguma sākuma sāk noskaidrot iepriekšējos un vienlaicīgos maksātājus. Kad tie ir zināmi, tas nedēļas laikā pieprasa piecu gadu datus: atlīdzības un apmeklējumus bez maksājumu paziņojumiem un līdzmaksājumiem, USCDI datus un iepriekšējās atļaujas, izņemot atteiktās, kopā ar to nestrukturēto dokumentāciju. Iepriekšējais maksātājs atbild vienas darba dienas laikā. Ja segums ir vienlaicīgs, apmaiņu atkārto vismaz reizi ceturksnī.

Grūtākais nav izejošā atbilde. Grūtākais ir pieņemt datus no maksātājiem, ar kuriem nekad neesat testējuši, un iekļaut tos dalībnieka ierakstā, kā to prasa noteikums.

Prior Authorization API

Šī ir tā, kas skar UM kodolu. API jāuzskaita apdrošinātās preces un pakalpojumi, kuriem vajadzīga iepriekšēja atļauja, jānorāda katram nepieciešamā dokumentācija, jāatbalsta HIPAA prasībām atbilstošs pieprasījums un atbilde un jāpasaka, vai maksātājs ir apstiprinājis (ar beigu datumu), atteicis (ar konkrētu iemeslu) vai viņam vajadzīga papildu informācija.

CMS šeit iesaka, bet neprasa, trīs Da Vinci ieviešanas vadlīnijas: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) un Prior Authorization Support (PAS). Praksē jūsu seguma noteikumiem un dokumentācijas anketām jākļūst mašīnlasāmām, nevis jāpaliek PDF politikas rokasgrāmatā. WEDI aptaujā maksātāji „iepriekšējo atļauju politiku digitalizāciju“ ierindoja starp trim lielākajiem izaicinājumiem.

Attiecībā uz pašu darījumu HHS maksātājiem deva rīcības brīvību. 2024. gada 28. februārī tas paziņoja par izpildes diskrecionāro pieeju: saskaņā ar CMS teikto tā National Standards Group „neveiks HIPAA administratīvās vienkāršošanas izpildes darbības pret HIPAA aptvertajām vienībām, kuras izvēlas neizmantot X12 278 standartu elektroniskā FHIR iepriekšējās atļaujas procesā“. Varat veidot tikai FHIR vai FHIR kopā ar X12 un līdzās saglabāt darījumu tikai ar X12.

Standarti

Prasītie standarti ir HL7 FHIR Release 4.0.1, US Core, SMART App Launch, Bulk Data Access un OpenID Connect Core; maksātāji noteiktos apstākļos brīvprātīgi drīkst izmantot jaunākas versijas. 2024. gada noteikumā US Core 3.1.1 un SMART App Launch 1.0.0 bija norādītas ar derīguma beigu datumu 2026. gada 1. janvārī, tāpēc vienojieties, kurām versijām veidojat, pirms kāds sāk rakstīt kartēšanu.

Kur pašu sistēmām parasti ir trūkumi

Spriežot pēc tā, ko prasa noteikums, šie ir trūkumi, kurus meklēt vispirms:

• Iepriekšēja atļauja kā ieraksts, nevis dokuments. Statusam, laika zīmogiem, atteikuma iemeslu kodiem un beigu datumam jābūt laukiem, kurus ieraksta brīdī, kad tie mainās, kopā ar vēsturi. Pa faksu nosūtītam lēmumam vajadzīgs strukturēts dvīnis.
• Seguma noteikumi. Kuriem pakalpojumiem vajadzīga atļauja un kāda dokumentācija vajadzīga katram, jābūt datiem, ko API var izsniegt. Daudzos plānos tas glabājas politikas PDF failos un vērtētāju galvās.
• Atlīdzības kā FHIR. Atlīdzībām un apmeklējumiem jāiznāk kā FHIR resursiem, pakalpojumu sniedzējiem un citiem maksātājiem bez maksājumu paziņojumiem un līdzmaksājumiem, bet dalībniekam ar tiem.
• Dalībnieka identitāte un vēsture. Lai sasaistītu cita maksātāja datus ar jūsu dalībnieku un atrastu jauna dalībnieka iepriekšējos maksātājus, vajag demogrāfiskos datus un seguma vēsturi, ko jūs, iespējams, neglabājat vienuviet.
• Piekrišanas stāvoklis. Atteikšanās Provider Access gadījumā un aktīva piekrišana Payer-to-Payer gadījumā, katra maināma jebkurā laikā un pārbaudāma katrā pieprasījumā. Štatam saņēmēja piekrišana jānodod arī šīs personas Medicaid pārvaldītās aprūpes plāniem.
• Vienas darba dienas pulkstenis. Nakts lieldatora pakešapstrāde dažiem datiem der, bet citiem ir par lēnu. Mēriet laiku no lēmuma līdz API, nevis tikai to, vai API atbild.
• Deleģētie piegādātāji. Ja lēmumus pieņem deleģēts UM piegādātājs, tā datiem jānonāk pie jums laikus, lai izpildītu jūsu vienas darba dienas pienākumu. WEDI 2026. gada februāra aptaujā maksātāju izaicinājumu sarakstā pirmajā vietā bija „deleģētās trešās puses, kurām ir grūtības savienoties ar dažādām sistēmām“.

Cik tālu ir nozare

WEDI 2026. gada februāra aptauja, publicēta 2026. gada 10. martā, konstatēja, ka attiecībā uz API prasībām „10 % vēl nav sākuši darbu“, salīdzinot ar 33 % 2025. gada oktobrī. Tā arī ziņoja par „ievērojamu pieaugumu to respondentu daļai, kuri lēš izmaksas virs 5 miljoniem USD: no 15 % (2025. gada okt.) līdz 25 % (2026. gada febr.)“. Izlase ir maza: 86 atbildes, no tām 52 % no maksātājiem. Uztveriet to kā signālu, nevis visaptverošu uzskaiti.

Vienpadsmit nedēļu plāns līdz 2027. gada 1. janvārim

No oktobra vidus MA organizācijai vai štata FFS programmai ir apmēram vienpadsmit nedēļas. Ar to nepietiek, lai no nulles izveidotu četras API, tāpēc plāns ir par secību un par to, ko varat parādīt pirmajā dienā.

1. Šonedēļ: pārliecinieties par savu termiņu un sākumpunktu. 1. janvāris vai vēlāks tarifu periods vai plāna gads? Uzskaitiet, kas jau darbojas: Patient Access un Provider Directory API, 2026. gada rādītāji, atteikumu iemesli.
2. 1. līdz 2. nedēļa: sasaistiet katru datu elementu ar tā avotu. Katrai API pierakstiet, kura sistēma šos datus glabā šodien (atlīdzības, UM, reģistrācija, pakalpojumu sniedzēju tīkls, klīniskie dati) un cik svaigi tie ir.
3. 1. līdz 3. nedēļa: izlemiet, kur atradīsies FHIR slānis. FHIR serveris vai fasāde mantoto sistēmu priekšā, ko baro izmaiņu notikumi vai bieži izraksti, parasti ir ātrāks ceļš nekā iemācīt kodola sistēmai runāt FHIR. Laiks aiziet kartēšanai un datu plūsmām.
4. 2. līdz 7. nedēļa: vispirms izveidojiet kopīgās daļas. Iepriekšējās atļaujas ierakstu, piekrišanu un piesaisti, dalībnieku sasaisti. No tām ir atkarīgas visas četras API.
5. 4. līdz 9. nedēļa: izveidojiet API. Patient Access papildinājumus, Provider Access ar masveida eksportu, Payer-to-Payer abos virzienos un Prior Authorization API ar ielādētiem seguma noteikumiem.
6. 8. līdz 11. nedēļa: testējiet ar reāliem partneriem. Pakalpojumu sniedzēja EHR piegādātāju, citu maksātāju, jūsu deleģēto UM piegādātāju. Testējiet piekrišanas izmaiņas, atteikumu ar tā iemeslu un statusa maiņu, kas sasniedz dalībnieku vienas darba dienas laikā.
7. 2027. gada 1. janvāris: palaidiet un mēriet. No pirmās dienas sekojiet aizkavei attiecībā pret vienas darba dienas noteikumiem un uzturiet datētu sarakstu ar to, kas vēl nav pabeigts.

Ja ar vienpadsmit nedēļām nepietiek, vērsieties pie atbilstības komandas un juristiem tagad, nevis decembrī, ar plānu, kas parāda, kas darbosies 1. janvārī un kas sekos un kad.

Medicaid pārvaldītās aprūpes plāns ar tarifu periodu no 2027. gada 1. jūlija vai QHP izdevējs ar vēlāku plāna gadu var sekot tiem pašiem soļiem ar lielāku laika rezervi. Tomēr sāciet tagad: maksātāji un pakalpojumu sniedzēji, ar kuriem testēsiet, sāk darbu 1. janvārī.

Kas vēl var mainīties

CMS-0062-P. 2026. gada 14. aprīlī CMS publicēja ierosinātu turpinājuma noteikumu. Tas padarītu pašlaik ieteiktās ieviešanas vadlīnijas obligātas no 2027. gada 1. oktobra, no tā paša datuma iekļautu zāles elektroniskajās iepriekšējās atļaujās un paredzētu, ka HHS pieņem FHIR kā HIPAA standartu iepriekšējo atļauju darījumiem X12 278 vietā. Par esošajiem termiņiem tajā teikts: „Šis priekšlikums šos atbilstības termiņus nemainītu.“ Komentāru pieņemšana beidzās 2026. gada 15. jūnijā, un 2026. gada 16. oktobrī Federal Register galīgais noteikums nav parādījies. Veidojiet atbilstoši 2024. gada noteikumam un glabājiet vadlīniju versijas vienā konfigurējamā vietā.

Versijas. Da Vinci vadlīnijas turpina mainīties. FY 2027 IPPS galīgajā noteikumā norādīts, ka EHR, kas sertificētas atbilstoši jaunajiem ONC iepriekšējo atļauju kritērijiem, „prasīs Da Vinci IG versijas 2.2 izmantošanu“. Tieši ar šīm sistēmām sazināsies jūsu Prior Authorization API.

Nekas no tā nav iemesls gaidīt. Noteikums ir galīgs, termiņi ir regulējuma tekstā, un CMS tos atkārtoja 8. oktobrī.

Kur saņemt palīdzību

Mēs strādājam ar sistēmām, kas atrodas aiz API: atlīdzību, apmeklējumu un atļauju datu FHIR kartēšana, izmaiņu plūsmas no vecākām atlīdzību un UM platformām, piekrišanas un piesaistes loģika un testi, kas pierāda, ka vienas darba dienas noteikumi tiek ievēroti. Ja kodola sistēma ir veca vai tās veidotāji ir aizgājuši, darbs sākas ar mūsu mantoto sistēmu uzturēšanas pakalpojumu, un, ja termiņš iekrīt platformas nomaiņas vidū, skatiet ERP modernizāciju.

Ja jūsu atlīdzību vai UM platformai neviens piegādātājs šīs API nepiegādās, rakstiet uz office@c9group.dev. Mēs esam inženieri, nevis veselības aprūpes juristi: tvēruma un līgumu jautājumi ir jūsu juristu ziņā, un mēs strādājam pēc viņu atbildes.