Engineering für den Europäischen Gesundheitsdatenraum: Was MedTech SaaS bis 2027 ändern muss

Die Verordnung über den Europäischen Gesundheitsdatenraum ist kein abstraktes Brüsseler Dokument, das in einem zukünftigen Release-Zyklus jemand anderen betreffen wird. Wenn du eine MedTech-SaaS betreibst, die Patienten, Kliniker oder Gesundheitseinrichtungen in der EU bedient, ist der EHDS eine konkrete Deadline mit konkreten technischen Verpflichtungen. Die Phaseneinleitung beginnt 2025, und die vollständigen Anforderungen für die Primärnutzung werden bis 2027 erwartet. Zu verstehen, welche Engineering-Änderungen er erfordert - und diese Änderungen so zu sequenzieren, dass sie deinen Feature-Roadmap nicht sprengen - ist jetzt eine Kernverantwortung jedes CTOs in diesem Bereich.

Dieser Beitrag arbeitet die wichtigsten Architekturänderungen durch, die EHDS erfordert, was jede auf Code-Ebene bedeutet und wie man das Phasieren auf einem realistischen Symfony-plus-Next.js-Stack angehen kann. Das ist keine Rechtsberatung; wende dich an deinen Compliance-Berater für die regulatorische Interpretation. Was folgt, ist die Engineering-Übersetzung.

Was EHDS tatsächlich auf Architekturebene erfordert

Die Verordnung unterscheidet zwischen zwei Nutzungskategorien. Die Primärnutzung umfasst den direkten Pflegekontext: ein Kliniker, der deine App nutzt, um Patientenakten einzusehen, einzugeben und darauf zu reagieren. Die Sekundärnutzung umfasst Forschung, Politik und Public-Health-Analysen - das Herausziehen de-identifizierter oder pseudonymisierter Daten aus deinem System in nationale Health Data Access Bodies (HDABs), die neue EU-Infrastruktur, die Daten über Mitgliedstaaten hinweg aggregieren wird.

Beide Kategorien legen technische Verpflichtungen auf, wirken sich aber unterschiedlich auf deine Architektur aus.

Für die Primärnutzung ist die Hauptanforderung Interoperabilität. Deine Plattform muss in der Lage sein, Patientendaten mithilfe von HL7 FHIR R4 (oder R5, wo Mitgliedstaaten es früh übernehmen) zu exportieren und, wo erforderlich, zu importieren. Die Verordnung verweist auf das European EHR Exchange Format, das auf FHIR-Profilen aufgebaut wird. In der Praxis bedeutet das, dass jede Entität, die du speicherst - Patientendemografie, klinische Beobachtungen, Rezepte, Laborbefunde, Bildgebungsmetadaten - eine maschinenlesbare FHIR-Darstellung benötigt, die auf Anfrage produziert werden kann. Das ist keine kosmetische API-Endpoint-Änderung; für die meisten SaaS-Produkte, die auf relationalen Datenmodellen aufgebaut sind, erfordert es eine nicht-triviale Mapping-Schicht.

Für die Sekundärnutzung ist die Verpflichtung komplexer. Patienten müssen in der Lage sein, ihre Einwilligung zur Nutzung ihrer Daten für bestimmte Sekundärzwecke zu erteilen und zu widerrufen - Forschungskategorien sind definiert und kodiert. Dein System muss diese Einwilligung mit ausreichender Granularität verfolgen, um die Daten eines Patienten von einer bestimmten Forschungskategorie auszuschließen, während sie in einer anderen enthalten bleiben. Der Widerruf muss innerhalb definierter Fristen verarbeitet werden, und du musst bei einem Audit nachweisen können, dass der Widerruf dort, wo technisch möglich, rückwirkend respektiert wurde. Das ist zweckbindende Metadaten auf Datensatzebene, nicht nur ein DSGVO-Einwilligungs-Checkbox auf einem Einstellungsbildschirm.

FHIR-Kompatibilität: Die Engineering-Realität

Wenn dein Produkt nicht mit FHIR im Sinn entworfen wurde, ist das Hinzufügen von FHIR-Unterstützung ein Projekt, kein Ticket. Hier ist, was die Arbeit tatsächlich beinhaltet.

