Zukunft Gesundheitskarte Oracle Healthcare Transaction Base

Transkript

1 Donnerstag, 10. November h00, Variohalle 1 Zukunft Gesundheitskarte Oracle Healthcare Transaction Base Olaf Heimburger ORACLE Deutschland GmbH, Berlin Schlüsselworte: Semantische Interoperabilität, HL7, Gesundheitskarte, HL7 RIM, Elektronisches Rezept, Elektronische Patientenakte Einleitung Die Anforderungen im Gesundheitswesen haben sich in den letzten Jahren drastisch verändert. Heute sind Informationen gefragt, die sich unmittelbar auf den individuellen Patienten beziehen und jederzeit direkt verfügbar sind. Gefordert ist eine neue IT-Plattform, an der alle Beteiligten des Gesundheitswesens teilnehmen können und die den problemlosen Austausch von Informationen ermöglicht. In der Vergangenheit hatte jede Institution des Gesundheitswesens angefangen von den Krankenkassen, über die behandelnden Ärzte in ihren Praxen, bis hin zu den Kliniken separate Daten über einzelne Patienten gespeichert. In der Regel sind daher bei allen Beteiligten unterschiedliche, teils proprietäre Systeme im Einsatz, die einen elektronischen Informationsaustausch erschweren, manchmal auch unmöglich machen. Zeitliche Verzögerungen durch manuelle Aktionen oder ungenaue und fehlerhafte Übertragungen sind die Folge. Viele Informationen werden deshalb mehrfach erhoben und Untersuchungen erneut durchgeführt; Versorgungs- und Abrechnungsprozesse sind nicht effizient und kostspielig. Die Bürger, die Kliniken und Ärzte, aber auch die Krankenkassen müssen mit einer aufgeblähten Administration leben. Die Forderung nach Kostensenkung im Gesundheitswesen, nach schnelleren und transparenteren Abläufen und einem verbesserten Management hat inzwischen zu einem Umdenken geführt. Patientendaten, die automatisch aktualisiert werden und den Beteiligten genau die Informationen liefern, die gerade für die Gesundheitsversorgung benötigt werden, sind gefragt. Damit wird beabsichtigt, dass jeder Bürger genau die Fürsorge erhält, die er braucht, ohne dass Budgets gesprengt werden oder die Qualität der Behandlung leidet. Ärzte sollen sicher sein, stets mit aktuellen Daten zu arbeiten, die ein transparentes Bild über laufende und bereits erfolgte Behandlungen oder Medikationen geben. Die Krankenkassen würden durch die Reduzierung von Fehl-, Über- und Unterversorgung ihrer Versicherten Millionenbeträge einsparen. Die Gesundheitskarte Die Gesundheitskarte ist so angelegt, dass sie vielfältige Einsatzgebiete bietet. Da nicht alle Funktionen sofort zur Verfügungen stehen werden, werden diese in Ausbaustufen realisiert. Die einzelnen Funktionen werden nachfolgend in der zur Zeit denkbaren Reihenfolge dargestellt. Die Stufen 1 und 2 sind Pflichtanwendungen, während es sich bei den Stufen 3 und 4 um freiwillige Anwendungen handelt. Stufe 1 Versichertendaten In der ersten Stufe wird die Gesundheitskarte mit den Versichertendaten und der Europäische Krankenversichertenkarte eingeführt. Stufe 2 Das Elektronische Rezept (erezept) Jährlich werden ungefähr 700 Millionen Rezepte ausgestellt. Bis zu fünfmal wird ein Rezept in Arztpraxen, Apotheken und Apothekenrechenzentren angefasst und neu bearbeitet. Diese bisher übliche Mischlösung aus elektronischer Dokumentation und Papierdokumentation macht Verwaltungsvorgänge unnötig komplex und teuer.

