Vor einigen Wochen habe ich hier kritisiert, dass das geplante neue elektronische Gesundheitsdossier (E-GD) erneut als zentrales Grossprojekt aufgesetzt wird. Daraufhin habe ich Bundesrätin Elisabeth Baume-Schneider geschrieben — und tatsächlich eine ausführliche Antwort vom Bundesamt für Gesundheit erhalten.

Die Antwort bestätigt mich in einem Punkt und macht mich in einem anderen besorgt.

Bestätigt fühle ich mich, weil der künftige Swiss Health Data Space (SwissHDS) explizit auf einem föderierten Data-Mesh-Ansatz und auf dem FHIR-Standard beruhen soll. Die Architekturfrage für die Datennutzung ist damit im Grundsatz richtig beantwortet.

Besorgt bin ich, weil das E-GD selbst weiterhin als „einheitliches System für die ganze Schweiz“ geplant ist, kombiniert mit Anschlusspflicht und Widerspruchslösung. Genau dieser Pfad — zentralisieren statt standardisieren — hat das heutige EPD scheitern lassen. Mehr Geld und mehr Pflicht werden ein konzeptionell schwaches System nicht erfolgreicher machen.

In diesem Beitrag möchte ich zeigen, dass ein föderiertes E-GD technisch möglich ist. Und ich erkläre das anhand von Techniken, die jede und jeder von uns täglich benutzt — denn das Internet hat genau dieses Architekturproblem vor dreissig Jahren auf elegante Weise gelöst.

Das Internet als Vorbild

Wenn ich mit Bekannten über das E-GD diskutiere, höre ich oft den Einwand, ein föderiertes System sei zwar theoretisch reizvoll, aber praktisch viel zu komplex. Mehrere Anbieter, Patienten verteilt, Notfallzugriff — das könne unmöglich zuverlässig funktionieren.

Tatsächlich tun wir genau das jeden Tag. Wenn ich eine E-Mail von meinem Konto bei kousz.ch an eine Bekannte mit Gmail-Adresse sende, funktioniert das nicht, weil ein zentraler Schweizer Maildienst alles vermittelt. Es funktioniert, weil die Welt sich auf das SMTP-Protokoll geeinigt hat. Mein Mailserver und der von Google sprechen dieselbe Sprache, sind aber technisch und organisatorisch vollständig unabhängig.

Genau dieses Muster lässt sich auf medizinische Daten übertragen. Die Tabelle zeigt, dass die Bausteine eines föderierten E-GD ihre direkten Vorbilder im offenen Internet haben:

Föderiertes E-GD	Bekannt aus dem Internet
Patient-Locator	DNS — Domain Name System
Trust Registry	Zertifizierungsstellen für TLS/HTTPS
FHIR-Profile CH	HTTP + HTML als gemeinsame Sprache
Mehrere Dossier-Anbieter	E-Mail-Provider — Gmail, Proton, Eigenbetrieb
SMART on FHIR	OAuth — „Mit Google anmelden“
Notfallkarte mit QR/NFC	Hardware-Token wie YubiKey/FIDO2
International Patient Summary	OpenGraph-Snippet auf Webseiten
Patient wählt Anbieter	Eigener Domain-Name, freie Hoster-Wahl

Keine dieser Techniken müsste der Bund neu erfinden. Sie sind etabliert, ausführlich dokumentiert, milliardenfach erprobt und in der Regel auf offenen Standards aufgebaut.

Die Architektur in drei Schichten

Das Modell besteht aus drei Schichten, die unterschiedliche Aufgaben haben — und genau dort zentral oder verteilt sind, wo es Sinn ergibt.

Bund-Schicht — die minimale Mitte

Hier liegt das, was der Bund tatsächlich zentral betreiben muss, damit Föderation überhaupt möglich wird. Drei Dienste reichen aus:

Patient-Locator — die DNS des Gesundheitswesens. Genauso wie DNS bei der Eingabe von villa-wellentanz.ch zurückmeldet, auf welchem Server die Domain liegt, antwortet der Patient-Locator: „Zu Patient X gibt es Datensätze bei Anbieter A, C und F.“ Keine Inhalte, nur Verweise. Pseudonymisiert, schlank, schnell. Technisch gibt es dafür mit IHE XCPD längst ein etabliertes Profil.

