gms | German Medical Science

49. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie (gmds)
19. Jahrestagung der Schweizerischen Gesellschaft für Medizinische Informatik (SGMI)
Jahrestagung 2004 des Arbeitskreises Medizinische Informatik (ÖAKMI)

Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie
Schweizerische Gesellschaft für Medizinische Informatik (SGMI)

26. bis 30.09.2004, Innsbruck/Tirol

Ausfallskonzept für die rein elektronische Patientenakte

Meeting Abstract (gmds2004)

Suche in Medline nach

  • corresponding author presenting/speaker Benno Sauter - Schweizer Paraplegiker-Zentrum, Nottwil, Schweiz
  • Jürg Luthiger - Fachhochschule Solothurn, Solothurn, Schweiz
  • Andreas Reber - Fachhochschule Solothurn, Solothurn, Schweiz
  • Boris Bremer - Fachhochschule Solothurn, Solothurn, Schweiz

Kooperative Versorgung - Vernetzte Forschung - Ubiquitäre Information. 49. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie (gmds), 19. Jahrestagung der Schweizerischen Gesellschaft für Medizinische Informatik (SGMI) und Jahrestagung 2004 des Arbeitskreises Medizinische Informatik (ÖAKMI) der Österreichischen Computer Gesellschaft (OCG) und der Österreichischen Gesellschaft für Biomedizinische Technik (ÖGBMT). Innsbruck, 26.-30.09.2004. Düsseldorf, Köln: German Medical Science; 2004. Doc04gmds300

Die elektronische Version dieses Artikels ist vollständig und ist verfügbar unter: http://www.egms.de/de/meetings/gmds2004/04gmds300.shtml

Veröffentlicht: 14. September 2004