2 18. Deutsche ORACLE-Anwenderkonferenz Das erezept und damit verbundene Möglichkeiten der elektronischen Kommunikation vermeiden Medienbrüche und sorgen für mehr Effizienz. Dabei werden die bestehenden Geschäftsabläufe in elektronische Verfahren umgesetzt, aber im Wesentlichen unverändert belassen. So ersetzt beispielsweise die qualifizierte digitale Signatur des elektronischen Rezeptes durch den Arzt dessen bisherige eigenhändige Unterschrift auf dem Papierrezept. Stufe 3 Notfalldaten In der Stufe 3 kommt die freiwillige Funktion Notfalldaten hinzu. Im Notfall kommt es darauf an, dass der Arzt in kürzester Zeit die richtige Diagnose stellt und umgehend die geeignete medizinische Therapie einleitet. Eine Herausforderung, denn als Notarzt kennt er in der Regel seinen Patienten nicht. Er weiß nicht, ob der Patient unter einer chronischen Erkrankung leidet. Er kann nicht ahnen, ob der Patient ein bestimmtes Arzneimittel nicht verträgt oder Allergien vorliegen. Und in vielen Fällen gibt es auch niemanden, der am Ort des Geschehens Auskunft über den Notfallpatienten geben kann, falls dieser selbst nicht mehr dazu in der Lage ist. Stufe 4 Die Elektronische Patientenakte (EPA) In einer ersten Anwendungsphase bietet die Karte die Möglichkeit, auf freiwilliger Basis die Arzneimitteldokumentation, die klinischen Basisdaten wie auch Notfalldaten elektronisch abzulegen. Durch einen Vermerk auf der Karte kann der behandelnde Arzt unter anderem erkennen, ob die Patientin oder der Patient an einem strukturierten Behandlungsprogramm für bestimmte chronische Erkrankungen, so genannten Disease-Management-Programmen (DMP) teilnimmt. Ein erster wichtiger Bestandteil der Gesundheitsakte ist die freiwillige Arzneimitteldokumentation. Heilberufler können sich mit Einverständnis des Patienten darüber informieren, welche Medikamente in welcher Dosierung der Patient erhalten hat. Die klinischen Basisdaten informieren die Heilberufler zusätzlich auch über persönliche Arzneimittelrisiken wie Arzneimittelallergien oder spezielle Arzneimittelunverträglichkeiten. So genannte Kontraindikationen, wie das Vorliegen einer Nierenausscheidungsstörung, werden ebenfalls vermerkt. IT Experience Paradigmenwechsel Meine Daten gehören mir Mit der Gesundheitskarte wird ein Paradigmenwechsel bezüglich der Datenhoheit vorgenommen. Wurden bisher die medizinischen Daten in Arztpraxen, Krankhäusern, Krankenkassen usw. gespeichert, wird in Zukunft der Patient bestimmen, wer welche Daten sehen und speichern darf. Dieser Paradigmenwechsel bedarf natürlich einer entsprechenden Infrastruktur und Information der Patienten. So soll jeder Patient die Möglichkeit haben, vom heimischen PC oder von Kiosksystemen seine Daten einsehen und mit entsprechenden Berechtigungen versehen zu können. Dabei spielen die Gesundheitskarte für den Patienten und die Heilberufsausweis (HBA) als kryptografische Schlüssel eine wichtige Rolle. Health Level 7 (HL 7) Für die internationale Standardisierung von medizinischen Daten gilt das gleiche wie für die andere Computerstandards: Es gibt einfach zu viele Standards. Die Standardisierungsorganisation Health Level 7 ist eine am American National Standards Institute (ANSI) akreditierte Standard-entwickelnde Organisation (Standards Developing Organization (SDO)). Sie befasst sich mit der Entwicklung von Kommunikationsstandards zum einheitlichen Datenaustausch. Bekannte und eingesetzte Standards sind u.a. HL7 v2 und CDA. HL 7 v3 Während sich HL7 v2 noch auf das reine Austauschformat konzentriert, wird in HL7 v3 ein Standard entwickelt, der sich nicht nur um die Nachrichtenformate kümmert, sondern zugleich auch ein einheitliches und ganzheitliches Datenmodell entwickelt. Reference Information Model Das Reference Information Model (RIM) bildet die Grundlage für den neuen HL7 v3 Standard. In ihm werden grundlegende Datentypen und deren Beziehungen zueinander definiert. Die Datentypen werden in vier Gruppen aufgeteilt: Entitäten (Entities), Rollen (Roles), klinische Vorgänge (Acts) und Beziehungen zwischen den klinischen Vorgängen (ActRelationships)