Trust Registry — die Zertifizierungsstelle des Systems. Wenn der Browser https://www.admin.ch anzeigt und das Schloss-Symbol grün ist, vertraut er, weil eine akkreditierte Zertifizierungsstelle das Server-Zertifikat ausgestellt hat. Genauso erhält ein E-GD-Anbieter ein Bund-Zertifikat, wenn er Mindeststandards für Sicherheit, Datenschutz und Verfügbarkeit nachweist. Vergleichbar mit Let’s Encrypt oder DigiCert, nur kuratiert vom Bund.

FHIR-Profile CH — die HTML-Spezifikation für medizinische Daten. Diese Profile gibt es bereits. eHealth Suisse hat sie als CH-EPR-FHIR-Profile publiziert. Sie sind die einzige Stelle, an der der Bund inhaltlich präzise sein muss.

Das ist alles. Drei kleine Dienste, kein riesiges System.

Anbieter-Schicht — viele, austauschbar, gleichwertig

Wer ein E-GD anbietet, muss FHIR-konform sein und im Trust Registry akkreditiert. Sonst nichts. Damit können sehr unterschiedliche Akteure parallel existieren:

• Spitalverbünde, die das Dossier ihrer Patientinnen führen
• Hausarzt-Netzwerke mit gemeinsamem Dossier für ihre Mitgliedspraxen
• Patientenorganisationen mit einem auf chronisch Kranke spezialisierten Dossier
• Kommerzielle Anbieter mit speziellen Funktionen — KI-Auswertung, Notfall-Optimierung, mehrsprachige Aufbereitung
• Technisch versierte Patientinnen und Patienten mit Eigenbetrieb — genau das, was ich heute schon mache

Das ist exakt die Situation bei E-Mail: Ich kann meinen Mailserver selbst betreiben, ein Konto bei Proton haben oder bei Google. Niemand merkt davon etwas, weil das Protokoll dasselbe ist.

Zugriffs-Schicht — Patient, Fachperson, Notfall

Die drei Pfade, auf denen Daten gelesen werden, haben je ihre eigenen Authentifizierungs-Mechanismen.

Patient — über die App des gewählten Anbieters, idealerweise mit der kommenden Schweizer e-ID. Der Patient steuert, wer auf welche Daten zugreifen darf — und kann Berechtigungen jederzeit widerrufen. Technisch ist das UMA 2.0, der etablierte Standard für patientengesteuerte Autorisierung.

Fachperson — aus dem Praxis- oder Klinik-Informationssystem (KIS) heraus, via SMART on FHIR. Das ist nichts anderes als OAuth: dasselbe Verfahren, mit dem ich mich heute bei einer Drittapp mit Google anmelden kann. Nur dass hier die „Drittapp“ das KIS der Ärztin ist und der „Account-Anbieter“ der E-GD-Anbieter des Patienten.

Notfall — der wichtigste Sonderfall, dazu gleich mehr.

Wie ein normaler Datenfluss aussieht

Konkret: Eine Ärztin in einer Notaufnahme will die Vorgeschichte eines neuen Patienten sehen.

1. Sie identifiziert den Patienten in ihrem KIS — e-ID, AHV-Pseudonym oder Krankenkassenkarte.
2. Das KIS fragt den Patient-Locator: „Welche Anbieter haben Daten zu diesem Patienten?“ Der Locator antwortet mit einer Liste von Endpunkten, sagen wir drei URLs.
3. Das KIS holt parallel von allen drei FHIR-Endpunkten die relevanten Ressourcen — Medikamente, Allergien, Diagnosen, Berichte. Die Autorisierung erfolgt über SMART on FHIR, mit vorgängiger Patientenfreigabe oder im Notfall über Break-Glass.
4. Das KIS aggregiert die Daten lokal zu einer einheitlichen Ansicht. Das ist trivial, weil alle Anbieter dieselben Profile verwenden.
5. Jeder Zugriff wird beim jeweiligen Anbieter protokolliert; der Patient sieht das in seiner App.

Wichtig: Der Bund sieht in diesem Ablauf keine einzige medizinische Information. Der Locator weiss nur, dass es bei Anbieter A einen Eintrag gibt, nicht was.

Der Notfallpfad

