CMS-0057-F per 1 januari 2027: payer-API's op eigen declaratie- en machtigingssystemen

Uiterlijk 1 januari 2027 moeten Medicare Advantage-organisaties (de private Medicare-plannen) en de fee-for-service-programma's van de staten voor Medicaid en CHIP (het zorgverzekeringsprogramma voor kinderen) vier FHIR-API's in gebruik hebben onder de CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F): de bestaande Patient Access API, uitgebreid met gegevens over voorafgaande machtigingen (prior authorization), en de nieuwe Provider Access, Payer-to-Payer en Prior Authorization API's. Medicaid managed care-plannen, CHIP managed care-entiteiten en verzekeraars met Qualified Health Plans (QHP) op de federale marktplaatsen volgen vanaf hun eerste rating period (tariefperiode) of plan year (polisjaar) die op of na die datum begint. Gerekend vanaf 16 oktober 2026 is dat nog elf weken, en CMS heeft de datum niet verschoven.

Het operationele deel van de regeling geldt al. Sinds 2026 moeten betrokken zorgfinanciers elke afgewezen machtiging specifiek motiveren, binnen vaste termijnen beslissen en cijfers over machtigingen publiceren.

Komen uw systemen voor declaraties, utilization management (UM, de beoordeling en sturing van zorggebruik) en verzekerden van een leverancier die deze vier API's meelevert, dan ligt het meeste bouwwerk bij die leverancier. Uw deel is configuratie, gedigitaliseerde machtigingsregels, berichten aan verzekerden en testen met partners.

Dit artikel is voor de rest: verzekeraars en overheidsinstanties waarvan de declaratie-engine, de UM-workflow of de verzekerdengegevens in een eigen systeem zitten, zelfgebouwd, zo ver aangepast dat upgraden niet meer gaat, of een Medicaid Management Information System (MMIS) met tientallen jaren aan lokale wijzigingen. Voor zulke systemen levert niemand de API's. Wij zijn ingenieurs, geen juristen: dit artikel legt uit wat de regeling van een systeem vraagt, niet hoe ze op uw contracten van toepassing is.

De data

De final rule is op 8 februari 2024 gepubliceerd in het Federal Register (het federale publicatieblad van de VS) en trad op 8 april 2024 in werking. Voor elk van de vier API's gelden dezelfde nalevingsdata: “uiterlijk 1 januari 2027 voor MA-organisaties en de FFS-programma's van de staten voor Medicaid en CHIP; uiterlijk de rating period die begint op of na 1 januari 2027 voor Medicaid managed care-plannen en CHIP managed care-entiteiten; en voor plan years die beginnen op of na 1 januari 2027 voor QHP-verzekeraars op de FFE's”.

Een Medicaid managed care-plan waarvan de rating periods op 1 juli beginnen, heeft dus tot 1 juli 2027. Een plan met een contract per kalenderjaar niet.

CMS noemt nog steeds dezelfde datum. De beleidspagina over de regeling, voor het laatst gewijzigd op 8 oktober 2026, zegt dat “betrokken zorgfinanciers in hoofdzaak tot 1 januari 2027 de tijd hebben om te voldoen aan de eisen voor application programming interfaces (API's) in deze final rule”.

Volgens de factsheet van CMS bestaan de verplichtingen voor 2026 uit beslissingen “binnen 72 uur voor versnelde (d.w.z. spoedeisende) aanvragen en zeven kalenderdagen voor standaard (d.w.z. niet-spoedeisende) aanvragen” (QHP-verzekeraars op de marktplaatsen vallen buiten die termijnen), een specifieke reden bij elke afwijzing, en openbare cijfers, waarbij “de eerste set cijfers uiterlijk 31 maart 2026 moet zijn gerapporteerd”. Ook het gebruik van de Patient Access API wordt elk jaar uiterlijk 31 maart aan CMS gerapporteerd. Draait iets hiervan nog niet, dan bent u daar al te laat mee, en het put uit dezelfde gegevens als de API's.

Geneesmiddelen vallen overal buiten. Elke bepaling over voorafgaande machtiging in CMS-0057-F sluit ze uit.

Wie eronder valt en wie niet

De regeling noemt ze impacted payers, betrokken zorgfinanciers: Medicare Advantage-organisaties (MA), de fee-for-service-programma's (FFS) van de staten voor Medicaid en CHIP, Medicaid managed care-plannen, CHIP managed care-entiteiten en QHP-verzekeraars op de Federally-facilitated Exchanges (FFE's, de federaal beheerde marktplaatsen voor zorgverzekeringen). De effectanalyse telt “365 moederorganisaties, waaronder de Medicaid- en CHIP-instanties van de staten”, die “verantwoordelijk zijn voor het implementeren en onderhouden van drie nieuwe API's”, en merkt op dat “75 procent van de zorgfinanciers in deze categorie minder dan 500 werknemers heeft”. Veel ervan zijn regionale plannen zonder groot platformteam.

