CMS-0057-F Final Rule: 4 FHIR APIs bis 2027

Was ist die CMS-0057-F Final Rule?

CMS-0057-F ist die Regel, die Vorabgenehmigungen und den Datenaustausch zwischen Kostenträgern in einen technischen Umsetzungstermin verwandelt. Die am 8. Februar 2024 im Federal Register veröffentlichte CMS Interoperability and Prior Authorization Final Rule gibt regulierten Krankenversicherungsplänen ein festes Datum vor – den 1. Januar 2027 –, bis zu dem vier produktive FHIR APIs betrieben werden müssen. Hinzu kommen operative Regeln zur Vorabgenehmigung, die bereits seit einem Jahr zuvor in Kraft sind. CMS schätzt, dass die Regel dem Gesundheitssystem über zehn Jahre hinweg rund 15 Milliarden US-Dollar einsparen wird, hauptsächlich durch die Reduzierung von Reibungsverlusten bei der Vorabgenehmigung.

Im Mittelpunkt der Regel stehen vier HL7 FHIR R4 APIs. Eine davon betreiben Sie möglicherweise bereits in irgendeiner Form. Drei sind neu.

• Patient Access API: Ermöglicht es Mitgliedern, ihre Abrechnungs-, klinischen und Vorabgenehmigungsdaten in Apps von Drittanbietern abzurufen.
• Provider Access API: Teilt Abrechnungs- und klinische Daten für die einem Leistungserbringer zugeordneten Mitglieder, und zwar in großen Mengen (Bulk).
• Payer-to-Payer API: Überträgt die Vorgeschichte eines Mitglieds zu seinem neuen Plan, wenn es den Kostenträger wechselt.
• Prior Authorization API: Führt den elektronischen Vorabgenehmigungsprozess von Anfang bis Ende durch.

Das Muster ist bei allen vier APIs dasselbe. Jede stellt Daten, die Sie bereits besitzen, über eine standardisierte Schnittstelle einem bestimmten Personenkreis zur Verfügung. Deshalb liegt der eigentliche Aufwand weniger im Aufbau der APIs selbst als in den dahinterliegenden Daten. Wie dieser Aufwand im Einzelnen aussieht, unterscheidet sich je nach API – die folgenden Abschnitte behandeln jede API gesondert.

Wer muss die Vorschriften einhalten, und wer ist befreit?

Die Regel gilt für sechs Arten von Kostenträgern: Medicare-Advantage-Organisationen, staatliche Medicaid- und CHIP-Fee-for-Service-Programme, Medicaid Managed Care Organizations, CHIP Managed Care Entities sowie Anbieter von Qualified Health Plans auf den bundesweit betriebenen Börsen. Wenn Sie eine dieser Organisationen betreiben, müssen Sie alle vier APIs aufbauen.

Viele Organisationen fallen nicht unter die Regel. Das traditionelle Medicare, arbeitgeberfinanzierte ERISA-selbstversicherte Pläne, eigenständige Part-D-Arzneimittelpläne und Medigap sind nicht erfasst. Delegierte Einheiten sind eine häufigere Quelle von Verwirrung. Ein Nutzungsmanagement-Anbieter, TPA, MSO oder IPA wird durch CMS-0057-F selbst nicht reguliert. Die Verpflichtung verbleibt beim Kostenträger, auch für Funktionen, die der Kostenträger auslagert. In der Praxis bedeutet das: Ein Plan, der die Vorabgenehmigung delegiert, muss dennoch eine konforme Prior Authorization API bereitstellen. Er muss diese API also entweder über das System des Anbieters aufbauen oder vom Anbieter verlangen, dass er sie bereitstellt. Der Anbieter wird auf kommerziellem Wege einbezogen, nicht weil die Regel ihn namentlich nennt.

Es gibt eine Ausnahme, die es wert ist, festgehalten zu werden, da sie das Detail ist, das die meisten Menschen falsch verstehen. QHP-Anbieter auf den Börsen sind nicht an die Entscheidungsfristen für Vorabgenehmigungen gebunden. Diese gelten für Medicare Advantage, Medicaid und CHIP. Alles andere gilt weiterhin für QHPs: alle vier APIs, die Regel zur Angabe spezifischer Ablehnungsgründe und die öffentliche Berichterstattung über Kennzahlen. Wenn Sie also einen QHP betreiben, planen Sie den API-Aufbau in vollem Umfang und lassen Sie die Entscheidungsfrist außer Acht.

