Mobile-Menu

Gesundheitsdaten EHDS und SwissHDS: Konsequenzen für Medizinprodukte und deren Hersteller

Ein Gastbeitrag von Frank Stein* 5 min Lesedauer

Mit dem Inkrafttreten des European Health Data Space (EHDS) im März 2025 und dem parallelen Aufbau des Swiss Health Data Space (SwissHDS) verändert sich der regulatorische Rahmen für Hersteller von Medizinprodukten grundlegend. Was bisher eine freiwillige technische Entscheidung war – die Unterstützung offener Datenstandards und interoperabler Schnittstellen – wird künftig zur regulatorischen Produktanforderung. Welche konkreten Pflichten, Risiken und strategischen Chancen ergeben sich daraus für Medizintechnikunternehmen?

Sobald ein Produkt Gesundheitsdaten generiert oder konsumiert, die in einem EHR landen oder daraus bezogen werden, greifen die Interoperabilitätspflichten.(Bild: © Toowongsa - stock.adobe.com)
Sobald ein Produkt Gesundheitsdaten generiert oder konsumiert, die in einem EHR landen oder daraus bezogen werden, greifen die Interoperabilitätspflichten.
(Bild: © Toowongsa - stock.adobe.com)

Der Anwendungsbereich des European Health Data Space (EHDS) ist weiter als viele Hersteller zunächst annehmen. Neben klassischen EHR-Systemen (Electronic Health Records) erfasst Artikel 27 der EHDS-Verordnung explizit auch Medizinprodukte gemäß MDR (EU) 2017/745, In-vitro-Diagnostika (IVD) gemäß IVDR (EU) 2017/746 sowie digitale Gesundheitsanwendungen (DiGA), sofern diese elektronische Gesundheitsdaten erzeugen, verarbeiten oder mit EHR-Systemen kommunizieren.

In der Praxis bedeutet dies: Ein vernetzter Infusionsautomat, der Dosierdaten in ein KIS überträgt, ein tragbares EKG-Gerät mit App-Anbindung, ein bildgebender PACS-Knoten oder eine KI-gestützte Diagnosesoftware (SaMD – Software as a Medical Device) sind potenziell alle vom EHDS-Regime erfasst. Entscheidend ist nicht die primäre Produktkategorie, sondern der Datenpfad: Sobald ein Produkt Gesundheitsdaten generiert oder konsumiert, die in einem EHR landen oder daraus bezogen werden, greifen die Interoperabilitätspflichten.

Interoperabilität als Designpflicht: Was Artikel 27 EHDS konkret verlangt

Artikel 27 der EHDS-Verordnung verpflichtet Hersteller betroffener Produkte zur Einhaltung von Interoperabilitätsanforderungen, die durch sogenannte Common Specifications (Durchführungsrechtsakte der EU-Kommission) bis spätestens 2027 konkretisiert werden. Die zentralen Anforderungen zeichnen sich bereits ab:

  • Unterstützung von HL7 FHIR (Fast Healthcare Interoperability Resources) als primäres Austauschformat für strukturierte Gesundheitsdaten
  • Offene, dokumentierte APIs für den Datenaustausch mit EHR-Systemen, ohne proprietäre Abhängigkeiten
  • Standardisierte Terminologien: SNOMED CT, LOINC, ICD-10/11 und EDQM für Medikamente
  • Protokollierungsfunktionen (Audit Logs) gemäß EHDS-Anforderungen für Primär- und Sekundärnutzung
  • Zugriffsmanagement, das Patientenrechte auf Dateneinsicht, Widerspruch und portabilität technisch abbildet
  • Sicherheitsanforderungen, die mit IEC 62443 und ISO 27001 kompatibel sind

Wichtig: Die EHDS-Verordnung sieht kein zusätzliches, eigenständiges Konformitätsbewertungsverfahren vor. Hersteller müssen jedoch bei Markteinführung und auf Nachfrage der Marktaufsicht nachweisen können, dass ihre Produkte die einschlägigen Common Specifications erfüllen. Dies ist de facto eine Erweiterung der technischen Dokumentation nach MDR Annex II/III.

Wechselwirkungen mit MDR, IVDR und AI Act

