CMS-0057-F ab 1. Januar 2027: Payer-APIs für eigene Abrechnungs- und Vorabgenehmigungssysteme

Bis zum 1. Januar 2027 müssen Medicare-Advantage-Organisationen (die privaten Medicare-Pläne) und die Fee-for-Service-Programme der Bundesstaaten für Medicaid und CHIP (das Krankenversicherungsprogramm für Kinder) vier FHIR-APIs nach der CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) in Betrieb haben: die bestehende Patient Access API, erweitert um Daten zu Vorabgenehmigungen, und die neuen APIs Provider Access, Payer-to-Payer und Prior Authorization. Medicaid-Managed-Care-Pläne, CHIP-Managed-Care-Einrichtungen und Versicherer mit Qualified Health Plans (QHP) auf den Marktplätzen des Bundes folgen mit ihrer ersten Rating Period (Vergütungsperiode) oder ihrem ersten Plan Year (Planjahr), die an oder nach diesem Tag beginnen. Stand 16. Oktober 2026 sind das noch elf Wochen, und CMS hat den Termin nicht verschoben.

Der operative Teil der Regelung gilt bereits. Seit 2026 müssen betroffene Kostenträger jede abgelehnte Vorabgenehmigung konkret begründen, innerhalb fester Fristen entscheiden und Kennzahlen zu Vorabgenehmigungen veröffentlichen.

Wenn Ihre Systeme für Abrechnung, Utilization Management (UM, die Prüfung und Steuerung von Leistungen) und Versichertenverwaltung von einem Anbieter stammen, der diese vier APIs mitliefert, liegt der größte Teil der Entwicklung beim Anbieter. Ihr Anteil sind Konfiguration, digitalisierte Regeln für Vorabgenehmigungen, Mitteilungen an Versicherte und Tests mit Partnern.

Dieser Artikel richtet sich an alle anderen: Versicherer und Behörden, deren Abrechnungs-Engine, UM-Workflow oder Versichertendaten in einem System liegen, das ihnen selbst gehört, ob selbst entwickelt, so weit angepasst, dass keine Updates mehr gehen, oder ein Medicaid Management Information System (MMIS) mit Jahrzehnten lokaler Änderungen. Für solche Systeme liefert niemand die APIs mit. Wir sind Ingenieure, keine Juristen: Dieser Artikel erklärt, was die Regelung von einem System verlangt, nicht, wie sie auf Ihre Verträge anzuwenden ist.

Die Termine

Die Final Rule wurde am 8. Februar 2024 im Federal Register (dem Amtsblatt der US-Bundesregierung) veröffentlicht und trat am 8. April 2024 in Kraft. Für jede der vier APIs legt sie dieselben Fristen fest: „bis zum 1. Januar 2027 für MA-Organisationen und die FFS-Programme der Bundesstaaten für Medicaid und CHIP; bis zur Rating Period, die am oder nach dem 1. Januar 2027 beginnt, für Medicaid-Managed-Care-Pläne und CHIP-Managed-Care-Einrichtungen; und für Plan Years, die am oder nach dem 1. Januar 2027 beginnen, für QHP-Versicherer auf den FFEs.“

Ein Medicaid-Managed-Care-Plan, dessen Rating Periods am 1. Juli beginnen, hat also bis zum 1. Juli 2027 Zeit. Ein Plan mit einem Vertrag nach Kalenderjahr nicht.

CMS nennt weiterhin dasselbe Datum. Die Informationsseite zur Regelung, zuletzt am 8. Oktober 2026 geändert, sagt, dass „betroffene Kostenträger in erster Linie bis zum 1. Januar 2027 Zeit haben, die Anforderungen dieser Final Rule an Programmierschnittstellen (APIs) zu erfüllen“.

Laut Factsheet von CMS umfassen die Pflichten für 2026 Entscheidungen „innerhalb von 72 Stunden bei beschleunigten (d. h. dringenden) Anträgen und sieben Kalendertagen bei Standardanträgen (d. h. nicht dringenden Anträgen)“ (QHP-Versicherer auf den Marktplätzen sind von diesen Fristen ausgenommen), eine konkrete Begründung für jede Ablehnung und öffentliche Kennzahlen, für die gilt: „Die ersten Kennzahlen müssen bis zum 31. März 2026 berichtet werden.“ Die Nutzung der Patient Access API wird CMS ebenfalls jedes Jahr bis zum 31. März gemeldet. Wenn davon etwas noch nicht läuft, ist es bereits verspätet, und es greift auf dieselben Daten zurück wie die APIs.

