Payer-to-Payer API: Die Einwilligung der Versicherten ist eine Aufgabe für Herbst 2026

Das Zugangstor zur Payer-to-Payer API

Wenn ein Mitglied einen Versicherungsplan verlässt und zu einem anderen wechselt, überträgt die Payer-to-Payer API dessen Krankengeschichte. Der neue Plan fordert vom alten bis zu fünf Jahre an Anspruchsdaten, klinischen Informationen und Vorabgenehmigungen an. Nichts wird übermittelt, bis das Mitglied zustimmt. Diese Zustimmung ist das einzige Zugangstor, und keine API holt sie für Sie ein. Dieser Artikel befasst sich mit diesem Zugangstor und richtet sich an Medicare Advantage-Pläne. Einen Überblick über die gesamte Regelung finden Sie in unserem CMS-0057-F-Überblick.

Derzeit ist der Kalender wichtiger als die technische Umsetzung. Die jährliche Medicare-Einschreibung für 2027 läuft vom 15. Oktober bis zum 7. Dezember 2026, ein gesetzlich festgelegter Zeitraum. Der Versicherungsschutz für alle, die sich einschreiben, beginnt am 1. Januar 2027 – dem Tag, an dem die Payer-to-Payer-Pflicht gemäß 42 CFR 422.121 in Kraft tritt. Bis dahin muss jedem bestehenden Mitglied die Möglichkeit zur Einwilligung angeboten werden, und allen, die sich während der jährlichen Einschreibung angemeldet haben, muss dasselbe Angebot innerhalb einer Woche nach Beginn des Versicherungsschutzes unterbreitet werden.

Beide Angebote werden durch ein direktes Gespräch mit dem Mitglied erfüllt. Dieses Gespräch muss eine bestimmte Reihe von Elementen umfassen: unter anderem den Namen des früheren Versicherers, auf wessen Namen dieser Versicherungsschutz bestand, und die Einwilligung selbst. Die Erfassung dieser Informationen bezeichnet dieser Artikel als „Capture". Ein Plan, der den 1. Januar ohne einen funktionierenden Prozess dafür erreicht, macht die Arbeit zu einer Nacherfassungskampagne für die gesamte Mitgliedschaft. Diese Kampagne läuft in denselben Wochen wie die Inbetriebnahme der API.

Was die Regel vorschreibt

Für Medicare Advantage sind die Pflichten im Payer-to-Payer-Abschnitt von 42 CFR 422.121 festgelegt. Medicaid, CHIP und die QHP-Anbieter auf den bundesweit betriebenen Marktplätzen haben jeweils ihre eigene Version desselben Abschnitts. Medicaid und CHIP unterscheiden sich in drei wichtigen Punkten: Dort erfasst der Staat die Einwilligung und nicht der Plan. Ein Austausch zwischen einem Staat und seinen eigenen Vertragspartnern erfordert überhaupt keine Einwilligung. Und Managed-Care-Pläne übernehmen die Pflicht über ihren Staatsvertrag und nicht direkt von CMS.

Für einen Medicare Advantage-Plan läuft die Pflicht wie folgt ab: Das Angebot zur Einwilligung und die Möglichkeit, diese zu ändern, sind bereitzustellen, und mit der Identifizierung früherer und gleichzeitiger Zahler des Mitglieds muss begonnen werden – beides spätestens eine Woche nach Beginn des Versicherungsschutzes. Bei Mitgliedern, die nicht reagieren, sind angemessene Bemühungen zu unternehmen. Sobald die Einwilligung und ausreichende Identifikationsdaten vorliegen, ist die Datenanfrage innerhalb einer Woche zu übermitteln, mit der Bestätigung, dass das Mitglied eingeschrieben ist und eingewilligt hat. Bei gleichzeitigen Zahlern ist dies vierteljährlich zu wiederholen, solange das Mitglied bei beiden Plänen versichert ist. All dies ist in verständlicher Sprache zu erläutern, wenn Sie das Mitglied ansprechen, einmal jährlich danach, und an einer zugänglichen Stelle auf Ihrer öffentlichen Website. Was Sie anfordern, ist der Patient Access-Datensatz der letzten fünf Jahre, ohne Abrechnungen der Leistungserbringer, Eigenbeteiligungen der Mitglieder und abgelehnte Vorabgenehmigungen, zuzüglich der unstrukturierten Dokumentation, die Vorabgenehmigungen beigefügt ist.