Erstens brauchst du eine Ressourcen-Mapping-Schicht. Jedes klinische Konzept in deinem Domänen-Modell - Diagnose, Rezept, Beobachtung, Begegnung - muss dem entsprechenden FHIR-Ressourcentyp zugeordnet werden (Condition, MedicationRequest, Observation, Encounter). Das ist keine mechanische Eins-zu-eins-Übersetzung. FHIR hat spezifische Konventionen für Codierungssysteme (SNOMED CT, LOINC, ICD-10), Erweiterungsmuster für Konzepte, die die Basisspezifikation nicht abdeckt, und Profilbeschränkungen, die Implementierungen der Mitgliedstaaten zusätzlich zu den Basisressourcen auferlegen.

Auf einem Symfony-Stack ist der sinnvolle Ansatz, dies als explizite Domänen-Service-Schicht zu implementieren - ein FhirResourceMapper, der deine internen Domain-Objekte nimmt und FHIR-konforme JSON-Ausgaben produziert. Es gibt PHP-Bibliotheken, die die FHIR-Ressourcenklassen bereitstellen (das tightenco/fhir-Paket oder das dcarbone/php-fhir-Paket), sodass du keine JSON-Shapes von Hand aufbauen musst. Aber die Mapping-Logik - welche deiner internen Kodierungswerte welchem SNOMED-Code zugeordnet wird, wie du Nulls und unbekannte Werte darstellst - ist Geschäftslogik, die keine Bibliothek bereitstellen kann.

Zweitens brauchst du eine FHIR-konforme API-Oberfläche. Die EHDS-Implementierungsleitfaden verweisen auf SMART on FHIR für die Autorisierung, das OAuth 2.0 Scopes auf FHIR-Ressourcentypen auf eine bestimmte Weise aufschichtet. Dein bestehendes OAuth oder sitzungsbasiertes Auth muss erweitert oder umschlossen werden, um SMART-Launch-Sequenzen zu unterstützen, insbesondere wenn du EHR-eingebettete Launch-Kontexte unterstützen musst. Das ist bedeutende Arbeit sowohl am Symfony-Backend als auch am Next.js-Frontend, wenn deine App die patientenseitige oder klinikseitige Launch-Muster verwendet.

Drittens, FHIR-Validierung. Ressourcen, die dein System produziert, müssen schema-gültig sein. Das Ausführen von FHIR-Validierung in CI - mithilfe des HAPI-Validators oder einer leichteren JSON-Schema-Prüfung - verhindert die stille Drift, bei der ein Mapping fehlerhafte Ressourcen produziert, die erst beim Einreichen an ein HDAB fehlschlagen. Fügt dies früh zur Pipeline hinzu, nicht als Nachgedanke vor der Einreichungsfrist.

Sekundärnutzungs-Einwilligungs-Architektur

Das ist der Teil, den die meisten MedTech-SaaS-Teams unterschätzen. Die DSGVO hat dir den allgemeinen Rahmen gegeben; EHDS fügt spezifische Zweckkategorien und spezifische Verpflichtungen für die Sekundärnutzung von Gesundheitsdaten hinzu.

Die Architektur, die du brauchst, hat drei Komponenten.

Zweckregister: Eine Tabelle oder ein strukturierter Speicher, der die Sekundärnutzungskategorien definiert, die deine Jurisdiktion exponiert. Diese sind nicht willkürlich - die EHDS-Verordnung und nationale Implementierungen definieren die erlaubten Kategorien (Krankheitsregister, klinische Forschung, Politikanalyse, Überwachung der öffentlichen Gesundheit usw.). Dein System muss den aktuellen Katalog kennen.

Einwilligungsdatensätze je Patient: Für jeden Patienten in deinem System brauchst du einen Datensatz, welchen Sekundärnutzungskategorien sie zugestimmt haben, wann diese Einwilligung gegeben wurde und ob sie geändert oder widerrufen wurde. Das muss eine First-Class-Entität in deinem Domänen-Modell sein, kein JSON-Blob in einer Einstellungsspalte. Es sollte nur-append mit Zeitstempeln sein - du erstellst einen Audit-Trail, kein veränderbares Präferenz-Objekt.

Datenexport-Filterung: Wenn dein System Daten an ein HDAB exportiert (entweder auf Anfrage oder über einen geplanten Batch), muss die Export-Pipeline gegen Einwilligungsdatensätze joinen und Patienten ausschließen, die der relevanten Zweckkategorie nicht zugestimmt haben oder ihre Einwilligung widerrufen haben. Wenn du eine Reporting- oder Analytics-Pipeline hast, muss dort dieselbe Filterung angewendet werden. Der Einwilligungsdatensatz ist nicht nur für den Export-Endpoint - er ist ein Gate für jeden Sekundärnutzungs-Datenfluss.

