CMS-0057-F fra 1. januar 2027: payer-API'er til egne afregnings- og forhåndsgodkendelsessystemer

Senest 1. januar 2027 skal Medicare Advantage-organisationer (de private Medicare-planer) og delstaternes fee for service-programmer under Medicaid og CHIP (sygeforsikringsprogrammet for børn) have fire FHIR-API'er i drift efter CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F): den eksisterende Patient Access API, udvidet med data om forhåndsgodkendelser (prior authorization), og de nye API'er Provider Access, Payer-to-Payer og Prior Authorization. Medicaid managed care-planer, CHIP managed care-enheder og udstedere af Qualified Health Plans (QHP) på de føderale markedspladser følger fra deres første rating period (takstperiode) eller plan year (planår), der begynder på eller efter den dato. Pr. 16. oktober 2026 er der elleve uger til, og CMS har ikke flyttet datoen.

Den operationelle del af reglen gælder allerede. Siden 2026 har de omfattede betalere skullet give en konkret begrundelse for hvert afslag på en forhåndsgodkendelse, træffe afgørelse inden for faste frister og offentliggøre nøgletal for forhåndsgodkendelser.

Kommer jeres systemer til afregning, utilization management (UM, vurdering og styring af forbruget af ydelser) og medlemmer fra en leverandør, der leverer de fire API'er, er det meste af udviklingen leverandørens opgave. Jeres del er konfiguration, digitaliserede regler for forhåndsgodkendelse, meddelelser til medlemmer og test med partnere.

Denne artikel er til resten: planer og myndigheder, hvis afregningsmotor, UM-workflow eller medlemsdata ligger i et system, de selv ejer, uanset om det er egenudviklet, tilpasset så meget, at det ikke længere kan opgraderes, eller et Medicaid Management Information System (MMIS) med årtiers lokale ændringer. Ingen leverer API'erne til den slags. Vi er ingeniører, ikke jurister: artiklen forklarer, hvad reglen kræver af et system, ikke hvordan den gælder for jeres kontrakter.

Datoerne

Den endelige regel blev offentliggjort i Federal Register den 8. februar 2024 (den amerikanske forbundsregerings lovtidende) og trådte i kraft den 8. april 2024. For hver af de fire API'er fastsætter den de samme frister: »senest 1. januar 2027 for MA-organisationer og delstaternes FFS-programmer under Medicaid og CHIP; senest den rating period, der begynder på eller efter 1. januar 2027, for Medicaid managed care-planer og CHIP managed care-enheder; og for plan years, der begynder på eller efter 1. januar 2027, for QHP-udstedere på FFE'erne«.

En Medicaid managed care-plan, hvis rating periods begynder 1. juli, har altså frist 1. juli 2027. En plan med en kontrakt, der følger kalenderåret, har ikke.

CMS angiver stadig samme dato. På CMS' side om reglen, senest ændret 8. oktober 2026, står der, at »omfattede betalere primært har frist til 1. januar 2027 til at opfylde kravene til application programming interfaces (API'er) i denne endelige regel«.

Ifølge CMS' faktaark består forpligtelserne for 2026 af afgørelser »inden for 72 timer for fremskyndede (dvs. hastende) anmodninger og syv kalenderdage for almindelige (dvs. ikke-hastende) anmodninger« (QHP-udstedere på markedspladserne er undtaget fra fristerne), en konkret begrundelse for hvert afslag og offentlige nøgletal, hvor »det første sæt nøgletal skal indberettes senest 31. marts 2026«. Brugen af Patient Access API indberettes også til CMS hvert år senest 31. marts. Kører noget af dette ikke endnu, er det allerede forsinket, og det trækker på de samme data som API'erne.

Lægemidler falder helt uden for. Alle bestemmelser om forhåndsgodkendelse i CMS-0057-F undtager dem.

Hvem er omfattet, og hvem er ikke

