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

Was ist die CMS-0057-F Final Rule?

CMS-0057-F ist die Verordnung, die Vorabgenehmigungen und den Datenaustausch zwischen Kostenträgern in eine technische Umsetzungspflicht mit fester Frist verwandelt. Die am 8. Februar 2024 im Federal Register veröffentlichte CMS Interoperability and Prior Authorization Final Rule gibt regulierten Krankenversicherungsplänen einen festen Termin vor – den 1. Januar 2027 – um vier produktive FHIR APIs zu betreiben, zuzüglich einer Reihe operativer Vorabgenehmigungsregeln, die bereits ein Jahr früher in Kraft traten. CMS schätzt, dass die Verordnung dem Gesundheitssystem über zehn Jahre hinweg rund 15 Milliarden US-Dollar einsparen wird, hauptsächlich durch den Abbau von Reibungsverlusten bei Vorabgenehmigungen.

Im Mittelpunkt der Verordnung 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 Ansprüche, klinischen Daten und Informationen zu Vorabgenehmigungen über Drittanbieter-Apps abzurufen.
• Provider Access API: gibt Ansprüche und klinische Daten für die einem Leistungserbringer zugeordneten Mitglieder im Bulk-Verfahren weiter.
• Payer-to-Payer API: überträgt die Krankengeschichte eines Mitglieds bei einem Versicherungswechsel an den neuen Plan.
• Prior Authorization API: wickelt den gesamten elektronischen Vorabgenehmigungsprozess von Anfang bis Ende ab.

Das Muster ist bei allen vier gleich. Jede API stellt Daten, die Sie bereits vorhalten, über eine standardisierte Schnittstelle einem bestimmten Personenkreis zur Verfügung. Deshalb liegt die eigentliche Arbeit weniger im Aufbau der APIs selbst als vielmehr in den dahinterstehenden Daten. Wie dieser Aufwand konkret aussieht, unterscheidet sich je nach API – die folgenden Abschnitte behandeln jede einzelne im Detail.

Wer muss die Anforderungen erfüllen, und wer ist ausgenommen?

Die Verordnung gilt für sechs Arten von Kostenträgern: Medicare Advantage-Organisationen, staatliche Medicaid- und CHIP-Fee-for-Service-Programme, Medicaid Managed Care-Organisationen, CHIP Managed Care-Einheiten sowie Anbieter von Qualified Health Plans (QHPs) an den bundesweit organisierten Börsen. Wenn Sie einen dieser Pläne betreiben, müssen Sie alle vier APIs entwickeln.

Viele Organisationen fallen nicht unter die Verordnung. Traditionelles Medicare, arbeitgeberfinanzierte ERISA-Selbstversicherungspläne, eigenständige Part D-Medikamentenpläne und Medigap sind nicht erfasst. Delegierte Einheiten sind eine häufigere Quelle der Verwirrung. Ein Utilization-Management-Anbieter, TPA, MSO oder IPA wird durch CMS-0057-F nicht direkt reguliert. Die Verpflichtung verbleibt beim Kostenträger, auch für Funktionen, die er auslagert. In der Praxis bedeutet das: Ein Plan, der die Vorabgenehmigung delegiert, muss trotzdem eine konforme Prior Authorization API bereitstellen – er baut diese API entweder über das System des Anbieters oder verlangt, dass der Anbieter sie zur Verfügung stellt. Der Anbieter wird kommerziell eingebunden, nicht weil die Verordnung ihn namentlich nennt.

Es gibt eine Ausnahme, die es sich lohnt festzuhalten, da sie der am häufigsten missverstandene Detail ist. QHP-Anbieter an 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-Aufwand vollständig ein und lassen Sie die Entscheidungsfristen außen vor.

Zwei Fristen, zwei Arten von Aufwand

Die Verordnung setzt zwei Termine, die unterschiedliche Teams erfordern.

Der erste, der 1. Januar 2026, liegt bereits hinter uns. Seitdem müssen betroffene Kostenträger (QHPs ausgenommen bei den Fristen) Entscheidungen zur Vorabgenehmigung innerhalb von 72 Stunden für dringende Anfragen und innerhalb von sieben Kalendertagen für Standardanfragen treffen, einen spezifischen Grund für jede Ablehnung angeben und jährlich Kennzahlen zu Vorabgenehmigungen auf ihrer Website veröffentlichen. Der erste dieser öffentlichen Berichte war bis zum 31. März 2026 fällig und bezog sich auf das Kalenderjahr 2025; er wird jährlich wiederholt. Dies ist eine Aufgabe für Richtlinien und Prozesse, die sich durch Änderungen im Arbeitsablauf und in der Governance lösen lässt.