3 Entitäten Zu den Entitäten zählen alle natürlichen oder juristischen Dinge wie Personen, Tiere, Organisationen, aber auch Material. Rollen Wie im normalen Leben kann jede Entität eine oder mehrere Rollen annehmen. Jede Person kann also Patient oder Arzt oder Besucher oder jede Kombination davon sein. In HL7 v3 wird von spielender (playing) und ausführender (scoping) Rolle gesprochen. Klinische Vorgänge Die sog. klinischen Vorgänge (Acts) beziehen sich auf alle Vorgänge, die während einer Behandlung vorkommen können. Die Klasse Acts hat eine Vielzahl von Subklassen die spezialisierte Vorgänge abbilden. Zu den Subklassen gehören u.a. Begegnungen (Encounter), Beobachtungen (Observation), besondere Ernährung (Diät). Beziehungen zwischen klinischen Vorgängen Zwischen klinischen Vorgängen können Beziehungen bestehen. Da ein klinischer Vorgang oft aus mehreren Teilvorgängen bestehen kann, werden Beziehungen zwischen den einzelnen Vorgängen durch sog. ActRelationships abgebildet. Der Gestaltungsprozess Aufbauend auf diesen Klassengruppen müssen bei der Anwendungsentwicklung Datenmodelle erstellt werden um alle gewünschten Informationen in der richtigen Form zu erhalten. Dafür wurden von HL7 sog. Refined Message Information Models (R-MIMs) entwickelt. R-MIMs werden verwendet um den Inhalt einer spezifischen Nachricht zu definieren. R-MIMs enthalten spezifische Daten und erleichtern die Validierung und Kommunikation von auszutauschenden Nachrichten auf einer visuellen Ebene. Bild 4: R-MIM für einen Patiententermin (Patient Encounter Appointment) Nachrichten Mit dem Reference Information Model und den RMIMs lassen sich vollständige, klinische Systeme erstellen. Damit die gespeicherten Daten ausgetauscht werden können, sind die Nachrichtenformate wesentlicher Bestandteil des HL7 v3 Standards. Es werden zur Zeit über 720 XML Schema Definitionen (XSDs) vorgegeben, die alle Aspekte der medizinischen Datenwelt abdecken. Oracle Healthcare Transaction Base Die Oracle Healthcare Transaction Base (HTB) implementiert das HL7 v3 RIM vollständig. Neben allen im Standard verwendeten Basistypen werden auch die im RIM vorgegebenen Klassen implementiert.

4 18. Deutsche ORACLE-Anwenderkonferenz HTB selber steht als J2EE-Dienst zur Verfügung und wird über eine Client-Bibliothek angesprochen. Diese übernimmt die notwendigen Low-Level Schritte um die Daten an den entsprechenden Dienst zu übermitteln oder zu erhalten. Die wichtigsten Dienste sind der Enterprise Terminology Service und der Rim- Service. Enterprise Terminology Service Im HL 7 v3 werden eine Anzahl von Wertelisten verwendet, die in HTB als Terminologien bezeichnet werden. Andere Beispiele für weitere Terminologien sind ICD 9 oder ICD 10, SNOMED oder LOINC aber auch Hauskataloge. Der Enterprise Terminology Service (ETS) bildet einen wesentlichen Stützpfeiler der HTB. Dieser Service implementiert vielfältige Funktionalitäten, um Terminologien zur Verfügung stellen und pflegen zu können. Die meisten der Terminologien veränderen sich über die Zeit oder werden nur in bestimmten Zusammenhängen gebraucht. Zum Beispiel wird oft SNOMED für die interne Arbeit verwendet, während bei der Abrechung ICD Codes gefordert sind. Der ETS bietet für beide Probleme eine Lösung an. Terminologien die sich über die Zeit entwickeln können versioniert werden. Durch ein passendes Mapping können Einträge der älteren Versionen auf Einträge der jüngeren Version verweisen (Intra- Terminology Mapping). Aber auch bei unterschiedlichen Terminologien lässt sich ein sog. Äquivalenz-Mapping definieren. Der ETS ist dann in der Lage zum Beispiel für einen SNOMED Code den entsprechenden ICD 10 Code zu liefern (Inter-Terminology Mapping). Da jedes Mapping nur in einer Richtung gilt, müssen für bidirektionale Mappings zwei Mappings definiert werden. IT Experience RimService Der RimService stellt die Java-Schnittstelle zur HTB dar. Er erwartet eine Datenstruktur, die einer HL7 v3 Message entspricht. Durch diese Anlehnung können alle HL7 v3 Message Typen und Formate unterstützt werden. Mit Hilfe der enthaltenen Java-Klassen kann der Java-Entwickler die entsprechenden Strukturen aufbauen und diese an den RimService übergeben. Bei der Suche nach Daten wird eine HL7 v3 Message Struktur geliefert. Da sich die Namen der Datentypen sehr eng an den HL7 v3 Standard halten, kann die Programmierung anhand der gewünschten Nachrichten sehr zügig erfolgen. Nachrichtenverarbeitung (XML Message Processing) Aufbauend auf den beiden Diensten ETS und RimService werden Dienste zur Verarbeitung von XML Nachrichten zur Verfügung gestellt. Diese Dienste werden als Inbound und Outbound Message Service bezeichnet und implementieren alle in HL7 v3 definierten Nachrichtentypen. Die Message Services können über alle bekannten Protokolle angesprochen werden. Mitgeliefert wird eine Implementierung für das HL7-eigene MLLP Protokoll. Andere Protokolle wie HTTP oder SOAP sind jedoch sehr einfach zu implementieren. Ein Pilot für die Gesundheitskarte Die Implementierung eines Piloten für die Gesundheitskarte kann nur in enger Zusammenarbeit mit allen Beteiligten, also Krankenkassen, Ärzten und Krankenhäusern funktionieren. Ideal für einen Piloten ist eine Modellregion, die den Vorzug einer abgeschlossenen Umgebung durch einen fest definierten Kreis der Versicherten und der Vertragshäuser bietet. Es muss davon ausgegangen werden, dass in jeder Umgebung bestehende Systeme als Datenquellen vorhanden sind. In einem Piloten sollten mindestens die Dienste Elektronisches Rezept und Elektronische Patientenakte implementiert werden.