Niet onder de regeling vallen, in elk geval niet rechtstreeks:

• Werkgeversplannen buiten deze programma's, en Original Medicare (het traditionele Medicare van de overheid). Ze staan niet op de lijst van betrokken zorgfinanciers.
• Zorgaanbieders. Hun kant is de Electronic Prior Authorization-maatstaf in de Promoting Interoperability-programma's van Medicare, waaraan ze voldoen met gecertificeerde EHR-technologie. De IPPS final rule voor boekjaar 2027 van 4 augustus 2026 (IPPS is het vergoedingssysteem van Medicare voor ziekenhuisopnames) heeft er voor ziekenhuizen in 2027 een optionele bonusmaatstaf van gemaakt.
• Gedelegeerde UM-partijen en TPA's (third party administrators, externe uitvoerders). Zij hebben geen eigen verplichting, maar die van de zorgfinancier loopt via hun systemen. Voor QHP-verzekeraars herhaalt de regeling dat zij “verantwoordelijk zijn voor hun eigen naleving en voor de naleving door alle gedelegeerde partijen en partijen verderop in de keten”.

Uitwegen zijn er weinig, en zo laat helpt geen ervan veel. Een staat kan voor zijn Medicaid- of CHIP-FFS-programma eenmalig een verlenging van een jaar aanvragen, maar die aanvraag hoort in zijn Advance Planning Document (APD, het project- en financieringsplan dat de staat bij CMS indient) en moet “vóór de nalevingsdatum goedgekeurd” zijn. Een staat met minstens 90 procent van zijn Medicaid-gerechtigden in managed care kan een vrijstelling aanvragen, en QHP-verzekeraars kunnen de marktplaats om een uitzondering vragen. Over de plannen zelf schreef CMS: “Wij hebben geen verlengingen of vrijstellingen voorgesteld voor MA-organisaties of Medicaid managed care-plannen.” Staten kunnen voor de bouw van de API's ook aanspraak maken op een verhoogde federale cofinanciering van 90 procent, die per geval via het APD wordt goedgekeurd.

Wat elke API moet doen

Alle vier hangen af van één ding dat een maatwerksysteem vaak mist: machtigingen als gestructureerde gegevens met een statusgeschiedenis. Bouw dat één keer, en alle vier lezen eruit.

Patient Access API: machtigingen toevoegen

Deze API hebt u sinds 1 januari 2021 in gebruik voor declaraties, encounters en klinische gegevens. Vanaf 2027 moet die ook elke machtiging voor producten en diensten bevatten: de status, de datum van goedkeuring of afwijzing, wanneer de machtiging afloopt, de goedgekeurde producten en diensten, bij afwijzing een specifieke reden, en de bijbehorende gestructureerde documentatie van de zorgaanbieder. De gegevens moeten beschikbaar zijn “uiterlijk 1 werkdag nadat” de zorgfinancier de aanvraag heeft ontvangen, binnen één werkdag na elke statuswijziging worden bijgewerkt, en bewaard blijven zolang de machtiging actief is en ten minste een jaar na de laatste wijziging.