Drei Punkte werden leicht falsch verstanden.

Die erste Woche betrifft das Stellen der Frage, nicht den Erhalt einer Antwort. Die Frist bezieht sich darauf, dem Mitglied die Frage zu stellen, nicht darauf, eine Antwort zu haben. CMS hatte „bei der Einschreibung" vorgeschlagen und „bei Beginn des Versicherungsschutzes" finalisiert, weil, wie es formulierte, Zahler möglicherweise keinen Kontakt zu Patienten vor der Einschreibung haben. Die Präambel der endgültigen Regel ergänzt, dass die Erfassung „länger dauern kann als der Einschreibungsprozess". Messen Sie daher den Anteil der neuen Mitglieder, denen Sie innerhalb von sieben Tagen die Frage gestellt haben, nicht den Anteil derer, die geantwortet haben. Ersteres ist Ihr Prozess, letzteres ist das Verhalten der Mitglieder. Ein Dashboard, das auf letzterem basiert, zeigt jeden Monat Rot an und sagt Ihnen dabei nichts.

Die zweite Woche ist diejenige, die still scheitern kann. Sie beginnt erst, wenn Sie sowohl die Einwilligung als auch genügend Informationen zur Identifizierung des anderen Zahlers haben, und von dort aus hat die Anfrage eine Woche Zeit, abzugehen. Das ist Latenz innerhalb Ihrer eigenen Verarbeitungswarteschlange – die einzige Frist hier, die Ihre Systeme ohne Beteiligung einer Person verpassen können – und sie verdient eine Überwachung.

Die Regel schreibt nicht vor, wo Sie fragen. CMS hat es abgelehnt, einen Prozess vorzuschreiben, und stattdessen auf „einen bereits etablierten Kontaktpunkt mit dem Patienten" verwiesen. Die Einwilligung muss also nicht im Einschreibungsantrag enthalten sein. Für Medicare Advantage setzt die Frist dies auch nicht voraus, da die Frist ab Beginn des Versicherungsschutzes läuft, nicht ab der Einschreibung. Der Begrüßungsanruf, die Zusendung des Versicherungsausweises, die erste Anmeldung im Portal und ein Service-Skript stehen Ihnen alle zur Verfügung. Wählen Sie den Kontaktpunkt, den Sie kontrollieren und messen können.

Wo FHIR beginnt – und wo nicht

CMS hat hierfür keinen technischen Standard festgelegt. Die Regel verlangt FHIR R4, US Core und die FHIR Bulk Data-Spezifikation, indem sie auf die von ONC übernommenen API-Standards verweist. Sie empfiehlt den Da Vinci PDex-Implementierungsleitfaden, ohne ihn zu fordern. PDex-Konformität ist daher eine Vereinbarung zwischen Handelspartnern und nichts, das CMS überprüft. Was PDex hinzufügt, ist die Form des Austauschs, und diese Form gibt an, welche Elemente Sie erfassen müssen.

Der anfragende Zahler beginnt mit $bulk-member-match und übermittelt je Mitglied demografische Patientendaten, den früheren Versicherungsschutz und die Einwilligung auf Basis der HRex Patient Demographics, Coverage und Consent-Profile. Der Responder bewertet jedes Mitglied einzeln und gibt drei Gruppen zurück: übereinstimmend, nicht übereinstimmend und einwilligungsbeschränkt – letzteres sind Mitglieder, die zwar gefunden wurden, deren Einwilligung aber nicht honoriert werden kann. Die übereinstimmende Gruppe speist $davinci-data-export (PDex Bulk Exchange).

