Payer-to-Payer API: Das Opt-In der Versicherten ist ein Lieferziel für Herbst 2026

Das Zugangstor zur Payer-to-Payer API

Wenn eine versicherte Person einen Versicherungsplan verlässt und zu einem anderen wechselt, ist die Payer-to-Payer API der Weg, auf dem ihre Vorgeschichte mitfolgt. Der neue Plan fragt beim alten nach bis zu fünf Jahren an Abrechnungsdaten, klinischen Daten und Prior Authorizations. Nichts wird übermittelt, bis die versicherte Person ihr Einverständnis gibt. Diese Genehmigung ist das gesamte Zugangstor, und keine API erfasst sie für Sie. Dieser Artikel befasst sich mit diesem Tor und ist für Medicare Advantage geschrieben; für den übrigen Teil der Regelung beginnen Sie mit unserem Überblick zu CMS-0057-F.

Derzeit ist der Kalender wichtiger als das Engineering. Die Medicare Annual Enrollment für 2027 läuft vom 15. Oktober bis zum 7. Dezember 2026, ein in der Regulierung festgeschriebenes Zeitfenster. Der Versicherungsschutz für alle, die sich anmelden, beginnt am 1. Januar 2027 – dem Tag, an dem die Payer-to-Payer-Pflicht gemäß 42 CFR 422.121 in Kraft tritt. Bis dahin steht jedem bestehenden Mitglied das Angebot zu, sich einzuschreiben, und jedem, der sich während der Annual Enrollment angemeldet hat, dasselbe Angebot innerhalb einer Woche nach Beginn des Versicherungsschutzes.

Beide Angebote werden durch ein Gespräch mit der versicherten Person erfüllt. Das Gespräch muss eine bestimmte Menge an Informationen zurückbringen: unter anderem, wer der frühere Versicherer war, auf wessen Namen dieser Versicherungsschutz lief, und die Einwilligung selbst. Die Erfassung dieser Informationen nennt dieser Artikel „Capture". Ein Plan, der den Januar ohne ein entsprechendes Verfahren erreicht, hat die Arbeit in eine nachträgliche Erfassungskampagne über die gesamte Mitgliedschaft verwandelt. Diese Kampagne läuft in denselben Wochen wie die API-Inbetriebnahme.

Was die Regelung verlangt

Für Medicare Advantage sind die Pflichten im Payer-to-Payer-Abschnitt von 42 CFR 422.121 verankert. Medicaid, CHIP und die QHP-Aussteller an den bundesstaatlich betriebenen Börsen erhalten jeweils ihre eigene Version desselben Abschnitts. Medicaid und CHIP unterscheiden sich in drei erwähnenswerten Punkten. Dort erfasst der Bundesstaat das Opt-In anstelle des Plans. Ein Datenaustausch zwischen einem Bundesstaat und seinen eigenen Vertragspartnern benötigt überhaupt kein Opt-In. Und Managed-Care-Pläne übernehmen die Pflicht über ihren Staatsvertrag und nicht direkt von CMS.

Für einen Medicare Advantage Plan verläuft die Pflicht wie folgt: Das Opt-In und eine Möglichkeit zur Änderung sind anzubieten, und die Identifizierung früherer und gleichzeitiger Kostenträger der versicherten Person beginnt beides spätestens eine Woche nach Beginn des Versicherungsschutzes. Bei Nichtantwort der versicherten Person sind angemessene Bemühungen zu unternehmen. Sobald die Genehmigung und ausreichende Identifikationsinformationen vorliegen, ist die Datenanfrage innerhalb einer Woche zu senden, mit der Bestätigung, dass die Person eingeschrieben ist und eingewilligt hat. Bei gleichzeitigen Kostenträgern ist dies vierteljährlich zu wiederholen, solange die Person in beiden Plänen ist. All dies ist in verständlicher Sprache zu erläutern, wenn die Frage gestellt wird, einmal jährlich danach und an einer zugänglichen Stelle auf der öffentlichen Website. Was angefordert wird, ist der Patient Access-Datensatz der letzten fünf Jahre, ohne Erstattungen an Leistungserbringer, Eigenanteile der Mitglieder und abgelehnte Prior Authorizations, aber einschließlich der unstrukturierten Dokumentation zu Prior Authorizations.

Drei Punkte lassen sich leicht falsch verstehen.

Die erste Woche läuft auf das Stellen der Frage, nicht auf das Erhalten einer Antwort. Die Frist gilt für die Aufforderung an die versicherte Person, nicht dafür, deren Antwort bereits vorliegen zu haben. CMS hatte „bei der Einschreibung" vorgeschlagen und „zu Beginn des Versicherungsschutzes" finalisiert, weil, wie es formulierte, Kostenträger möglicherweise keinen Kontakt zu Patienten vor der Einschreibung haben. Die Präambel zur Abschlussregel ergänzt, dass die Erfassung „länger dauern kann als der Einschreibeprozess". Messen Sie daher den Anteil neuer Mitglieder, die Sie innerhalb von sieben Tagen befragt haben, nicht den Anteil, der geantwortet hat. Ersteres ist Ihr Prozess, letzteres ist das Verhalten der versicherten Personen. Ein Dashboard, das auf dem zweiten Wert basiert, zeigt jeden Monat Rot an und sagt Ihnen dabei nichts.

Die zweite Woche ist diejenige, die still scheitern kann. Sie beginnt erst, wenn sowohl die Einwilligung als auch ausreichende Informationen zur Identifizierung des anderen Kostenträgers vorliegen, und von dort aus hat die Anfrage eine Woche Zeit, versendet zu werden. Das ist Latenz in Ihrer eigenen Warteschlange – die einzige Frist hier, die Ihre Systeme ohne Beteiligung einer Person verfehlen können – und sie verdient eine Überwachung.

Die Regelung schreibt nicht vor, wo gefragt werden soll. CMS hat davon abgesehen, ein Verfahren vorzuschreiben, und stattdessen auf „einen bereits etablierten Kontaktpunkt mit dem Patienten" verwiesen. Das Opt-In muss also nicht auf dem Einschreibungsantrag stehen. Für Medicare Advantage setzt die Frist dies auch nicht voraus, da die Uhr ab Beginn des Versicherungsschutzes und nicht ab der Einschreibung läuft. Das Willkommensgespräch, die Versichertenkartenszusendung, das erste Portal-Login und ein Serviceskript 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 formuliert. Die Regelung 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 Implementation Guide, ohne ihn zu verlangen. PDex-Konformität ist daher eine Vereinbarung zwischen Handelspartnern und nicht etwas, das CMS überprüft. Was PDex hinzufügt, ist die Form des Austauschs – und diese Form zeigt, welche Elemente erfasst werden müssen.

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

FHIR ist das Format der Anfrage, nicht das Format der Erfassung. Weder die Regelung noch die Leitfäden verlangen eine FHIR Questionnaire zur Fragestellung oder einen FHIR-Server zur Speicherung der Antworten. PDex macht die Speicherung des Consent-Datensatzes sogar für den Empfänger optional. Es prüft zur Validierung einer Anfrage nur vier Dinge: ob das Mitglied zugeordnet wurde, ob der Responder den vom Mitglied gewählten Umfang berücksichtigen kann, ob der Einwilligungszeitraum gültig ist, und ob der anfragende Kostenträger der im Consent genannte Kostenträger ist. Auf der anfragenden Seite gibt es überhaupt keine Speicheranforderung. Was geschuldet wird, ist ein konformes HRex Patient-, Coverage- und Consent-Objekt zum Zeitpunkt des Versands der Anfrage – alles auf der Eingangsseite dieser Transformation bleibt Ihnen zu gestalten überlassen.

Konnektivität ist ebenfalls keine Voraussetzung. Die versicherte Person liest den Namen eines Kostenträgers von einer Karte ab, aber der Austausch benötigt eine Organisation mit einem Identifikator und einem aktiven Endpunkt. Es gibt keinen nationalen Kostenträgeridentifikator und kein nationales Verzeichnis, um von einem zum anderen zu gelangen. CMS stellt fest, dass Kostenträger den früheren Kostenträger wahrscheinlich direkt kontaktieren müssten, um herauszufinden, ob er die API überhaupt unterstützt. Eine vorgeschlagene Regelung vom April 2026 würde diese Lücke beginnen zu schließen, indem Kostenträger verpflichtet werden, ihre Payer-to-Payer- und andere API-Endpunkte innerhalb von 60 Tagen nach einer Abschlussregel an CMS zu melden. Der Mechanismus ist noch zu bestimmen, behandeln Sie ihn daher als Richtungsvorgabe und nicht als Planungsgrundlage. In jedem Fall spricht dies dafür, Einwilligungen jetzt zu erfassen, denn sie werden zu Anfragen, sobald Endpunkte verfügbar sind.

Sollten Sie dennoch in FHIR erfassen?

„Nicht vorgeschrieben" ist nicht dasselbe wie „nicht empfehlenswert". FHIR-native Erfassung kann zwei Formen annehmen. Wenn die Seite, die das Mitglied sieht, Ihre eigene ist, kann sie beim Absenden selbst den Consent schreiben, und keine Form-Engine ist involviert. Wenn die Form auch als Daten vorliegen soll, ist das mitgliederseitige Formular eine FHIR Questionnaire, die Antworten landen als QuestionnaireResponse, und der Consent wird daraus abgeleitet. Zwei Argumente sprechen für beide Wege.

Sie benötigen einen FHIR-lesbaren Consent-Speicher auf der Serverseite ohnehin. Provider Access erlaubt es Ihnen, einem Leistungserbringer nur dann zu antworten, wenn das Mitglied nicht widersprochen hat, und auf der Payer-to-Payer-Responderseite validieren Sie den Consent, der mit jeder Anfrage eingeht. Ihre APIs lesen bei jedem Aufruf bereits einen Consent-Speicher. Wenn Sie anderswo erfassen, besitzen Sie einen Synchronisierungsjob. Es gibt auch das Nachweisproblem. HRex Consent erwartet source mit einem Verweis auf eine DocumentReference – den Nachweis über das, dem das Mitglied zugestimmt hat, anstatt eines Ja-oder-Nein-Flags. Eine QuestionnaireResponse ist bereits dieser Nachweis, mit Zeitstempel und verknüpft mit dem Fragebogen und seiner Version.

Ein Questionnaire benötigt keinen Release-Slot des Anbieters. Das Argument gegen FHIR-native ist Bequemlichkeit: Die Mitglieder befinden sich bereits im Einschreibeablauf des Anbieters, daher muss das Hinzufügen von zwei Fragen dort schneller sein. Das gilt nur, wenn der Anbieter es umsetzen kann – und eine Umfangauswahl, einen Vertreterweg und eine Unterschrift zu einem mitgliederseitigen Ablauf hinzuzufügen ist keine kleine Änderungsanfrage. Ownership entscheidet darüber. Ein Portal, das Sie kontrollieren, kann den Consent beim Absenden schreiben. Ein Formular, das Sie hosten, kann aus der Willkommens-E-Mail, dem Portal, einer SMS oder einem Link, den ein Mitarbeiter vorliest, verlinkt werden. Ein Portal, das Sie nicht kontrollieren, wird beides ohne dieselbe Änderungsanfrage nicht tun. Der Kontaktpunkt bleibt so oder so dort, wo er war; was sich ändert, ist, wer den Wortlaut im November anpassen kann.

Das eigentliche Argument dagegen ist die Migration. Wenn Sie bereits eine Consent-Tabelle betreiben, die das Unternehmen als System of Record behandelt, bedeutet FHIR-native zu werden, diese zu migrieren. Das ist klar zu trennen, denn der Erfassungskanal, das Formular und das System of Record sind drei separate Entscheidungen.

Vier Entscheidungen vor der Einschreibesaison

1. Wo die Erfassung stattfindet und was die Antwort danach hält. Der Kanal ist der Ort, an dem die Frage das Mitglied erreicht: der Einschreibungsanbieter, das Portal, der Service-Desktop oder Papier. Das System of Record ist dasjenige, das Ihre APIs lesen, sobald das Mitglied geantwortet hat, und es muss nicht dasselbe System sein. Wenn Berechtigungen bereits in einer Tabelle gespeichert sind, die Sie betreiben, ist diese Tabelle ein geerbtes System of Record und kein Kanal, und der Kanal ist dasjenige, das sie befüllt. Keine dieser Entscheidungen muss auf den API-Build warten. Was auch immer Sie wählen: Fügen Sie einen Weg für Mitglieder hinzu, die kein Portal nutzen. CMS „empfiehlt nachdrücklich, dass es eine Möglichkeit geben sollte, die Einwilligung telefonisch oder auf andere Weise zu erfassen". Die Anforderungen zu Sprache und Barrierefreiheit gemäß 45 CFR Part 92 gelten für das Formular und das Skript.

2. Wie lang der Einwilligungszeitraum ist. CMS sagt, die Entscheidung gilt „auf unbestimmte Zeit bei diesem Kostenträger", bis das Mitglied sie widerruft. HRex Consent macht jedoch sowohl ein Startdatum als auch ein Enddatum verpflichtend. Das Enddatum ist daher Ihre Richtlinie und keine Antwort des Mitglieds – und es muss auf dem Formular erscheinen, das das Mitglied unterzeichnet.

3. Welchen Umfangwert der Consent trägt und ob das Mitglied ihn wählt. HRex erkennt zwei Richtlinienwerte, deren Namen der Intuition widersprechen: #sensitive gewährt alles einschließlich dessen, was das Gesetz als sensibel behandelt; #regular gewährt alles außer dem. Sie müssen die Wahl nicht dem Mitglied überlassen, denn die Regelung fordert ein Ja oder Nein, und der Umfang gehört nicht zu den Dingen, die Sie erläutern müssen.

Was Sie nicht überspringen können, ist die Entscheidung selbst, denn der Wert reist im ausgehenden Consent mit. Ein Formular, das nicht fragt, legt ihn per Richtlinie fest – das ist eine rechtliche Frage und keine Designfrage. Das Senden von #sensitive bestätigt, dass das Mitglied die Offenlegung von Unterlagen genehmigt hat, die durch 42 CFR Part 2 und staatliches Recht geschützt sind. Die Regelung erlaubt den Austausch nur, wenn die Offenlegung nicht durch anderes Recht verboten ist. Wie viele Daten tatsächlich bei Ihnen ankommen, zieht in die entgegengesetzte Richtung. Ein Responder ohne Sicherheitsetiketten kann die sensible Teilmenge nicht trennen, daher schließt PDex das Mitglied aus, anstatt zu filtern. Das Mitglied, das weniger angefordert hat, erhält nichts, während das Mitglied, das alles angegeben hat, eine vollständige Vorgeschichte erhält.

4. Auf welche PDex-Version Ihre gespeicherten Datensätze ausgerichtet sind. Ein einziger Einschreibekontakt kann das Payer-to-Payer-Opt-In und das Provider Access-Opt-Out gemeinsam erfassen, daher betrifft diese Entscheidung beide Datensätze. PDex 2.2.0 fügt eine Kategorienkodierung hinzu, die angibt, zu welcher API jeder Consent-Datensatz gehört – auf dem Provider Access Consent-Profil verpflichtend –, 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 ist in beiden Versionen identisch. Für Provider Access: Formen Sie das, was Sie speichern, auf 2.2.0 und nicht auf 2.1 aus – 2.2.0 ist die aktuelle Version, und Datensätze, die in diesem Herbst im 2.1-Format geschrieben werden, erfordern eine Migration. Die eigene Empfehlung von CMS nennt weiterhin PDex 2.0.0, daher ist dies eine Wette auf den Leitfaden und nicht auf die Regelung. Gesondert zu prüfen: Beide Consent-Profile referenzieren einen US Core 7.0.0 Patient, während die Regelung selbst auf US Core 3.1.1 verweist. Die Version, die Ihre Consent-Datensätze voraussetzen, ist möglicherweise nicht die Version, auf die der Rest Ihres Builds ausgerichtet ist.

Was das Mitglied gefragt werden soll

„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" markiert ein Element, das CMS in der Präambel nennt, das das Profil aber überhaupt nicht einschränkt.

Das ist die Gesamtheit. Jedes von HRex Consent geforderte Element erscheint entweder oben oder wird vom Profil selbst festgelegt. Das Profil setzt Status, Umfang, Offenlegungskategorie, Genehmigung, die Offenlegungshandlung und die zwei Akteurollen für Sie. Der Einwilligungszeitraum, die zwei Organisationsakteure und der aufbewahrte Nachweis stammen aus Ihrer eigenen Konfiguration und nicht vom Mitglied, und das unterzeichnete Dokument kann dort verbleiben, wo Ihre Unterlagen heute gespeichert sind. Nur eine nicht offensichtliche Frage hier kann von niemandem außer dem Mitglied beantwortet werden: ob der frühere Versicherungsschutz auf dessen eigenen Namen lief.

Was nicht gefragt werden soll

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

• Anfangs- und Enddatum des Versicherungsschutzes. CMS räumt ein, dass sie „in manchen Fällen nützlich sein können", rät aber davon ab: „Patienten kennen oder erinnern sich wahrscheinlich nicht an diese genauen Daten, noch sind sie leicht zu finden." Ein Pflichtdatumsfeld bringt wenig Genauigkeit bei der Zuordnung und kostet Ausfüllquote.
• Jüngste Leistungen und deren Daten. Als belastend abgeraten, da das Mitglied diese vom Kostenträger einholen müsste, der gerade befragt werden soll.
• Sozialversicherungsnummern. Zur Patientenidentifikation „nur wenn notwendig (und gesetzlich zulässig)" zu verwenden.
• Den spezifischen Plannamen. Kommentatoren forderten CMS auf, ihn nicht zu verlangen: Plannamen sind lang, wenig intuitiv, und Mitglieder wechseln Pläne, ohne den Kostenträger zu wechseln. CMS hat sich nicht eindeutig positioniert, daher ist das Weglassen eine Designentscheidung. Was das Routing benötigt, ist der Kostenträger, nicht das Produkt.

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

Wenn das Mitglied nicht antwortet oder seine Meinung ändert

Ein Widerruf wirkt nur in die Zukunft. Er stoppt künftige Anfragen – einschließlich des vierteljährlichen Austauschs mit gleichzeitigen Kostenträgern –, verpflichtet Sie aber nicht, bereits empfangene Daten zu löschen. Unverändert bleibt die Einwilligung auf unbestimmte Zeit bei diesem Kostenträger bestehen und wird nicht weitergegeben: Der nächste Plan erfasst seine eigene. Ein Widerruf wird auch nicht über die API übermittelt, daher benötigen beide Seiten einen manuellen Weg für eine Genehmigungsänderung, die telefonisch beim früheren Kostenträger gemeldet wird.

Angemessene Bemühungen haben eine Untergrenze: CMS empfiehlt eine Nachverfolgung, bevor geschlussfolgert wird, dass das Mitglied sich gegen ein Opt-In entscheidet, und ermutigt dazu, eine Möglichkeit zur Ablehnung anzubieten, damit die Nachverfolgung endet. Versuche und Ablehnungen sind zu dokumentieren, sonst können Sie beides nicht belegen.

Ein Gespräch, zwei Datensätze

Der Provider Access-Opt-Out-Hinweis trägt dieselbe Auslösebedingung – eine Woche nach Beginn des Versicherungsschutzes –, was es ermöglicht, beides in einem Kontakt zu erfassen und so zwei Outreach-Programme zu einem zu machen.

Die Datensätze bleiben separat und sind unterschiedlich geformt: Das PDex Provider Consent-Profil macht das Enddatum und das Quelldokument optional, während HRex Consent beides verlangt, zuzüglich zweier Organisationsakteure. Die Kategorienkodierung in PDex 2.2.0 hält sie in einem Speicher trennbar. Keines dieser Flags darf jemals eine Patient Access-Antwort einschränken, bei der die App-Autorisierung des Mitglieds selbst das Berechtigungsereignis ist.

Wie Health Samurai unterstützt

Payerbox ist die CMS-0057-F-Plattform von Health Samurai für Krankenkassen und ist bereits heute bei Kostenträgern im Einsatz. Das Designprinzip lautet: integrieren, nicht ersetzen – und das Consent-Capture-Modul, das wir derzeit entwickeln, folgt diesem Prinzip. Sie fragen Mitglieder weiterhin dort, wo Sie sie bereits erreichen, und die Consent-Tabelle, die Sie bereits betreiben, bleibt das System of Record.

Die vollständige Lösung finden Sie auf der Payerbox-Seite für CMS-0057-F. Um Ihren eigenen Erfassungsweg vor dem Ende der Einschreibesaison durchzuarbeiten, vereinbaren Sie einen Gesprächstermin. Wir sehen uns an, wo Ihr Opt-In heute liegt, was Ihr Formular erfassen muss, und was nötig ist, um das in eine konforme Anfrage gegen das umzuwandeln, was Ihre Handelspartner bereitstellen.