CMS-0057-F og 1. januar 2027: betaler-API-er i egenutviklede systemer for kravbehandling og forhåndsgodkjenning

Innen 1. januar 2027 må Medicare Advantage-organisasjoner (private planer i Medicare) og delstatenes fee-for-service-programmer (betaling per tjeneste) i Medicaid og CHIP, de offentlige helseprogrammene for lavinntektsgrupper og barn, ha fire FHIR-API-er i drift. Kravet står i CMS Interoperability and Prior Authorization final rule (CMS-0057-F), den endelige forskriften om interoperabilitet og forhåndsgodkjenning fra CMS, den føderale etaten for Medicare og Medicaid. De fire er det eksisterende Patient Access API, utvidet med data om forhåndsgodkjenninger, og de nye Provider Access API, Payer-to-Payer API og Prior Authorization API. Medicaid managed care-planer, CHIP managed care-enheter og utstedere av Qualified Health Plans (QHP) på de føderale markedsplassene følger fra sin første rating period (satsperiode) eller sitt første plan year (planår) som begynner på eller etter den datoen. Per 16. oktober 2026 er det elleve uker igjen, og CMS har ikke flyttet fristen.

Den operative halvdelen av forskriften gjelder allerede. Siden 2026 har berørte betalere (impacted payers: planene og programmene forskriften gjelder for) måttet gi en konkret begrunnelse for hvert avslag på forhåndsgodkjenning, avgjøre søknader innen faste frister og publisere nøkkeltall for forhåndsgodkjenning.

Kommer systemene dine for kravbehandling, utilization management (UM, vurderingen av om en behandling er nødvendig og dekkes) og medlemmer fra en leverandør som leverer disse fire API-ene, er mesteparten av byggejobben leverandørens. Din del er konfigurasjon, digitaliserte regler for forhåndsgodkjenning, varsler til medlemmene og testing med partnere.

Denne artikkelen er for resten: planer og etater der kravmotoren, UM-arbeidsflyten eller medlemsdataene ligger i et system de eier selv, enten det er utviklet internt, tilpasset så langt at det ikke lenger kan oppgraderes, eller et Medicaid Management Information System (MMIS, delstatens forvaltningssystem for Medicaid) med flere tiår med lokale endringer. Ingen leverer API-ene for slike systemer. Vi er ingeniører, ikke jurister: her forklarer vi hva forskriften krever at et system gjør, ikke hvordan den gjelder for kontraktene dine.

Datoene

Forskriften ble kunngjort i det føderale kunngjøringsbladet Federal Register 8. februar 2024 og trådte i kraft 8. april 2024. For hvert av de fire API-ene fastsetter den de samme fristene: «innen 1. januar 2027 for MA-organisasjoner og delstatenes FFS-programmer i Medicaid og CHIP; innen satsperioden som begynner på eller etter 1. januar 2027, for Medicaid managed care-planer og CHIP managed care-enheter; og for planår som begynner på eller etter 1. januar 2027, for QHP-utstedere på FFE-ene».

En Medicaid managed care-plan med satsperioder som starter 1. juli, har derfor frist til 1. juli 2027. En plan med kontrakt som følger kalenderåret, har ikke det.

CMS holder fast ved samme dato. Etatens side om forskriften, sist endret 8. oktober 2026, sier at «berørte betalere har i hovedsak frist til 1. januar 2027 med å oppfylle kravene til applikasjonsprogrammeringsgrensesnitt (API) i denne endelige forskriften».

Pliktene fra 2026 er, slik CMS' faktaark beskriver dem, avgjørelser «innen 72 timer for hastesaker (dvs. akutte forespørsler) og sju kalenderdager for standardforespørsler (dvs. ikke-akutte forespørsler)» (QHP-utstedere på markedsplassene er unntatt fra fristene), en konkret begrunnelse for hvert avslag og offentlige nøkkeltall, der «det første settet med nøkkeltall må rapporteres innen 31. mars 2026». Bruken av Patient Access API rapporteres også til CMS hvert år innen 31. mars. Er noe av dette ikke i drift ennå, er det allerede forsinket, og det bygger på de samme dataene som API-ene.

Legemidler faller helt utenfor. Alle bestemmelsene om forhåndsgodkjenning i CMS-0057-F unntar dem.

Hvem som er omfattet, og hvem som ikke er det