Arzneimittel sind von alledem ausgenommen. Jede Bestimmung zu Vorabgenehmigungen in CMS-0057-F schließt sie aus.

Wer erfasst ist und wer nicht

Die Regelung nennt sie betroffene Kostenträger (impacted payers): Medicare-Advantage-Organisationen (MA), die Fee-for-Service-Programme (FFS) der Bundesstaaten für Medicaid und CHIP, Medicaid-Managed-Care-Pläne, CHIP-Managed-Care-Einrichtungen und QHP-Versicherer auf den Federally-facilitated Exchanges (FFEs, die vom Bund betriebenen Krankenversicherungsmarktplätze). Ihre Folgenabschätzung zählt „365 Mutterorganisationen, einschließlich der Medicaid- und CHIP-Behörden der Bundesstaaten“, die „für die Einführung und den Betrieb von drei neuen APIs verantwortlich sind“, und hält fest, dass „75 Prozent der Kostenträger in dieser Kategorie weniger als 500 Beschäftigte haben“. Viele davon sind regionale Pläne ohne großes Plattformteam.

Nicht erfasst, zumindest nicht direkt:

• Arbeitgeberpläne außerhalb dieser Programme sowie Original Medicare (das klassische, staatlich verwaltete Medicare). Sie stehen nicht auf der Liste der betroffenen Kostenträger.
• Leistungserbringer. Ihre Seite ist die Kennzahl Electronic Prior Authorization in den Promoting-Interoperability-Programmen von Medicare, erfüllt über zertifizierte EHR-Technologie. Die IPPS-Final-Rule für das Fiskaljahr 2027 vom 4. August 2026 (IPPS ist das Vergütungssystem von Medicare für stationäre Leistungen) hat sie für Krankenhäuser im Jahr 2027 zu einer optionalen Bonuskennzahl gemacht.
• Delegierte UM-Dienstleister und TPAs (Third Party Administrators, externe Abwickler). Sie haben keine eigene Pflicht, aber die des Kostenträgers läuft durch ihre Systeme. Für QHP-Versicherer wiederholt die Regelung, dass sie „für ihre eigene Compliance und die Compliance aller delegierten oder nachgelagerten Stellen verantwortlich sind“.

Auswege gibt es wenige, und so spät hilft keiner davon viel. Ein Bundesstaat kann für sein Medicaid- oder CHIP-FFS-Programm eine einmalige Verlängerung um ein Jahr beantragen, doch der Antrag gehört in sein Advance Planning Document (APD, der Projekt- und Finanzierungsplan gegenüber CMS) und muss „vor dem Stichtag genehmigt“ sein. Ein Bundesstaat, der mindestens 90 Prozent seiner Medicaid-Leistungsberechtigten über Managed Care versorgt, kann eine Befreiung beantragen, und QHP-Versicherer können beim Marktplatz eine Ausnahme beantragen. Zu den Plänen selbst schrieb CMS: „Wir haben keine Verlängerungen oder Befreiungen für MA-Organisationen oder Medicaid-Managed-Care-Pläne vorgeschlagen.“ Für den Aufbau der APIs können Bundesstaaten außerdem erhöhte Bundesmittel mit einem Bundesanteil von 90 Prozent beantragen, die im Einzelfall über das APD genehmigt werden.

Was jede API leisten muss

Alle vier hängen von einer Sache ab, die einem eigenen System oft fehlt: Vorabgenehmigungen als strukturierte Daten mit Statushistorie. Bauen Sie das einmal, und alle vier lesen daraus.

Patient Access API: Vorabgenehmigungen ergänzen

Diese API betreiben Sie seit dem 1. Januar 2021 für Abrechnungen, Encounter-Daten und klinische Daten. Ab 2027 muss sie zusätzlich jede Vorabgenehmigung für Sach- und Dienstleistungen enthalten: ihren Status, das Datum der Genehmigung oder Ablehnung, ihr Ende, die genehmigten Leistungen, bei einer Ablehnung eine konkrete Begründung und die zugehörige strukturierte Dokumentation des Leistungserbringers. Die Daten müssen „spätestens 1 Geschäftstag nach“ dem Eingang des Antrags beim Kostenträger verfügbar sein, innerhalb eines Geschäftstags nach jeder Statusänderung aktualisiert werden und so lange vorgehalten werden, wie die Genehmigung aktiv ist, und mindestens ein Jahr nach ihrer letzten Änderung.

