---
{
  "title": "So überprüfen Sie Ihre CMS-0057-F-APIs: Sieben Fragen an Ihr Team",
  "description": "Ihr Team sagt, die CMS-0057-F-APIs seien bereit. Sieben Fragen, die Sie vor den Fristen 2027 stellen sollten, samt den Nachweisen, die als Antwort vorliegen sollten.",
  "date": "2026-11-12",
  "author": "Mike Kulakov",
  "reading-time": "15 min read",
  "tags": [
    "Compliance",
    "Integrations"
  ],
  "tldr": "Eine funktionierende Demo zeigt nicht, dass die richtigen Daten die richtige Partei rechtzeitig erreichen. Jede Pflicht aus CMS-0057-F gilt gegenüber jemandem außerhalb Ihres Plans: der App eines Mitglieds, einem Leistungserbringer, der Patientendaten anfordert, einem Leistungserbringer, der eine Vorabgenehmigung beantragt, einem anderen Krankenversicherungsplan, einem App-Entwickler, CMS und der Öffentlichkeit. Hier ist eine Frage für jeden dieser Fälle – plus eine für Ihr eigenes Team –, ergänzt durch die jeweilige Regelanforderung und die Nachweise, die mit der Antwort vorliegen sollten.",
  "utm-campaign": "fhir_expert",
  "utm-content": "cms0057-cio-how-to-check"
}
---