Hier liegt der eigentliche Hebel — und der Punkt, an dem alle bisherigen EPD-Konzepte besonders schwach sind.

Mein Modell sieht vor: Der Patient trägt eine Notfallkarte mit QR-Code und NFC-Chip. Sie enthält:

• Eine signierte URL zu einem Patient/$summary-Endpoint des gewählten Anbieters. Das ist eine standardisierte FHIR-Operation, die ein International Patient Summary (IPS) zurückgibt: Diagnosen, Medikamente, Allergien, Notfallkontakte, kompakt und maschinenlesbar.
• Ein zeitbegrenztes Break-Glass-Token, das die Karte selbst generiert. Challenge-Response, vergleichbar mit FIDO2 oder einem YubiKey.

Damit kann das Notfallpersonal in unter zwei Sekunden eine vollständige IPS-Übersicht laden — ohne Patienten-Anmeldung, ohne vorgängige Anbindung der Institution an eine zentrale Plattform, ohne Login. Der Patient muss nicht ansprechbar sein. Jeder Zugriff wird signiert protokolliert und beim Patient binnen Stunden sichtbar gemacht.

Und das Beste: Diese Architektur funktioniert auch dann, wenn die zentralen Bundes-Dienste gerade ausgefallen sind, weil das IPS direkt beim Anbieter liegt. Die Notfallkarte enthält bereits den vollständigen Verweis. Das ist Resilienz, wie sie nur ein dezentrales System bieten kann.

Praktisch alle Bausteine existieren bereits

Wer denkt, das müsse erst entwickelt werden, irrt. Hier eine Liste der relevanten Standards — alle international etabliert, alle dokumentiert, alle einsetzbar:

• FHIR R4 / R5 mit den CH-Profilen von eHealth Suisse
• IHE XCPD / mXCPD für Patient-Discovery zwischen Anbietern
• SMART on FHIR für sichere Drittanbieter-Apps
• OAuth 2.0 / OpenID Connect für Authentifizierung
• UMA 2.0 — User-Managed Access — für patientengesteuerte Berechtigungen
• International Patient Summary (IPS) als HL7-Standard für Notfalldaten
• FIDO2 / WebAuthn für hardware-basierte Notfallauthentifizierung
• Die kommende Schweizer e-ID als nationaler Identitätsanker

Der Bund müsste also nicht ein riesiges System bauen, sondern wenige Dutzend Seiten Spezifikation schreiben — was genau muss ein akkreditierter Anbieter erfüllen — und drei kleine Dienste betreiben: Trust Registry, Patient-Locator, Profile-Publikation. Das ist eine andere Grössenordnung als das heutige EPD-Programm.

Was das ändert

Würde das E-GD so aufgesetzt, hätte das mehrere konkrete Konsequenzen.

Innovation entstünde dort, wo sie heute schon entsteht — bei den Akteuren mit konkreten Anwendungsfällen. Eine Patientenorganisation kann ein Dossier bauen, das speziell auf ihre Mitglieder zugeschnitten ist. Ein Hausarzt-Netzwerk kann seines optimieren. Wer es besser macht, gewinnt Patientinnen. Wer schlechter wird, verliert sie. Das ist der Mechanismus, der das offene Web zu dem gemacht hat, was es heute ist.

Das Projektrisiko sinkt drastisch, weil der Bund nur eine schlanke Infrastruktur baut, nicht das ganze System. Selbst wenn ein einzelner Anbieter scheitert, sind nicht alle Daten weg — der Patient wählt einen neuen, importiert seine Daten, weiter geht’s. Das ist die direkte Übersetzung von „Mailserver-Wechsel“ auf das Gesundheitswesen.

Der Notfallzugriff wird endlich realistisch lösbar, weil er nicht durch eine zentrale Login-Maschinerie muss.

Und am wichtigsten: Patientinnen und Patienten erhalten echte Wahlfreiheit. Nicht ein staatliches System, das man nehmen oder ablehnen muss, sondern eine Wahl zwischen mehreren vertrauenswürdigen Anbietern, mit der Möglichkeit, den Anbieter zu wechseln oder selbst zu betreiben.

Das wäre der Paradigmenwechsel: weg vom Grossprojekt, hin zu einem offenen Protokoll. Wie damals beim Internet.

jpk