Ein UM-System, das Entscheidungen als Freitextnotizen festhält oder den Status nur per Fax verschickt, kann diese Daten nicht ohne Änderungen liefern.

Provider Access API

Leistungserbringer im Netz des Kostenträgers können die Daten eines Patienten abrufen: Abrechnungen und Encounter-Daten ohne Zahlungsavise an Leistungserbringer und ohne Kostenbeteiligung, die klinischen Datenklassen der USCDI (der US-Kerndatensatz für den Austausch von Gesundheitsdaten) und Informationen zu Vorabgenehmigungen, für Leistungen ab dem 1. Januar 2016. Der Kostenträger antwortet innerhalb eines Geschäftstags, aber nur für Patienten, die er diesem Leistungserbringer zugeordnet hat und die nicht widersprochen haben.

Dafür braucht es drei Dinge, die ein Altsystem selten hat. Einen Zuordnungsprozess (Attribution), der Versicherte mit Leistungserbringern verknüpft. Ein Opt-out, das der Versicherte jederzeit ändern kann, mit verständlichen Hinweisen vor der ersten Nutzung, innerhalb einer Woche nach Versicherungsbeginn und jedes Jahr. Und einen Massenexport, denn zu den vorgeschriebenen Standards gehört FHIR Bulk Data Access, für einen Leistungserbringer, der nach seinem gesamten Patientenstamm fragt.

Payer-to-Payer API

Kommt ein Versicherter neu hinzu, bittet der neue Kostenträger um Erlaubnis (hier gilt Opt-in) und beginnt innerhalb einer Woche nach Versicherungsbeginn, frühere und parallele Kostenträger zu ermitteln. Sobald er sie kennt, fordert er innerhalb einer Woche die Daten aus fünf Jahren an: Abrechnungen und Encounter-Daten ohne Zahlungsavise und Kostenbeteiligung, USCDI-Daten und Vorabgenehmigungen außer abgelehnten, mit ihrer unstrukturierten Dokumentation. Der frühere Kostenträger antwortet innerhalb eines Geschäftstags. Bei paralleler Versicherung wiederholt sich der Austausch mindestens vierteljährlich.

Schwierig ist nicht die ausgehende Antwort. Schwierig ist es, Daten von Kostenträgern anzunehmen, mit denen Sie nie getestet haben, und sie in Ihre Versichertenakte zu übernehmen, wie es die Regelung verlangt.

Prior Authorization API

Diese API reicht bis in den Kern des UM. Sie muss die versicherten Leistungen auflisten, die eine Vorabgenehmigung erfordern, für jede die nötige Dokumentation nennen, einen HIPAA-konformen Antrag und eine HIPAA-konforme Antwort unterstützen und angeben, ob der Kostenträger genehmigt hat (mit Enddatum), abgelehnt hat (mit konkreter Begründung) oder weitere Informationen braucht.

CMS empfiehlt hier drei Da-Vinci-Implementierungsleitfäden, schreibt sie aber nicht vor: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) und Prior Authorization Support (PAS). In der Praxis müssen Ihre Leistungsregeln und Dokumentationsfragebögen maschinenlesbar werden, statt als PDF in einem Richtlinienhandbuch zu stehen. Kostenträger in der Umfrage von WEDI (einem US-Branchenverband für elektronischen Datenaustausch im Gesundheitswesen) zählten „die Digitalisierung der Richtlinien für Vorabgenehmigungen“ zu ihren drei größten Herausforderungen.

Bei der Transaktion selbst hat das Gesundheitsministerium HHS den Kostenträgern Spielraum gelassen. Am 28. Februar 2024 kündigte es an, von der Durchsetzung abzusehen (Enforcement Discretion): Laut CMS wird die National Standards Group von CMS „keine Durchsetzungsmaßnahmen nach der HIPAA Administrative Simplification gegen HIPAA-pflichtige Stellen ergreifen, die sich entscheiden, den Standard X12 278 im Rahmen eines elektronischen FHIR-Prozesses für Vorabgenehmigungen nicht zu verwenden“. Sie können also nur auf FHIR bauen oder FHIR mit X12 kombinieren und daneben eine reine X12-Transaktion beibehalten.

Die Standards

Vorgeschrieben sind HL7 FHIR Release 4.0.1, US Core, SMART App Launch, Bulk Data Access und OpenID Connect Core; neuere Versionen dürfen Kostenträger unter Bedingungen freiwillig verwenden. Die Regelung von 2024 nannte US Core 3.1.1 und SMART App Launch 1.0.0 mit einem Ablaufdatum zum 1. Januar 2026. Legen Sie also fest, auf welche Versionen Sie bauen, bevor jemand das Mapping schreibt.

