Das epSOS (Smart Open Services for European Patients) ist ein EU-Projekt das zeigt, wie technische EU-Vernetzungsprojekte - auch in anderen Bereichen AUßERHALB des Gesundheitswesens - funktionieren.

Was ist das Ziel von epSOS?

• Wie man inkompatible Systeme integrieren und auf einen gemeinsamen Nenner bringen kann
• Das Überwinden von Sprachbarrieren
• Ohne zentrale Struktur (Server in Brüssel mit allen Patientendaten) geht es auch!

Die Grundlage von epSOS ist die Patientenrechte-Richtlinie für die grenzüberschreitende Patientenversorgung.

Die funktionalen Einheiten von epSOS

• Patient Summary, eine Kurzakte mit den wichtigsten med. Infos zum Patienten
• ePrescription, die elektronsiche Verschreibung von Rezepten
• Infrastuktur selbst

Nun gibt es ja bekannermaßen die europäische Krankenversicherungskarte (Auf der Rückseite der eGK). Hierauf sind jedoch lediglich die Stammdaten sowie Versicherungsinformationen zum Zwecke der Abrechnung enthalten. Um aber auch medizinische Daten für die Behandlung (im Notfall) zur Verfügung zu haben, gibt es die sog. Patient Summary.

Patient Summary

Diese medizinischen Informationen über einen Patienten dienen dem Notfall, aber auch dem Arztbesuch außerhalb des Notfalls in einem anderen EU-Land.

Die wichtigste Eigenschaft der Patient Summary ist, dass keine Daten zentral gespeichert werden. Bei Bedarf wird sie von Zielland aus dem Heimatland direkt abgerufen und übertragen. Dies ist jedoch zugleich eine Herausforderung, genau wie folgende Themen:

• EU-weite Identifikation von Arzt & Patient
• EU-weite Autorisierung von Arzt & Patient
• EU-weite einheitliche & eindeutige Semantik (Sprachbarrieren bei Feldern und Inhalten des Datensatzes)
• Interoperatibilität
• Unterschiedliche Rechtssysteme
• Unterschiedliche Sicherheitsniveaus

Folgende Daten können (ganz bewusst, denn jedes Land definiert selbst, welche Elemente es mit einschließt) in einer Patient Summary, im Folgenden "Dokument" genannt, enthalten sein:

• Persönliche Daten des Patienten
• Kontaktinformationen
• "Medical Problems": Implantate, Vorerkrankrungen, Aktive Diagnosen und Probleme
• "History of past illness": Bereits erfolgte Operationen, behandelte Symtpome
• Medikationen
• Schwangerschaft
• Rauchen, Alkoholkonsum
• Befunde
• Das Datum dieses Datensatzes

Laut Definition gibt einen verpflichtenden (mandatory)-Datensatz mit den technisch minimalen Informationen. Diese müssen vorhanden sein, sonst wird das Dokument vom anfordernden NCP abgewiesen. Als Pendant dazu gibt es fachlich-medizinische Mindestinformationen sowie einen erweiterten Datensatz.

Diese Daten sind in einem profilierten HL7/CDA-R3-Dokument gepseichert. Es ist hochstrukturiert und die inhalte sind kodiert. Optinal kann auch ein Originaldokument im PDF-Format in das HL7-CDA-Dokument eingebettet sein.

epSOS-Architektur

Die Infrastruktur ist eine serviceorientierte und nachrichtenbasierte Architektur (wie die TI in Deutschland). Es gibt jedoch eine synchrone Kommunikation zwischen den Service-Providern und den Service-Consumern. Die angeforderten Daten werden über das epSOS-System übertragen, nicht gespeichert.

Der Datenaustausch erfolgt über nationale Gateways, sie sind das Rückgrat dieser Infrastruktur. Sie werden "National Contact Points" (NCP) genannt und bilden einen "Circle of Trust": Gegenseitiges Vertrauen ohne übergeordnete Struktur (deshalb auch bewusst "dezentral" betitelt, ohne Involvierung von irgendwelchen Brüsseler Servern).

Das "Telefonbuch" der Dienste ist die sog. "Trusted Service List". Hiermit wird der für den Patienten benötigte, korrekte Dienst (NCP) lokalisiert. Es ist der einzige Dienst, der zentral verfügbar ist.

Um einen Patienten epSOS-weit eindeutig zu identifizieren (abhängig von der Policy/Sicherheitsrichtlinie des Residenzlandes), gibt es den "epSOS Identification Service". Er arbeitet mit allgemeinen Identifiern (Perso-Nr, Führerschein, Soz-vers-nr) oder über spezielle eHealth-Identifier (KV-Nr, Master Patient Index).

Bei epSOS kommen Interoperabilitätsstandards zum Einsatz (IHE-Profile):

• XCA: Cross-Community Access
• XCPD: Cross-Community Patient Discovery
• XDR: Cross-Enterprise Document Reliable Interchange

Sicherheitsaspekte

Für Kommunikationsbeziehungen authentifizieren sich die NCPs gegenseitig. Der Transport der Nachrichten erfolgt verschlüsselt und mit einer elektronischen Signatur von jedem NCP. Zudem werden die "eigenen" Ärzte eines Landes/NCP validiert und bei Erfolg eine "Assertion" ausgestellt. Sie enthält außerdem das Siverheitsniveau der Authentisierung (Beispielsweise verwenden die Tschechen ein niedrigeres Niveau als hier in Deutschland).

Jede Anforderung und jede Datenübertragung wird selbstverständlich vom NCP dokumentiert.

Technischer Hintergrund: 

Jede epSOS-Nachricht (SOAP-Nachricht) trägt zwei SAML-Assertions (v 2.0):

• Die Bestätigung der Identität des anfordernden Arztes
• Eine epSOS-eigene Bestätigung, dass der Patient wirklich in Behandlung beim behaupteten Arzt und somit die Übertragung legitim ist

Wie sieht ein epSOS-Prozess aus?

1. Ein Service-Consumer (z.B. Arzt) in Tschechien fordert ein Patient Summary an.
2. Patient unterschreibt eine Einwilligung (wenn nicht vorher geschehen)
3. Der Arzt identifiziert und authentifiziert sich beim tschechischen NCP
4. In Deutschland gefordert: Der Patient muss sich ebenfalls authentifizieren
5. Der Arzt setzt eine Anforderung an den tschechischen NCP ab (samt Einwilligung und Kennwort des Patienten)
6. Tschechischer NCP bestätigt die Authentifizierung des Arztes gegenüber dem deutschen NCP und schickt die Anforderung endgültig raus.
7. Nach Erhalt fordert der deutsche NCP die Patient Summary aus dem lokalen Fachdienst (z.B. in der TI) an und transformiert die Daten eventuell.
8. Wenn das Dokument/der Datensatz valide und die Integrität gewährleistet ist, schickt der deutsche NCP es in einer signierten SOAP-Nachricht an den tschechischen NCP bzw. an den Arzt.
9. Beide NCP loggen diesen Zugriff und die Datenübertragung.

Semantische Interoperabilität

Wie ordnet man semantisch Übersetzungen zwischen Code-Systemen korrekt zu?

Verschiedene Standards wie HL7-CDA, LOINC, UCUM, ATC usw (Siehe auch diesen Beitrag) wollen gemeinsam genutzt werden. Als weitere Hilfe stehen Kodiersysteme bzw. Ontologien bereit.

Quelle:Fraunhofer Fokus