Een UM-systeem dat beslissingen als vrije tekst vastlegt, of de status alleen per fax doorgeeft, kan die gegevens niet zonder aanpassingen leveren.

Provider Access API

Gecontracteerde zorgaanbieders kunnen de gegevens van een patiënt opvragen: declaraties en encounters zonder betaalspecificaties aan zorgaanbieders en zonder eigen bijdragen, de klinische gegevensklassen van USCDI (de Amerikaanse kernset voor de uitwisseling van klinische gegevens) en informatie over machtigingen, voor zorg met een behandeldatum vanaf 1 januari 2016. De zorgfinancier antwoordt binnen één werkdag, maar alleen voor patiënten die hij aan die zorgaanbieder heeft toegewezen en die geen gebruik hebben gemaakt van hun opt-out.

Daarvoor zijn drie dingen nodig die een legacysysteem zelden heeft. Een attributieproces dat verzekerden aan zorgaanbieders koppelt. Een opt-out die de verzekerde op elk moment kan wijzigen, met informatie in begrijpelijke taal vóór het eerste gebruik, binnen een week na de start van de dekking en elk jaar. En bulkexport, omdat FHIR Bulk Data Access tot de verplichte standaarden hoort, voor een zorgaanbieder die naar zijn volledige patiëntenbestand vraagt.

Payer-to-Payer API

Wanneer een verzekerde instroomt, vraagt de nieuwe zorgfinancier om toestemming (hier geldt opt-in) en begint hij binnen een week na de start van de dekking eerdere en gelijktijdige zorgfinanciers op te sporen. Zodra die bekend zijn, vraagt hij binnen een week vijf jaar aan gegevens op: declaraties en encounters zonder betaalspecificaties of eigen bijdragen, USCDI-gegevens, en machtigingen behalve afgewezen machtigingen, met hun ongestructureerde documentatie. De vorige zorgfinancier antwoordt binnen één werkdag. Bij gelijktijdige dekking wordt de uitwisseling minstens elk kwartaal herhaald.

Het lastige deel is niet het uitgaande antwoord. Het lastige deel is gegevens ontvangen van zorgfinanciers waarmee u nooit hebt getest, en die verwerken in uw verzekerdendossier, zoals de regeling eist.

Prior Authorization API

Dit is de API die tot in de kern van UM reikt. De API moet de gedekte producten en diensten tonen waarvoor een machtiging nodig is, per item de vereiste documentatie aangeven, een HIPAA-conforme aanvraag en respons ondersteunen, en melden of de zorgfinancier heeft goedgekeurd (met einddatum), afgewezen (met een specifieke reden) of meer informatie nodig heeft.

CMS beveelt hier drie Da Vinci-implementatiegidsen aan, maar verplicht ze niet: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) en Prior Authorization Support (PAS). In de praktijk moeten uw dekkingsregels en documentatievragenlijsten machineleesbaar worden, in plaats van een beleidshandboek in pdf. Zorgfinanciers in de enquête van WEDI (een Amerikaanse brancheorganisatie voor elektronische gegevensuitwisseling in de zorg) rekenden “het digitaliseren van machtigingsbeleid” tot hun drie grootste uitdagingen.

Voor de transactie zelf gaf HHS (het Amerikaanse ministerie van Volksgezondheid) de zorgfinanciers ruimte. Op 28 februari 2024 kondigde het enforcement discretion aan, het bewust afzien van handhaving: volgens CMS zal de National Standards Group van CMS “geen handhavingsmaatregelen op grond van HIPAA Administrative Simplification nemen tegen onder HIPAA vallende entiteiten die ervoor kiezen de X12 278-standaard niet te gebruiken als onderdeel van een elektronisch FHIR-proces voor voorafgaande machtiging”. U kunt dus alleen op FHIR bouwen of FHIR met X12 combineren, en daarnaast een transactie met alleen X12 aanhouden.

De standaarden