© 2004 Sauter et al.
Dieser Artikel ist ein Open Access-Artikel und steht unter den Creative Commons Lizenzbedingungen (http://creativecommons.org/licenses/by-nc-nd/3.0/deed.de). Er darf vervielf&aauml;ltigt, verbreitet und &oauml;ffentlich zug&aauml;nglich gemacht werden, vorausgesetzt dass Autor und Quelle genannt werden.


Gliederung

Text

Einleitung

Im Schweizer Paraplegiker Zentrum ist per 1999 eine kommerzielle moderne elektronische Patientenakte eingeführt worden. Dieses System basiert grundsätzlich auf einem zentralen Datenserver. Über das LAN (Local Area Network) und über das WLAN (Wireless Local Area Network) können die Client Applikationen auf diese zentrale Datenablage lesend und schreibend zugreifen. Als Rechner kommen dabei PCs, Labtops oder auch mobile Einheiten (Pen-Pads) zum Einsatz.

Die digitale Patientenakte nimmt in den Prozessen des SPZ eine zentrale Rolle ein. Die zugrunde liegende Vision ist ihre lückenlose Integration in die IT-Landschaft am SPZ: Der Datenaustausch zwischen den Ärzten, Pflegefachpersonal, Sekretariaten, Labor und den Fachabteilungen (Radiologie, Orthopädie, etc.) soll immer gewährleistet sein, um dadurch echte Qualitäts- und Zeitvorteile zu erzielen.

Das kommerzielle EPR System, das am SPZ eingesetzt wird, kann keine hundertprozentige Verfügbarkeit garantieren, da das System aus verschiedenen Komponenten unterschiedlicher und voneinander unabhängiger Lieferanten besteht (EPR Software, Betriebssystem Software, Datenbank Software, Rechner Hardware, Netzwerk Hardware, usw.). Nach der Einführung der elektronischen Pflegedokumentation Mitte 2002 hat sich schnell gezeigt, dass eine hundertprozentige Verfügbarkeit der Daten auf den Stationen unabdingbar ist. Es musste deshalb eine Lösung gefunden werden, welche die Schwachstellen dieses zentralisierten Systems umgeht.

Methoden

Anhand einer Risikoanalyse wurden die Gefahrenpotentiale für die Verfügbarkeit der elektronischen Patientenakte eruiert und eingeordnet. Darauf aufbauend wurde bestimmt, welche Daten wie bearbeitet werden können müssen, um diese Risiken zu minimieren.

In einem zweistufigen Verfahren wurden dann Lösungen zum Verfügbarkeitsproblem gesucht und gefunden. Dabei wurde auf ein rasch umsetzbares aber einfaches und ein ausgefeilteres aber aufwändigeres Modell gesetzt.

Die Ergebnisse sollten mit möglichst geringer Zuhilfenahme kostenpflichtiger Software auskommen, bzw. falls dennoch nötig, diese Kosten möglichst niedrig halten.

Ergebnisse

Die Risikoanalyse ergab, dass bei der Konzepterstellung primär die Nichtgefährdung, bzw. die nach wie vor optimale Behandlungsmöglichkeit der Patienten bei einem Ausfall der elektronischen Patientenakte im Vordergrund steht. Diese Prämissen lassen die Möglichkeit eines rein lesenden Datenzugriffs zu, da im Notfall auch auf Papier weiterdokumentiert werden könnte. Dafür wurde ein Service erstelle, welcher die wichtigsten Daten über einen Browser nach dezentralen Orten verteilt und dort lokal zur Verfügung stellt. Die erste Lösung (Iteration 1) wurde dann so umgesetzt:

Eine Sammlung von Datenbank-Prozeduren und Sichten wird über ein zeitgetriggertes, nach jedem Schichtwechsel in der Pflege aufgerufenes Script abgearbeitet und liefert für jede Station ein HTML- bzw. XML-File, welches über die anschliessend erfolgenden Calls des Push-Services die entstandenen Dateien auf verschiedene Rechner der Stationen liefert und die bestehenden Files überschreibt. Diese Ausfallsrechner sind 24 Stunden am Tag online und werden pro Station einmal implementiert. Die Daten werden nur auf der Intensivpflegestation für alle stationären Patienten abgespeichert.

In der Stufe zwei des Ausfallkonzepts haben wir neben der Verfügbarkeit aller Daten der stationären Patienten auch eine Möglichkeit geschaffen, neu hinzukommende Daten einzugeben. Es ist also sowohl ein Lese- wie auch ein Schreibezugriff auf die Akte möglich. Die Lösung wurde in Form einer Datenbank-Replikation implementiert. Die Iteration 2 erklärt sich wie folgt:

Auf jeder Station wird ein dedizierter Rechner aufgestellt, welcher mit Oracle Standard Edition 8.1.7 aufgesetzt wird. Diese Server dienen als Empfänger der mittels „updateble snapshots" [1] auf sie replizierten Daten. Die Replikation erfolgt jedoch nach einer Selektion, welche durch die sich auf der entsprechenden Station befindlichen Patienten gegeben ist. So ergeben die Datensätze dieser verschiedenen Replikations-Server zusammen das Kollektiv der stationären Patienten.

Diskussion

Die Verfügbarkeit einer rein elektronischen Krankengeschichte muss sehr hoch sein, damit die Sicherheit der Patienten nicht gefährdet wird und eine gleich bleibende Akzeptanz der User erreicht werden kann. Es gibt wenig Literatur, wie bei einer solchen Gefährdung vorgegangen werden soll, wenn auch die Problematik bekannt ist [2]. Würde ein Systemausfall den Zugriff auf Daten der Krankengeschichte eines Patienten, dessen Zustand sich akut verschlechtert verunmöglichen, könnten schwerwiegende haftungsrechtliche Konsequenzen entstehen. Es ist deshalb äusserst ratsam, für diesen Fall vorzusehen, denn wenn auch die Stabilität und Performance von Netzwerken, Servern und Software stetig verbessert werden nimmt die Beherrschbarkeit der Technologie durch zunehmende Komplexität ab und die Bedrohung durch Malware stetig zu, was die Wahrscheinlichkeit eines Zwischenfalls nicht geringer werden lässt. Natürlich könnten diese Daten auch in Form von Hardcopys erstellt werden, dies erfordert allerdings einen nicht geringen Aufwand an Papier-, Druck- und Entsorgungskosten, da es sich dabei ja um sensible Daten handelt. Einen Medienbruch zu vermeiden ist deshalb nahe liegend.

Das Datenset für die Iteration 1 wurde bezogen auf den Zweck formuliert und dient dem Kliniker dazu, die Gründe für allfällige akute Änderungen im Gesundheitszustand der Patienten schneller zu finden. Natürlich liessen sich noch viele weitere Parameter ergänzen, wir denken aber, damit den maximalen potentiellen Nutzen mit einem Minimum an Daten und Aufwand hergestellt zu haben.

Die Dezentralisierung erfolgte aufgrund des identifizierten Klumpenrisikos einer zentral erstellten und gemanagten IT-Umgebung und macht unserer Meinung nach erheblichen Sinn. Natürlich muss dabei der Datenschutz gewährleistet bleiben und es kommt zu einem weiteren Zielkonflikt zwischen Usability, Datenschutz und Patientensicherheit, wobei diese unserer Ansicht nach in umgekehrter Reihenfolge zu bevorzugen sind.

Wir haben mit der in Iteration 2 umgesetzten Methode verhindert, dass eine Multi-Master-Rreplikation implementiert werden muss, da zwar mehrere Clients vom Master bedient werden, jeweils aber nur sich nicht schneidende Teilmengen repliziert werden. So konnten Hardware- und Lizenzkosten sowie der Programmieraufwand in Grenzen gehalten werden. Die Iteration 2 ist nicht ganz wartungsfreundlich, bietet aber zusätzliche Möglichkeiten für spezielle Fälle, in denen Offline-Verfügbarkeit der gesamten Daten notwendig ist (wie z.B. bei der Verlegung eines monitorisierten Patienten in ein anderes Spital). Es ist jedoch zu beachten, dass je nach Integrationsstufe die elektronische Patientenakte eine sehr zentrale Rolle im Klinikalltag spielt, welche für eine steigende Anzahl von Personen die unverzichtbare Basis für ihre tägliche Arbeit bildet. Aus diesem Grund muss der „Produktionsausfall" bei über mehrere Stunden stehendem System gegen die Wartungs- und Unterhaltskosten eines Systems, welches einen reduzierten unvernetzten Betrieb aufrecht zu erhalten vermag. aufgerechnet werden.

Schlussfolgerungen

Die reine elektronische Patientenakte braucht ein Ausfallskonzept, welches im Mindesten die Möglichkeit einer uneingeschränkten medizinischen Betreuung der Patienten während eines Ausfalls sicherstellt.


Literatur

1.
http://www-db.stanford.edu/dbseminar/Archive/SpringY95/downing-abstract.html
2.
Computer Crash - Lessons from a System Failure, Peter Kilbridge, N Engl J Med 2003; 348:881-882, Mar 6, 2003