Reglen kalder dem omfattede betalere (impacted payers): Medicare Advantage-organisationer (MA), delstaternes fee for service-programmer (FFS) under Medicaid og CHIP, Medicaid managed care-planer, CHIP managed care-enheder og QHP-udstedere på Federally-facilitated Exchanges (FFE'er, de føderalt drevne markedspladser for sygeforsikring). Konsekvensanalysen tæller »365 moderorganisationer, herunder delstaternes Medicaid- og CHIP-myndigheder«, som »er ansvarlige for at implementere og vedligeholde tre nye API'er«, og bemærker, at »75 procent af betalerne i denne kategori har under 500 ansatte«. Mange er regionale planer uden et stort platformteam.

Ikke omfattet, i hvert fald ikke direkte:

• Arbejdsgiverplaner uden for disse programmer samt Original Medicare (den traditionelle, offentligt administrerede Medicare). De står ikke på listen over omfattede betalere.
• Behandlere. Deres side er Electronic Prior Authorization-målet i Medicares Promoting Interoperability-programmer, som opfyldes med certificeret EHR-teknologi. Den endelige IPPS-regel for regnskabsåret 2027 fra 4. august 2026 (IPPS er Medicares afregningssystem for indlæggelser) gjorde det til et valgfrit bonusmål for hospitaler i 2027.
• Delegerede UM-aktører og TPA'er (third party administrators, eksterne administratorer). De har ingen selvstændig forpligtelse, men betalerens forpligtelse løber gennem deres systemer. For QHP-udstedere gentager reglen, at de »er ansvarlige for deres egen compliance og for compliance hos alle delegerede eller underliggende enheder«.

Der er få veje ud, og ingen af dem hjælper meget så sent. En delstat kan søge om en engangsforlængelse på ét år for sit Medicaid- eller CHIP-FFS-program, men anmodningen skal stå i dens Advance Planning Document (APD, den projekt- og finansieringsplan, delstaten indsender til CMS) og skal være »godkendt før skæringsdatoen«. En delstat med mindst 90 procent af sine Medicaid-modtagere i managed care kan søge om fritagelse, og QHP-udstedere kan bede markedspladsen om en undtagelse. Om selve planerne skrev CMS: »Vi foreslog ikke forlængelser eller fritagelser for MA-organisationer eller Medicaid managed care-planer.« Delstaterne kan desuden få 90 procent forhøjet føderal medfinansiering til at bygge API'erne, godkendt fra sag til sag gennem APD'et.

Hvad hver API skal kunne

Alle fire afhænger af én ting, som et specialudviklet system ofte mangler: forhåndsgodkendelser som strukturerede data med statushistorik. Byg det én gang, så læser alle fire derfra.

Patient Access API: tilføj forhåndsgodkendelser

Den API har I kørt siden 1. januar 2021 for afregninger, encounters og kliniske data. Fra 2027 skal den også indeholde hver forhåndsgodkendelse af varer og ydelser: dens status, datoen for godkendelse eller afslag, hvornår den udløber, de godkendte varer og ydelser, en konkret begrundelse ved afslag og tilhørende struktureret dokumentation fra behandleren. Dataene skal være tilgængelige »senest 1 arbejdsdag efter«, at betaleren modtager anmodningen, opdateres inden for én arbejdsdag efter enhver statusændring og opbevares, så længe godkendelsen er aktiv, og i mindst et år efter dens seneste ændring.

Et UM-system, der registrerer afgørelser som fritekstnoter eller kun sender status pr. fax, kan ikke levere de data uden ændringer.

Provider Access API

Behandlere i betalerens netværk kan anmode om en patients data: afregninger og encounters uden afregningsspecifikationer til behandlere og uden egenbetaling, de kliniske dataklasser i USCDI (det amerikanske kernedatasæt for udveksling af kliniske data) og oplysninger om forhåndsgodkendelser, for ydelser leveret fra 1. januar 2016. Betaleren svarer inden for én arbejdsdag, men kun for patienter, den har knyttet til den pågældende behandler, og som ikke har fravalgt deling (opt-out).

Det kræver tre ting, som et ældre system sjældent har. En tilknytningsproces (attribution), der kobler medlemmer til behandlere. Et fravalg, som medlemmet kan ændre når som helst, med meddelelser i et klart sprog før første brug, inden for en uge efter dækningens start og hvert år. Og bulkeksport, fordi de krævede standarder omfatter FHIR Bulk Data Access til en behandler, der spørger til hele sin patientliste.

Payer-to-Payer API

Når et medlem kommer til, beder den nye betaler om tilladelse (her gælder tilvalg, opt-in) og begynder inden for en uge efter dækningens start at finde tidligere og samtidige betalere. Når den har dem, anmoder den inden for en uge om fem års data: afregninger og encounters uden afregningsspecifikationer eller egenbetaling, USCDI-data og forhåndsgodkendelser bortset fra afslag, med deres ustrukturerede dokumentation. Den tidligere betaler svarer inden for én arbejdsdag. Ved samtidig dækning gentages udvekslingen mindst hvert kvartal.

Det svære er ikke det udgående svar. Det er at tage imod data fra betalere, I aldrig har testet med, og indarbejde dem i jeres medlemsjournal, som reglen kræver.

Prior Authorization API

Det er den, der når ind i UM-kernen. API'en skal vise de dækkede varer og ydelser, der kræver forhåndsgodkendelse, angive den dokumentation, der kræves for hver, understøtte en HIPAA-kompatibel anmodning og et HIPAA-kompatibelt svar og oplyse, om betaleren har godkendt (med slutdato), givet afslag (med en konkret begrundelse) eller har brug for flere oplysninger.

CMS anbefaler, men kræver ikke, tre Da Vinci-implementeringsguider her: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) og Prior Authorization Support (PAS). I praksis skal jeres dækningsregler og dokumentationsspørgeskemaer være maskinlæsbare og ikke en politikhåndbog i PDF. Betalere i WEDI's undersøgelse (WEDI er en amerikansk brancheorganisation for elektronisk dataudveksling i sundhedssektoren) placerede »digitalisering af politikker for forhåndsgodkendelse« blandt deres tre største udfordringer.