De verplichte standaarden zijn HL7 FHIR Release 4.0.1, US Core, SMART App Launch, Bulk Data Access en OpenID Connect Core; zorgfinanciers mogen onder voorwaarden vrijwillig nieuwere versies gebruiken. De regeling van 2024 noemde US Core 3.1.1 en SMART App Launch 1.0.0 met een vervaldatum van 1 januari 2026, dus leg vast naar welke versies u bouwt voordat iemand aan de mapping begint.

Waar eigen systemen meestal tekortschieten

Uitgaande van wat de regeling vraagt, zijn dit de hiaten om eerst naar te kijken:

• Machtiging als record, niet als document. Status, tijdstempels, codes voor afwijzingsredenen en de einddatum moeten velden zijn, geschreven op het moment dat ze veranderen, met geschiedenis. Een per fax verstuurde beslissing heeft een gestructureerde tegenhanger nodig.
• De dekkingsregels. Welke diensten een machtiging vereisen, en welke documentatie bij elk ervan hoort, moet bestaan als gegevens die de API kan uitleveren. Bij veel plannen zit dat in beleids-pdf's en in de hoofden van beoordelaars.
• Declaraties als FHIR. Declaraties en encounters moeten als FHIR-resources naar buiten komen, zonder betaalspecificaties en eigen bijdragen voor zorgaanbieders en andere zorgfinanciers, maar met die gegevens voor de verzekerde.
• Identiteit en historie van verzekerden. Gegevens van een andere zorgfinancier aan uw verzekerde koppelen, en de eerdere zorgfinanciers van een nieuwe verzekerde vinden, vraagt om demografische gegevens en een dekkingshistorie die u misschien niet op één plek bijhoudt.
• Toestemmingsstatus. Een opt-out voor Provider Access en een opt-in voor Payer-to-Payer, allebei op elk moment te wijzigen en bij elke aanvraag gecontroleerd. Een staat moet de opt-in van een gerechtigde bovendien doorgeven aan diens Medicaid managed care-plannen.
• De klok van één werkdag. Een nachtelijke batch op het mainframe volstaat voor sommige gegevens en is te traag voor andere. Meet de tijd van beslissing tot API, niet alleen of de API antwoordt.
• Gedelegeerde leveranciers. Neemt een gedelegeerde UM-leverancier de beslissingen, dan moeten diens gegevens u op tijd bereiken voor uw verplichting van één werkdag. De enquête van WEDI uit februari 2026 zette “gedelegeerde derden die moeite hebben om verbinding te maken met verschillende systemen” bovenaan de uitdagingen van zorgfinanciers.

Hoe ver de sector is

De enquête van WEDI uit februari 2026, gepubliceerd op 10 maart 2026, vond voor de API-eisen dat “10% nog niet met het werk is begonnen”, tegenover 33% in oktober 2025. Ook meldde ze “een opvallende stijging van een geschatte kostenpost boven 5 miljoen dollar, van 15% (okt. ’25) naar 25% (feb. ’26)”. De steekproef is klein: 86 reacties, waarvan 52% van zorgfinanciers. Lees het als een signaal, niet als een volledige telling.

Een plan van elf weken tot 1 januari 2027

Vanaf half oktober heeft een MA-organisatie of een FFS-programma van een staat ongeveer elf weken. Dat is niet genoeg om vier API's vanaf nul te bouwen. Het plan draait dus om de volgorde, en om wat u op dag één kunt laten zien.