FHIR ist das Format der Anfrage, nicht das Format der Erfassung. Weder die Regel noch die Leitfäden verlangen einen FHIR Questionnaire, um die Fragen zu stellen, oder einen FHIR-Server, um die Antworten zu speichern. PDex macht das Speichern des Consent-Datensatzes sogar für den Empfänger optional. Es prüft nur vier Dinge, um eine Anfrage zu validieren: ob das Mitglied übereinstimmt, ob der Responder den vom Mitglied gewählten Umfang einhalten kann, ob der Einwilligungszeitraum gültig ist, und ob der anfragende Zahler derjenige ist, der in der Einwilligung genannt wird. Auf der anfragenden Seite gibt es überhaupt keine Speicheranforderung. Was Sie schulden, ist ein konformes HRex Patient-, Coverage- und Consent-Objekt zum Zeitpunkt der Anfrage – und alles auf der Eingangsseite dieser Transformation liegt in Ihrer Gestaltungsfreiheit.

Konnektivität ist ebenfalls keine Voraussetzung. Das Mitglied liest den Namen eines Zahlers von einer Karte ab, aber der Austausch benötigt eine Organisation mit einem Identifikator und einem aktiven Endpunkt. Es gibt keinen nationalen Zahler-Identifikator und kein nationales Verzeichnis, um von einem zum anderen zu gelangen. CMS sagt, Zahler müssten wahrscheinlich den früheren Zahler direkt kontaktieren, um überhaupt herauszufinden, ob er die API unterstützt. Eine vorgeschlagene Regel vom April 2026 würde diese Lücke schrittweise schließen und Zahler verpflichten, ihre Payer-to-Payer- und anderen API-Endpunkte innerhalb von 60 Tagen nach einer endgültigen Regel an CMS zu melden. Der Mechanismus ist noch festzulegen, behandeln Sie ihn also als Richtungsvorgabe und nicht als etwas, gegen das Sie bereits planen sollten. In jedem Fall ist dies ein Argument dafür, Einwilligungen jetzt zu erfassen, da sie zu Anfragen werden, sobald Endpunkte verfügbar sind.

Sollten Sie dennoch in FHIR erfassen?

„Nicht erforderlich" bedeutet nicht dasselbe wie „nicht sinnvoll". Eine FHIR-native Erfassung kann zwei Formen annehmen. Wenn die Seite, die das Mitglied sieht, Ihnen gehört, kann sie beim Absenden selbst den Consent schreiben, ohne dass eine Formularmaschine beteiligt ist. Wenn das Formular auch als Daten vorliegen soll, ist das mitgliederseitige Formular ein FHIR Questionnaire, die Antworten landen als QuestionnaireResponse, und der Consent wird daraus abgeleitet. Zwei Argumente sprechen für beide Ansätze.

Sie benötigen auf der ausliefernden Seite ohnehin einen FHIR-lesbaren Consent-Speicher. Provider Access erlaubt es Ihnen, einem Leistungserbringer nur dann zu antworten, wenn das Mitglied nicht widersprochen hat, und auf der Payer-to-Payer-Responder-Seite validieren Sie die Einwilligung, die mit jeder Anfrage eingeht. Ihre APIs lesen bei jedem Aufruf bereits einen Consent-Speicher. Wenn Sie woanders erfassen, haben Sie einen Synchronisierungsjob. Es gibt auch das Nachweisproblem. HRex Consent möchte, dass source auf eine DocumentReference verweist – den Nachweis dessen, was das Mitglied zugestimmt hat, und nicht nur ein Ja-oder-Nein-Flag. Eine QuestionnaireResponse ist bereits dieser Nachweis, mit Zeitstempel und verknüpft mit dem Fragenset und seiner Version.

