CMS-0057-F och 1 januari 2027: API:er för betalare i egenutvecklade system för skadereglering och förhandsgodkännande

Senast 1 januari 2027 måste Medicare Advantage-organisationer och de delstatliga Medicaid- och CHIP-programmen med fee-for-service ha fyra FHIR-API:er i drift enligt CMS slutliga regel om interoperabilitet och förhandsgodkännande (CMS-0057-F): det befintliga Patient Access API, utökat med data om förhandsgodkännanden, samt de nya Provider Access, Payer-to-Payer och Prior Authorization API. Medicaid managed care-planer, CHIP managed care-enheter och utfärdare av Qualified Health Plans på de federala marknadsplatserna följer från sin första ratingperiod eller sitt första planår som börjar den dagen eller senare. Den 16 oktober 2026 är det elva veckor dit, och CMS har inte flyttat datumet.

Regelns operativa del gäller redan. Sedan 2026 måste berörda betalare ange ett specifikt skäl för varje nekat förhandsgodkännande, fatta beslut inom fasta tidsramar och publicera nyckeltal för förhandsgodkännanden.

Om dina system för skadereglering, utilization management och medlemmar kommer från en leverantör som levererar de här fyra API:erna, står leverantören för det mesta av bygget. Din del är konfiguration, digitaliserade regler för förhandsgodkännande, meddelanden till medlemmar och tester med partner.

Den här artikeln är för alla andra: planer och myndigheter vars skaderegleringsmotor, UM-flöde eller medlemsdata ligger i ett system de själva äger, oavsett om det är egenutvecklat, anpassat så långt att det inte längre går att uppgradera, eller ett Medicaid Management Information System (MMIS) med decennier av lokala ändringar. Ingen levererar API:erna för sådana system. Vi är ingenjörer, inte jurister: här förklarar vi vad regeln kräver att ett system gör, inte hur den gäller för dina avtal.

Datumen

Den slutliga regeln publicerades i Federal Register den 8 februari 2024 och trädde i kraft den 8 april 2024. För vart och ett av de fyra API:erna anger den samma datum för efterlevnad: ”senast 1 januari 2027 för MA-organisationer och delstatliga Medicaid- och CHIP-program med FFS; senast den ratingperiod som börjar 1 januari 2027 eller senare för Medicaid managed care-planer och CHIP managed care-enheter; och för planår som börjar 1 januari 2027 eller senare för QHP-utfärdare på FFE.”

En Medicaid managed care-plan vars ratingperioder börjar 1 juli har alltså fram till 1 juli 2027. En plan med kalenderårsavtal har det inte.

CMS anger fortfarande samma datum. På dess policysida för regeln, senast ändrad den 8 oktober 2026, står att ”berörda betalare har i huvudsak till 1 januari 2027 på sig att uppfylla kraven på API:er (application programming interface) i denna slutliga regel.”

Skyldigheterna från 2026 är enligt CMS faktablad beslut ”inom 72 timmar för brådskande ärenden och sju kalenderdagar för ordinarie (icke brådskande) ärenden” (QHP-utfärdare på marknadsplatserna omfattas inte av tidsramarna), ett specifikt skäl för varje avslag och offentliga nyckeltal, där ”den första uppsättningen nyckeltal ska rapporteras senast 31 mars 2026.” Användningen av Patient Access API rapporteras också till CMS varje år senast 31 mars. Om något av detta inte är i drift ännu är det redan sent, och det bygger på samma data som API:erna.

Läkemedel ligger helt utanför. Alla bestämmelser om förhandsgodkännande i CMS-0057-F undantar dem.

Vem som omfattas och vem som inte gör det

Regeln kallar dem berörda betalare (impacted payers): Medicare Advantage-organisationer (MA), delstatliga Medicaid- och CHIP-program med fee-for-service (FFS), Medicaid managed care-planer, CHIP managed care-enheter och QHP-utfärdare på Federally-facilitated Exchanges (FFE). Regelns konsekvensanalys räknar med ”365 moderorganisationer, inklusive delstatliga Medicaid- och CHIP-myndigheter,” som ”ansvarar för att införa och underhålla tre nya API:er,” och konstaterar att ”75 procent av betalarna i denna kategori har färre än 500 anställda.” Många är regionala planer utan något stort plattformsteam.