Zwei Fristen, zwei Arten von Arbeit

Die Regel hat zwei Termine im Kalender gesetzt, und sie erfordern unterschiedliche Teams.

Der erste, der 1. Januar 2026, liegt bereits hinter uns. Seitdem müssen betroffene Kostenträger (QHPs ausgenommen, was die Fristen betrifft) Vorabgenehmigungsentscheidungen innerhalb von 72 Stunden bei dringenden Anfragen und sieben Kalendertagen bei Standardanfragen treffen, für jede Ablehnung einen spezifischen Grund angeben und jährlich Kennzahlen zur Vorabgenehmigung auf ihrer Website veröffentlichen. Der erste dieser öffentlichen Berichte war bis zum 31. März 2026 fällig, umfasste das Kalenderjahr 2025 und wird jährlich wiederholt. Dies ist eine Aufgabe für Politik und Prozesse. Sie können sie mit Änderungen an Arbeitsabläufen und Governance-Strukturen erfüllen.

Der zweite Termin, der 1. Januar 2027, ist die API-Frist – und der schwierigere. Er ist technischer Natur, und Sie können ihn nicht mit einem Memo schließen. Die vier folgenden Abschnitte beschreiben, was diese technische Umsetzung konkret beinhaltet.

Patient Access API

Patient Access ist die eine API, die die meisten betroffenen Pläne bereits in irgendeiner Form betreiben, da sie auf die Regel von 2020 zurückgeht. Ein Mitglied autorisiert eine Drittanbieter-App, und der Plan gibt seine Daten über einen mit OAuth 2.0 gesicherten SMART on FHIR-Flow an diese zurück. Das Mitglied hält die Autorisierung und kann sie widerrufen.

Was darüber übermittelt wird, ist umfangreich: abgerechnete Ansprüche und Begegnungsdaten im CARIN-Blue-Button-Format, klinische Daten als USCDI und, für Pläne mit Arzneimittelabdeckung, Formulardaten. CMS-0057-F fügt bis zum 1. Januar 2027 eine Sache hinzu: Informationen zur Vorabgenehmigung – Status und spezifischer Grund –, für alles außer Arzneimitteln.

Der Aufwand liegt selten beim Endpunkt selbst. Er liegt in der Datenqualität dahinter: korrekte Zuordnung von Ansprüchen, Aktualität des Feeds und Verantwortlichkeit für Lücken. Pläne melden CMS jährlich auch Nutzungskennzahlen zur Patient Access API. Gut umgesetzt ist diese API mehr als eine Compliance-Fläche. Dieselbe saubere, mitgliedsorientierte Datenschicht kann auch Ihre eigene Mitglieder-App oder Ihr Portal unterstützen.

Provider Access API

Provider Access ist neu, und hier unterschätzen Teams den Aufwand – denn es ist nicht nur ein Endpunkt. Es gibt einem im Netzwerk befindlichen Leistungserbringer Zugang zu den Abrechnungs- und Begegnungsdaten, klinischen USCDI-Daten und Vorabgenehmigungsinformationen der ihm zugeordneten Mitglieder, geliefert als Bulk-Export.

Das Authentifizierungsmodell unterscheidet sich von Patient Access. Kein Patient klickt auf „Genehmigen". Der Plan authentifiziert die Leistungserbringerorganisation als System über SMART Backend Services und führt einen FHIR Bulk Data-Export über die zugeordnete Mitgliedergruppe des Leistungserbringers durch. Der Aufwand liegt nicht beim Export, sondern bei der Governance drumherum:

• Zuordnung (Attribution). Der Plan muss wissen, welche Leistungserbringer eine Behandlungsbeziehung mit welchen Mitgliedern haben, und diese Zuordnungslisten aktuell halten.
• Opt-out. Mitglieder können die Weitergabe ihrer Daten an Leistungserbringer ablehnen, und der Plan muss diese Entscheidung respektieren und nachverfolgen.

Wenn diese beiden Punkte korrekt umgesetzt sind, ist der Export selbst Routine.

Payer-to-Payer API