Wo eigene Systeme meist nicht ausreichen

Ausgehend von dem, was die Regelung verlangt, sollten Sie zuerst nach diesen Lücken suchen:

• Vorabgenehmigung als Datensatz, nicht als Dokument. Status, Zeitstempel, Codes für Ablehnungsgründe und das Enddatum müssen Felder sein, die bei jeder Änderung geschrieben werden, mit Historie. Eine per Fax verschickte Entscheidung braucht ein strukturiertes Gegenstück.
• Die Leistungsregeln. Welche Leistungen eine Genehmigung brauchen und welche Dokumentation jeweils nötig ist, muss als Daten vorliegen, die die API ausliefern kann. Bei vielen Plänen steckt das in PDF-Richtlinien und in den Köpfen der Prüfer.
• Abrechnungen als FHIR. Abrechnungen und Encounter-Daten müssen als FHIR-Ressourcen herauskommen, für Leistungserbringer und andere Kostenträger ohne Zahlungsavise und Kostenbeteiligung, für den Versicherten aber mit.
• Identität und Historie der Versicherten. Um die Daten eines anderen Kostenträgers Ihrem Versicherten zuzuordnen und die früheren Kostenträger eines neuen Versicherten zu finden, brauchen Sie demografische Daten und eine Versicherungshistorie, die Sie vielleicht nicht an einem Ort führen.
• Einwilligungsstatus. Ein Opt-out für Provider Access und ein Opt-in für Payer-to-Payer, beide jederzeit änderbar und bei jeder Anfrage geprüft. Ein Bundesstaat muss das Opt-in einer leistungsberechtigten Person außerdem an deren Medicaid-Managed-Care-Pläne weitergeben.
• Die Frist von einem Geschäftstag. Ein nächtlicher Mainframe-Batch reicht für manche Daten und ist für andere zu langsam. Messen Sie die Zeit von der Entscheidung bis zur API, nicht nur, ob die API antwortet.
• Delegierte Dienstleister. Wenn ein delegierter UM-Dienstleister die Entscheidungen trifft, müssen seine Daten Sie rechtzeitig für Ihre Pflicht von einem Geschäftstag erreichen. Die WEDI-Umfrage vom Februar 2026 setzte „delegierte Dritte, die Schwierigkeiten haben, sich mit verschiedenen Systemen zu verbinden“ an die erste Stelle der Herausforderungen der Kostenträger.

Wie weit die Branche ist

Die Umfrage von WEDI vom Februar 2026, veröffentlicht am 10. März 2026, ergab für die API-Anforderungen: „10 % haben mit ihrer Arbeit noch nicht begonnen“, gegenüber 33 % im Oktober 2025. Sie meldete außerdem „einen deutlichen Anstieg bei geschätzten Kosten von über 5 Millionen US-Dollar, von 15 % (Okt. ’25) auf 25 % (Feb. ’26)“. Die Stichprobe ist klein: 86 Antworten, 52 % davon von Kostenträgern. Lesen Sie sie als Signal, nicht als Vollerhebung.

Ein Elf-Wochen-Plan bis zum 1. Januar 2027

Ab Mitte Oktober hat eine MA-Organisation oder ein FFS-Programm eines Bundesstaats etwa elf Wochen. Das reicht nicht, um vier APIs aus dem Nichts zu bauen. Im Plan geht es deshalb um die Reihenfolge und darum, was Sie am ersten Tag vorweisen können.