5 Bild 5: Eine Architektur für die Gesundheitskarte Das Elektronische Rezept Als Pflichtdienst sollte das Elektronische Rezept implementiert werden. Um den Missbrauch dieser Daten zu vermeiden, müssen diese verschlüsselt und nahezu strukturlos abgespeichert werden. Eine Implementierung dieser Funktionalität ist aus Sicht der Datenspeicherung relativ einfach und kann mit einfachen Datenbankmitteln vorgenommen werden. Datenrecherche oder auswertungen finden nicht statt. Die Elektronische Patientenakte Bei der Implementierung der elektronischen Patientenakte muss zunächst ermittelt werden, welche Informationen in welcher Form dargestellt werden sollen und aus welchen Systemen diese Informationen in die Patientenakte gelangen können. Es ist zu erwarten, dass einige Werteliste (auch Terminologien) mit gleicher Bedeutung aber mit unterschiedlichen Werten auftauchen. Diese lassen sich sehr gut im Terminology Server der HTB einpflegen und durch Cross Maps verbinden. Übliche Wertelisten wie ICD-9, LOINC oder ICD-10 werden bereits unterstützt, müssen aber noch geladen werden. Zur Darstellung der Patientenakte wird üblicherweise eine Hierarchie aus Patient-Organisation-Vorgänge oder eine zeitliche Krankengeschichte gewählt. Die hierarchische Darstellung lehnt sich an die vom Windows Explorer bekannte Baumdarstellung an. Hier werden die klinischen Vorgänge den ausführenden Organisationen (wie Krankenhaus, Arzt, etc.) zugeordnet. Eine zeitliche Darstellung der Krankengeschichte hat den Vorzug einer besseren Einordnung der Klinischen Vorgänge, hat aber Nachteile bei der Zuordnung zu den ausführenden Organisationen. Ideal wäre die Implementierung beider Darstellungen, die vom Anwender nach Bedarf gewählt werden können. Datenaustausch Da heutige Systeme im günstigsten Fall lediglich HL7 v2 Nachrichten austauschen können, muss eine Konvertierung in HL7 v3 Nachrichten vorgenommen werden. Diese Konvertierung wird von der Messaging Engine aufgerufen und durch einen passenden Konverter vorgenommen. Nach erfolgter Konvertierung wird die HL7 v3 Nachricht an den Inbound Messaging Service der HTB weitergeleitet.

6 18. Deutsche ORACLE-Anwenderkonferenz Darstellung der Daten Die Darstellung der Daten kann über die üblichen Möglichkeiten der Benutzeroberflächen erfolgen. Da hier unterschiedliche Technologien zur Verfügung stehen und auch eingesetzt werden müssen, bietet es sich an die EPA mit der HTB als WebService zur Verfügung zu stellen. Mit dieser Grundlage können die einzelnen Anwendungen mit dem nötigen Bezug zu den Anwendern gestaltet werden. So können die Arzt und Apotheken-Anwendungen für die gewünschten Plattformen (zum Beispiel Microsoft Windows und Apple Macintosh) als native Anwendung implementiert werden. Das Kiosksystem für den Patienten jedoch üblicherweise als Web-Anwendung. Ausbau des Systems Durch die Verwendung von WebServices ist ein solches System leicht mit anderen Systemen zu koppeln. Durch die Verwendung von BPEL können wesentliche Abläufe dynamisch erfolgen und bei Bedarf hinzugefügt werden. Kontaktadresse: Olaf Heimburger HTB Technical Manager ORACLE Deutschland GmbH Schlossstrasse 2 D Berlin IT Experience Telefon: +49 (0) Fax: +49 (0) Olaf.Heimburger@oracle.com Internet: