Der 7. jährliche CMS HL7 FHIR Connectathon fand vom 14. bis 16. Juli 2026 statt – eine kostenlose virtuelle Veranstaltung, organisiert von den Centers for Medicare & Medicaid Services (CMS) gemeinsam mit HL7 International. Ziel ist das praxisnahe Testen: Implementierer setzen reale FHIR-Workflows gegeneinander ein, arbeiten gemeinsam an Schwachstellen und bereiten sich auf die in Kraft tretenden Interoperabilitätsanforderungen von CMS und ONC vor.
Für Krankenversicherungen gelten diese Anforderungen nach einem konkreten Zeitplan. CMS-0057-F setzt die Prior Authorization API und die Payer-to-Payer API zum 1. Januar 2027 in Kraft.
Wir haben Payerbox, unsere FHIR-Compliance-Plattform für Krankenversicherungen, in zwei Tracks eingebracht: Burden Reduction und PDex – mit direkten Tests gegen andere Kostenträger- und Anbietersysteme. Im Folgenden beschreiben wir, was wir ausgeführt haben, was nicht funktionierte und was wir geändert haben.
Burden Reduction Track
Im Da Vinci Burden Reduction Track (CRD, DTR und PAS: der elektronische Prior Authorization Stack) war Payerbox auf der Kostenträgerseite. Unser Server stellte die CDS-Hooks-Dienste, DTR-Fragebögen und PAS-Operationen bereit, und EHR-Anbieter testeten ihre providerseitigen Implementierungen dagegen. Im Verlauf von zwei Tagen führten wir Sitzungen mit sechs EHR-Anbietern durch: Epic, MEDITECH, Darena Health, MEDHOST, Oracle Health und Altera Digital Health. Unser Dank gilt allen sechs Teams für ihre gute Vorbereitung.
Das gemeinsame Szenario war eine Vorautorisierung für Heimsauerstofftherapie. Ein CRD-order-sign-Hook gibt eine Karte „Vorautorisierung erforderlich" zurück, die eine coverage-information-Systemaktion trägt, die auf einen DTR-Fragebogen verweist. Der Kliniker füllt das vorausgefüllte Formular aus, und das resultierende Bundle wird an PAS Claim/$submit übermittelt, das innerhalb von Sekunden eine ClaimResponse zurückgibt. Die Entscheidung des Utilization Managements folgt, und das EHR ruft sie über $inquire ab.
Über diesen Happy Path hinaus haben wir die vier CRD-Hooks, die Payerbox implementiert (order-sign, order-select, order-dispatch und appointment-book), DTR $questionnaire-package, PAS $inquire, CDex $submit-attachment sowie die Flows für Claim-Aktualisierung und -Stornierung erprobt. Die vollständige Kette – von der CRD-Karte über das DTR-Formular bis zur PAS-Einreichung – lief mit echten EHR-Systemen als Treiber vollständig durch. In mehreren Durchläufen kamen Bezeichner, die in unserer CRD-Antwort geprägt wurden, in der PAS-Einreichung des Partners zu uns zurück. Das ist ein guter Beweis dafür, dass die einzelnen Teile verbunden sind – und es erforderte auf beiden Seiten echten Engineering-Aufwand.
Was wir behoben haben
Live-EHR-Clients erzeugten eine priorisierte Fehlerliste. Eine Klasse von Korrekturen wurde noch während der Veranstaltung ausgeliefert, am zweiten Tag: Wir haben die Validierungsstrenge gelockert, sodass harmlose Abweichungen bei Anzeigezeichenketten und Referenzen als Warnungen behandelt werden statt zu blockieren, während tatsächlich unvollständige Einreichungen weiterhin eine saubere Fehlerantwort erhalten. Ein Payload, der in einer Vormittagssitzung fehlgeschlagen war, wurde beim Wiederholung noch am selben Nachmittag akzeptiert.
Die übrigen Korrekturen wurden in den darauffolgenden drei Tagen umgesetzt:
- Claim-Stornierung von Ende zu Ende, sodass eine stornierte Vorautorisierung über
$inquiresichtbar ist. - Coverage-Zusicherungen wurden von bedingten zu eindeutigen Entscheidungen geändert.
- Fragebogen-Vorausfüllung: Sieben Fragebögen wurden nie vorausgefüllt, weil ihre Launch-Kontexte ungebunden waren – was erst sichtbar wurde, als echte DTR-Clients echte Formulare öffneten.
- CRD-Hook-Anfragen mit
fhirServer: nullwurden abgelehnt, obwohl ein fehlender Schlüssel akzeptiert wurde; explizite Nullwerte werden nun wie fehlende Schlüssel behandelt. - PAS-Bundle-Abgeschlossenheit: Ressourcen, die aus einem früheren CRD-Austausch stammten, werden nicht mehr als kostenträgerseitig bekannte Referenzen gezählt, sodass
$submitein Bundle, das nicht in sich geschlossen ist, korrekt ablehnt.
Was wir zurückgegeben haben
Wir haben Partnern Hinweise zur PAS-Bundle-Selbstständigkeit gegeben (welche referenzierten Ressourcen im Einreichungs-Bundle enthalten sein müssen) sowie zu DTR-Launch-Signalisierung in CRD 2.1, wo die coverage-information-Systemaktion das ältere Card-Link-Muster ablöst, zuzüglich mehrerer kleinerer Beobachtungen zu Testdaten.
PDex Track
Im Da Vinci Payer Data Exchange (PDex) Track haben wir Payerbox gegen drei weitere Systeme getestet: InterSystems, Hike Health und CareEvolution. Unser Dank gilt allen drei Teams für die Tests gegen unser System. Ziel war der vollständige Payer-to-Payer-Flow von Ende zu Ende: Member Matching über $bulk-member-match, gefolgt von Bulk Data Export über $davinci-data-export.
Die Teams, die sich gegen unser System integrierten, erstellten eine eigene priorisierte Liste. Die meisten Punkte gruppierten sich um einige wenige Themen:
- Angleichung unseres CapabilityStatement daran, wie das IG erwartet, dass PDex-Operationen deklariert werden
- Lockerung einiger strenger Validierungs- und Request-Body-Prüfungen, die Partner behinderten
- Verschärfung unserer Bulk-Export-Filter
- Verbesserung der Lesbarkeit des einwilligungsbasierten Routings von gematchten Mitgliedern, wenn ein Mitglied eingeschränkt wird
Nichts davon ist struktureller Natur. Es handelt sich um Interoperabilitätsdetails, die nur im Zusammenspiel mit echten Gegenstellen sichtbar werden. Jeder Punkt wird als eigenes Issue verfolgt, und keines ist zum Zeitpunkt der Veröffentlichung abgeschlossen – das ist der ehrliche Zustand eines Tracks, in den wir eingestiegen sind, um genau das zu finden.
Wir haben auch Beobachtungen zurückgegeben: Einige Implementierungen führten während der Veranstaltung keine Referenz- oder FHIR-Validierung durch, und eine zeigte eine Diskrepanz zwischen synchronen und asynchronen Matching-Zählungen.
Provider Access
Derselbe Track umfasst auch Provider Access, eine weitere der vier CMS-0057-F APIs, und unsere Sitzung mit InterSystems erstreckte sich über beide. Provider Access nutzt den Großteil der Payer-to-Payer-Mechanik wieder: $provider-member-match löst die einem anfragenden Anbieter zugeordneten Mitglieder auf, und dasselbe $davinci-data-export liefert deren Anspruchs-, klinische und Vorautorisierungsdaten. Es lohnt sich, die Struktur explizit zu benennen, da dies der Teil ist, den Kostenträger am häufigsten neu gestalten müssen: Es handelt sich um einen Bulk Export über eine zugeordnete Gruppe, nicht um eine bedarfsgesteuerte Einzelpatienten-Abfrage. Die oben genannte Fehlerliste stammt aus den Payer-to-Payer-Szenarien.
Was das für Kostenträger bedeutet
CMS-0057-F ist mit keiner Prüfung verbunden. Es gibt keine autorisierte Prüfstelle und keine verbindliche Testsuite, wie es sie für ONC-zertifizierte EHRs gibt; Konformitätswerkzeuge wie Touchstone existieren, sind jedoch nicht vorgeschrieben. Nichts zertifiziert also, dass eine Prior Authorization oder Payer-to-Payer API funktioniert. Der einzige Nachweis besteht darin, dass sie gegen Gegenstellen ausgeführt wurde, die man nicht kontrolliert.
Das ist es, was ein Connectathon bringt – und deshalb sind die oben genannten Fehlerlisten der wertvolle Teil dieses Beitrags. Jeder Punkt auf ihnen stammte aus dem Payload eines Partners, nicht aus unserer eigenen Testsuite: ein ungebundener Launch-Kontext, der einen Fragebogen leer ließ; ein Bundle, das in sich geschlossen wirkte, bis ein echtes EHR es sendete; ein Nullwert, wo unser Schema einen fehlenden Schlüssel erwartete. Nichts davon lässt sich durch Tests gegen sich selbst erreichen.
Wenn Sie also Ihre eigene Bereitschaft oder die eines Anbieters beurteilen, lohnt es sich, diese Frage vor Januar 2027 zu stellen: Gegen welche echten Gegenstellen wurde dies geprüft, und was ist dabei nicht funktioniert?
Selbst ausprobieren
Möchten Sie Payerbox auf dieselbe Weise testen, wie es unsere Connectathon-Partner getan haben? Wir können Ihnen die Szenarien einrichten, die wir während der Veranstaltung durchgeführt haben: Member Matching und Bulk Export auf der PDex-Seite, CRD, DTR und PAS auf der Burden-Reduction-Seite. Zugang beantragen – wir helfen Ihnen beim Einstieg.
Wenn Sie Payer-to-Payer-Austausch oder elektronische Vorautorisierung auf FHIR aufbauen und einfach Erfahrungen austauschen möchten, nehmen Sie Kontakt auf. Wir freuen uns von Ihnen zu hören.