1. Deze week: bevestig uw datum en uw uitgangspositie. 1 januari, of een latere rating period of een later plan year? Zet op een rij wat al live is: de Patient Access API en de Provider Directory API, de cijfers over 2026, de afwijzingsredenen.
2. Week 1 tot 2: koppel elk gegevenselement aan zijn bron. Leg per API vast welk systeem de gegevens vandaag bevat (declaraties, UM, inschrijving, zorgaanbiedersnetwerk, klinisch) en hoe actueel ze zijn.
3. Week 1 tot 3: bepaal waar de FHIR-laag komt. Een FHIR-server of -facade voor de legacysystemen, gevoed door wijzigingsevents of frequente extracties, is meestal sneller dan het kernsysteem FHIR leren spreken. De tijd gaat zitten in de mapping en de feeds.
4. Week 2 tot 7: bouw eerst de gedeelde onderdelen. Het machtigingsrecord, toestemming en attributie, het matchen van verzekerden. Alle vier de API's hangen ervan af.
5. Week 4 tot 9: bouw de API's. De uitbreidingen van Patient Access, Provider Access met bulkexport, Payer-to-Payer in beide richtingen, en de Prior Authorization API met uw dekkingsregels erin geladen.
6. Week 8 tot 11: test met echte tegenpartijen. De EHR-leverancier van een zorgaanbieder, een andere zorgfinancier, uw gedelegeerde UM-leverancier. Test wijzigingen in toestemming, een afwijzing met de reden erbij, en een statuswijziging die de verzekerde binnen een werkdag bereikt.
7. 1 januari 2027: live gaan en meten. Meet vanaf dag één de doorlooptijd tegen de regels van één werkdag, en houd een gedateerde lijst bij van wat nog niet af is.

Zijn elf weken niet genoeg, leg dat dan nu voor aan uw compliance-team en juridisch adviseur, niet pas in december, met een plan dat laat zien wat op 1 januari live is en wat wanneer volgt.

Een Medicaid managed care-plan met een rating period per 1 juli 2027, of een QHP-verzekeraar met een later plan year, kan dezelfde stappen volgen met meer ruimte. Begin toch nu: de zorgfinanciers en zorgaanbieders waarmee u gaat testen, gaan op 1 januari live.

Wat er nog kan verschuiven

CMS-0062-P. Op 14 april 2026 publiceerde CMS een voorstel voor een vervolgregeling. Die zou de nu aanbevolen implementatiegidsen vanaf 1 oktober 2027 verplicht maken, vanaf dezelfde datum geneesmiddelen toevoegen aan de elektronische voorafgaande machtiging, en HHS FHIR laten vaststellen als HIPAA-standaard voor machtigingstransacties, in plaats van X12 278. Over de bestaande deadlines zegt het voorstel: “Dit voorstel zou die nalevingsdata niet wijzigen.” De commentaarperiode sloot op 15 juni 2026, en op 16 oktober 2026 is er nog geen final rule in het Federal Register verschenen. Bouw volgens de regeling van 2024, en houd uw gidsversies op één configureerbare plek.

Versies. De Da Vinci-gidsen blijven veranderen. De IPPS final rule voor boekjaar 2027 merkt op dat EHR's die zijn gecertificeerd volgens de nieuwe criteria van ONC (de Amerikaanse overheidsinstantie voor zorg-IT) voor machtigingen “het gebruik van versie 2.2 van de Da Vinci-IG's zullen vereisen”. Dat zijn de systemen waarmee uw Prior Authorization API gaat praten.

Niets hiervan is een reden om te wachten. De regeling is definitief, de data staan in de regelgevingstekst, en CMS heeft ze op 8 oktober herhaald.

Waar u hulp krijgt

Wij werken aan de systemen achter de API's: FHIR-mapping van declaratie-, encounter- en machtigingsgegevens, wijzigingsfeeds uit oudere declaratie- en UM-platforms, logica voor toestemming en attributie, en de tests die aantonen dat de regels van één werkdag worden gehaald. Onze dienst onderhoud van legacysystemen is waar dat begint wanneer het kernsysteem oud is of de mensen die het bouwden zijn vertrokken, en valt de deadline midden in de vervanging van een platform, kijk dan bij ERP-modernisering.

Is uw declaratie- of UM-platform er een waarvoor geen leverancier deze API's zal leveren, schrijf dan naar office@c9group.dev. Wij zijn ingenieurs, geen gezondheidsjuristen: vragen over reikwijdte en contracten horen bij uw juridisch adviseur, en wij bouwen naar diens antwoord.