Wenn Sie einen Medicare-Advantage-Plan betreiben, verpflichtet CMS Sie jetzt zur Veröffentlichung eines Anbieterverzeichnisses, das auflistet, welche Leistungserbringer und Einrichtungen für jeden Plan im Netzwerk sind, damit Medicare Plan Finder (MPF) die Frage beantworten kann, die Versicherte tatsächlich stellen: Ist mein Arzt abgedeckt? Diese Frage ist MA-spezifisch: Ein MA-Plan deckt ein vertraglich vereinbartes Netzwerk ab, und da MA ein bundesfinanziertes Medicare-Programm ist, das von privaten Versicherern verwaltet wird, kann CMS vorschreiben, wie das Verzeichnis zu veröffentlichen ist. Das Verzeichnis muss maschinenlesbar sein, innerhalb von 30 Tagen nach jeder Änderung aktualisiert werden und einmal jährlich bestätigt werden. Es ist Teil von CMS' umfassenderem Vorstoß hin zur FHIR-basierten Interoperabilität.
CMS akzeptiert zwei Formate – eine flache JSON-Datei oder FHIR; hier wird das FHIR-Format aufgebaut. Es folgt PDex Plan-Net, dem Da Vinci IG, der das Netzwerk eines Plans über FHIR-Profile auf InsurancePlan, Organization (sowohl als Netzwerk als auch als Einrichtung), Practitioner, PractitionerRole, Location und OrganizationAffiliation standardisiert, einschließlich der Verweise zwischen diesen. CMS fragt Ihren Server nicht pro Versichertem ab: Sein Crawler nimmt Ihre veröffentlichten Dateien einmal täglich auf und validiert sie, gemäß dem technischen Implementierungsleitfaden. Schlägt die Validierung fehl, wird die jährliche Bestätigung versäumt oder wird CMS' Datenqualitätsschwelle unterschritten, unterdrückt CMS Ihr Verzeichnis in MPF – in der Regel wird es wiederhergestellt, sobald das Problem behoben ist. Während es unterdrückt ist, können Versicherte, die Pläne vergleichen, Ihr Netzwerk nicht sehen. Daher ist es wichtig, dass das Verzeichnis bei jedem Durchlauf gültig ist.
Der Rest dieses Artikels beschreibt diese Pipeline, Schritt für Schritt.
Funktionsweise
Ihre Daten befinden sich bereits in Payerbox. Die Pipeline wandelt sie in die Dateien um, die CMS crawlt – nach einem festgelegten Zeitplan. Vier Stufen:
Der tägliche Durchlauf von Anfang bis Ende: Extraktion aus Payerbox, Filterung auf die In-Network-Teilmenge, Bündelung als FHIR, anschließende Veröffentlichung der Dateien, die CMS crawlt.
Ein geplanter Job führt das Ganze jeden Morgen aus, vor CMS' täglichem Crawl.
Alles nach der Extraktion ist einfacher Code über NDJSON und läuft daher mit einem Beispiel-Export, ohne Live-FHIR-Server.
Datenabruf
Es gibt zwei Möglichkeiten, die Ressourcen aus Payerbox abzurufen. Die Pipeline liest über eine gemeinsame
Quellschnittstelle, sodass beide verwendet werden könnten; wir nutzen Bulk $export.
- Die FHIR-REST-API. Seitenweise Abfrage mit gewöhnlichen Suchanfragen. Das ist gut geeignet für einen kleinen, gezielten Ausschnitt, aber das Abrufen ganzer Ressourcentypen in großem Umfang bedeutet viele Roundtrips, und die Daten können sich zwischen Seiten ändern.
- Die FHIR-Bulk-
$export-Operation. Diese Operation läuft asynchron und streamt alles in einem Durchlauf als NDJSON aus – ohne das seitenweise Abdriften beim Abfragen der Live-API. Sie ist genau dafür konzipiert, weshalb wir sie verwenden.
$export ist die standardmäßige FHIR Bulk Data Access-Operation,
mit _typeFilter zum Hineinreichen selektiver Filter in den Export und +gzip bei _outputFormat, um
den Dump klein zu halten. Mit _typeFilter sendet der Server nur die relevanten Ressourcen:
GET /fhir/$export
?_outputFormat=application/fhir+ndjson+gzip
&_type=InsurancePlan,Organization,Practitioner,PractitionerRole,Location,OrganizationAffiliation
&_typeFilter=InsurancePlan?status=active&_profile=.../plannet-InsurancePlan&_id=...
&_typeFilter=PractitionerRole?active=true&_profile=.../plannet-PractitionerRole&network=...
&_typeFilter=OrganizationAffiliation?active=true&_profile=.../plannet-OrganizationAffiliation&network=...
Gestartet mit dem Prefer: respond-async-Request-Header gibt $export 202 Accepted
mit einem Content-Location-Response-Header zurück: die Status-URL, die abgefragt wird, bis die NDJSON-Dateien
bereit sind. Pläne, Practitioner-Roles und Affiliations kommen bereits
auf aktive, In-Network-Plan-Net-Ressourcen eingeschränkt zurück. Die referenzierten untergeordneten Ressourcen kommen vollständig zurück,
sodass ein beibehaltener Datensatz niemals auf etwas Verworfenes zeigt.
Filterung auf die In-Network-Teilmenge
Das $export war der erste Filter: _typeFilter grenzt die übergeordneten Ressourcen auf dem FHIR-Server ein. Ein
codeseitiger Durchlauf löst dann die untergeordneten Ressourcen auf: Er durchläuft den Graphen (Plan → Netzwerk → verbundene
Organisationen und Leistungserbringer → ihre Standorte), behält eine untergeordnete Ressource nur dann bei, wenn eine beibehaltene übergeordnete Ressource
darauf verweist, und verwirft den Rest. Dieser Graph entspricht den Verweisen, die PDex
Plan-Net zwischen den sechs Ressourcen definiert:
Die Verweise zwischen Plan-Net-Ressourcen. _typeFilter grenzt die übergeordneten Ressourcen (InsurancePlan,
PractitionerRole, OrganizationAffiliation) auf dem FHIR-Server ein; der Code-Durchlauf behält dann die
von ihnen referenzierten untergeordneten Ressourcen bei.
Bündelung und Veröffentlichung
Beibehaltene Ressourcen werden in FHIR Bundles
(type: collection) aufgenommen, aufgeteilt nach Ressourcentyp in nummerierte Dateien (PractitionerRole-001.json,
-002.json usw.); jede Ressource behält ihr meta.lastUpdated aus der Quelle, das der Leitfaden
dem Datum der letzten Aktualisierung jedes Datensatzes zuordnet. CMS erwartet die Aufteilung: Er verlangt eine vertragsbezogene
Indexdatei – ein
Manifest jeder Datei-URL, die der Crawler zuerst liest:
{
"provider_urls": [
"https://.../H9999/2026/InsurancePlan-001.json",
"https://.../H9999/2026/PractitionerRole-001.json",
"https://.../H9999/2026/PractitionerRole-002.json",
"https://.../H9999/2026/Organization-001.json"
]
}
Die Aufteilung hält jede Datei in einer überschaubaren Größe für den Crawler; die Pipeline wechselt zur nächsten nummerierten Datei, sobald ein Bundle zu groß wird oder eine Eintragsgrenze überschreitet.
Die Veröffentlichung unterliegt einer strengen Regel: Ein Crawl darf niemals auf ein halb geschriebenes Verzeichnis treffen. Eine
Datei wie Organization-042.json enthält von einem Durchlauf zum nächsten unterschiedliche Ressourcen; daher ist
ein direktes Überschreiben, während das alte Manifest noch darauf zeigt, ein zerrissener Lesevorgang. Die Veröffentlichung ist daher ein atomarer Austausch: Die alten Dateien werden gelöscht, die neuen Bundles hochgeladen, anschließend
wird index.json als letztes hochgeladen. Dieser letzte Upload ist der einzige Schritt, der die neue Version live schaltet,
sodass ein Crawler mitten in der Veröffentlichung das gestrige Verzeichnis, das heutige oder einen kurzen 404 während des Austauschs sieht –
niemals eine halbfertige Mischung. Ein Durchlauf, der mittendrin fehlschlägt, löst eine Benachrichtigung aus. Es gibt keine partielle Wiederaufnahme:
Der nächste Durchlauf erstellt das gesamte Verzeichnis einfach von Grund auf neu.
Bereitstellung für den Crawler
CMS empfiehlt bedingte Anfragen, und der Endpunkt bedient sie. Jede Datei trägt einen ETag
(einen Fingerabdruck ihres Inhalts, der sich ändert, wenn die Datei sich ändert) und einen Last-Modified-Zeitstempel; der Crawler speichert diese und ruft beim nächsten Besuch eine Datei nur dann erneut ab, wenn sich ihr
ETag geändert hat. Unveränderte Dateien werden als 304 Not Modified ohne Body zurückgegeben:
GET /mpf-provider-directory/H9999/2026/Organization-042.json
If-None-Match: "a1b2c3" # the ETag the crawler received on its last fetch
→ 304 Not Modified # unchanged since then, so no body
Bei einem Verzeichnis mit Tausenden von Bundle-Dateien, die sich täglich kaum ändern, ist das der Unterschied
zwischen einem aufwändigen erneuten Crawl und einem günstigen. Es erklärt auch den atomaren Austausch: Der ETag muss
genau dann umschlagen, wenn sich der Inhalt ändert.
Dieser Endpunkt agiert als Proxy für einen privaten Bucket, anstatt den Bucket selbst offenzulegen, und benötigt keine Authentifizierung: Das Plan-Net-Verzeichnis ist für den offenen Zugang konzipiert, ohne Client-Registrierung.
Möchten Sie eines selbst aufbauen?
Der Aufbau ist für alle, die regelmäßig mit FHIR-Servern arbeiten, ein verhältnismäßig überschaubares Engineering-Vorhaben: ein täglicher Export-Filter-Bundle-Publish-Job. Die Sorgfalt liegt jedoch darin, es bei jedem Durchlauf korrekt auszuführen, und das Ganze setzt voraus, dass bereits korrekte Plan-Net-Daten im FHIR-Server vorhanden sind. Diese dorthin zu bringen, ist ein eigenes Projekt. Die Datenqualität sollte kontinuierlich überwacht und der PDex Plan-Net-Ressourcensatz fortlaufend gegen CMS' MPF-Kriterien validiert werden.
Dieses Verzeichnis wird als optionales Modul von Payerbox, Health Samurai's Plattform für CMS-Payer-Anforderungen, ausgeliefert, die auch die für 2027 fälligen CMS-0057-F-APIs bereitstellt.
Bauen Sie ein Anbieterverzeichnis für Medicare Plan Finder? Sprechen Sie mit unserem Team, um loszulegen.