Med hensyn til selve transaktionen gav HHS (det amerikanske sundhedsministerium) betalerne spillerum. Den 28. februar 2024 meddelte ministeriet, at det ville undlade håndhævelse (enforcement discretion): ifølge CMS vil agenturets National Standards Group »ikke foretage håndhævelse efter HIPAA Administrative Simplification over for HIPAA-omfattede enheder, der vælger ikke at bruge X12 278-standarden som led i en elektronisk FHIR-proces for forhåndsgodkendelse«. I kan bygge kun med FHIR eller med FHIR og X12 og beholde en ren X12-transaktion ved siden af.

Standarderne

De krævede standarder er HL7 FHIR Release 4.0.1, US Core, SMART App Launch, Bulk Data Access og OpenID Connect Core; betalere må frivilligt bruge nyere versioner på visse betingelser. 2024-reglen angav US Core 3.1.1 og SMART App Launch 1.0.0 med udløbsdato 1. januar 2026, så afklar, hvilke versioner I bygger efter, før nogen skriver mappingen.

Hvor egenudviklede systemer typisk kommer til kort

Ud fra det, reglen kræver, er det disse huller, I bør lede efter først:

• Forhåndsgodkendelse som en post, ikke et dokument. Status, tidsstempler, koder for afslagsgrunde og slutdatoen skal være felter, der skrives, når de ændres, med historik. En afgørelse sendt pr. fax skal have en struktureret tvilling.
• Dækningsreglerne. Hvilke ydelser der kræver godkendelse, og hvilken dokumentation hver af dem kræver, skal være data, som API'en kan levere. Hos mange planer ligger det i PDF-politikker og i sagsbehandlernes hoveder.
• Afregninger som FHIR. Afregninger og encounters skal komme ud som FHIR-ressourcer, uden afregningsspecifikationer og egenbetaling for behandlere og andre betalere, men med dem for medlemmet.
• Medlemmets identitet og historik. At matche en anden betalers data med jeres medlem og finde et nyt medlems tidligere betalere kræver demografiske data og dækningshistorik, som I måske ikke har samlet ét sted.
• Samtykkestatus. Et fravalg for Provider Access og et tilvalg for Payer-to-Payer, som hver især kan ændres når som helst og kontrolleres ved hver anmodning. En delstat skal også give en modtagers tilvalg videre til vedkommendes Medicaid managed care-planer.
• Uret på én arbejdsdag. En natlig mainframe-batch er fin til nogle data og for langsom til andre. Mål tiden fra afgørelse til API, ikke kun om API'en svarer.
• Delegerede leverandører. Hvis en delegeret UM-leverandør træffer afgørelserne, skal dens data nå frem til jer i tide til jeres forpligtelse på én arbejdsdag. WEDI's undersøgelse fra februar 2026 placerede »delegerede tredjeparter, der har udfordringer med at forbinde sig til forskellige systemer« øverst blandt betalernes udfordringer.

Hvor langt branchen er

WEDI's undersøgelse fra februar 2026, offentliggjort 10. marts 2026, viste for API-kravene, at »10 % endnu ikke er gået i gang med arbejdet«, mod 33 % i oktober 2025. Den rapporterede også »en markant stigning i en anslået omkostning på over 5 millioner dollar fra 15 % (okt. ’25) til 25 % (feb. ’26)«. Stikprøven er lille: 86 svar, heraf 52 % fra betalere. Læs den som et signal, ikke som en totaltælling.

En plan på elleve uger frem til 1. januar 2027

