ehealth in der Schweiz Erfahrungen aus einem Forschungsprojekt

Transkript

1 ehealth in der Schweiz Erfahrungen aus einem Forschungsprojekt

2 Agenda Gründe für ehealth ehealth Architektur und Vertrauensraum Herausforderungen Projekt epd-demoumgebung Fazit 2

3 Bekannte Probleme Nach einem Arztwechsel (Umzug) ist die Hälfte der Patientengeschichte weg Rezepte sind weder für den Patienten noch den Apotheker 100% identifizierbar Im Ausland oder in einer Notsituation werden wichtige Informationen (Impfung, Allergien) gebraucht, sind aber nicht verfügbar Dokumente gehen beim Versand/Transport (Spezialist zu Hausarzt) verloren 3

4 Die Lösung ehealth Strategie ehealth, beschlossen am , «soll der Bevölkerung den Zugang zu einem effizienten, sicheren sowie kostengünstigen Gesundheitswesen gewährleisten.» Patientendaten sollen elektronisch gespeichert und einfach, aber sicher vom Standort unabhängig abrufbar sein Dabei spielt Datenschutz eine zentrale Rolle Institut für Wirtschaftsinformatik

5 Ziele ehealth Bestehende Prozesse vereinfachen und verknüpfen Mehrwert durch effizientere Koordination der Akteure schaffen Höhere Qualität mittels durchgängig elektronischer Prozesse erreichen ehealth durch gesteigerte Lebens- & Standortqualität als Wirtschaftsfaktor etablieren 5

6 Gruppenarbeit: Wie würdet Ihr das ehealth-system modellieren? Aufgabe: Gegeben sei nachfolgender Ablauf. Welche Daten würdet Ihr wo speichern und wie austauschen? Welche Randbedingungen gibt es? Zeit: 20 Min ohne Pause Erwartetes Resultat: Kurze, mündliche Besprechung der Lösung Beispielablauf: Patient besucht seinen Hausarzt wegen Knieschmerzen Arzt schickt Patient zum MRI Patient besucht Fachpraxis, welche die Bilder erstellt Patient besucht wieder Hausarzt Arzt kann die Bilder einsehen und Behandlung definieren Patient geht zur Apotheke und holt sich die notwendigen Medikamente 6

7 Möglicher Ablauf auf ehealth-konzept abgestimmt Patient besucht Hausarzt wegen Knieschmerzen, Patient identifiziert sich mittels Versichertenkarte Arzt schickt Patient zum MRI, Überweisung ist im Patienten-Profil gespeichert und kann von Fachpraxis aufgerufen werden Patient besucht Fachpraxis, welche die Bilder erstellt und diese in das Patienten-Profil speichert Patient besucht wieder Hausarzt und gewährt diesem Zugriff auf die Bilder Arzt kann die Bilder einsehen und seine Behandlung definieren, benötigte Medikamente speichert er im Patienten-Profil und sendet sie an Apotheke Patient geht zur Apotheke und holt sich die notwendigen Medikamente, wobei das Rezept auf der Versichertenkarte gespeichert ist 7

8 Architektur ehealth 8

9 Wichtige Begriffe Akteure: Hausarzt, Apotheke, Spezialist, etc. Gemeinschaft: Zusammenschluss mehrerer Akteure Stammgemeinschaft: Gemeinschaft, welcher der Patient angehört (immer 1) 9

10 Architekturgrundsätze Jeder Patient / jeder Behandelnde kann sich mittels elektronischem Ausweis authentifizieren Jede Gemeinschaft verwaltet die Daten ihrer Mitglieder Dezentrale Datenhaltung Zentrale Register helfen, Gemeinschaften, Akteure und Patienten zu finden Patienten kontrollieren mittels Berechtigungssystem, wer welche Daten sieht Es können fünf Vertraulichkeitsstufen definiert werden: Demografische, Nützliche, Medizinische, Sensible und Geheime Daten 10

11 ehealth Vertrauensraum Community Portal Index Health Professional Index Health Organization Index Metadata Index Role Index 11

12 Grundsätze Vertrauensraum Die Kommunikation ist standardisiert und findet gesichert statt Für Datenaustausch werden Web Services (SOAP/XML) verwendet Die zentralen Register enthalten lediglich Pointer zur verantwortlichen Gemeinschaft Patienten können jederzeit kontrollieren, wer welche Daten bearbeitet respektive gelesen hat Nur geprüfte Gemeinschaften können im Vertrauensraum teilnehmen 12

13 Herausforderungen Grosse Variation an unterschiedlichen Daten Hohe Anforderungen an Datenschutz führen zu komplexen Berechtigungsprozessen Generell viele komplexe Standards zu berücksichtigen ( Vielen Akteuren fehlt die Infrastruktur, die technische Fachkompetenz, die Motivation, Eingliederung in eine Gemeinschaft nicht trivial 13

14 Projekt epd-demoumgebung Erstellen einer Demoumgebung, welche die zentralen Dienste bereitstellt Komponenten sind Web Frontend zur grafischen Verwaltung der Daten Web Services zur automatisierten m2m Kommunikation LDAP zur Verwaltung der organisatorischen Daten sehr viele Mutationen und Mehrfacheinträge (Arzt kann mehreren Organisationen angehören) Terminologie-Server für semantische Integration Datenbank zur Speicherung sonstiger Daten 14

15 Projekterfahrung Standards werden noch immer angepasst Integration eher kleines Problem, da von Grund auf begonnen wird Anforderungen sind teils ohne wirklichen Grund gegeben (Terminologie- Server) Sprache (sowohl de/fr, als auch Domäne/Fachjargon) stellt Hürde dar Technische Komplexität kann leicht Patienten und Akteure überfordern* * Von ursprünglich 8 Hochschulen haben nur 2 eingereicht 15

16 Fazit Die dezentrale Datenhaltung und Organisation in Gemeinschaften reduziert auf den ersten Blick die Komplexität des Gesamtsystems (oder verlagert sie) Dazu erfordert sie jedoch genau definierte Schnittstellen und Standards, welche zur Zeit noch optimiert werden Andererseits verlagert sich die technische Herausforderung so von einer zentralen Instanz auf viele heterogene Gemeinschaften Es braucht Standards für Schnittstellen, aber auch interne Architektur Integrationsprobleme sind noch gering, da System neu aufgebaut wird Durch hohe Komplexität (Aufteilung zentral-dezentral) können aber schnell Probleme bei Systemanpassungen entstehen 16