Forskriften kaller dem impacted payers: Medicare Advantage-organisasjoner (MA), delstatenes fee-for-service-programmer (FFS) i Medicaid og CHIP, Medicaid managed care-planer, CHIP managed care-enheter og QHP-utstedere på Federally-facilitated Exchanges (FFEs, markedsplassene den føderale staten driver). Konsekvensanalysen teller «365 morsorganisasjoner, inkludert delstatenes Medicaid- og CHIP-etater», som «er ansvarlige for å innføre og vedlikeholde tre nye API-er», og påpeker at «75 prosent av betalerne i denne kategorien har under 500 ansatte». Mange er regionale planer uten et stort plattformteam.

Ikke omfattet, i hvert fall ikke direkte:

• Arbeidsgiverplaner utenfor disse programmene, og Original Medicare (det tradisjonelle Medicare som staten driver selv). De står ikke på listen over impacted payers.
• Tjenesteytere. Deres side er målet Electronic Prior Authorization i Medicares Promoting Interoperability-programmer, som oppfylles med sertifisert EHR-teknologi (elektronisk pasientjournal). Den årlige sykehusforskriften i Medicare, FY 2027 IPPS final rule av 4. august 2026, gjorde det til et valgfritt bonusmål for sykehus i 2027.
• Delegerte UM-aktører og TPA-er (tredjepartsadministratorer). De har ingen egen plikt, men betalerens plikt går gjennom systemene deres. For QHP-utstedere gjentar forskriften at de «er ansvarlige for egen etterlevelse og for etterlevelsen til alle delegerte aktører eller aktører lenger ned i kjeden».

Det finnes få utveier, og ingen av dem hjelper stort så sent. En delstat kan be om én engangsutsettelse på ett år for FFS-programmet sitt i Medicaid eller CHIP, men søknaden legges inn i delstatens Advance Planning Document (APD, planleggingsdokumentet for føderal IT-finansiering) og må være «godkjent før fristen for etterlevelse». En delstat med minst 90 prosent av Medicaid-mottakerne sine i managed care kan søke om fritak, og QHP-utstedere kan be markedsplassen om unntak. Om selve planene skrev CMS: «Vi foreslo ikke utsettelser eller fritak for MA-organisasjoner eller Medicaid managed care-planer.» Delstatene kan også kreve 90 prosent forhøyet føderal medfinansiering (enhanced federal matching funds) til å bygge API-ene, godkjent sak for sak gjennom APD-en.

Hva hvert API må gjøre

Alle fire avhenger av én ting et spesialtilpasset system ofte mangler: forhåndsgodkjenning som strukturerte data med statushistorikk. Bygg det én gang, så leser alle fire fra det.

Patient Access API: legg til forhåndsgodkjenninger

Dette API-et har du hatt i drift siden 1. januar 2021, for krav, pasientkontakter (encounters) og kliniske data. Fra 2027 må det også vise hver forhåndsgodkjenning for varer og tjenester: status, datoen den ble innvilget eller avslått, når den utløper, hvilke varer og tjenester som er innvilget, en konkret begrunnelse ved avslag og tilhørende strukturert dokumentasjon fra tjenesteyteren. Dataene må være tilgjengelige «senest 1 virkedag etter» at betaleren mottar forespørselen, oppdateres innen én virkedag etter hver statusendring og bevares så lenge godkjenningen er aktiv og i minst ett år etter siste endring.

Et UM-system som registrerer avgjørelser som fritekstnotater, eller som bare sender status på faks, kan ikke levere dette uten endringer.

Provider Access API

Tjenesteytere i nettverket kan be om en pasients data: krav og pasientkontakter uten tjenesteyternes oppgjørsdata (remittances) eller egenandeler (cost-sharing), dataklassene i USCDI (det amerikanske kjernesettet av kliniske data) og opplysninger om forhåndsgodkjenninger, for tjenester utført fra og med 1. januar 2016. Betaleren svarer innen én virkedag, men bare for pasienter den har knyttet til den aktuelle tjenesteyteren, og som ikke har reservert seg.

Det krever tre ting et eldre system sjelden har. En tilknytningsprosess (attribution) som knytter medlemmer til tjenesteytere. En reservasjonsmulighet (opt-out) som medlemmet kan endre når som helst, med varsler i klart språk før første bruk, innen en uke etter at dekningen starter, og hvert år. Og masseeksport, fordi de påkrevde standardene omfatter FHIR Bulk Data Access for en tjenesteyter som spør om en hel pasientliste.

Payer-to-Payer API

Når et nytt medlem kommer inn, ber den nye betaleren om samtykke (her gjelder opt-in) og begynner innen en uke etter dekningsstart å identifisere tidligere og samtidige betalere. Når den har dem, ber den innen en uke om fem års data: krav og pasientkontakter uten oppgjørsdata eller egenandeler, USCDI-data og forhåndsgodkjenninger unntatt avslåtte, med tilhørende ustrukturert dokumentasjon. Den forrige betaleren svarer innen én virkedag. Ved samtidig dekning gjentas utvekslingen minst hvert kvartal.

Det vanskelige er ikke det utgående svaret. Det er å ta imot data fra betalere du aldri har testet mot, og innlemme dem i medlemsposten, slik forskriften krever.

Prior Authorization API

Det er dette API-et som når helt inn i UM-kjernen. API-et må liste opp de dekkede varene og tjenestene som krever forhåndsgodkjenning, angi hvilken dokumentasjon som kreves for hver av dem, støtte en HIPAA-kompatibel forespørsel og et HIPAA-kompatibelt svar, og vise om betaleren har innvilget (med sluttdato), avslått (med konkret begrunnelse) eller trenger mer informasjon.

CMS anbefaler, men krever ikke, tre implementeringsveiledere fra HL7-prosjektet Da Vinci her: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) og Prior Authorization Support (PAS). I praksis må dekningsreglene og dokumentasjonsskjemaene dine bli maskinlesbare, ikke en retningslinjehåndbok i PDF. Betalerne i undersøkelsen til WEDI (Workgroup for Electronic Data Interchange, en amerikansk bransjeorganisasjon) plasserte «digitalisering av retningslinjer for forhåndsgodkjenning» blant sine tre største utfordringer.

For selve transaksjonen har HHS gitt betalerne spillerom. Den 28. februar 2024 kunngjorde departementet at det ville utvise skjønn i håndhevingen (enforcement discretion): ifølge CMS vil etatens National Standards Group «ikke iverksette håndhevingstiltak etter HIPAA Administrative Simplification mot aktører som omfattes av HIPAA, og som velger å ikke bruke X12 278-standarden som del av en elektronisk FHIR-prosess for forhåndsgodkjenning». Du kan bygge rent FHIR eller FHIR med X12, og beholde en ren X12-transaksjon ved siden av.

Standardene

De påkrevde standardene er HL7 FHIR Release 4.0.1, US Core, SMART App Launch, Bulk Data Access og OpenID Connect Core; betalere kan frivillig bruke oppdaterte versjoner, på visse vilkår. Forskriften fra 2024 oppførte US Core 3.1.1 og SMART App Launch 1.0.0 med utløpsdato 1. januar 2026, så bestem hvilke versjoner du bygger mot før noen skriver mappingen.

Hvor egenutviklede systemer vanligvis kommer til kort

Ut fra det forskriften krever, er dette hullene du bør se etter først:

• Forhåndsgodkjenning som en post, ikke et dokument. Status, tidsstempler, årsakskoder for avslag og sluttdatoen må være felt, skrevet når de endres, med historikk. En avgjørelse sendt på faks trenger et strukturert motstykke.
• Dekningsreglene. Hvilke tjenester som krever godkjenning, og hvilken dokumentasjon hver av dem krever, må være data API-et kan levere. I mange planer ligger dette i retningslinjer i PDF og i hodene på saksbehandlerne.
• Krav som FHIR. Krav og pasientkontakter må komme ut som FHIR-ressurser, med oppgjørsdata og egenandeler fjernet for tjenesteytere og andre betalere, men beholdt for medlemmet.
• Medlemsidentitet og historikk. Å matche en annen betalers data mot ditt medlem, og finne et nytt medlems tidligere betalere, krever demografiske data og dekningshistorikk du kanskje ikke har samlet ett sted.
• Samtykkestatus. En reservasjon (opt-out) for Provider Access og et samtykke (opt-in) for Payer-to-Payer, som hver kan endres når som helst og kontrolleres ved hver forespørsel. En delstat må også videreformidle en mottakers opt-in til vedkommendes Medicaid managed care-planer.
• Klokken på én virkedag. En nattlig batch på stormaskinen holder for noen data og er for treg for andre. Mål tiden fra avgjørelse til API, ikke bare om API-et svarer.
• Delegerte leverandører. Tar en delegert UM-leverandør avgjørelsene, må dataene derfra nå deg i tide til fristen din på én virkedag. WEDIs undersøkelse fra februar 2026 satte «delegerte tredjeparter som har utfordringer med å koble seg til ulike systemer» øverst blant betalernes utfordringer.

Hvor langt bransjen har kommet

WEDIs undersøkelse fra februar 2026, publisert 10. mars 2026, fant at for API-kravene har «10 % ennå ikke startet arbeidet», mot 33 % i oktober 2025. Den rapporterte også «en merkbar økning i anslått kostnad på over 5 millioner dollar, fra 15 % (okt. ’25) til 25 % (feb. ’26)». Utvalget er lite: 86 svar, 52 % av dem fra betalere. Les det som et signal, ikke en totaltelling.

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