Fra midten af oktober har en MA-organisation eller et FFS-program i en delstat omkring elleve uger. Det er ikke nok til at bygge fire API'er fra bunden, så planen handler om rækkefølge og om, hvad I kan vise på dag ét.

1. Denne uge: bekræft jeres dato og jeres udgangspunkt. 1. januar eller en senere rating period eller et senere plan year? Skriv ned, hvad der allerede kører: Patient Access API og Provider Directory API, nøgletallene for 2026, afslagsgrundene.
2. Uge 1 til 2: knyt hvert dataelement til sin kilde. Skriv for hver API ned, hvilket system der har dataene i dag (afregning, UM, tilmelding, behandlernetværk, kliniske data), og hvor friske de er.
3. Uge 1 til 3: beslut, hvor FHIR-laget skal ligge. En FHIR-server eller -facade foran de ældre systemer, forsynet af ændringshændelser eller hyppige udtræk, er som regel hurtigere end at lære kernesystemet at tale FHIR. Det er mappingen og dataleverancerne, der tager tiden.
4. Uge 2 til 7: byg de fælles dele først. Posten for forhåndsgodkendelse, samtykke og tilknytning, matchning af medlemmer. Alle fire API'er afhænger af dem.
5. Uge 4 til 9: byg API'erne. Tilføjelserne til Patient Access, Provider Access med bulkeksport, Payer-to-Payer i begge retninger og Prior Authorization API med jeres dækningsregler indlæst.
6. Uge 8 til 11: test med rigtige modparter. En behandlers EHR-leverandør, en anden betaler, jeres delegerede UM-leverandør. Test ændringer i samtykke, et afslag med begrundelse og en statusændring, der når medlemmet inden for én arbejdsdag.
7. 1. januar 2027: gå i drift og mål. Følg svartiden op mod reglerne om én arbejdsdag fra dag ét, og før en dateret liste over det, der ikke er færdigt.

Er elleve uger ikke nok, så tag det op med jeres compliance-team og jeres juridiske rådgivere nu, ikke i december, med en plan, der viser, hvad der kører 1. januar, og hvad der følger hvornår.

En Medicaid managed care-plan med en rating period fra 1. juli 2027 eller en QHP-udsteder med et senere plan year kan følge de samme trin med mere luft. Start alligevel nu: de betalere og behandlere, I skal teste med, går i drift 1. januar.

Hvad der stadig kan ændre sig

CMS-0062-P. Den 14. april 2026 offentliggjorde CMS et forslag til en opfølgende regel. Den ville gøre de nu anbefalede implementeringsguider obligatoriske fra 1. oktober 2027, tilføje lægemidler til elektronisk forhåndsgodkendelse fra samme dato og lade HHS indføre FHIR som HIPAA-standard for transaktioner om forhåndsgodkendelse i stedet for X12 278. Om de eksisterende frister siger forslaget: »Dette forslag ville ikke ændre disse frister.« Høringsfristen udløb 15. juni 2026, og pr. 16. oktober 2026 er der ikke offentliggjort nogen endelig regel i Federal Register. Byg efter 2024-reglen, og hold jeres guideversioner samlet ét konfigurerbart sted.

Versioner. Da Vinci-guiderne bliver ved med at ændre sig. Den endelige IPPS-regel for regnskabsåret 2027 bemærker, at EHR-systemer, der er certificeret efter de nye kriterier for forhåndsgodkendelse fra ONC (den amerikanske myndighed for sundheds-IT), »vil kræve brug af version 2.2 af Da Vinci-IG'erne«. Det er de systemer, jeres Prior Authorization API skal tale med.

Intet af dette er en grund til at vente. Reglen er endelig, datoerne står i forskriftsteksten, og CMS gentog dem 8. oktober.

Hvor I kan få hjælp

Vi arbejder med systemerne bag API'erne: FHIR-mapping af afregnings-, encounter- og godkendelsesdata, ændringsfeeds ud af ældre afregnings- og UM-platforme, logik for samtykke og tilknytning og de test, der viser, at reglerne om én arbejdsdag holder. Vores service til vedligeholdelse af ældre systemer er der, hvor det arbejde starter, når kernesystemet er gammelt, eller de folk, der byggede det, er rejst, og lander fristen midt i en platformudskiftning, så se ERP-modernisering.

Er jeres afregnings- eller UM-platform en, som ingen leverandør vil levere disse API'er til, så skriv til office@c9group.dev. Vi er ingeniører, ikke sundhedsjurister: spørgsmål om omfang og kontrakter hører hjemme hos jeres juridiske rådgivere, og vi bygger efter deres svar.