Für Hersteller, die bereits unter MDR oder IVDR reguliert sind, entsteht ein Mehrschichtenmodell aus Anforderungen, die miteinander wechselwirken, aber unterschiedliche Behörden und Verfahren involvieren:

  • MDR/IVDR: Sicherheit, Leistungsfähigkeit, klinische Bewertung, Qualitätsmanagementsystem (ISO 13485); technische Dokumentation, Konformitätsbewertung durch benannte Stelle
  • EHDS: Interoperabilität, Datenzugang, Portabilität, Audit-Logging; Nachweis der Konformität mit Common Specifications; Marktaufsicht durch nationale EHDS-Behörden
  • AI Act: Für KI-basierte SaMD: Hochrisiko-KI-System nach Anhang III; Konformitätsbewertung, Transparenz- und Robustheitspflichten, EU-Datenbank-Registrierung
  • NIS2/ISO 27001: Cybersicherheitspflichten für Hersteller als kritische oder wichtige Einrichtungen; Informationssicherheitsmanagementsystem, Incident Reporting

Die praktische Herausforderung besteht darin, dass diese Anforderungen zwar inhaltlich komplementär sind, aber in separaten Dokumentations-, Nachweis- und Auditprozessen abgebildet werden müssen. Hersteller, die ihre Qualitätsmanagementsysteme (ISO 13485) und technische Dokumentation nicht frühzeitig auf EHDS-Anforderungen erweitern, riskieren eine fragmentierte Compliance-Architektur, die in Audits und Marktüberwachungsverfahren zu Lücken führt.

SwissHDS: Zusätzliche Anforderungen für den Schweizer Markt

Für Hersteller, die sowohl den EU- als auch den Schweizer Markt bedienen, kommt eine zweite Ebene hinzu: der Swiss Health Data Space (SwissHDS) übernimmt die Grundlogik des EHDS, adaptiert sie jedoch auf die föderale Schweizer Struktur. Konkret bedeutet dies:

  • SwissHDS setzt ebenfalls auf HL7 FHIR und internationale Standards – die Schweiz orientiert sich an den EHDS-Interoperabilitätsanforderungen, ohne diese eins zu eins zu übernehmen.
  • Die Schweiz plant für 2030 die automatische Eröffnung eines elektronischen Gesundheitsdossiers (EGD) für alle Einwohnerinnen und Einwohner. Produkte, die in den Schweizer Markt integriert sind, müssen EGD-fähig sein.
  • SwissHDS-Basisdienste (Identitätsdienste, Datenzugangsdienste) werden über die DigiSanté-Architektur bereitgestellt. Hersteller müssen ihre Produkte an diese nationalen Dienste anbinden.
  • Die SwissHDS-Kommission definiert die Teilnahmebedingungen – fehlende Konformität kann faktisch zu Marktbarrieren führen, auch wenn kein formales Zulassungsverfahren vorgesehen ist.

Für Hersteller mit EU- und Schweizer Marktzulassung empfiehlt sich eine konvergente Architekturstrategie: FHIR-basierte Schnittstellen und standardisierte Terminologien als gemeinsames Fundament, mit länderspezifischen Konfigurationsschichten für EHDS- und SwissHDS-Basisdienste.

Auswirkungen auf Produktentwicklung und technische Dokumentation

Die EHDS-Anforderungen sind keine Post-Market-Pflichten, die nach der Markteinführung ergänzt werden können. Sie müssen in den Entwicklungsprozess integriert werden – idealerweise bereits in der Designphase. Für Hersteller, die nach ISO 13485 zertifiziert sind, bedeutet das konkret:

  • Erweiterung des Design Inputs (Anforderungsmanagement) um EHDS-Interoperabilitätsanforderungen und Common Specifications
  • Aufnahme von Interoperabilitäts- und Datenschutzaspekten in die Software-Risikoanalyse (ISO 14971) und die Cybersicherheits-Risikobeurteilung (IEC 81001-5-1)
  • Validierungsprotokolle für FHIR-Schnittstellen, API-Konformitätstests und Audit-Log-Funktionen
  • Erweiterung der technischen Dokumentation (MDR Annex II) um Nachweise zur EHDS-Konformität
  • Pflege der Nachkonformitätsdokumentation bei Aktualisierung der Common Specifications durch die EU-Kommission

Für Software-Updates und neue Versionen gilt: Jede Änderung, die den Datenpfad, die Schnittstellen oder die Protokollierungslogik betrifft, ist unter dem Gesichtspunkt der EHDS-Konformität zu bewerten und zu dokumentieren. Dies ist analog zur Change-Control-Logik unter MDR, erfordert aber einen eigenen Bewertungspfad.