Fra midten av oktober har en MA-organisasjon eller et FFS-program i en delstat omtrent elleve uker. Det holder ikke til å bygge fire API-er fra bunnen av, så planen handler om rekkefølge, og om hva du kan vise frem den første dagen.

1. Denne uken: bekreft datoen din og utgangspunktet ditt. 1. januar, eller en senere satsperiode eller et senere planår? List opp hva som allerede er i drift: Patient Access API og Provider Directory API, nøkkeltallene for 2026, begrunnelsene for avslag.
2. Uke 1 til 2: knytt hvert dataelement til kilden. For hvert API skriver du ned hvilket system som har dataene i dag (krav, UM, medlemsregistrering, tjenesteyternettverk, klinisk) og hvor ferske de er.
3. Uke 1 til 3: bestem hvor FHIR-laget skal ligge. En FHIR-server eller fasade foran de eldre systemene, matet med endringshendelser eller hyppige uttrekk, er som regel raskere enn å lære kjernesystemet å snakke FHIR. Det er mappingen og datastrømmene som tar tiden.
4. Uke 2 til 7: bygg de felles delene først. Posten for forhåndsgodkjenning, samtykke og tilknytning, matching av medlemmer. Alle fire API-ene avhenger av dem.
5. Uke 4 til 9: bygg API-ene. Tilleggene i Patient Access, Provider Access med masseeksport, Payer-to-Payer i begge retninger og Prior Authorization API med dekningsreglene dine lastet inn.
6. Uke 8 til 11: test med ekte motparter. EHR-leverandøren til en tjenesteyter, en annen betaler, den delegerte UM-leverandøren din. Test endringer i samtykke, et avslag med begrunnelse og en statusendring som når medlemmet innen én virkedag.
7. 1. januar 2027: gå i drift og mål. Mål forsinkelsen mot reglene om én virkedag fra første dag, og hold en datert liste over det som ikke er ferdig.

Holder ikke elleve uker, ta det opp med compliance-avdelingen og advokatene dine nå, ikke i desember, med en plan som viser hva som er i drift 1. januar, og hva som kommer når.

En Medicaid managed care-plan med satsperiode fra 1. juli 2027, eller en QHP-utsteder med et senere planår, kan følge de samme trinnene med bedre tid. Start likevel nå: betalerne og tjenesteyterne du skal teste med, går i drift 1. januar.

Hva som fortsatt kan endre seg

CMS-0062-P. 14. april 2026 publiserte CMS et forslag til oppfølgingsforskrift. Det ville gjøre de implementeringsveilederne som i dag er anbefalt, obligatoriske fra 1. oktober 2027, ta med legemidler i elektronisk forhåndsgodkjenning fra samme dato og la HHS innføre FHIR som HIPAA-standard for transaksjoner om forhåndsgodkjenning i stedet for X12 278. Om de eksisterende fristene sier det: «Dette forslaget vil ikke endre disse fristene for etterlevelse.» Høringsfristen gikk ut 15. juni 2026, og per 16. oktober 2026 har ingen endelig forskrift kommet i Federal Register. Bygg etter forskriften fra 2024, og hold versjonene av veilederne på ett konfigurerbart sted.

Versjoner. Da Vinci-veilederne endrer seg stadig. FY 2027 IPPS final rule påpeker at EHR-systemer sertifisert etter de nye kriteriene for forhåndsgodkjenning fra ONC (det føderale kontoret for helse-IT) «vil kreve bruk av versjon 2.2 av Da Vinci-veilederne». Det er de systemene ditt Prior Authorization API skal snakke med.

Ingenting av dette er en grunn til å vente. Forskriften er endelig, datoene står i forskriftsteksten, og CMS gjentok dem 8. oktober.

Hvor du får hjelp

Vi jobber med systemene bak API-ene: FHIR-mapping av krav, pasientkontakter og godkjenningsdata, endringsstrømmer ut av eldre plattformer for kravbehandling og UM, logikk for samtykke og tilknytning, og testene som viser at reglene om én virkedag holder. Vår tjeneste for vedlikehold av eldre systemer er der dette starter når kjernesystemet er gammelt eller de som bygde det, har sluttet, og havner fristen midt i et plattformbytte, se ERP-modernisering.

Er plattformen din for kravbehandling eller UM en som ingen leverandør vil levere disse API-ene til, skriv til office@c9group.dev. Vi er ingeniører, ikke helserettsjurister: spørsmål om virkeområde og kontrakt hører hjemme hos advokatene dine, og vi bygger etter svaret deres.