> For the complete documentation index, see [llms.txt](https://www.health-samurai.io/llms.txt).
> Use it to discover all available pages before guessing URLs.

---
Ihr Team oder Ihr Anbieter sagt, die CMS-0057-F-APIs seien bereit. Die Demo funktioniert: Eine Test-App meldet sich an und ruft die Ansprüche eines Mitglieds ab. Am 1. Januar 2027 werden die Provider Access-, Payer-to-Payer- und Prior Authorization-APIs verpflichtend, und Vorabgenehmigungsdaten werden in die Patient Access API aufgenommen. Die Frage, die sich Ihnen stellt, ist, ob „bereit" auch „konform" bedeutet.

Eine Demo zeigt, dass ein Endpunkt antwortet. Sie zeigt nicht, wie spät die Daten eintreffen, ob ein Leistungserbringer ausschließlich seine eigenen Patienten sieht oder ob ein Entwickler die Dokumentation ohne Konto lesen kann. Die Regel schreibt alle drei vor. Jede Pflicht dient jemandem außerhalb Ihres Plans, und dieser ist der Erste, der es bemerkt, wenn sie nicht erfüllt wird.

Hier sind daher sieben Fragen, die Sie Ihrem Team stellen sollten. Die ersten vier verfolgen die Daten aus jeder API bis zu demjenigen, der sie angefordert hat: die App eines Mitglieds, ein Leistungserbringer, der Patientendaten möchte, ein Leistungserbringer, der eine Vorabgenehmigung möchte, und ein anderer Krankenversicherungsplan. Die letzten drei behandeln, was alle vier APIs gemeinsam haben: Dokumentation, die ein App-Entwickler lesen kann, die Berichte und Mitteilungen, die CMS und die Öffentlichkeit sehen, sowie die Tests hinter allem.

Zu jeder Frage erhalten Sie die entsprechende Regelanforderung und die Nachweise, die Ihr Team Ihnen vorlegen können sollte. Sie müssen dafür keinen Code lesen. Und dies ist keine einmalige Prüfung – stellen Sie die Fragen vor den Fristen 2027 und stellen Sie sie danach weiter.

Wenn Sie einen Medicaid Managed Care-Plan betreiben, gelten dieselben Pflichten für Sie über Ihren Vertrag mit dem Bundesstaat, und jede Frage weist darauf hin, wo sie abweichen. Die Termine funktionieren anders. Ihre richten sich nach Ihrem Bewertungszeitraum, den 12 Monaten, für die der Bundesstaat Ihre Kopfpauschalen festlegt. Jeder Bundesstaat legt fest, wann sein Bewertungszeitraum beginnt, sodass eine Pflicht für 2027 bei Ihnen am 1. April, 1. Juli oder 1. September 2027 beginnen kann.

Die Links in diesem Beitrag verweisen auf [die Medicare Advantage-Abschnitte der Regel](https://www.ecfr.gov/current/title-42/section-422.119). Die Medicaid-Abschnitte finden sich in [42 CFR Teil 438](https://www.ecfr.gov/current/title-42/part-438). Für einen Überblick über die Regel als Ganzes empfehlen wir unsere [CMS-0057-F-Übersicht](/articles/understanding-the-cms-0057-f-interoperability-and-prior-authorization-final-rule).

Die sieben Fragen auf einen Blick:

| Frage | Gilt ab | Nachweise, die Sie anfordern sollten |
|---|---|---|
| 1. App eines Mitglieds | Seit 2021. Vorabgenehmigungsdaten ab 1. Januar 2027 | Ansprüche in der API innerhalb eines Werktags; Zählungen pro Jahr seit 2016; ein Grund für jede Ablehnung |
| 2. Leistungserbringer, der Patientendaten anfordert | 1. Januar 2027 | Ein Attributionstest mit drei Anfragen; Opt-outs ausgeschlossen; vollständige Antwort innerhalb eines Werktags |
| 3. Leistungserbringer, der eine Vorabgenehmigung beantragt | 1. Januar 2027 | Jeder aufgelistete Code durch die API geführt; gleiche Dokumentation und Ergebnisse wie Ihre Prüfer |
| 4. Ein anderer Krankenversicherungsplan | 1. Januar 2027 | Opt-in rechtzeitig angeboten; Anfragen innerhalb einer Woche versandt; ein Test-Datenaustausch in beide Richtungen |
| 5. Ein App-Entwickler | Patient Access seit 2021. Die anderen drei APIs ab 1. Januar 2027 | Dokumentation von Ihrer Startseite ohne Konto lesbar; schriftliche Kriterien für die Sperrung von Apps |
| 6. CMS und die Öffentlichkeit | Berichte bis 31. März jedes Jahres, erstmals 2026. Mitgliederseiten seit 2021 | Jeder Bericht, jede Mitteilung und jede Seite, jeweils mit einem Verantwortlichen und einem Link |
| 7. Ihr eigenes Team | Patient Access seit 2021. Die anderen drei APIs ab 1. Januar 2027 | Prüfungen 1 bis 4 nach Zeitplan mit Benachrichtigungen; Versionen pro API; aktuellster Konformitätsprüfbericht |

Für einen Medicaid Managed Care-Plan bedeutet ein Datum 2026 oder 2027 den ersten Bewertungszeitraum, der an oder nach diesem Datum beginnt.

## 1. App eines Mitglieds

**Fragen Sie Ihr Team.** Wenn die App eines Mitglieds dessen Daten anfordert, sind alle Daten vorhanden und pünktlich verfügbar?

**Was die Regel sagt.** Die Patient Access API muss der App eines Mitglieds die folgenden Daten, die Sie pflegen, für Leistungsdaten ab dem 1. Januar 2016 bereitstellen:

- Abgerechnete Ansprüche, einschließlich Zahlungsentscheidungen, die angefochten werden können, wurden oder werden, mit Erstattungen an den Leistungserbringer und dem Eigenanteil des Mitglieds. Fällig einen Werktag nach Verarbeitung des Anspruchs.
- Leistungsdaten von Leistungserbringern, die Sie über Kopfpauschalen vergüten. Fällig einen Werktag nach Eingang.
- Klinische Daten: jede Datenklasse in USCDI, der föderalen Liste standardisierter Gesundheitsdaten wie Diagnosen, Laborbefunde, Medikamente und Allergien. Fällig einen Werktag nach Eingang.
- Wenn Sie Part D anbieten: Part D-Arzneimittelansprüche mit Erstattungen und Eigenanteilen, fällig einen Werktag nach Abrechnung des Anspruchs, sowie Ihr Formularium mit Stufen und Nutzungsmanagementregeln.
- Ab dem 1. Januar 2027: jede Vorabgenehmigung für Leistungen und Dienste, Arzneimittel ausgenommen. Die App sieht deren Status, das Datum der Genehmigung oder Ablehnung, das Enddatum, was genehmigt wurde, einen spezifischen Ablehnungsgrund sowie die strukturierte Dokumentation, die der Leistungserbringer eingereicht hat. Fällig einen Werktag nach der Anfrage und nach jeder Statusänderung, und mindestens ein Jahr nach der letzten Änderung aufzubewahren.

Ein Medicaid Managed Care-Plan lässt verschreibungspflichtige ambulante Medikamente aus und schließt alle seine Leistungsdaten sowie die Anspruchs- und Leistungsdaten seiner Subunternehmer ein.

**Was die Antwort zeigen sollte.** Drei Ergebnisse, entnommen aus den Ladeprotokollen und der API – nicht aus dem Designdokument.

- **Pünktlichkeit.** Ihr Team sollte wissen, welcher Anteil der Ansprüche der vergangenen Woche innerhalb eines Werktags nach dem Datum erschienen ist, das das Abrechnungssystem als Verarbeitungsdatum markiert hat. Das Ziel ist 100 % mit einem dokumentierten Grund für jeden verspäteten Anspruch. Dieselbe Kennzahl sollte für Leistungsdaten, klinische Daten, Part D-Ansprüche und Vorabgenehmigungen vorliegen, jeweils gemessen ab dem in der Regel festgelegten Datum. Ein nächtlicher Ladelauf kann bestehen. Ein wöchentlicher Ladelauf kann es nicht.
- **Historie.** Nehmen Sie eine Stichprobe langjähriger Mitglieder und zählen Sie deren Ansprüche und Leistungsdaten für jedes Jahr seit 2016 – einmal in der API und einmal in Ihren eigenen Unterlagen. Das bedeutet jedes System, das die Daten des Mitglieds enthält, einschließlich eines Abrechnungssystems, das Sie inzwischen ersetzt haben, sofern Sie dessen Daten noch aufbewahren. Für einen Medicaid-Plan bedeutet das auch die Daten von Subunternehmern und kopfpauschal vergüteten Leistungserbringern. Eine Plattform, die nur ab ihrem Startdatum geladen wurde, besteht diesen Test nicht – ebenso wenig eine mit einem fehlenden Jahr.
- **Ablehnungen.** Zwei Zahlen für den vergangenen Monat, die gleich sein sollten. Die erste ist die Anzahl der abgelehnten Vorabgenehmigungsanfragen für Leistungen und Dienste – Arzneimittel nicht mitgezählt –, über alle Systeme hinweg, die darüber entscheiden. Das schließt jeden Anbieter ein, der für Sie entscheidet, da der Plan für seine Anbieter verantwortlich bleibt. Die zweite ist die Anzahl dieser Ablehnungen, die mit einem spezifischen Grund in der API ankommen. Eine Lücke zwischen beiden bedeutet Ablehnungen, die die API nie erreichen oder sie ohne Grund erreichen. Seit dem 1. Januar 2026 muss jede Ablehnung, die Sie einem Leistungserbringer übermitteln, bereits einen spezifischen Grund enthalten, unabhängig vom Übermittlungsweg. Der Grund existiert also irgendwo – die Frage ist, ob der Feed ihn in die API überträgt. Die Regel gibt keine Liste von Grundcodes vor, daher bitten Sie auch darum, fünf Ablehnungen so zu sehen, wie sie die App eines Mitglieds anzeigt. Jede sollte den Grund angeben – zum Beispiel, welche Kriterien die Anfrage nicht erfüllt hat.

Führen Sie die Vorabgenehmigungsprüfungen bis 2027 in der Vorproduktionsumgebung durch, mit echten Anfragen und Ablehnungen aus dem Produktions-Feed. Testdaten enthalten einen ausgefüllten Grund, sodass eine Lücke nicht sichtbar wird.

## 2. Leistungserbringer, der Patientendaten anfordert

**Fragen Sie Ihr Team.** Wenn ein netzwerkintern tätiger Leistungserbringer die Daten eines Patienten anfordert, erhält er ausschließlich seine eigenen Patienten und nur diejenigen, die kein Opt-out erklärt haben?

**Was die Regel sagt.** Ab dem 1. Januar 2027 stellt die [Provider Access API](https://www.ecfr.gov/current/title-42/section-422.121) netzwerkinternen Leistungserbringern dieselben Daten wie die Patient Access API bereit, zurückgehend bis zum 1. Januar 2016, jedoch ohne Erstattungen an den Leistungserbringer und ohne Eigenanteile des Mitglieds. Die Daten sind spätestens einen Werktag nach der Anfrage des Leistungserbringers bereitzustellen. Vor der Weitergabe bestätigen Sie die Identität des Leistungserbringers und prüfen, ob das Mitglied ihm zugeordnet ist, unter Verwendung Ihres eigenen Verfahrens zur Verknüpfung von Mitgliedern mit netzwerkinternen Leistungserbringern. Mitglieder können jederzeit ein Opt-out erklären und ihre Entscheidung ändern, und die Möglichkeit zum Opt-out muss verfügbar sein, bevor Sie erstmals Daten weitergeben.

**Was die Antwort zeigen sollte.**

- **Attribution.** Ein Test mit drei Anfragen. Ein netzwerkintern tätiger Leistungserbringer, der Daten zu einem ihm zugeordneten Mitglied anfordert, erhält die Daten. Derselbe Leistungserbringer, der Daten zu einem nicht zugeordneten Mitglied anfordert, erhält nichts. Ein Leistungserbringer außerhalb Ihres Netzwerks erhält nichts.
- **Opt-out.** Ein Mitglied, das ein Opt-out erklärt hat, wird aus der Antwort ausgeschlossen. Sobald dieses Mitglied wieder zustimmt, werden seine Daten wieder zurückgegeben.
- **Pünktlichkeit.** Wie lange jede Anfrage dauert, bis die Daten bereitstehen. Es sollte ein Werktag oder weniger sein. Bei einer Anfrage, die eine ganze Patientengruppe umfasst, endet die Zeitmessung bei der vollständigen Antwort, nicht beim ersten Datensatz.
- **Historie.** Die gleiche jahresweise Prüfung wie in Frage 1.

## 3. Leistungserbringer, der eine Vorabgenehmigung beantragt

**Fragen Sie Ihr Team.** Liefert die Prior Authorization API einem Leistungserbringer dieselbe Antwort wie unsere Prüfer – für jeden Code, einschließlich der Codes, die ein Anbieter für uns prüft?

**Was die Regel sagt.** Ab dem 1. Januar 2027 muss die [Prior Authorization API](https://www.ecfr.gov/current/title-42/section-422.122) Ihre Liste der vorabgenehmigungspflichtigen Leistungen und Dienste enthalten. Sie muss dem Leistungserbringer auch mitteilen, welche Dokumentation jeder Eintrag erfordert, und angeben, ob Sie genehmigen (und bis wann), ablehnen oder weitere Informationen benötigen. Eine Ablehnung muss einen spezifischen Grund angeben.

**Was die Antwort zeigen sollte.**

- **Codeliste.** Jeder Code auf Ihrer Vorabgenehmigungsliste wird über die API geführt, einschließlich der Codes, die ein Anbieter für Sie prüft. Arzneimittel sind nicht im Geltungsbereich. Wenn ein Code Bedingungen hat – etwa den Behandlungsort oder die Anzahl der Einheiten –, testen Sie einen Fall, der die Bedingung erfüllt, und einen, der es nicht tut. Eine Stichprobe von Codes, die nicht auf der Liste stehen, wird als nicht vorabgenehmigungspflichtig zurückgegeben. Die API und Ihre Prüfer arbeiten mit einer einzigen aktuellen Liste.
- **Dokumentation.** Für eine Stichprobe von Codes fordert die API dieselbe Dokumentation an wie Ihre Prüfer.
- **Entscheidungen.** Für einige Testanfragen gibt die API das Ergebnis zurück, das ein Prüfer erzielt hat: genehmigt mit dem Datum oder Ereignis, wann die Genehmigung endet; abgelehnt mit einem spezifischen Grund; oder eine Anforderung weiterer Informationen.

## 4. Ein anderer Krankenversicherungsplan

**Fragen Sie Ihr Team.** Wenn ein Mitglied von einem anderen Plan wechselt, werden wir seine Historie rechtzeitig anfordern? Wenn ein anderer Plan uns anfragt, werden wir rechtzeitig antworten?

**Was die Regel sagt.** Ab dem 1. Januar 2027 laufen beide Richtungen über die Payer-to-Payer API, und beide hängen vom Opt-in des Mitglieds ab.

- **Anfragen.** Sie bieten das Opt-in an und beginnen, die früheren und gleichzeitigen Pläne jedes Mitglieds zu ermitteln. Für aktuelle Mitglieder beginnt beides bis zum 1. Januar 2027. Für neue Mitglieder beginnt beides innerhalb einer Woche nach Versicherungsbeginn oder nach der Akzeptanz der Einschreibung durch CMS, je nachdem, was später eintritt. Sobald Sie das Opt-in und ausreichende Informationen über den anderen Plan vorliegen haben, geht die Anfrage innerhalb einer Woche raus. Für einen Plan, bei dem das Mitglied gleichzeitig versichert ist, wiederholen Sie die Anfrage mindestens vierteljährlich.
- **Antworten.** Wenn ein anderer Plan anfragt und bestätigt, dass das Mitglied bei ihm eingeschrieben ist und ein Opt-in erklärt hat, stellen Sie die Daten innerhalb eines Werktags bereit.
- **Daten.** Patient Access-Daten der letzten fünf Jahre, ohne Erstattungen an den Leistungserbringer, Eigenanteile des Mitglieds und abgelehnte Vorabgenehmigungen. Hinzu kommt die unstrukturierte Dokumentation, die Leistungserbringer mit Vorabgenehmigungen eingereicht haben.

Wenn Sie einen Medicaid Managed Care-Plan betreiben, überträgt die Regel das Opt-in und die Suche nach früheren und gleichzeitigen Plänen dem Bundesstaat, der das Opt-in dann an Sie weitergibt. Die Regel schreibt nicht vor, wie das geschehen soll, und nicht jeder Bundesstaat hat dafür bereits ein Verfahren eingerichtet. Das Versenden der Anfragen, deren Wiederholung und die Beantwortung anderer Pläne verbleiben in jedem Fall bei Ihnen.

**Was die Antwort zeigen sollte.**

- **Opt-in-Angebot.** Der Anteil der aktuellen Mitglieder, denen das Opt-in bis zum 1. Januar 2027 angeboten wurde, und der Anteil der neuen Mitglieder, denen es innerhalb einer Woche angeboten wurde. Zählen Sie die Angebote, nicht die Antworten, denn die Frist gilt für das Anbieten. Für einen Medicaid-Plan fragen Sie stattdessen, was Ihr Bundesstaat für das Angebot eingerichtet hat und wie die Opt-ins bei Ihnen ankommen werden. Wenn die Antwort lautet, dass noch nichts eingerichtet ist, fragen Sie, wer in der Zwischenzeit das Opt-in einholt und wo es aufbewahrt wird. Ohne Opt-in geht keine Anfrage raus.
- **Pünktlichkeit.** Wie lange es dauert vom Vorliegen des Opt-ins und der Angaben zum anderen Plan bis zum Versand der Anfrage. Es sollte eine Woche oder weniger sein. Bei Mitgliedern mit einem gleichzeitigen Plan sollte die letzte Wiederholungsanfrage weniger als ein Quartal alt sein.
- **Test-Datenaustausch.** In der Vorproduktionsumgebung, in beide Richtungen, mit dem Testsystem eines anderen Krankenversicherungsplans oder einem simulierten. Ihre Anfrage gibt an, dass das Mitglied bei Ihnen eingeschrieben ist und ein Opt-in erklärt hat. Ihre Antwort auf deren Anfrage liegt innerhalb eines Werktags vor. Für ein Testmitglied mit mehr als fünf Jahren Historie werden genau die oben beschriebenen Daten zurückgegeben.

## 5. Ein App-Entwickler

**Fragen Sie Ihr Team.** Kann jemand ohne Konto die Dokumentation aller vier APIs lesen?

**Was die Regel sagt.** Jede API benötigt eine öffentliche Dokumentation: wie sie aufgerufen wird, was sie akzeptiert, was sie zurückgibt und wie sich eine App registriert. Die Regel verbietet „die Anforderung, sich zu registrieren oder ein Konto zu erstellen, um die Dokumentation zu erhalten". Ebenso dürfen Sie keine Gebühr erheben, sie nur per E-Mail versenden oder Entwickler dazu verpflichten, Werbematerial zu lesen oder vorab einer Nachrichtenübermittlung zuzustimmen.

Die Regel begrenzt auch, wann Sie einer App den Zugang verweigern dürfen. Wenn Sie jemals einer App den Zugang zu einer der vier APIs verweigern oder beenden, benötigen Sie objektive, überprüfbare Kriterien, die auf jede App in gleicher Weise angewendet werden. Die Entscheidung muss auf der Feststellung beruhen, dass die App Gesundheitsdaten von Mitgliedern in Ihren Systemen einem unzumutbaren Risiko aussetzt.

**Was die Antwort zeigen sollte.** Sie können die Dokumentation selbst prüfen. Die Regel verlangt, dass sie auf Ihrer Website veröffentlicht oder über einen öffentlichen Link erreichbar ist. Beginnen Sie daher dort, wo ein Entwickler beginnen würde: der Startseite Ihres Plans, geöffnet in einem privaten Browserfenster. Finden Sie von dort aus die Seite für Entwickler und folgen Sie den Links für jede API. Wenn Sie sie von der Startseite aus nicht finden können, kann ein Entwickler es auch nicht. Sie sollten alles lesen können – einschließlich der Anleitung zur App-Registrierung –, ohne sich anzumelden, ein E-Mail-Formular auszufüllen, zu bezahlen oder ein Kästchen anzukreuzen. Die Registrierung einer App kann weiterhin ein Konto erfordern. Das Lesen der Anleitung dazu darf es nicht. Dokumentation, die im Portal eines Anbieters hinter dessen Login sitzt, besteht diese Anforderung nicht. Für die Sperrung einer App fragen Sie nach den schriftlichen Kriterien und danach, wer sie anwendet.

## 6. CMS und die Öffentlichkeit

**Fragen Sie Ihr Team.** Welche Berichte, Mitgliedermitteilungen und Seiten verlangt die Regel, wer ist für jeden einzelnen verantwortlich, und wo kann ich ihn einsehen?

**Was die Regel sagt.** Teile der Regel sind überhaupt keine Endpunkte, sondern Berichte und einfach verständliche Seiten:

- Nutzungszahlen der Patient Access API, bis 31. März jedes Jahres an CMS zu melden, erstmals fällig am 31. März 2026.
- Statistiken zu Vorabgenehmigungen, bis 31. März jedes Jahres auf Ihrer Website zu veröffentlichen, erstmals fällig am 31. März 2026.
- Eine Seite, die Mitgliedern hilft, eine App sicher auszuwählen, und ihnen zeigt, wo sie eine Beschwerde einreichen können. Sie gilt für Patient Access seit dem 1. Januar 2021.
- Für Provider Access: einfach verständliche Informationen für Mitglieder über den Datenaustausch und die Möglichkeit zum Opt-out. Sie werden versandt, bevor Sie erstmals Daten weitergeben, und danach jährlich, und bleiben auf Ihrer öffentlichen Website. Neue Mitglieder erhalten sie innerhalb einer Woche nach Versicherungsbeginn oder nach der Akzeptanz der Einschreibung durch CMS, je nachdem, was später eintritt. Für einen Medicaid-Plan gilt: innerhalb einer Woche nach der Einschreibung. Leistungserbringer erhalten auf Ihrer Website ebenfalls einfach verständliche Anleitungen, einschließlich der Nutzung Ihres Attributionsverfahrens.
- Für Payer-to-Payer: einfach verständliche Informationen für Mitglieder bei der Anfrage zum Opt-in, jährlich und auf Ihrer öffentlichen Website. Ein Medicaid-Plan stellt sie jährlich und auf seiner Website bereit. Die Mitteilung, die der Opt-in-Anfrage beiliegt, ist Aufgabe des Bundesstaates.

**Was die Antwort zeigen sollte.** Eine Liste aller Berichte, Mitteilungen und Seiten, jeweils mit einem namentlich genannten Verantwortlichen. Für die beiden Berichte: die CMS-Einreichung vom März 2026 und die Seite mit den Statistiken. Für jede Seite: ein Link, den Sie aufrufen können. Für die Mitgliedermitteilungen: das letzte Mailing oder die letzte Nachricht mit dem Datum des Versands.

## 7. Ihr eigenes Team

**Fragen Sie Ihr Team.** Werden wir merken, wenn eine dieser Prüfungen zu scheitern beginnt, und setzen wir die Versionen der Standards ein, die die Regel erlaubt?

**Was die Regel sagt.** Jede der vier APIs erfordert „routinemäßige Tests und Überwachung", um sicherzustellen, dass sie funktioniert.

Die CMS-Regel benennt auch die Standards, denen jede API folgt. Für jeden verweist sie auf eine Version auf einer [vom Office of the National Coordinator for Health IT (ONC) gepflegten Liste](https://www.ecfr.gov/current/title-45/section-170.215):

- Alle vier APIs verwenden FHIR R4, den Basisstandard, und US Core, die darauf aufbauenden US-Profile.
- Alle außer Payer-to-Payer verwenden SMART App Launch, das Verfahren, mit dem sich eine App anmeldet und autorisiert wird.
- Provider Access und Payer-to-Payer verwenden Bulk Data für eine ganze Patientengruppe in einer Anfrage.
- Patient Access verwendet OpenID Connect zur Bestätigung der Benutzeridentität.

Bei zweien davon verweist die CMS-Regel auf ältere Versionen: US Core 3.1.1 und SMART App Launch 1.0.0. Die CMS-Regel erlaubt die Verwendung einer neueren Version, wenn ONC diese für sein Zertifizierungsprogramm zugelassen hat und kein anderes Gesetz dies verbietet. Der Wechsel darf den Zugang der Nutzer zu den Daten nicht unterbrechen.

Derzeit verlangt die Regel nicht die Da Vinci- oder CARIN-Implementierungsleitfäden, die detaillierten FHIR-Spezifikationen für Zahlerdaten. Eine [im April 2026 vorgeschlagene CMS-Regel](https://www.federalregister.gov/documents/2026/04/14/2026-07205/medicare-and-medicaid-programs-patient-protection-and-affordable-care-act-interoperability-standards) würde CARIN Blue Button, Da Vinci Payer Data Exchange und die Da Vinci-Leitfäden für Vorabgenehmigungen ab dem 1. Oktober 2027 vorschreiben. Sie ist noch nicht abschließend.

Derselbe Vorschlag „empfiehlt nachdrücklich", dass Zahler Testwerkzeuge wie Inferno, das quelloffene Testtool von ONC, für die Tests verwenden, die die Regel bereits verlangt. Inferno verfügt über [Test-Kits](https://inferno.healthit.gov/test-kits/) für US Core, SMART App Launch, Bulk Data sowie die CARIN- und Da Vinci-Leitfäden. Ein bestandener Lauf zeigt, dass die Antworten einer API dem Standard entsprechen. Er zeigt nicht, dass Ansprüche pünktlich eintreffen, dass ein Leistungserbringer ausschließlich seine eigenen Patienten sieht oder dass die Ablehnungen eines Anbieters einen Grund enthalten. Er beantwortet also einen Teil dieser Frage, nicht die Fragen 1 bis 6.

**Was die Antwort zeigen sollte.**

- **Überwachung.** Die Prüfungen aus den Fragen 1 bis 4 laufen nach einem Zeitplan, mit den aktuellsten Ergebnissen und der Person, die benachrichtigt wird, wenn eine Prüfung fehlschlägt. Ein einzelner Test vor dem Go-live ist keine Überwachung.
- **Versionen.** Eine Zeile für jede API und jeden Standard mit der jeweiligen Version. Jede Version ist entweder die, auf die die CMS-Regel verweist, oder eine neuere, die ONC für sein Zertifizierungsprogramm zugelassen hat. Für eine neuere Version kann das Team erklären, warum der Wechsel niemanden vom Datenzugang abgeschnitten hat. Die Liste gibt auch an, ob jede API den CARIN- und Da Vinci-Leitfäden folgt, damit Sie wissen, wie viel Arbeit verbleibt, wenn der Vorschlag abschließend wird.
- **Konformität.** Für jede API der aktuellste Inferno-Bericht gegen die Versionen auf dieser Liste und die Leitfäden, denen die API folgt, mit dem Datum des Laufs.

Wenn eine Zeile noch US Core 3.1.1 oder SMART App Launch 1.0.0 ausweist, sollte das Team einen Migrationsplan haben. Die Zertifizierung beider durch ONC ist am 1. Januar 2026 ausgelaufen, und seitdem kann Gesundheits-IT nicht mehr nach diesen Versionen zertifiziert werden. Eine [abschließende Regel von ONC](https://www.federalregister.gov/documents/2026/10/28/2026-21943/health-data-technology-and-interoperability-onc-deregulatory-actions-to-unleash-prosperity) entfernt beide am 28. Dezember 2026 von seiner Liste. Der CMS-Vorschlag vom April 2026 würde es Zahlern untersagen, eine abgelaufene Version zu verwenden, womit US Core 6.1.0, das für Version 3 von USCDI entwickelt wurde, und SMART App Launch 2.0.0 verbleiben würden. Bis das abschließend ist, sind die neueren Versionen für Zahler erlaubt, aber nicht vorgeschrieben.

## Wie Health Samurai unterstützt

Mit [Payerbox](/cms-0057-f), der Plattform von Health Samurai für CMS-0057-F, erhalten Sie mehr als ein Produkt: ein Team, das Ihnen hilft, diese sieben Fragen zu beantworten. [Buchen Sie eine einstündige Bereitschaftsprüfung](/contacts) und wir gehen alle sieben gemeinsam mit Ihrem Team durch.