🇨🇭 Dieser Beitrag betrifft die Schweiz. In Deutschland und Österreich gelten andere Gesetze (BSIG/DSGVO bzw. NISG 2024).

EPD Integration in Informationssysteme: Schnittstellen sicher gestalten

Einleitung

Die Integration des elektronischen Patientendossiers (EPD) in bestehende Primärsysteme gehört zu den technisch anspruchsvollsten Vorhaben, mit denen IT-Leitungen und Informationssicherheitsbeauftragte von Schweizer Spitälern derzeit konfrontiert sind. Seit der schrittweisen Einführung des EPD auf Basis des Bundesgesetzes über das elektronische Patientendossier (EPDG) steigt der Druck, die EPD Integration in Informationssysteme nicht nur funktional, sondern auch sicherheitstechnisch sauber umzusetzen. Die relevanten Schnittstellen sind öffentlich dokumentiert – doch die sicherheitsrelevanten Implikationen werden in der Praxis oft unterschätzt. Dieser Artikel beleuchtet, was bei der technischen Integration zu beachten ist, welche Sicherheitsanforderungen gelten und wie Sie die häufigsten Stolperfallen vermeiden.

Rechtlicher Rahmen: EPDG, nDSG und ISG

Bevor die technische Umsetzung beginnt, müssen die regulatorischen Grundlagen klar sein. In der Schweiz sind für die EPD-Integration drei Rechtsbereiche massgebend:

EPDG und KVG-Pflichten Das EPDG verpflichtet stationäre Leistungserbringer (Spitäler, Geburtshäuser, Pflegeheime), ihren Patientinnen und Patienten ein EPD anzubieten. Die Anbindung an eine zertifizierte Gemeinschaft oder Stammgemeinschaft ist Voraussetzung. Die technischen Anforderungen an die Schnittstellen werden durch die Ausführungsgesetzgebung (KVV und zugehörige Verordnungen) sowie die Vorgaben von eHealth Suisse konkretisiert.

nDSG: Datenschutz seit September 2023 Das neue Datenschutzgesetz (nDSG) gilt seit September 2023 und verschärft die Anforderungen an die Bearbeitung besonders schützenswerter Personendaten – zu denen Gesundheitsdaten explizit zählen. Technische und organisatorische Massnahmen (TOM) müssen dem Stand der Technik entsprechen. Wer Schnittstellen zu einem EPD-System betreibt, ist Verantwortlicher im Sinne des nDSG und muss entsprechende Schutzkonzepte nachweisen können.

ISG: Meldepflicht seit April 2025 Das Informationssicherheitsgesetz (ISG) und die damit verbundene Meldepflicht für Cyberangriffe auf kritische Infrastrukturen gilt seit April 2025. Spitäler fallen in der Regel unter diese Kategorie. Ein Sicherheitsvorfall, der über eine EPD-Schnittstelle ermöglicht wird, ist meldepflichtig beim Bundesamt für Cybersicherheit (BACS/NCSC). Das hat direkte Konsequenzen für Ihr Incident-Response-Prozess: Die EPD-Integration muss in Ihrem ISMS explizit als kritischer Anwendungsbereich erfasst sein.

Hinweis: Dieser Artikel ersetzt keine Rechtsberatung. Für rechtliche Fragen wenden Sie sich an eine auf Gesundheitsrecht spezialisierte Anwaltskanzlei.

Technische Architektur: Die EPD-Schnittstellen im Überblick

eHealth Suisse dokumentiert die verfügbaren Schnittstellen detailliert auf der EPD-Integrationsseite. Für Sicherheitsverantwortliche sind folgende Schnittstellenkategorien relevant:

IHE-Profile als Grundlage Die EPD-Integration basiert auf internationalen IHE-Profilen (Integrating the Healthcare Enterprise). Zentrale Profile sind: - XDS.b (Cross-Enterprise Document Sharing) für den Dokumentenaustausch - PIX/PDQ für die Patientenidentifikation - ATNA (Audit Trail and Node Authentication) für Audit-Logging und Transportverschlüsselung - XUA (Cross-Enterprise User Assertion) für die Authentifizierung auf Benutzerebene

SMART on FHIR und HL7 FHIR R4 Neuere Integrationsszenarien setzen zunehmend auf FHIR (Fast Healthcare Interoperability Resources). Primärsystemhersteller und Eigenentwickler müssen klären, welche FHIR-Endpunkte die jeweilige Gemeinschaft unterstützt und wie OAuth 2.0-basierte Autorisierungsflows sicher implementiert werden.