Ein Questionnaire benötigt keinen Release-Slot des Anbieters. Das Argument gegen FHIR-native ist Bequemlichkeit: Da die Mitglieder bereits im Einschreibungsworkflow des Anbieters sind, müsste das Hinzufügen von zwei Fragen dort schneller sein. Das gilt nur, wenn der Anbieter es umsetzen kann – und das Hinzufügen einer Umfangsauswahl, eines Vertreter-Pfads und einer Unterschrift zu einem mitgliederseitigen Workflow ist keine kleine Änderungsanfrage. Die Eigentümerschaft entscheidet. Ein Portal, das Sie kontrollieren, kann beim Absenden den Consent schreiben. Ein Formular, das Sie hosten, kann von der Begrüßungs-E-Mail, dem Portal, einer SMS oder einem Link, den ein Mitarbeiter vorliest, aufgerufen werden. Ein Portal, das Sie nicht kontrollieren, wird beides ohne dieselbe Änderungsanfrage nicht tun. Der Kontaktpunkt bleibt in jedem Fall derselbe; was sich ändert, ist, wer den Wortlaut im November korrigieren kann.

Das eigentliche Argument dagegen ist die Migration. Wenn Sie bereits eine Einwilligungstabelle betreiben, die das Unternehmen als führendes System betrachtet, bedeutet FHIR-native eine Migration. Es lohnt sich, dies getrennt zu betrachten, denn der Erfassungskanal, das Formular und das führende System sind drei verschiedene Entscheidungen.

Vier Entscheidungen vor der Einschreibungsphase

1. Wo die Erfassung stattfindet und was die Antwort danach speichert. Der Kanal ist der Weg, über den die Frage das Mitglied erreicht: der Einschreibungsanbieter, das Portal, der Service-Desktop oder Papier. Das führende System ist das, was Ihre APIs nach der Antwort des Mitglieds auslesen, und es muss nicht dasselbe System sein. Wenn Einwilligungen bereits in einer von Ihnen betriebenen Tabelle gespeichert sind, ist diese Tabelle ein geerbtes führendes System und kein Kanal – und der Kanal ist das, was sie befüllt. Keine der beiden Entscheidungen muss auf den API-Aufbau warten. Stellen Sie unabhängig von Ihrer Wahl einen Weg für Mitglieder bereit, die kein Portal nutzen. CMS „empfiehlt nachdrücklich, dass es eine Möglichkeit für Patienten gibt, ihre Einwilligung telefonisch oder auf anderem Wege zu erteilen". Die Pflichten zur Sprachzugänglichkeit und für Menschen mit Behinderungen gemäß 45 CFR Teil 92 gelten für das Formular und das Skript.

2. Was der Einwilligungszeitraum ist. CMS erklärt, die Wahl sei „unbegrenzt gültig bei diesem Zahler", bis das Mitglied sie widerruft. HRex Consent macht jedoch sowohl ein Anfangsdatum als auch ein Enddatum obligatorisch. Das Enddatum ist also Ihre Richtlinie und keine Antwort des Mitglieds – und es muss auf dem Formular erscheinen, das das Mitglied unterzeichnet.

3. Welchen Umfangswert die Einwilligung enthält und ob das Mitglied ihn wählt. HRex kennt zwei Richtlinienwerte, deren Namen entgegen der Intuition benannt sind: #sensitive gewährt alles einschließlich dessen, was das Gesetz als sensibel einstuft; #regular gewährt alles außer diesem. Sie müssen die Wahl nicht vor das Mitglied stellen, da die Regel nach einem Ja oder Nein fragt und der Umfang nicht zu den Dingen gehört, die Sie erläutern müssen.

Was Sie nicht überspringen können, ist die Entscheidung selbst, da der Wert weiterhin in der ausgehenden Einwilligung mitreist. Ein Formular, das nicht fragt, legt ihn durch Richtlinie fest – und das ist eine Rechtsfrage und keine Designentscheidung. Das Senden von #sensitive bestätigt, dass das Mitglied die Offenlegung von Aufzeichnungen autorisiert hat, die gemäß 42 CFR Teil 2 und staatlichem Recht geschützt sind. Die Regel erlaubt den Austausch nur, soweit die Offenlegung nicht durch andere Gesetze verboten ist. Die tatsächlich bei Ihnen eingehende Datenmenge wirkt in die entgegengesetzte Richtung. Ein Responder ohne Sicherheitskennzeichnungen kann die sensible Teilmenge nicht trennen, weshalb PDex vorsieht, das Mitglied auszuschließen statt zu filtern. Das Mitglied, das weniger beantragt hat, erhält nichts, während das Mitglied, das alles autorisiert hat, eine vollständige Historie erhält.

4. Für welche PDex-Version Ihre gespeicherten Datensätze gestaltet sind. Ein einziger Einschreibungskontakt kann die Payer-to-Payer-Einwilligung und den Provider Access-Widerspruch gemeinsam erfassen, daher gilt diese Entscheidung für beide Datensätze. PDex 2.2.0 fügt eine Kategorie-Codierung hinzu, die identifiziert, zu welcher API jeder Consent-Datensatz gehört – für das Provider Access Consent-Profil obligatorisch –, erweitert den Unterzeichner auf persönliche Vertreter und fügt drei Suchparameter hinzu. Payer-to-Payer-Datensätze sind davon nicht betroffen, da sie HRex Consent verwenden und dieses Profil in beiden Versionen identisch ist. Für Provider Access sollten Sie das, was Sie speichern, für 2.2.0 und nicht für 2.1 gestalten: 2.2.0 ist die aktuelle Version, und Datensätze, die in diesem Herbst für die Version 2.1 geschrieben werden, erfordern eine spätere Migration. Die eigene Empfehlung von CMS nennt noch PDex 2.0.0, das ist also eine Wette auf den Leitfaden und nicht auf die Regel. Gesondert zu prüfen: Beide Consent-Profile verweisen auf einen US Core 7.0.0 Patient, während die Regel selbst auf US Core 3.1.1 verweist. Die Version, die Ihre Consent-Datensätze voraussetzen, entspricht möglicherweise nicht der Version, auf die der Rest Ihres Aufbaus abzielt.

Was Sie das Mitglied fragen sollten

„Erforderlich" bedeutet, dass das Profil ohne dieses Element ungültig ist. „Must support" bedeutet, dass das empfangende System in der Lage sein muss, das Element zu verarbeiten, wenn Sie es senden – das ist nicht dasselbe wie eine Pflicht, das Mitglied danach zu fragen. „Empfohlen" kennzeichnet ein Element, das CMS in der Präambel nennt, das das Profil aber überhaupt nicht einschränkt.

Das ist die Gesamtheit davon. Jedes von HRex Consent geforderte Element erscheint entweder oben oder wird vom Profil selbst festgelegt. Das Profil legt für Sie Status, Umfang, Offenlegungskategorie, Genehmigung, Offenlegungshandlung und die beiden Akteur-Rollen fest. Der Einwilligungszeitraum, die beiden Organisations-Akteure und der aufbewahrte Nachweis stammen aus Ihrer eigenen Konfiguration und nicht vom Mitglied, und das unterzeichnete Dokument kann dort verbleiben, wo Ihre Dokumente heute gespeichert sind. Nur eine nicht offensichtliche Frage hier kann ausschließlich vom Mitglied beantwortet werden: ob der frühere Versicherungsschutz auf den eigenen Namen lautete.

Was Sie nicht fragen sollten

Drei der vier folgenden Punkte stammen aus der Präambel. Der vierte ist eine Designentscheidung, die sich daraus ergibt.