Die Widerrufsbehandlung ist, wo Teams dazu neigen, Abkürzungen zu nehmen. EHDS verlangt, dass der Widerruf innerhalb eines definierten Fensters verarbeitet wird und dass du nachweisen kannst, dass er respektiert wurde. Für Batch-Exporte bedeutet das, frühere Exporte erneut auszuführen oder anzupassen, wenn ein Patient zwischen Export-Zyklen widerruft. Ob ein rückwirkender Widerruf technisch erforderlich ist, hängt von der spezifischen Datennutzung und Implementierung des Mitgliedstaats ab, aber das Entwerfen deiner Export-Pipeline als neu-ausführbar mit einer aktuellen Einwilligungs-Momentaufnahme ist der korrekte Standard. Damit vermeidest du den schmerzhaften Fall, in dem du einem HDAB erklären musst, warum Daten nach einem Widerruf eines Patienten enthalten waren.

Auditgerade Zugriffslogs

Sowohl die Primärnutzung als auch die Sekundärnutzung unter EHDS erfordert, dass Patienten ein Protokoll sehen können, wer auf ihre Daten zugegriffen hat, wann und zu welchem Zweck. Das ist kein Schönheitsmerkmal - es ist ein Patientenrecht unter der Verordnung, analog zum DSGVO-Auskunftsrecht, aber spezifischer für Zugriffsereignisse auf Gesundheitsdaten.

Die Engineering-Anforderung ist ein unveränderliches Zugriffsprotokoll, das erfasst: die zugreifende Entität (Kliniker, Forscher, nachgelagertes System), die zugegriffene Datenkategorie (klinische Notiz, Rezept, Bildgebung, Laborbefund), den Zeitstempel, den angegebenen Zweck und die Rechtsgrundlage. Dieses Protokoll muss je Patient abfragbar sein und über eine patientenseitige Schnittstelle bereitgestellt werden.

Wenn du Symfony verwendest, ist der kanonische Ansatz ein Event-Subscriber oder Doctrine-Lifecycle-Listener, der Zugriffsereignisse in eine separate, nur-append Tabelle oder einen Audit-Log-Service schreibt. Die wichtigste Designbeschränkung ist, dass diese Tabelle nicht durch denselben Anwendungscode änderbar sein darf, der klinische Daten liest und schreibt - du möchtest eine logische (oder physische) Trennung, die Manipulationen erschwert und Audit-Trails glaubwürdig macht. Eine schreibgeschützte Log-Tabelle mit einem separaten Schema-Benutzer, der nur INSERT-Rechte hat, oder ein event-sourced Log, das in einen separaten Service geschrieben wird, sind beides vernünftige Muster je nach deiner Skalierung.

Auf dem Frontend in Next.js ist die patientenseitige Zugriffslog-Ansicht eine schreibgeschützte Timeline-Komponente. Der schwierigere Teil ist die UX: den Log für Patienten, die nicht technisch sind, lesbar zu machen. "API-Anfrage von clinical_user_47239 an /fhir/r4/Observation" ist nicht nützlich. Du brauchst menschenlesbare Beschreibungen ("Dein Hausarzt hat am 14. Mai 2026 auf deine Laborbefunde zugegriffen"), was erfordert, Log-Ereignisse beim Schreiben mit den richtigen Metadaten anzureichern.

Die Arbeit phasenweise umsetzen ohne den Roadmap zu stoppen

Nichts davon muss in einem einzigen Big-Bang-Release geliefert werden. Der Ansatz, der funktioniert, ist es nach Verpflichtungstyp und Risiko zu phasieren.

Phase 1 - Fundament (jetzt bis Ende 2025): Das Einwilligungs-Datenmodell und das Zweckregister implementieren. Das hat keine externe Abhängigkeit und geringes Risiko - du fügst Tabellen und eine Einwilligungs-Verwaltungs-UI hinzu, änderst aber keine bestehenden klinischen Datenflüsse. Gleichzeitig die Audit-Log-Infrastruktur aufbauen. Das sind grundlegende Investitionen, auf denen alles andere aufbaut.

Phase 2 - FHIR-Mapping-Schicht (Q1-Q2 2026): Den Ressourcen-Mapper für deine wichtigsten Entitätstypen aufbauen. Starte mit denjenigen, die am wahrscheinlichsten zuerst angefragt werden: Patientendemografie, Observation, Condition. FHIR-Validierung in CI einrichten. Die FHIR-API noch nicht extern exponieren - nutze diese Phase, um die Mapping-Qualität intern zu validieren.