1. Diese Woche: Termin und Ausgangslage klären. Der 1. Januar oder eine spätere Rating Period oder ein späteres Plan Year? Listen Sie auf, was schon läuft: die Patient Access API und die Provider Directory API, die Kennzahlen für 2026, die Ablehnungsgründe.
2. Wochen 1 bis 2: jedes Datenelement seiner Quelle zuordnen. Halten Sie für jede API fest, welches System die Daten heute führt (Abrechnung, UM, Versichertenbestand, Leistungserbringernetz, klinische Daten) und wie aktuell sie sind.
3. Wochen 1 bis 3: entscheiden, wo die FHIR-Schicht liegt. Ein FHIR-Server oder eine Fassade vor den Altsystemen, gespeist aus Änderungsereignissen oder häufigen Extrakten, ist meist schneller, als dem Kernsystem FHIR beizubringen. Die Zeit steckt im Mapping und in den Datenfeeds.
4. Wochen 2 bis 7: zuerst die gemeinsamen Bausteine bauen. Der Datensatz für Vorabgenehmigungen, Einwilligung und Zuordnung, der Abgleich von Versicherten. Alle vier APIs hängen davon ab.
5. Wochen 4 bis 9: die APIs bauen. Die Erweiterungen der Patient Access API, Provider Access mit Massenexport, Payer-to-Payer in beide Richtungen und die Prior Authorization API mit hinterlegten Leistungsregeln.
6. Wochen 8 bis 11: mit echten Gegenstellen testen. Der EHR-Anbieter eines Leistungserbringers, ein anderer Kostenträger, Ihr delegierter UM-Dienstleister. Testen Sie Änderungen der Einwilligung, eine Ablehnung mit Begründung und eine Statusänderung, die den Versicherten innerhalb eines Geschäftstags erreicht.
7. 1. Januar 2027: live gehen und messen. Messen Sie vom ersten Tag an die Latenz gegen die Fristen von einem Geschäftstag, und führen Sie eine datierte Liste dessen, was noch nicht fertig ist.

Wenn elf Wochen nicht reichen, bringen Sie das jetzt zu Ihrem Compliance-Team und Ihrer Rechtsberatung, nicht erst im Dezember, mit einem Plan, der zeigt, was am 1. Januar live ist und was wann folgt.

Ein Medicaid-Managed-Care-Plan mit einer Rating Period ab dem 1. Juli 2027 oder ein QHP-Versicherer mit einem späteren Plan Year kann dieselben Schritte mit mehr Luft gehen. Fangen Sie trotzdem jetzt an: Die Kostenträger und Leistungserbringer, mit denen Sie testen werden, gehen am 1. Januar live.

Was sich noch bewegen kann

CMS-0062-P. Am 14. April 2026 veröffentlichte CMS den Entwurf einer Folgeregelung. Sie würde die derzeit empfohlenen Implementierungsleitfäden ab dem 1. Oktober 2027 verpflichtend machen und ab demselben Datum Arzneimittel in die elektronische Vorabgenehmigung aufnehmen, und HHS würde FHIR anstelle von X12 278 als HIPAA-Standard für Transaktionen zur Vorabgenehmigung übernehmen. Zu den bestehenden Fristen heißt es: „Dieser Vorschlag würde diese Fristen nicht ändern.“ Die Kommentierungsfrist endete am 15. Juni 2026, und Stand 16. Oktober 2026 ist keine Final Rule im Federal Register erschienen. Bauen Sie nach der Regelung von 2024, und halten Sie Ihre Leitfadenversionen an einer einzigen konfigurierbaren Stelle.

Versionen. Die Da-Vinci-Leitfäden entwickeln sich weiter. Die IPPS-Final-Rule für das Fiskaljahr 2027 hält fest, dass EHRs, die nach den neuen Kriterien der ONC (der US-Behörde für Gesundheits-IT) für Vorabgenehmigungen zertifiziert sind, „die Verwendung von Version 2.2 der Da-Vinci-IGs erfordern werden“. Das sind die Systeme, mit denen Ihre Prior Authorization API sprechen wird.

Nichts davon ist ein Grund zu warten. Die Regelung ist endgültig, die Termine stehen im Verordnungstext, und CMS hat sie am 8. Oktober wiederholt.

Wo Sie Hilfe bekommen

Wir arbeiten an den Systemen hinter den APIs: FHIR-Mapping von Abrechnungs-, Encounter- und Genehmigungsdaten, Änderungsfeeds aus älteren Abrechnungs- und UM-Plattformen, Logik für Einwilligung und Zuordnung und die Tests, die zeigen, dass die Fristen von einem Geschäftstag eingehalten werden. Unsere Wartung von Bestandssystemen ist der Einstieg, wenn das Kernsystem alt ist oder die Leute, die es gebaut haben, nicht mehr da sind, und wenn die Frist mitten in eine Plattformablösung fällt, lesen Sie die Seite zur ERP-Modernisierung.

Wenn Ihre Abrechnungs- oder UM-Plattform eine ist, für die kein Anbieter diese APIs liefern wird, schreiben Sie an office@c9group.dev. Wir sind Ingenieure, keine Juristen für Gesundheitsrecht: Fragen zum Geltungsbereich und zu Verträgen gehören zu Ihrer Rechtsberatung, und wir bauen nach deren Antwort.