Healthcare-SaaS-Compliance in Europa: EHDS, MDR und was Engineers wirklich bauen müssen

Healthcare-SaaS-Compliance in Europa hat den Ruf, ein Thema für Juristen zu sein. Ist sie nicht. Sobald du an den Erwägungsgründen vorbeigelesen hast, sind die Verordnung zum Europäischen Gesundheitsdatenraum und die Medizinprodukteverordnung Listen von Dingen, die dein Engineering-Team bauen muss: Datenexport in bestimmten Formaten, Zugriffs-Endpoints, Audit-Trails mit definierter Aufbewahrung und technische Dokumentation, die deine Architektur so beschreibt, dass eine Benannte Stelle sie prüfen kann. Den EHDS haben wir auf strategischer Ebene in einem früheren Beitrag behandelt. Dieser hier geht in die Details: was die Verordnungen auf Code- und Infrastrukturebene verlangen und wie wir diese Arbeit auf einem Symfony- und PostgreSQL-Stack angehen.

Der übliche Disclaimer gilt. Nichts davon ist Rechtsberatung, und Klassifizierungsentscheidungen brauchen einen Regulatory Consultant. Die Engineering-Übersetzung unten ist der Teil, den dir dein Anwalt nicht geben kann.

Was der EHDS von deinem Produkt erwartet

Der EHDS (Verordnung 2025/327) ist im März 2025 in Kraft getreten und gilt gestaffelt, die meisten Pflichten zur Primärnutzung greifen ab 2029, einige Datenkategorien folgen später. Das klingt weit weg. Ist es nicht, denn die Pflichten berühren dein Datenmodell, und Datenmodelle sind das Langsamste, was sich in einer Codebasis ändern lässt.

Primärnutzung bedeutet, dass Patienten und Kliniker über nationale Infrastruktur auf Gesundheitsdaten zugreifen. Wenn dein SaaS eine der prioritären Kategorien hält, etwa Patientenkurzakten, eRezepte, Laborergebnisse, Entlassberichte oder Metadaten medizinischer Bildgebung, musst du diese Daten im europäischen Austauschformat für elektronische Patientenakten verfügbar machen. In der Praxis heißt das: ein verlässlicher Exportpfad von deinem internen Schema zu strukturierten FHIR-Ressourcen, plus Schnittstellen, die die nationalen Zugangsdienste konsumieren können.

Sekundärnutzung ist der Teil, den die meisten SaaS-Anbieter unterschätzen. Gesundheitsdatenhalter können verpflichtet werden, Daten für Forschungs- und Politikzwecke an Health Data Access Bodies bereitzustellen. Das impliziert Anonymisierungs- oder Pseudonymisierungs-Pipelines, einen Weg, eine Datenanfrage zu beantworten, ohne deine Produktionsdatenbank zu verschicken, und ein Opt-out-Handling, das ein Audit übersteht.

Die Engineering-Konsequenz ist einfach zu formulieren und teuer zu ignorieren: Wenn sich dein kanonisches Datenmodell nicht sauber auf FHIR mappen lässt, kostet jede einzelne dieser Pflichten mehr. Bring zuerst das Modell in Ordnung.

Wann dein SaaS die Grenze zum Medizinprodukt überschreitet

Die MDR-Klassifizierung ist der Punkt, an dem gewöhnliche Produktentscheidungen still zu regulatorischen Ereignissen werden. Regel 11 der MDR behandelt Software: Wenn deine Software Informationen liefert, die für diagnostische oder therapeutische Entscheidungen genutzt werden, ist sie mindestens Risikoklasse IIa. Sie steigt auf IIb, wenn diese Entscheidungen eine schwerwiegende Verschlechterung des Gesundheitszustands oder einen chirurgischen Eingriff verursachen könnten, und auf Klasse III, wenn sie Tod oder irreversible Verschlechterung verursachen könnten. Das Guidance-Dokument MDCG 2019-11 ist hier die Pflichtlektüre; es ist deutlich verdaulicher als die Verordnung selbst.

Die Grenze ist leicht aus Versehen überschritten. Ein Dashboard, das Laborwerte anzeigt, ist wahrscheinlich kein Medizinprodukt. Ein Feature, das einen Wertetrend als Zeichen einer sich verschlechternden Nierenfunktion markiert und eine Überweisung vorschlägt, ist es mit ziemlicher Sicherheit. Ein Risiko-Score, ein Triage-Vorschlag, ein Dosierungsrechner: Jedes davon kann ein Modul deines Produkts in die Klassifizierung ziehen.