Lokaler EPD-Adapter vs. Direktintegration Viele Spitäler setzen auf einen lokalen EPD-Adapter (Middleware), der zwischen dem Primärsystem und der Gemeinschaftsinfrastruktur vermittelt. Dies hat Vorteile für die Isolation und Kontrolle, schafft aber auch eine zusätzliche Komponente im Angriffspfad. Alternativ bieten einige KIS-Hersteller eine direkte Integration an – dabei liegt die Verantwortung für die Sicherheitskonfiguration beim Hersteller, was entsprechende Lieferantenvereinbarungen erfordert.

Sicherheitsanforderungen bei der EPD Integration in Informationssysteme

Die EPD Integration in Informationssysteme ist kein reines IT-Projekt – sie ist ein sicherheitskritisches Vorhaben, das strukturierte Risikoanalyse erfordert. Folgende Anforderungen müssen Sie adressieren:

Identitäts- und Zugriffsmanagement (IAM)

Das EPD kennt verschiedene Rollenmodelle: Patienten, Fachpersonen, Hilfspersonen und technische Nutzer. Die Zertifikate für Fachpersonen (HPC – Health Professional Card) und Einrichtungen (SMC-B analog) müssen korrekt in Ihr IAM eingebunden sein. Kritische Fragen:

  • Wie werden abgelaufene oder entzogene Zertifikate zeitnah aus dem System entfernt?
  • Ist das Provisionierungs- und Deprovisionierungsverfahren für Fachpersonen-Zertifikate in Ihre HR-Prozesse eingebunden?
  • Werden privilegierte Dienstkonten (technische Nutzer) nach dem Prinzip der minimalen Rechte konfiguriert?

Transportverschlüsselung und ATNA

Das IHE-Profil ATNA schreibt TLS für alle Verbindungen vor. In der Praxis zeigen sich hier häufig Schwachstellen:

  • TLS-Versionen: Nur TLS 1.2 oder 1.3 sind akzeptabel. TLS 1.0 und 1.1 müssen deaktiviert sein.
  • Zertifikatsverwaltung: Abgelaufene Serverzertifikate sind ein häufiger Audit-Befund. Implementieren Sie ein Certificate-Lifecycle-Management.
  • Mutual TLS (mTLS): Viele EPD-Gemeinschaften verlangen beidseitige Zertifikatsauthentifizierung. Stellen Sie sicher, dass Ihre Middleware dies korrekt umsetzt.

Audit-Logging und SIEM-Integration

Das ATNA-Profil verlangt vollständige, manipulationsgeschützte Audit-Trails. Diese Logs müssen:

  • Alle Dokumentenzugriffe, Suchen und Freigabeoperationen erfassen
  • Unveränderlich gespeichert werden (Write Once, Read Many)
  • In Ihr zentrales SIEM integriert sein, damit anomale Zugriffsmuster erkannt werden

Ein Use Case, den Sie in Ihrem SIEM abbilden sollten: Massenabruf von Patientendossiers durch einen einzelnen Benutzeraccount ausserhalb der regulären Arbeitszeiten. Dies kann auf kompromittierte Zugangsdaten oder Insider-Bedrohungen hinweisen.

Netzwerksegmentierung

Der EPD-Adapter oder die FHIR-Endpunkte dürfen nicht im selben Netzwerksegment liegen wie Ihre allgemeine IT-Infrastruktur. Empfohlen wird:

  • Dediziertes VLAN für EPD-Komponenten
  • Firewall-Regeln, die nur die notwendigen Ports und Protokolle erlauben
  • Web Application Firewall (WAF) vor FHIR-REST-Endpunkten
  • Regelmässige Überprüfung der Firewall-Regeln (mindestens jährlich)

Risikomanagement und ISMS: So verankern Sie die EPD-Integration

Die EPD-Schnittstelle ist ein Asset mit erhöhtem Schutzbedarf – sie verarbeitet besonders schützenswerte Gesundheitsdaten und ist gleichzeitig mit externer Infrastruktur (der Gemeinschaft) verbunden. In Ihrem ISMS nach ISO 27001 (ergänzt durch ISO 27799 für Gesundheitsinformationen) sollten Sie folgende Punkte verankern:

Risikoregister: Erfassen Sie die EPD-Integration als eigenständiges Asset mit zugehörigen Bedrohungsszenarien: Kompromittierung der Schnittstellenkommunikation, unbefugter Datenzugriff über API-Schwachstellen, Denial-of-Service gegen den EPD-Adapter.

