--- { "title": "CMS HL7 FHIR Connectathon 2026: Ergebnisse aus den Tracks Burden Reduction und PDex", "description": "Health Samurai nahm an zwei Tracks des 7. jährlichen CMS HL7 FHIR Connectathons teil: Burden Reduction und PDex Payer-to-Payer. Hier erfahren Sie, was wir getestet haben und was wir dabei gelernt haben.", "date": "2026-07-28", "author": "Health Samurai Team", "reading-time": "5 min read", "tags": ["Integrations", "Compliance"], "utm-campaign": "events", "utm-content": "connectathon-2026" } --- > 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. --- 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 praktisches Testen: Implementierer setzen echte FHIR-Workflows gegeneinander ein, arbeiten gemeinsam an Schwachstellen und bereiten sich auf die kommenden Interoperabilitätsanforderungen von CMS und ONC vor. Wir haben in diesem Jahr an zwei Tracks teilgenommen – **Burden Reduction** und **PDex Payer-to-Payer** – und unsere Implementierungen direkt gegen andere Payer- und Anbietersysteme getestet. Nachfolgend finden Sie eine Zusammenfassung des jeweiligen Verlaufs. ## Burden Reduction Track Im Da Vinci **Burden Reduction** Track (CRD, DTR und PAS – der elektronische Stack für Prior Authorization) übernahmen wir die Payer-Seite: Unser Server stellte die CDS Hooks, DTR-Fragebögen und PAS-Operationen bereit, während EHR-Anbieter ihre providerseitigen Implementierungen dagegen testeten. Über zwei Tage hinweg führten wir Sitzungen mit **Epic**, **MEDITECH**, **Darena Health**, **MEDHOST**, **Oracle Health** und **Altera Digital Health** durch. Vielen Dank an alle für die sorgfältig vorbereiteten Tests. Das gemeinsame Testszenario war eine Prior Authorization für Heim-Sauerstofftherapie: Ein CRD `order-sign`-Hook gibt eine Karte mit dem Hinweis „Prior Authorization erforderlich" zurück, die eine Coverage-Information-Systemaktion mit Verweis auf einen DTR-Fragebogen enthält; die Klinikerin bzw. der Kliniker füllt das vorausgefüllte Formular aus, und das resultierende Bundle wird an PAS `Claim/$submit` übermittelt, wo es innerhalb von Sekunden beschieden wird. Über diesen Happy Path hinaus erprobten wir alle vier CRD Hooks, DTR `$questionnaire-package`, PAS `$inquire`, CDex `$submit-attachment` sowie die Workflows für Anspruchsaktualisierung und -stornierung. Die gesamte Kette – vom CRD-Card über das DTR-Formular bis zur PAS-Einreichung – lief mit echten EHR-Systemen als Treiber vollständig durch. In mehreren Durchläufen kamen Identifier, die in unserer CRD-Antwort geprägt wurden, in der PAS-Einreichung des Partners wieder bei uns an. Das ist ein überzeugender Beweis dafür, dass die einzelnen Teile zusammenpassen – und er erforderte auf beiden Seiten echten Engineering-Aufwand. Wie beim PDex-Track lieferte das Testen gegen echte Systeme uns eine konkrete, priorisierte Liste von Verbesserungen, und die meisten davon haben wir noch während der Veranstaltung selbst behoben und neu deployt. Eine Payload, die in einer Morgensitzung fehlschlug, bestand am selben Nachmittag beim erneuten Test häufig. Einige Beispiele: Derselbe HCPCS-Code kann unter verschiedenen URI-Schreibweisen ankommen; daher haben wir das Policy-Matching so angepasst, dass diese kanonisiert werden, anstatt sich darauf zu verlassen, welche das EHR verwendet. Wir haben die Validierungsstrenge angepasst, sodass harmlose Abweichungen bei Display-Strings und Referenzen nun als Warnung ausgegeben werden statt zu blockieren, während unvollständige Einreichungen weiterhin eine klare Fehlerantwort erhalten. Außerdem haben wir Coverage-Aussagen auf eindeutige Entscheidungen umgestellt und Probleme bei der Fragebogen-Vorausfüllung behoben, die erst auftraten, als echte DTR-Clients echte Formulare öffneten. Der Austausch verlief auch hier in beide Richtungen. Wir haben Partnern Hinweise zur PAS-Bundle-Selbstständigkeit gegeben (welche referenzierten Ressourcen im Einreichungs-Bundle enthalten sein müssen) sowie zum DTR-Launch-Signaling in CRD 2.1, wo die Coverage-Information-Systemaktion das ältere Card-Link-Muster abgelöst hat, zuzüglich einiger kleinerer Beobachtungen zu Testdaten. Zwei Probleme haben wir unterhalb unseres eigenen Codes lokalisiert und an unseren FHIR-Plattformanbieter gemeldet. ## PDex Payer-to-Payer Track Im Da Vinci **Payer Data Exchange (PDex)** Payer-to-Payer Track testeten wir unsere Implementierung gegen drei andere Systeme: **InterSystems**, **Hike Health** und **CareEvolution**. Vielen Dank an alle Teilnehmenden für den Test unserer Lösung. Ziel war es, den vollständigen Payer-to-Payer-Ablauf von Anfang bis Ende zu erproben – Member Matching über `$bulk-member-match`, gefolgt von Bulk Data Export über `$davinci-data-export`. Das Testen gegen echte Systeme brachte eine konkrete, priorisierte Liste von Verbesserungen zutage, die von den Teams, die unsere Lösung integrierten, rückgemeldet wurden. Das Feedback konzentrierte sich auf einige wenige Themen: Abgleich unseres CapabilityStatements mit den Erwartungen des IG hinsichtlich der Deklaration von PDex-Operationen, Lockerung einiger strenger Validierungs- und Request-Body-Prüfungen, die Partnern im Weg standen, Präzisierung unserer Bulk-Export-Filter sowie eine verständlichere Darstellung des einwilligungsbasierten Routings von matched Members, wenn ein Member Einschränkungen unterliegt. Dabei handelt es sich um keine strukturellen Probleme; es sind genau die Art von Interoperabilitätsdetails, die erst beim Testen gegen echte Systeme sichtbar werden, und wir arbeiten sie derzeit ab. Auch wir haben einige Beobachtungen an unsere Testpartner zurückgegeben – zum Beispiel, dass einige Implementierungen während der Veranstaltung keinerlei Referenz- oder FHIR-Validierung durchführten und eine ein Missverhältnis zwischen synchronen und asynchronen Matching-Zählungen aufwies. Genau dieser bidirektionale Austausch ist der Sinn eines Connectathons: Jedes Team geht mit einem klareren, handlungsorientierteren Backlog nach Hause. ## Selbst ausprobieren Möchten Sie unsere Implementierung auf dieselbe Weise testen, wie es unsere Connectathon-Partner getan haben? Wir können Sie mit denselben Szenarien einrichten, die wir während der Veranstaltung verwendet haben: Member Matching und Bulk Export auf der PDex-Seite sowie den CRD-, DTR- und PAS-Ablauf auf der Burden-Reduction-Seite. Nehmen Sie Kontakt mit uns auf, und wir helfen Ihnen beim Einstieg. Und wenn Sie Payer-to-Payer-Datenaustausch oder elektronische Prior Authorization auf FHIR aufbauen und einfach Erfahrungen austauschen möchten, freuen wir uns ebenfalls von Ihnen zu hören.