Engineering fur den Europaischen Gesundheitsdatenraum: Was MedTech SaaS bis 2027 andern muss

Die Verordnung uber den Europaischen Gesundheitsdatenraum ist kein abstraktes Brusseler Dokument, das in einem zukunftigen 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 vollstandigen Anforderungen fur die Primarnutzung werden bis 2027 erwartet. Zu verstehen, welche Engineering-Anderungen er erfordert - und diese Anderungen so zu sequenzieren, dass sie deinen Feature-Roadmap nicht sprengen - ist jetzt eine Kernverantwortung jedes CTOs in diesem Bereich.

Dieser Beitrag arbeitet die wichtigsten Architekturanderungen 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 fur die regulatorische Interpretation. Was folgt, ist die Engineering-Ubersetzung.

Was EHDS tatsachlich auf Architekturebene erfordert

Die Verordnung unterscheidet zwischen zwei Nutzungskategorien. Die Primarnutzung umfasst den direkten Pflegekontext: ein Kliniker, der deine App nutzt, um Patientenakten einzusehen, einzugeben und darauf zu reagieren. Die Sekundarnutzung 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 uber Mitgliedstaaten hinweg aggregieren wird.

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

Fur die Primarnutzung ist die Hauptanforderung Interoperabilitat. Deine Plattform muss in der Lage sein, Patientendaten mithilfe von HL7 FHIR R4 (oder R5, wo Mitgliedstaaten es fruh ubernehmen) 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 Entitat, die du speicherst - Patientendemografie, klinische Beobachtungen, Rezepte, Laborbefunde, Bildgebungsmetadaten - eine maschinenlesbare FHIR-Darstellung benotigt, die auf Anfrage produziert werden kann. Das ist keine kosmetische API-Endpoint-Anderung; fur die meisten SaaS-Produkte, die auf relationalen Datenmodellen aufgebaut sind, erfordert es eine nicht-triviale Mapping-Schicht.

Fur die Sekundarnutzung ist die Verpflichtung komplexer. Patienten mussen in der Lage sein, ihre Einwilligung zur Nutzung ihrer Daten fur bestimmte Sekundarzwecke zu erteilen und zu widerrufen - Forschungskategorien sind definiert und kodiert. Dein System muss diese Einwilligung mit ausreichender Granularitat verfolgen, um die Daten eines Patienten von einer bestimmten Forschungskategorie auszuschliessen, wahrend sie in einer anderen enthalten bleiben. Der Widerruf muss innerhalb definierter Fristen verarbeitet werden, und du musst bei einem Audit nachweisen konnen, dass der Widerruf dort, wo technisch moglich, ruckwirkend respektiert wurde. Das ist zweckbindende Metadaten auf Datensatzebene, nicht nur ein DSGVO-Einwilligungs-Checkbox auf einem Einstellungsbildschirm.

FHIR-Kompatibilitat: Die Engineering-Realitat

Wenn dein Produkt nicht mit FHIR im Sinn entworfen wurde, ist das Hinzufugen von FHIR-Unterstutzung ein Projekt, kein Ticket. Hier ist, was die Arbeit tatsachlich beinhaltet.

Erstens brauchst du eine Ressourcen-Mapping-Schicht. Jedes klinische Konzept in deinem Domanen-Modell - Diagnose, Rezept, Beobachtung, Begegnung - muss dem entsprechenden FHIR-Ressourcentyp zugeordnet werden (Condition, MedicationRequest, Observation, Encounter). Das ist keine mechanische Eins-zu-eins-Ubersetzung. FHIR hat spezifische Konventionen fur Codierungssysteme (SNOMED CT, LOINC, ICD-10), Erweiterungsmuster fur Konzepte, die die Basisspezifikation nicht abdeckt, und Profilbeschrankungen, die Implementierungen der Mitgliedstaaten zusatzlich zu den Basisressourcen auferlegen.

Auf einem Symfony-Stack ist der sinnvolle Ansatz, dies als explizite Domanen-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 Geschaftslogik, die keine Bibliothek bereitstellen kann.

Zweitens brauchst du eine FHIR-konforme API-Oberflache. Die EHDS-Implementierungsleitfaden verweisen auf SMART on FHIR fur 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 unterstutzen, insbesondere wenn du EHR-eingebettete Launch-Kontexte unterstutzen 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, mussen schema-gultig sein. Das Ausfuhren von FHIR-Validierung in CI - mithilfe des HAPI-Validators oder einer leichteren JSON-Schema-Prufung - verhindert die stille Drift, bei der ein Mapping fehlerhafte Ressourcen produziert, die erst beim Einreichen an ein HDAB fehlschlagen. Fugt dies fruh zur Pipeline hinzu, nicht als Nachgedanke vor der Einreichungsfrist.

Sekundarnutzungs-Einwilligungs-Architektur

Das ist der Teil, den die meisten MedTech-SaaS-Teams unterschatzen. Die DSGVO hat dir den allgemeinen Rahmen gegeben; EHDS fugt spezifische Zweckkategorien und spezifische Verpflichtungen fur die Sekundarnutzung von Gesundheitsdaten hinzu.

Die Architektur, die du brauchst, hat drei Komponenten.

Zweckregister: Eine Tabelle oder ein strukturierter Speicher, der die Sekundarnutzungskategorien definiert, die deine Jurisdiktion exponiert. Diese sind nicht willkurlich - die EHDS-Verordnung und nationale Implementierungen definieren die erlaubten Kategorien (Krankheitsregister, klinische Forschung, Politikanalyse, Uberwachung der offentlichen Gesundheit usw.). Dein System muss den aktuellen Katalog kennen.