Strategische Positionierung: Risiken und Chancen

Die EHDS-Anforderungen sind zunächst eine Compliance-Last – aber gleichzeitig ein Differenzierungsmerkmal. Hersteller, die EHDS- und SwissHDS-Konformität frühzeitig als Produktmerkmal kommunizieren, können sich im Wettbewerb von proprietären Legacy-Lösungen abheben, insbesondere in Ausschreibungen öffentlicher Krankenhäuser und Gesundheitsnetzwerke.

  • Risiko: Wer bis 2027 keine FHIR-fähigen Schnittstellen implementiert hat, riskiert ab 2029 Marktbarrieren beim Zugang zu EU-Krankenhäusern und digitalen Gesundheitsplattformen.
  • Risiko: Fehlende Audit-Log-Funktionen können in Marktüberwachungsverfahren als Konformitätslücke gewertet werden – mit Konsequenzen für die CE-Kennzeichnung.
  • Chance: EHDS-konforme Produkte sind EU-weit exportfähig ohne marktspezifische Schnittstellenanpassungen – ein erheblicher Vorteil für Schweizer Medtech-KMU.
  • Chance: Die Sekundärnutzung von Gesundheitsdaten (Forschung, Public Health, AI-Training) eröffnet neue Geschäftsmodelle für Hersteller, die ihre Produkte als Datenproduzenten im EHDS positionieren.
  • Chance: Frühzeitige Einbindung in SwissHDS-Pilotprojekte und DigiSanté-Branchengremien schafft Gestaltungseinfluss auf nationale Implementierungsstandards.

Empfehlungen für Hersteller

Auf Basis der aktuellen Regulierungslage und der absehbaren Zeitlinie empfehlen sich folgende Maßnahmen:

  • Sofortmaßnahmen (bis 2026): Gap-Analyse der bestehenden Produktarchitektur gegen EHDS-Artikel 27 und HL7 FHIR R4/R5; Identifikation betroffener Produkte und Schnittstellen; Aufnahme von EHDS in das Risikomanagement und die Roadmap
  • Mittelfristig (2026 bis 2027): Implementierung FHIR-basierter APIs; Erweiterung der technischen Dokumentation; Aufbau von Validierungs- und Testinfrastruktur für Interoperabilitätsanforderungen; Beobachtung der Common Specifications-Veröffentlichungen
  • Langfristig (2027 bis 2029): Vollständige EHDS-Konformität als Markteinführungsvoraussetzung; SwissHDS-Anbindung für Schweizer Produkte; Positionierung als „datenraumfähige" Produktlinie gegenüber Einkäufern und Ausschreibenden

Auf einen Blick
  • Interoperabilität ist ab 2027 keine Option mehr – sie wird zur regulatorischen Produktanforderung für alle Medizinprodukte, IVD und SaMD, die Gesundheitsdaten erzeugen oder nutzen.
  • Die EHDS-Anforderungen müssen in Design Input, Risikoanalyse und technische Dokumentation integriert werden – ein nachträgliches Nachrüsten wird aufwendig und riskant.
  • Für den Schweizer Markt kommt mit SwissHDS eine komplementäre, aber eigenständige Anforderungsschicht hinzu, die EGD-Fähigkeit und SwissHDS-Basisdienst-Anbindung verlangt.
  • Das Mehrschichtenmodell MDR/IVDR + EHDS + AI Act + NIS2 erfordert eine konsolidierte Compliance-Architektur, um Redundanzen zu minimieren und Lücken zu vermeiden.
  • Hersteller, die frühzeitig investieren, schaffen sich einen nachhaltigen Marktzugang in der EU und der Schweiz und eröffnen neue Geschäftsmodelle durch datenraumfähige Produkte.

Jetzt Newsletter abonnieren

Wöchentlich die wichtigsten Infos zur Digitalisierung im Gesundheitswesen

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Quellenhinweise:

Dieser Artikel erschien ursprünglich bei unserer Schwesterpublikation Devicemed.

* Der Autor: Prof. Dr. Dr. h.c. Frank Stein ist Senior Expert Regulatory Affairs Healthcare & Health-IT bei Healthcare Projects Consulting & Management Stein.

(ID:50891382)

Weiterführende Inhalte