Utanför, åtminstone inte direkt:

• Arbetsgivarplaner utanför dessa program, och Original Medicare. De finns inte på listan över berörda betalare.
• Vårdgivare. Deras del är måttet Electronic Prior Authorization i Medicares Promoting Interoperability-program, som uppfylls med certifierad EHR-teknik. Den slutliga IPPS-regeln för FY 2027 från 4 augusti 2026 gjorde det till ett frivilligt bonusmått för sjukhus 2027.
• Delegerade UM-enheter och TPA:er. De har inga egna skyldigheter, men betalarens skyldigheter går genom deras system. För QHP-utfärdare upprepar regeln att de ”ansvarar för sin egen efterlevnad och för efterlevnaden hos alla delegerade enheter och underleverantörer.”

Det finns få vägar ut, och ingen hjälper mycket så här sent. En delstat kan begära en engångsförlängning på ett år för sitt Medicaid- eller CHIP-program med FFS, men begäran ska ingå i dess Advance Planning Document (APD) och måste vara ”godkänd före datumet för efterlevnad.” En delstat med minst 90 procent av sina Medicaid-förmånstagare i managed care kan begära undantag, och QHP-utfärdare kan be marknadsplatsen om ett undantag. Om planerna själva skrev CMS: ”Vi föreslog inga förlängningar eller undantag för MA-organisationer eller Medicaid managed care-planer.” Delstater kan också få 90 procent förhöjd federal medfinansiering för att bygga API:erna, godkänd från fall till fall via APD.

Vad varje API måste göra

Alla fyra hänger på en sak som ett specialutvecklat system ofta saknar: förhandsgodkännanden som strukturerad data med statushistorik. Bygg det en gång, så läser alla fyra därifrån.

Patient Access API: lägg till förhandsgodkännanden

Det här API:et har du haft i drift sedan 1 januari 2021 för skadeärenden, encounters och klinisk data. Från 2027 måste det också innehålla varje förhandsgodkännande för produkter och tjänster: status, datum för godkännande eller avslag, när det upphör, vilka produkter och tjänster som godkänts, ett specifikt skäl vid avslag och tillhörande strukturerad dokumentation från vårdgivaren. Datan ska finnas tillgänglig ”senast 1 arbetsdag efter” att betalaren tagit emot begäran, uppdateras inom en arbetsdag efter varje statusändring och sparas så länge godkännandet gäller och minst ett år efter den senaste ändringen.

Ett UM-system som registrerar beslut som fritextanteckningar, eller bara skickar status per fax, kan inte leverera detta utan ändringar.

Provider Access API

Vårdgivare i nätverket kan begära en patients data: skadeärenden och encounters utan ersättningsavräkningar till vårdgivare och utan patientens kostnadsandel, USCDI:s klasser av klinisk data samt information om förhandsgodkännanden, för vårdtillfällen från 1 januari 2016. Betalaren svarar inom en arbetsdag, men bara för patienter som den har knutit till den vårdgivaren och som inte har valt bort delningen.

Det kräver tre saker som ett äldre system sällan har. En attributionsprocess som kopplar medlemmar till vårdgivare. En möjlighet för medlemmen att välja bort delningen när som helst, med meddelanden på klarspråk före första användningen, inom en vecka från att försäkringsskyddet börjar och varje år. Och bulkexport, eftersom de obligatoriska standarderna omfattar FHIR Bulk Data Access för en vårdgivare som frågar om en hel patientlista.

Payer-to-Payer API

När en medlem ansluter ber den nya betalaren om tillstånd (här krävs aktivt samtycke) och börjar identifiera tidigare och samtidiga betalare inom en vecka från att försäkringsskyddet börjar. När den har dem begär den fem års data inom en vecka: skadeärenden och encounters utan ersättningsavräkningar och kostnadsandelar, USCDI-data och förhandsgodkännanden utom de nekade, med tillhörande ostrukturerad dokumentation. Den tidigare betalaren svarar inom en arbetsdag. Vid samtidigt försäkringsskydd upprepas utbytet minst en gång per kvartal.

Det svåra är inte det utgående svaret. Det är att ta emot data från betalare som du aldrig har testat mot och föra in den i din medlemsakt, som regeln kräver.

Prior Authorization API