Der zweite Termin, der 1. Januar 2027, ist die API-Frist – und die ist anspruchsvoller. Sie ist technischer Natur und lässt sich nicht mit einem Memo schließen. Die vier folgenden Abschnitte beschreiben, was dieser technische Aufwand konkret umfasst.

Patient Access API

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

Der Umfang der übermittelten Daten ist breit: abgerechnete Ansprüche und Begegnungsdaten im CARIN Blue Button-Format, klinische Daten gemäß USCDI und – bei Plänen mit Medikamentendeckung – Formulardaten. CMS-0057-F ergänzt bis zum 1. Januar 2027 eine weitere Anforderung: Informationen zu Vorabgenehmigungen – Status und spezifischer Grund – für alles außer Medikamenten.

Die eigentliche Herausforderung liegt selten im Endpunkt selbst. Sie liegt in der Datenqualität dahinter: der korrekten Zuordnung von Ansprüchen, der Aktualität des Datenfeeds und dem Umgang mit Lücken. Pläne müssen außerdem jährlich Nutzungskennzahlen zur Patient Access API an CMS melden. Gut umgesetzt, ist diese API mehr als eine Compliance-Oberfläche. Die gleiche aufgeräumte, mitgliederorientierte Datenschicht kann auch die eigene Mitglieder-App oder das eigene Portal unterstützen.

Provider Access API

Provider Access ist neu und der Bereich, in dem Teams den Aufwand unterschätzen – denn es handelt sich nicht nur um einen Endpunkt. Es gibt einem netzwerkangehörigen Leistungserbringer Zugang zu den Ansprüchen, Begegnungsdaten, klinischen USCDI-Daten und Vorabgenehmigungsinformationen der ihm zugeordneten Mitglieder, bereitgestellt im Bulk-Verfahren.

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 dem Leistungserbringer zugeordnete Mitgliedergruppe durch. Der Aufwand liegt nicht im Export selbst, sondern in der Governance darum herum:

• Zuordnung. Der Plan muss wissen, welche Leistungserbringer ein Behandlungsverhältnis mit welchen Mitgliedern haben, und diese Zuordnungslisten aktuell halten.
• Widerspruchsrecht. Mitglieder können die Weitergabe ihrer Daten an Leistungserbringer ablehnen, und der Plan muss diese Entscheidung berücksichtigen und nachverfolgen.

Sind diese beiden Punkte geklärt, ist der Export selbst Routine.

Payer-to-Payer API

Payer-to-Payer ist zuerst ein Identitäts- und Einwilligungsprojekt, bevor es ein API-Projekt ist. Wenn ein Mitglied Ihrem Plan beitritt, haben Sie eine Woche Zeit, beim vorherigen Kostenträger bis zu fünf Jahre Krankengeschichte anzufordern – Ansprüche, klinische Daten und Vorabgenehmigungsaufzeichnungen – damit Sie mit Kontext statt mit einer leeren Akte beginnen. Wenn ein Mitglied den Plan verlässt, befinden Sie sich auf der anderen Seite dieser Anfrage und antworten dem neuen Plan. Kostendaten, Vergütungen für Leistungserbringer und der Eigenanteil der Versicherten sind ausgenommen.

Die Übertragung ist der einfache Teil. Die schwierigen Teile sind die zwei Hürden davor. Mitgliederabgleich: Sie und der andere Plan müssen sich einigen, dass Sie über dieselbe Person sprechen – trotz unterschiedlicher Identifikatoren und ohne gemeinsamen Schlüssel. Einwilligung: Anders als bei Provider Access wird nichts übermittelt, solange das Mitglied nicht ausdrücklich zustimmt; daher benötigen Sie eine Möglichkeit, diese Einwilligung einzuholen und zu berücksichtigen. Bei Mitgliedern, die gleichzeitig über mehr als einen Plan versichert sind, erfolgt der Austausch mindestens vierteljährlich statt einmalig bei der Aufnahme.

Prior Authorization API

Die ersten drei APIs veröffentlichen oder übertragen Daten. Die Prior Authorization API ist ein anderes Tier: Sie führt eine Transaktion durch. Ein Leistungserbringer stellt Ihrem Plan eine Anfrage, und Ihr Plan muss innerhalb einer festgelegten Frist mit einer echten Entscheidung antworten. Dies ist eine Geschäftsprozessintegration, keine Datenbereitstellung – weshalb sie die anspruchsvollste der vier APIs ist und das umfangreichste Regelwerk mit sich bringt.