Payer-to-Payer ist zunächst ein Identitäts- und Einwilligungsprojekt, bevor es ein API-Projekt ist. Wenn ein Mitglied Ihrem Plan beitritt, haben Sie eine Woche Zeit, den vorherigen Kostenträger nach bis zu fünf Jahren Vorgeschichte zu fragen – Ansprüche, klinische Daten und Vorabgenehmigungsunterlagen –, damit Sie mit Kontext statt mit einer leeren Akte beginnen. Wenn ein Mitglied den Plan verlässt, befinden Sie sich auf der anderen Seite dieses Austauschs und antworten dem neuen Plan. Kostendaten, Leistungserbringerabrechnungen und Kostenbeteiligungen der Versicherten sind ausgenommen.

Die Übertragung selbst ist der einfache Teil. Die schwierigen Teile sind die zwei Hürden davor. Member Matching: Sie und der andere Plan müssen sich darüber einigen, dass Sie über dieselbe Person sprechen, die in verschiedenen Systemen unter unterschiedlichen Kennungen geführt wird, ohne gemeinsamen Schlüssel. Einwilligung: Anders als bei Provider Access werden keine Daten übertragen, wenn das Mitglied nicht ausdrücklich zustimmt. Sie benötigen daher eine Möglichkeit, diese Zustimmung zu erfassen und zu berücksichtigen. Bei Mitgliedern, die gleichzeitig bei mehr als einem Plan versichert sind, erfolgt der Austausch mindestens vierteljährlich statt einmalig bei der Einschreibung.

Prior Authorization API

Die ersten drei APIs veröffentlichen oder verschieben Daten. Die Prior Authorization API ist ein anderes Wesen: Sie führt eine Transaktion durch. Ein Leistungserbringer stellt Ihrem Plan eine Frage, und Ihr Plan muss innerhalb einer festgelegten Frist mit einer echten Entscheidung antworten. Dies ist eine Geschäftsprozessintegration, keine Datenbereitstellung – weshalb sie die schwierigste der vier APIs ist und den umfassendsten Satz an Standards erfordert.

Drei Da-Vinci-Implementierungsleitfäden greifen ineinander, um diesen Prozess zu steuern. Es beginnt mit CRD, Coverage Requirements Discovery. Wenn ein Leistungserbringer einen Artikel oder eine Leistung anordnet oder plant, löst ein Hook aus dem EHR aus, und Ihr Plan antwortet in Echtzeit: Ist eine Vorabgenehmigung erforderlich, und welche Dokumentation wird benötigt? Falls ja, übergibt DTR, Documentation Templates and Rules, dem EHR einen intelligenten Fragebogen und füllt vor, was aus der Akte entnommen werden kann, damit der Leistungserbringer keine Daten erneut eingeben muss, die das System bereits kennt. Schließlich übermittelt PAS, Prior Authorization Support, die Anfrage und gibt die Entscheidung zurück: genehmigt, abgelehnt mit einem spezifischen Grund oder ausstehend für weitere Informationen. CMS empfiehlt diese Leitfäden, schreibt sie aber nicht formal vor.

Hier muss auch ein häufiges Missverständnis korrigiert werden. FHIR ersetzt X12 nicht. Der PAS-Leitfaden ist darauf ausgelegt, die HIPAA-mandatierte X12-278-Transaktion zu transportieren, sodass die zugrunde liegende Anfrage und Antwort weiterhin X12 sind. Ein Kostenträger kann das Backend als rein FHIR-basiert, rein X12-basiert oder als Hybrid beider Ansätze betreiben und dabei die Anforderungen der Regel erfüllen. Zusätzliche klinische Dokumentation wird über einen separaten Da-Vinci-Mechanismus, CDex, übermittelt, anstatt in die Genehmigungsnachricht selbst gepresst zu werden.

Ein weiteres Element verbindet die Kostenträgerseite mit den Leistungserbringern. Ab der Leistungsperiode 2027 bestätigen förderfähige Kliniker und Krankenhäuser im Rahmen des Medicare Promoting Interoperability-Programms, dass sie mindestens eine Vorabgenehmigung elektronisch über eine Prior Authorization API angefordert haben. Diese Maßnahme ist das Nachfragesignal. Deshalb ist Ihre Prior Authorization API nicht nur ein Compliance-Endpunkt, sondern etwas, das Ihr Leistungserbringernetzwerk nun erwartet wird zu nutzen.