Lieferantenmanagement (Supply Chain): Wenn Sie einen externen EPD-Adapter-Hersteller oder Ihre KIS-Lösung nutzen, muss dies in Ihr Lieferantenrisikomanagement einfliessen. Verlangen Sie schriftliche Sicherheitsnachweise (z.B. Penetrationstest-Berichte, SOC 2-Zertifikate) und klare Verantwortlichkeiten im Vertrag.

Business Impact Analyse (BIA): Was passiert, wenn die EPD-Schnittstelle ausfällt? In welchen Prozessen (Notaufnahme, Entlassung, Medikation) entstehen kritische Abhängigkeiten? Definieren Sie RTO (Recovery Time Objective) und RPO für die EPD-Anbindung.

Patch- und Schwachstellenmanagement: IHE-Profile und FHIR-Bibliotheken werden regelmässig aktualisiert. Stellen Sie sicher, dass Ihr Adapter und Ihre Primärsystem-Integration in das reguläre Patch-Management eingebunden ist.

Häufige Stolperfallen in der Praxis

Aus der Beratungspraxis und aus Audit-Erfahrungen zeigen sich wiederkehrende Probleme bei der EPD-Integration:

1. Fehlende Trennung von Test- und Produktivumgebung Entwicklungs- und Testzugang zum EPD (Referenzumgebung von eHealth Suisse) wird mit echten Patientendaten getestet. Das verletzt das nDSG und muss durch klare Testdatenrichtlinien verhindert werden.

2. Undokumentierte technische Konten Bei der Erstintegration werden Dienstkonten angelegt, die nie in das IAM-Inventar aufgenommen werden. Führen Sie ein vollständiges Inventar aller technischen Identitäten, die auf EPD-Schnittstellen zugreifen.

3. Fehlende Datenschutz-Folgenabschätzung Das nDSG schreibt eine Datenschutz-Folgenabschätzung (DSFA) vor, wenn die Bearbeitung besonders schützenswerter Daten in grossem Umfang erfolgt. Die EPD-Integration erfüllt diesen Schwellenwert in der Regel. Eine fehlende DSFA ist ein Risiko bei EDÖB-Prüfungen.

4. Kein Incident-Response-Plan für EPD-spezifische Szenarien Der allgemeine IR-Plan deckt EPD-spezifische Szenarien oft nicht ab: Was tun, wenn über eine kompromittierte API-Verbindung auf Dossiers dritter Patienten zugegriffen wurde? Wer informiert die betroffene Gemeinschaft? Wer meldet an das BACS?

5. Vernachlässigtes Logging auf Applikationsebene ATNA-Logs werden oft nur auf Infrastrukturebene ausgewertet. Anwendungsseitige Logs (welcher Arzt hat welches Dossier geöffnet) werden nicht ins SIEM überführt und ermöglichen keine zeitnahe Anomalieerkennung.

Implementierungs-Checkliste: EPD-Integration sicher umsetzen

Die folgende Checkliste dient als Orientierung – sie ersetzt keine vollständige Risikoanalyse:

  • [ ] Schutzbedarf der EPD-Schnittstelle formal bewertet und im Risikoregister erfasst
  • [ ] Datenschutz-Folgenabschätzung (DSFA) nach nDSG durchgeführt und dokumentiert
  • [ ] TLS 1.2/1.3 erzwungen, ältere Protokollversionen deaktiviert
  • [ ] Zertifikats-Lifecycle-Management implementiert (Alerts vor Ablauf)
  • [ ] Mutual TLS (mTLS) konfiguriert und getestet
  • [ ] Netzwerksegmentierung für EPD-Adapter/Endpunkte umgesetzt
  • [ ] ATNA-Audit-Logs ins zentrale SIEM integriert
  • [ ] SIEM-Use-Cases für EPD-spezifische Anomalien definiert
  • [ ] Alle technischen Konten inventarisiert und nach Least-Privilege konfiguriert
  • [ ] Lieferantenverträge (KIS-Hersteller, Adapter-Anbieter) um Sicherheitspflichten ergänzt
  • [ ] EPD-Ausfall in der Business Impact Analyse berücksichtigt
  • [ ] Incident-Response-Plan um EPD-spezifische Szenarien erweitert
  • [ ] Meldeprozess an BACS gemäss ISG definiert
  • [ ] Trennung Test-/Produktivumgebung sichergestellt, Testdatenrichtlinie vorhanden
  • [ ] Regelmässige Penetrationstests der EPD-Schnittstellen eingeplant
Kostenlose NIS2-Bestandsaufnahme starten →
Weitere Artikel im Wissensbereich Aktuelle Sicherheitswarnungen für das Gesundheitswesen