Drei Da Vinci Implementation Guides greifen ineinander, um diesen Prozess abzuwickeln. Er beginnt mit CRD, Coverage Requirements Discovery. Wenn ein Leistungserbringer ein Produkt oder eine Dienstleistung verordnet oder plant, löst ein Hook im 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 ihn vor, soweit die Akte Informationen enthält – damit der Leistungserbringer keine Daten neu eingeben muss, die das System bereits kennt. Schließlich sendet PAS, Prior Authorization Support, die Anfrage und gibt die Entscheidung zurück: genehmigt, abgelehnt mit einem spezifischen Grund oder zurückgestellt für weitere Informationen. CMS empfiehlt diese Guides, schreibt sie jedoch nicht verbindlich vor.

Hier ist auch ein weit verbreitetes Missverständnis zu korrigieren. FHIR ersetzt nicht X12. Der PAS-Guide ist so konzipiert, dass er die nach HIPAA vorgeschriebene X12 278-Transaktion transportiert, sodass Anfrage und Antwort im Kern weiterhin auf X12 basieren. Ein Kostenträger kann das Backend als reines FHIR, reines X12 oder als Hybrid betreiben und die Verordnung trotzdem erfüllen. Zusätzliche klinische Dokumentation wird über einen separaten Da Vinci-Mechanismus, CDex, übermittelt, anstatt in die Genehmigungsnachricht selbst eingebettet zu werden.

Ein weiteres Element verbindet die Kostenträgerseite mit den Leistungserbringern. Ab dem Leistungszeitraum 2027 bestätigen zugelassene 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 Kennzahl ist das Nachfragesignal. Deshalb ist Ihre Prior Authorization API nicht nur ein Compliance-Endpunkt, sondern etwas, das Ihr Leistungserbringernetzwerk nun voraussichtlich nutzen wird.

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

Wenn CMS-0057-F vertraut wirkt, liegt das daran, dass sie auf CMS-9115-F, der Interoperability and Patient Access-Verordnung von 2020, aufbaut. Jene frühere Verordnung etablierte die Patient Access API und die Provider Directory API. Sie sah auch einen Payer-to-Payer-Datenaustausch vor, den CMS jedoch nie durchsetzte und der nie API-basiert war.

CMS-0057-F vollendet dieses Vorhaben. Sie behält die früheren APIs bei, baut den Payer-to-Payer-Austausch 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 Berichtspflicht. Die Richtung ist konsistent. Umfang und Durchsetzungskraft sind neu. CMS hat der Verordnung keine spezifische Geldstrafe beigefügt, setzt sie jedoch über die Befugnisse durch, die es bereits gegenüber jedem Programm besitzt – Medicare Advantage-Verträge, Medicaid- und CHIP-Aufsicht sowie QHP-Zertifizierung. Das Risiko ist vertraglicher und regulatorischer Natur, nicht als veröffentlichter Dollarbetrag ausgewiesen.

Wie Health Samurai unterstützt

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-Vorabgenehmigungsguides CRD, DTR und PAS.

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

Diese FHIR-Schicht zahlt sich auch nach der Frist weiter aus. Der Datenspeicher, den Sie für die vier APIs aufbauen, ist zugleich ein Analysespeicher: Dieselben normalisierten Daten fließen in Risikoanpassung, Stars- und Qualitätskennzahlen sowie in die Bevölkerungsgesundheit ein. Compliance-Ausgaben verwandeln sich in ein wiederverwendbares Datengut statt in eine Einweg-Verpackung, und die nächste regulatorische Anforderung trifft auf Daten, die bereits standardisiert sind.

Dies ist produktive Software, kein Versprechen in einer Präsentation. 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 im unabhängigen Payer-Scorecard von Flexpa vom November 2025 – es ist also nicht nur im Einsatz, sondern gehört zu den am besten bewerteten. 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 beim HL7 Da Vinci Connectathon Burden Reduction-Track einsetzen.

Die vollständige Lösung finden Sie auf der Payerbox-Seite zu CMS-0057-F. Wenn Sie ein fachkundiges Gespräch darüber wünschen, wie Ihr Plan in Bezug auf die Januar-2027-Frist aufgestellt ist, vereinbaren Sie einen Gesprächstermin: Wir analysieren Ihre Verpflichtungen, betrachten Ihre Quellsysteme und zeigen Ihnen, wie eine Payerbox-Implementierung auf Ihren verbleibenden Zeitplan passt.