Klasse IIa ist die Stufe, die dein Engineering-Leben verändert. Sie löst die Beteiligung einer Benannten Stelle aus, klinische Bewertung nach Artikel 61, technische Dokumentation nach den Anhängen II und III, ein Qualitätsmanagementsystem (praktisch ISO 13485) und Post-Market Surveillance. Für die Codebasis bedeutet das Anforderungs-Traceability, einen dokumentierten Software-Lifecycle (IEC 62304 ist der Referenzstandard), Risikomanagement-Aufzeichnungen und Change Control, die belegen kann, warum jedes Release sicher ist.

Der Rat, den wir Kunden geben: Zieh die Medizinprodukt-Grenze bewusst. Isoliere das Clinical-Decision-Feature in ein eigenes Modul mit eigenem Release-Zyklus und eigener Dokumentation, damit die Benannte Stelle dieses Modul prüft und nicht dein gesamtes SaaS. Das ist eine Architekturentscheidung, und sie nachträglich einzubauen ist schmerzhaft. Unsere Code-Quality-Consulting-Engagements im Healthtech-Bereich starten oft genau hier: mit der Bewertung, ob die aktuelle Architektur überhaupt eine verteidigbare Medizinprodukt-Grenze tragen kann.

Die Datenstandards, um die du nicht herumkommst

Drei Standardfamilien tauchen in fast jedem europäischen Healthtech-Build auf.

HL7 FHIR R4 ist das Austauschformat. Der EHDS treibt es voran, nationale Infrastrukturen setzen es voraus, und jeder Integrationspartner wird danach fragen. Lerne die Ressourcentypen, die auf deine Domäne mappen, typischerweise Patient, Observation, Condition, MedicationRequest und DiagnosticReport, und behandle FHIR-Profile als Verträge, nicht als Vorschläge.

Kodiersysteme geben den Daten Bedeutung. SNOMED CT für klinische Begriffe, ICD-10 (in Deutschland ICD-10-GM) für Diagnosen, LOINC für Laborbeobachtungen. SNOMED CT erfordert eine Lizenz über das nationale Release Center, was Teams überrascht, die es für frei nutzbar hielten. Plane echte Zeit für das Terminologie-Mapping ein; es bewegt sich langsamer, als irgendjemand erwartet.

DICOM deckt die Bildgebung ab. Wenn dein Produkt Radiologie auch nur berührt, brauchst du DICOM-Ingestion und wahrscheinlich DICOMweb-Endpoints, und die Bildgebung wird von diesem Tag an deine Storage-Planung dominieren.

Audit-Trails: MDR-Anhang II will mehr als dein DSGVO-Log

Die meisten SaaS-Teams betreiben bereits irgendein Audit-Logging für die DSGVO-Rechenschaftspflicht: wer wann auf welchen Datensatz zugegriffen hat. Die MDR-Dokumentation verlangt etwas anderes in Form und Lebensdauer. Anhang II fordert technische Dokumentation zu Design-Informationen, Verifikations- und Validierungsergebnissen und Risikomanagement. Für Software lesen Auditoren das als die Fähigkeit, eine released Version zurück zu ihren Anforderungen, ihrer Testevidenz und ihren bekannten Anomalien zu verfolgen.

Du landest also bei zwei Audit-Systemen. Das Access-Log im DSGVO-Stil ist hochvolumig, pro Request, in der Aufbewahrung begrenzt und nach betroffener Person abfragbar. Der Nachweis im MDR-Stil ist pro Release, langlebig und verknüpft Anforderungen mit Code und Testergebnissen. Versuch nicht, beide aus einer Tabelle zu bedienen. Wir implementieren das Access-Log als append-only PostgreSQL-Tabelle, monatlich partitioniert und hash-verkettet, wo Manipulationssicherheit zählt, und generieren die Release-Dokumentation aus CI-Artefakten in der Delivery-Pipeline.

Deutschland im Speziellen: DiGA und die Telematikinfrastruktur

Deutschland legt zwei nationale Schichten auf die EU-Regeln.

DiGA ist der Erstattungsweg für digitale Gesundheitsanwendungen. Die Listung über den Fast Track des BfArM erfordert den Nachweis eines positiven Versorgungseffekts, aber das Engineering-Gate kommt zuerst: Sicherheitsanforderungen auf Basis der technischen Richtlinien des BSI, Datenschutz-Zertifizierung und Interoperabilitätsanforderungen inklusive strukturiertem Datenexport. Teams unterschätzen die Sicherheitsdokumentation regelmäßig. Sie setzt einen Reifegrad voraus, mit Penetrationstests und funktionierenden ISMS-Prozessen, den ein Seed-Stage-Produkt am ersten Tag selten hat.