Was sich gegenüber der Regel von 2020 geändert hat

Wenn CMS-0057-F vertraut erscheint, liegt das daran, dass sie auf CMS-9115-F aufbaut, der Interoperability and Patient Access Final Rule von 2020. Diese frühere Regel hat die Patient Access API und die Provider Directory API eingeführt. Sie sah auch einen Payer-to-Payer-Datenaustausch vor, aber CMS hat diese Bestimmung nie durchgesetzt, und sie war nie API-basiert.

CMS-0057-F vollendet das Werk. Sie behält die früheren APIs bei, baut Payer-to-Payer als durchsetzbare FHIR API neu auf, fügt Provider Access und Prior Authorization hinzu, integriert Vorabgenehmigungsdaten in Patient Access und ergänzt die operativen Fristen sowie die öffentliche Berichterstattung. Die Richtung ist konsistent. Umfang und Durchsetzungskraft sind neu. CMS hat der Regel keine spezifische Geldstrafe beigefügt, setzt sie jedoch über die Befugnisse durch, die es bereits gegenüber den einzelnen Programmen besitzt – Medicare-Advantage-Verträge, Medicaid- und CHIP-Aufsicht sowie QHP-Zertifizierung. Das Risiko ist vertraglich und regulatorisch, nicht als veröffentlichter Dollarbetrag.

Wie Health Samurai helfen kann

Payerbox ist die CMS-0057-F-Plattform von Health Samurai für Krankenversicherungspläne, aufgebaut auf unserem FHIR-R4-nativen Aidbox-Kern. Sie implementiert alle vier APIs mit Produktionsunterstützung für die Da-Vinci-Leitfäden zur Vorabgenehmigung – CRD, DTR und PAS.

Das Designprinzip entspricht dem, was ein enger Zeitplan tatsächlich erfordert: integrieren, nicht ersetzen. Ihre Abrechnungsplattform, Ihr UM-System und Ihr Verzeichnis bleiben, wo sie sind. Payerbox sitzt davor, liest ihre Daten und übersetzt sie in konformes FHIR für jede API. Der Mehrwert liegt nicht darin, Datensätze in ein neues System zu verschieben, sondern darin, die Datensätze, die Sie bereits besitzen, korrekt über eine Standardschnittstelle bereitzustellen.

Diese FHIR-Schicht zahlt sich auch nach der Frist weiterhin aus. Der Datenspeicher, den Sie für die vier APIs aufbauen, ist gleichzeitig ein Analysedatenspeicher: Dieselben normalisierten Daten fließen in die Risikoanpassung, Stars- und Qualitätskennzahlen sowie die Bevölkerungsgesundheit ein. Compliance-Ausgaben werden zu einem wiederverwendbaren Datenwert statt zu einer einmaligen Hülle, und die nächste regulatorische Anforderung trifft auf Daten, die Sie bereits standardisiert haben.

Dies ist Produktionssoftware, kein Versprechen auf Folien. Payerbox ist heute bei Kostenträgern im Einsatz. VillageCareMAX betreibt seine Patient Access API auf Payerbox und belegte Platz 2 mit 91 von 100 Punkten in Flexpa's unabhängigem Kostenträger-Scorecard vom November 2025 – damit ist es nicht nur im Einsatz, sondern zählt zu den besten. Ein delegierter Vorabgenehmigungsanbieter betreibt den vollständigen Payerbox-ePA-Stack – CRD, DTR und PAS – in der Produktion. Und wir halten den Stack konform, indem wir ihn zum HL7 Da Vinci Connectathon Burden Reduction Track bringen.

Wenn Sie eine Einschätzung auf Architektenebene erhalten möchten, wo Ihr Plan im Hinblick auf die Januar-2027-Frist steht, führt Health Samurai eine CMS-0057-F-Bereitschaftsprüfung durch. Wir erfassen Ihre Verpflichtungen, analysieren Ihre Quellsysteme und zeigen Ihnen, wie eine Payerbox-Implementierung für Ihren verbleibenden Zeitplan aussieht.

Siehe auch: CMS-Compliance-Implementierung und Aidbox g(10)-Zertifizierung.