Det här är API:et som når UM-kärnan. Det måste lista de produkter och tjänster som omfattas och kräver förhandsgodkännande, ange vilken dokumentation varje kräver, stödja en HIPAA-kompatibel begäran och ett svar, och tala om ifall betalaren godkänt (med slutdatum), nekat (med ett specifikt skäl) eller behöver mer information.

CMS rekommenderar, men kräver inte, tre implementeringsguider från Da Vinci här: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) och Prior Authorization Support (PAS). I praktiken måste dina regler för försäkringsskydd och dina dokumentationsformulär bli maskinläsbara, inte en policymanual i PDF. Betalarna i WEDI:s enkät placerade ”Digitizing prior authorization policies” bland sina tre största utmaningar.

För själva transaktionen gav HHS betalarna utrymme. Den 28 februari 2024 meddelade departementet att det avstår från tillsyn: enligt CMS kommer dess National Standards Group ”inte att vidta tillsynsåtgärder enligt HIPAA Administrative Simplification mot HIPAA-omfattade enheter som väljer att inte använda standarden X12 278 som en del av en elektronisk FHIR-process för förhandsgodkännande.” Du kan bygga enbart med FHIR eller med FHIR och X12, och behålla en transaktion med enbart X12 vid sidan av.

Standarderna

De obligatoriska standarderna är HL7 FHIR Release 4.0.1, US Core, SMART App Launch, Bulk Data Access och OpenID Connect Core; betalare får frivilligt använda nyare versioner, på vissa villkor. 2024 års regel angav US Core 3.1.1 och SMART App Launch 1.0.0 med ett utgångsdatum 1 januari 2026, så bestäm vilka versioner du bygger mot innan någon skriver mappningen.

Där egenutvecklade system brukar brista

Utifrån vad regeln kräver är det här luckorna att leta efter först:

• Förhandsgodkännandet som post, inte som dokument. Status, tidsstämplar, koder för avslagsskäl och slutdatum måste vara fält, skrivna när de ändras, med historik. Ett beslut som skickats per fax behöver en strukturerad motsvarighet.
• Reglerna för försäkringsskydd. Vilka tjänster som kräver godkännande, och vilken dokumentation var och en kräver, måste vara data som API:et kan leverera. I många planer finns det i policy-PDF:er och i handläggarnas huvuden.
• Skadeärenden som FHIR. Skadeärenden och encounters måste kunna tas ut som FHIR-resurser, med ersättningsavräkningar och kostnadsandelar borttagna för vårdgivare och andra betalare men kvar för medlemmen.
• Medlemmens identitet och historik. Att matcha en annan betalares data mot din medlem, och att hitta en ny medlems tidigare betalare, kräver demografiska uppgifter och försäkringshistorik som du kanske inte har på ett ställe.
• Samtyckesstatus. Ett bortval för Provider Access och ett aktivt samtycke för Payer-to-Payer, båda möjliga att ändra när som helst och kontrollerade vid varje förfrågan. En delstat måste dessutom föra vidare en förmånstagares samtycke till personens Medicaid managed care-planer.
• Klockan på en arbetsdag. En nattlig batchkörning på stordatorn duger för viss data och är för långsam för annan. Mät tiden från beslut till API, inte bara om API:et svarar.
• Delegerade leverantörer. Om en delegerad UM-leverantör fattar besluten måste dess data nå dig i tid för din skyldighet på en arbetsdag. WEDI:s enkät från februari 2026 placerade ”Delegated third parties facing challenges connecting with different systems” först bland betalarnas utmaningar.

Hur långt branschen har kommit

WEDI:s enkät från februari 2026, publicerad den 10 mars 2026, visade att när det gäller API-kraven har ”10 % ännu inte påbörjat arbetet”, mot 33 % i oktober 2025. Den rapporterade också ”en tydlig ökning av andelen med en uppskattad kostnad över 5 miljoner dollar, från 15 % (okt. 2025) till 25 % (feb. 2026).” Urvalet är litet: 86 svar, varav 52 % från betalare. Läs det som en signal, inte som en totalundersökning.

En plan på elva veckor fram till 1 januari 2027

Från mitten av oktober har en MA-organisation eller ett delstatligt FFS-program ungefär elva veckor. Det räcker inte för att bygga fyra API:er från grunden, så planen handlar om ordningsföljd och om vad du kan visa upp första dagen.