Die Telematikinfrastruktur ist das nationale Gesundheitsnetz. Wenn dein Produkt mit der elektronischen Patientenakte ePA sprechen, eRezept-Verordnungen verarbeiten oder Daten mit Arztpraxen austauschen soll, verbindest du dich über Gematik-spezifizierte Komponenten. Behandle das als eigenes Projekt: zertifizierte Konnektoren, kartenbasierte Identität, Konformitätstests. Prüfe früh, ob dein Hosting-Setup die TI überhaupt erreichen kann, denn die Antwort schränkt deine Infrastrukturentscheidungen ein. Das ist einer der Gründe, warum wir Tech-Stack-Strategie-Arbeit vor einem Healthtech-Build machen und nicht danach.

FHIR in PostgreSQL speichern, auf die Symfony-Art

Das Muster, das wir nutzen, ist Dokumentenspeicherung innerhalb der relationalen Datenbank. Jede FHIR-Ressource lebt als JSONB in PostgreSQL, eine Zeile pro Ressourcenversion: eine interne id, der Ressourcentyp, die FHIR-id, eine Versionsnummer, der JSONB-Payload, Timestamps und eine Handvoll extrahierter Spalten für die Felder, die du ständig abfragst, etwa die Patientenreferenz und den klinischen Code. Ein GIN-Index auf dem Payload deckt Ad-hoc-Queries ab; Btree-Indizes auf den extrahierten Spalten decken die Hot Paths ab. Aktualisiere eine Ressource nie in-place. Füge eine neue Versionszeile ein und verfolge die aktuelle Version separat. Das gibt dir die Versionshistorie, die FHIR erwartet, und einen audit-freundlichen Nachweis zugleich.

Auf der Symfony-Seite: Behandle FHIR-Ressourcen als Dokumente, nicht als Doctrine-Entities. Tief verschachtelte FHIR-Strukturen auf relationale Entities zu mappen erzeugt ein Schema, das niemand warten kann. Wir halten eine dünne Repository-Schicht, die eingehende Ressourcen gegen die relevanten Profile validiert, die JSONB-Zeilen schreibt und über Messenger ein Event publiziert, damit nachgelagerte Konsumenten, von der Suchindizierung bis zur Sekundärnutzungs-Pipeline, von der Ingestion entkoppelt bleiben. Symfonys Serializer übernimmt die API-Schicht. API Platform funktioniert, wenn du eine breitere REST-Oberfläche willst, wobei FHIRs eigenes Interaktionsmodell aus Read, Search und History schmal genug ist, dass handgeschriebene Controller absolut wartbar bleiben.

Zwei hart erarbeitete Hinweise. FHIR-Suchparameter sehen einfach aus und sind es nicht; implementiere nur die, die deine Integrationspartner nutzen, und schreib diese Liste auf. Und halte dein kanonisches Geschäftsmodell von der FHIR-Repräsentation getrennt. FHIR ist ein Austauschformat. Produkte, die rohe FHIR-Ressourcen als internes Domänenmodell übernehmen, bezahlen dafür in jedem Feature, das nicht wie eine FHIR-Interaktion aussieht.

Healthcare-SaaS-Compliance ist ein Architekturproblem

Alles oben belohnt Teams, die früh entscheiden, wo Daten leben, wo die Medizinprodukt-Grenze sitzt und auf welche Standards das Kernmodell mappen muss. FHIR-Export, MDR-Dokumentation und TI-Anbindung an ein fertiges Produkt anzubauen ist möglich. Wir haben es gemacht. Es kostet aber ein Vielfaches dessen, was dieselben Fähigkeiten kosten, wenn sie von Anfang an eingeplant sind, weshalb Healthtech einer der Bereiche ist, in denen unsere Custom-Software-Development-Praxis auf einer Architekturphase besteht, bevor irgendjemand Feature-Code schreibt.

Wenn du ein zweites Paar Augen auf deine EHDS-Exposure, dein MDR-Klassifizierungsrisiko oder ein FHIR-Storage-Design willst, schreib an hello@wolf-tech.io oder schau dich auf wolf-tech.io um. Ein einstündiges Gespräch, bevor die Architektur einfriert, ist die günstigste Compliance-Maßnahme, die du je kaufen wirst.