Einwilligungsdatensatze je Patient: Fur jeden Patienten in deinem System brauchst du einen Datensatz, welchen Sekundarnutzungskategorien sie zugestimmt haben, wann diese Einwilligung gegeben wurde und ob sie geandert oder widerrufen wurde. Das muss eine First-Class-Entitat in deinem Domanen-Modell sein, kein JSON-Blob in einer Einstellungsspalte. Es sollte nur-append mit Zeitstempeln sein - du erstellst einen Audit-Trail, kein veranderbares Praferenz-Objekt.

Datenexport-Filterung: Wenn dein System Daten an ein HDAB exportiert (entweder auf Anfrage oder uber einen geplanten Batch), muss die Export-Pipeline gegen Einwilligungsdatensatze joinen und Patienten ausschliessen, 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 fur den Export-Endpoint - er ist ein Gate fur jeden Sekundarnutzungs-Datenfluss.

Die Widerrufsbehandlung ist, wo Teams dazu neigen, Abkurzungen zu nehmen. EHDS verlangt, dass der Widerruf innerhalb eines definierten Fensters verarbeitet wird und dass du nachweisen kannst, dass er respektiert wurde. Fur Batch-Exporte bedeutet das, fruhere Exporte erneut auszufuhren oder anzupassen, wenn ein Patient zwischen Export-Zyklen widerruft. Ob ein ruckwirkender Widerruf technisch erforderlich ist, hangt von der spezifischen Datennutzung und Implementierung des Mitgliedstaats ab, aber das Entwerfen deiner Export-Pipeline als neu-ausfuhrbar mit einer aktuellen Einwilligungs-Momentaufnahme ist der korrekte Standard. Damit vermeidest du den schmerzhaften Fall, in dem du einem HDAB erklaren musst, warum Daten nach einem Widerruf eines Patienten enthalten waren.

Auditgerade Zugriffslogs

Sowohl die Primarnutzung als auch die Sekundarnutzung unter EHDS erfordert, dass Patienten ein Protokoll sehen konnen, wer auf ihre Daten zugegriffen hat, wann und zu welchem Zweck. Das ist kein Schonheitsmerkmal - es ist ein Patientenrecht unter der Verordnung, analog zum DSGVO-Auskunftsrecht, aber spezifischer fur Zugriffsereignisse auf Gesundheitsdaten.

Die Engineering-Anforderung ist ein unveranderliches Zugriffsprotokoll, das erfasst: die zugreifende Entitat (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 uber 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 Designbeschrankung ist, dass diese Tabelle nicht durch denselben Anwendungscode anderbar sein darf, der klinische Daten liest und schreibt - du mochtest eine logische (oder physische) Trennung, die Manipulationen erschwert und Audit-Trails glaubwurdig macht. Eine schreibgeschutzte 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 vernunftige Muster je nach deiner Skalierung.

Auf dem Frontend in Next.js ist die patientenseitige Zugriffslog-Ansicht eine schreibgeschutzte Timeline-Komponente. Der schwierigere Teil ist die UX: den Log fur Patienten, die nicht technisch sind, lesbar zu machen. "API-Anfrage von clinical_user_47239 an /fhir/r4/Observation" ist nicht nutzlich. 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 Abhangigkeit und geringes Risiko - du fugst Tabellen und eine Einwilligungs-Verwaltungs-UI hinzu, anderst aber keine bestehenden klinischen Datenflusse. 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 fur deine wichtigsten Entitatstypen 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-Qualitat intern zu validieren.

Phase 3 - FHIR-API und SMART on FHIR (Q3 2026): Die FHIR-REST-API-Oberflache und die SMART-Launch-Integration hinzufugen. Gegen eine HDAB-Sandbox testen, wenn dein Mitgliedstaat eine bereitstellt. Ein begrenztes Pilot-Programm mit einer Partnereinrichtung durchfuhren.

Phase 4 - Sekundarnutzungs-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 halt 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 Sekundarnutzungs-Architektur sind gut verstandene Probleme, durch die sich ein Spezialist schnell bewegt. Die Mapping-Schicht ist muhsam, 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 vollstandige Ubergabe. Du behaltst die Eigentumarschaft uber 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 mochtest, melde dich unter hello@wolf-tech.io oder besuche wolf-tech.io.

FAQ

Wann beginnt die EHDS-Durchsetzung tatsachlich? Die Verordnung ist 2024 in Kraft getreten. Primarnutzungspflichten fur EHRs werden ab 2025 erwartet, wobei die Sekundarnutzungsinfrastruktur und die HDAB-Integration bis 2027 phasenweise eingefuhrt werden. Die Umsetzungsfristen der Mitgliedstaaten variieren - verifiziere den aktuellen Stand fur deine Jurisdiktion.

Mussen wir alle FHIR-Ressourcentypen implementieren? Nein. Die Verordnung spezifiziert Kategorien von Gesundheitsdaten: Patientenzusammenfassung, Rezepte, Laborbefunde, medizinische Bilder, Entlassungsberichte und Genomik. Du brauchst FHIR-Darstellungen fur die Datenkategorien, die dein Produkt tatsachlich handhabt. Eine Plattform, die sich auf Laborbefunde konzentriert, hat einen engeren Mapping-Umfang als ein vollstandiges EHR.

Wie interagiert EHDS mit der DSGVO? EHDS ist lex specialis zur DSGVO fur Gesundheitsdaten - es fugt Verpflichtungen zusatzlich zu und in manchen Fallen modifiziert es, wie die DSGVO im spezifischen Kontext der Weitergabe von Gesundheitsdaten gilt. Deine DSGVO-Compliance-Infrastruktur (Einwilligungsdatensatze, Datenverarbeitungsvertrage, 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 fur die meisten SaaS-Unternehmen wahrscheinlich ein starkerer Treiber als Geldbussen.