1. Den här veckan: bekräfta ditt datum och din utgångspunkt. 1 januari, eller en senare ratingperiod eller ett senare planår? Lista det som redan är i drift: Patient Access och Provider Directory API, nyckeltalen för 2026, avslagsskälen.
2. Vecka 1 till 2: koppla varje dataelement till sin källa. Skriv för varje API ner vilket system som har datan i dag (skadereglering, UM, inskrivning, vårdgivarnätverk, kliniskt) och hur aktuell den är.
3. Vecka 1 till 3: bestäm var FHIR-lagret ska ligga. En FHIR-server eller fasad framför de äldre systemen, matad med ändringshändelser eller täta extrakt, går oftast fortare än att lära kärnsystemet att tala FHIR. Det är mappningen och flödena som tar tid.
4. Vecka 2 till 7: bygg de gemensamma delarna först. Posten för förhandsgodkännanden, samtycke och attribution, medlemsmatchning. Alla fyra API:er är beroende av dem.
5. Vecka 4 till 9: bygg API:erna. Tilläggen i Patient Access, Provider Access med bulkexport, Payer-to-Payer i båda riktningarna och Prior Authorization API med dina regler för försäkringsskydd inlästa.
6. Vecka 8 till 11: testa med verkliga motparter. En vårdgivares EHR-leverantör, en annan betalare, din delegerade UM-leverantör. Testa ändrat samtycke, ett avslag med sitt skäl och en statusändring som når medlemmen inom en arbetsdag.
7. 1 januari 2027: driftsätt och mät. Följ latensen mot reglerna om en arbetsdag från första dagen, och för en daterad lista över det som inte är klart.

Om elva veckor inte räcker, ta upp det med din compliancefunktion och dina jurister nu, inte i december, med en plan som visar vad som är i drift 1 januari och vad som följer och när.

En Medicaid managed care-plan med ratingperiod från 1 juli 2027, eller en QHP-utfärdare med ett senare planår, kan följa samma steg med mer marginal. Börja ändå nu: de betalare och vårdgivare du ska testa med går i drift 1 januari.

Vad som fortfarande kan ändras

CMS-0062-P. Den 14 april 2026 publicerade CMS ett förslag till uppföljande regel. Det skulle göra de nu rekommenderade implementeringsguiderna obligatoriska från 1 oktober 2027, lägga till läkemedel i elektroniskt förhandsgodkännande från samma datum och låta HHS anta FHIR som HIPAA-standard för transaktioner om förhandsgodkännande i stället för X12 278. Om de befintliga tidsgränserna säger förslaget: ”Detta förslag skulle inte ändra dessa datum för efterlevnad.” Remisstiden gick ut den 15 juni 2026, och den 16 oktober 2026 har ingen slutlig regel publicerats i Federal Register. Bygg mot 2024 års regel, och håll versionerna av guiderna på ett enda konfigurerbart ställe.

Versioner. Da Vinci-guiderna utvecklas hela tiden. Den slutliga IPPS-regeln för FY 2027 konstaterar att EHR-system som certifierats mot ONC:s nya kriterier för förhandsgodkännande ”kommer att kräva version 2.2 av Da Vinci-guiderna.” Det är de systemen som ditt Prior Authorization API kommer att kommunicera med.

Inget av detta är ett skäl att vänta. Regeln är slutlig, datumen står i regeltexten och CMS upprepade dem den 8 oktober.

Var du får hjälp

Vi arbetar med systemen bakom API:erna: FHIR-mappning av data om skadeärenden, encounters och godkännanden, ändringsflöden ut ur äldre plattformar för skadereglering och UM, logik för samtycke och attribution, och de tester som visar att reglerna om en arbetsdag håller. Vår tjänst för underhåll av äldre system är där det börjar när kärnsystemet är gammalt eller de som byggde det har slutat, och om tidsgränsen hamnar mitt i ett plattformsbyte, se ERP-modernisering.

Om din plattform för skadereglering eller UM är en som ingen leverantör kommer att leverera de här API:erna för, skriv till office@c9group.dev. Vi är ingenjörer, inte jurister inom hälso- och sjukvård: frågor om tillämpningsområde och avtal hör hemma hos dina jurister, och vi bygger efter deras svar.