• Anfangs- und Enddaten des Versicherungsschutzes. CMS räumt ein, dass diese „in einigen Fällen nützlich sein können", rät aber davon ab: „Patienten werden diese genauen Daten wahrscheinlich weder kennen noch sich daran erinnern, noch sind sie leicht zu finden." Ein Pflichtdatumsfeld bringt wenig Abgleichgenauigkeit und beeinträchtigt die Ausfüllrate.
• Jüngste Leistungen und ihre Daten. Als belastend eingestuft, da das Mitglied diese vom Zahler erfragen müsste, den Sie gleich selbst anfragen werden.
• Sozialversicherungsnummern. Zur Identifizierung von Patienten „nur dann zu verwenden, wenn notwendig (und gesetzlich zulässig)".
• Der spezifische Planname. Kommentatoren drängten CMS, diesen nicht zu verlangen: Plannamen sind lang, wenig intuitiv, und Mitglieder wechseln Pläne, bleiben aber beim gleichen Zahler. CMS hat sich nicht eindeutig festgelegt, daher ist das Weglassen eine Designentscheidung. Was für das Routing benötigt wird, ist der Zahler, nicht das Produkt.

Was CMS tatsächlich befürwortet, ist kurz: Name des Patienten, Mitgliedsnummer, Geburtsdatum, Wohnadresse und Telefonnummer, plus Name des früheren Zahlers und eine Patientenidentifikationsnummer oder ein ähnlicher Identifikator.

Wenn das Mitglied nicht antwortet oder seine Meinung ändert

Der Widerruf wirkt nur in die Zukunft. Er stoppt künftige Anfragen, einschließlich des vierteljährlichen Austauschs mit gleichzeitigen Zahlern, aber nichts verpflichtet Sie, bereits Erhaltenes zu löschen. Ohne Widerruf gilt die Einwilligung unbegrenzt bei diesem Zahler und wird nicht übertragen: Der nächste Plan holt sich seine eigene. Auch der Widerruf wird nicht über die API übertragen, sodass bei einem Mitglied, das den früheren Zahler direkt kontaktiert, beide Seiten einen Betreiberpfad für eine per Telefon bekannt gewordene Einwilligungsänderung benötigen.

Angemessene Bemühungen haben eine Mindestanforderung: CMS empfiehlt, einmal nachzufassen, bevor man schlussfolgert, dass das Mitglied sich dafür entscheidet, nicht einzuwilligen, und ermutigt dazu, ihm eine Möglichkeit zu geben abzulehnen, damit die Nachfassaktionen enden. Versuche und Ablehnungen sind zu dokumentieren, sonst können Sie weder das eine noch das andere begründen.

Ein Gespräch, zwei Datensätze

Der Provider Access-Opt-out-Hinweis hat denselben Auslöser – eine Woche nach Beginn des Versicherungsschutzes –, was es ermöglicht, beides in einem Kontakt zu kombinieren und zwei Outreach-Programme in eines zu verwandeln.

Die Datensätze bleiben getrennt und sind unterschiedlich gestaltet: Das PDex Provider-Consent-Profil lässt Enddatum und Quelldokument optional, während HRex Consent beides sowie zwei Organisations-Akteure vorschreibt. Die Kategorie-Codierung in PDex 2.2.0 hält sie in einem Speicher unterscheidbar. Kein Flag darf jemals eine Patient Access-Antwort sperren, wo das eigene App-Autorisierungsereignis des Mitglieds das Einwilligungsereignis ist.

Wie Health Samurai hilft

Payerbox ist die CMS-0057-F-Plattform von Health Samurai für Krankenversicherer und wird heute bereits von Zahlern eingesetzt. Das Designprinzip lautet: integrieren, nicht ersetzen – und das Consent-Capture-Modul, das wir derzeit entwickeln, folgt diesem Prinzip. Sie fragen Mitglieder dort, wo Sie sie bereits erreichen, und die Einwilligungstabelle, die Sie bereits betreiben, bleibt das führende System.

Die vollständige Lösung finden Sie auf der Payerbox-Seite für CMS-0057-F. Um Ihren eigenen Erfassungsweg vor Ende der Einschreibungsphase durchzuarbeiten, vereinbaren Sie einen Gesprächstermin. Wir schauen uns gemeinsam an, wo Ihre Einwilligung heute gespeichert ist, was Ihr Formular erfassen muss, und was es braucht, um das in eine konforme Anfrage gegen das umzuwandeln, was Ihre Handelspartner bereitstellen.