Phase 3 - FHIR-API und SMART on FHIR (Q3 2026): Die FHIR-REST-API-Oberfläche und die SMART-Launch-Integration hinzufügen. Gegen eine HDAB-Sandbox testen, wenn dein Mitgliedstaat eine bereitstellt. Ein begrenztes Pilot-Programm mit einer Partnereinrichtung durchführen.

Phase 4 - Sekundärnutzungs-Export-Pipeline und patientenseitige Zugriffslog-UI (Q4 2026 - Q1 2027): Die Export-Pipeline mit Einwilligungsfilterung verbinden. Die patientenseitige Zugriffslog-Ansicht aufbauen. Das ist der Zeitpunkt, an dem du dich ernsthaft mit dem HDAB-Registrierungsprozess befasst, der seinen eigenen Zeitplan und Dokumentationsanforderungen hat.

Diese Phasierung hält das Produktionsrisiko gering, erlaubt dir, klinische Features durchgehend zu liefern, und verhindert die Situation, in der du versuchst, alles in den sechs Monaten vor der Deadline zu implementieren.

Wo externe Hilfe beschleunigt

Die FHIR-Mapping-Arbeit und die Sekundärnutzungs-Architektur sind gut verstandene Probleme, durch die sich ein Spezialist schnell bewegt. Die Mapping-Schicht ist mühsam, aber nicht neu; jemand, der es bereits getan hat, kennt die Edge Cases - nullFlavor-Handling, Extension-URLs, Profilversionsunterschiede - und schreibt produktionsreife Mapper schneller als ein Team, das FHIR zum ersten Mal begegnet.

Wenn dein Team stark, aber EHDS-unvertraut ist, bringt ein fokussiertes Engagement zu Architektur und Code-Review zu Beginn jeder Phase typischerweise bessere Ergebnisse als eine vollständige Übergabe. Du behältst die Eigentümerschaft über den Code; externe Expertise stellt sicher, dass du nicht in eine Sackgasse baust.

Wolf-Tech arbeitet mit MedTech-SaaS-Teams an compliance-getriebenem Engineering wie diesem. Wenn du deinen EHDS-Phasierungsplan ausarbeitest und einen technischen Review deiner Architektur möchtest, melde dich unter hello@wolf-tech.io oder besuche wolf-tech.io.

FAQ

Wann beginnt die EHDS-Durchsetzung tatsächlich? Die Verordnung ist 2024 in Kraft getreten. Primärnutzungspflichten für EHRs werden ab 2025 erwartet, wobei die Sekundärnutzungsinfrastruktur und die HDAB-Integration bis 2027 phasenweise eingeführt werden. Die Umsetzungsfristen der Mitgliedstaaten variieren - verifiziere den aktuellen Stand für deine Jurisdiktion.

Müssen wir alle FHIR-Ressourcentypen implementieren? Nein. Die Verordnung spezifiziert Kategorien von Gesundheitsdaten: Patientenzusammenfassung, Rezepte, Laborbefunde, medizinische Bilder, Entlassungsberichte und Genomik. Du brauchst FHIR-Darstellungen für die Datenkategorien, die dein Produkt tatsächlich handhabt. Eine Plattform, die sich auf Laborbefunde konzentriert, hat einen engeren Mapping-Umfang als ein vollständiges EHR.

Wie interagiert EHDS mit der DSGVO? EHDS ist lex specialis zur DSGVO für Gesundheitsdaten - es fügt Verpflichtungen zusätzlich zu und in manchen Fällen modifiziert es, wie die DSGVO im spezifischen Kontext der Weitergabe von Gesundheitsdaten gilt. Deine DSGVO-Compliance-Infrastruktur (Einwilligungsdatensätze, Datenverarbeitungsverträge, Handhabung von Auskunftsersuchen) ist ein Fundament, auf dem du aufbaust, nicht eines, das du ersetzt.

Was sind die Strafen bei Nichteinhaltung? Durchsetzungsmechanismen existieren, aber Einzelheiten werden auf Mitgliedstaatsebene definiert. Das Reputationsrisiko, vom HDAB-Netzwerk ausgeschlossen zu werden - nicht in der Lage zu sein, Institutionen zu bedienen, die EHDS-konforme Lieferanten verlangen - ist für die meisten SaaS-Unternehmen wahrscheinlich ein stärkerer Treiber als Geldbußen.