7. Elektronische Gesundheitskarte. 7. Elektronische Gesundheitskarte. 7. Elektronische Gesundheitskarte. 7. Elektronische Gesundheitskarte

Transkript

1 Krankenhausinformationssysteme (KIS) 1. Grundlegende Begriffe und Definitionen 2. Ziele und Nutzen von KISen 3. Modellierung von KISen 4. Aufbau eines KIS 5. Aufbau Medizinischer Informationssysteme 6. Elektronische Patientenakte 8. Topologien und Integrationsaspekte 9. Auswahl und Einführung von KISen 10. Management von KISen 6.14 Datenschutzmodul Anwendungsfunktionen einer Berechtigungsverwaltung in der EPA Benutzerverwaltung Bezug zu Mitarbeiterstammdaten Zuweisungsmöglichkeit von Rollen oder Rechten zu Benutzern Rollenverwaltung Rollenhierarchien Rollenbezogene Rechtedefinitionen Verwaltung inhaltssensitive Zugriffsberechtigungen Verwaltung objektstatusbezogener Zugriffsberechtigungen 6.14 Datenschutzmodul Anwendungsfunktionen einer Berechtigungsverwaltung in der EPA Protokollierungsfunktionen Datenveränderungen Datenübertragungen Digitale Signaturfunktion Diagnosen, Symptome etc. Freigegebene Dokumente (Briefe, Protokolle, Befunde) Verschlüsselungsfunktion Diagnosen, Symptome etc. Freigegebene Dokumente (Briefe, Protokolle, Befunde) Komponenten: Elektronische Gesundheitskarte HPC / Heilberufeausweis Sicherheitsmodulkarte (SMC Typ B) für Konnektor Sicherheitsmodulkarte (SMC Typ A) für entfernte Steckung und lokale Nutzung Komponenten: Kartenlesegeräte Komponenten: Angepasste Primärsysteme Konnektoren (bisher 4 zugelassen) Telematikinfrstruktur Angepasste Primärsysteme Telematikinfrastruktur 1

2 Konsequenzen für die KIS-Weiterentwicklung : Konsequenzen für die KIS-Weiterentwicklung : Konsequenzen für die KIS-Weiterentwicklung : Chancen der egk für Krankenhäuser: 8. Topologien und Integrationsaspekte 8.2 Integrationsaspekte 8.5 KIS-Portale Architektur der Logischen Werkzeugebene Anwendungssysteme Kommunikationsschnittstellen Drei prinzipielle Paradigmen Monolythisches Informationssystem Heterogenes Informationssystem Komponentenbasierte Informationssysteme In der Praxis gilt: Je größer und komplexer ein Unternehmen ist, desto eher kommen heterogene Informationssysteme zum Einsatz, da kein Anbieter alle dort notwendigen Funktionen innerhalb eines monolythischen Systems anbieten kann. 2

3 Monolythische Informationssysteme System aus einem Guss System von einem Hersteller Alle Systemkomponenten basieren auf einem einheitlichen Datenmodell einheitlichen Design- und Implementierungsprinzipien einer einheitlichen Software-Architektur einheitlichen Bedienungsprinzipien (erwartungskonform) Modularisierung ist möglich Heterogene Informationssysteme Systeme von verschiedenen Herstellern Alle Systeme basieren auf unterschiedlichen Datenmodellen unterschiedlichen Design- und Implementierungsprinzipien unterschiedlichen Software-Architekturen unterschiedlichen Bedienungsprinzipien Kommunikationsabgleich und Datenaustausch zwischen den Systemen über sogenannte Kommunikationsserver Komponentenbasierte Informationssysteme Objektorientierte Architektur Systeme bestehen nicht mehr aus einer Vielzahl voneinander unabhängiger Programme, die auf getrennt davon gehaltene Daten zugreifen sondern Systeme bestehen aus aktiven Objekten, die ihre Funktion kapseln und über offen gelegte Schnittstellen mit anderen Objekten kommunizieren. Schlagwort SOA Service-Orientierte Architektur Gegenüberstellung Monolythisch / Heterogen Vor- und Nachteile Monolythischer und Heterogener Informationssysteme Typen von Lösungsanbietern Gesamtlösungsanbieter Lösungen sind breit angelegt (decken alle Bereiche ab), gehen aber nicht sehr in die (funktionale) Tiefe Spezialisierung muß der Kunde über Formulargeneratoren selbst herstellen Häufig intern doch zusammengekaufte Module, die nicht unbedingt über ein einheitliches Datenmodell verfügen Kernlösungsanbieter Administrative Gesamtlösung mit Anbindungsfunktionen von medizinischen Subsystemen Speziallösungsanbieter Hochkompetente Lösungen für Teilbereiche 3

4 8.2 Integrationsaspekte Integration auf 4 verschiedenen Ebenen notwendig: 8.2 Integrationsaspekte Technikintegration Integration auf Ebene der Infrastruktur Technische Erreichbarkeit der Systeme Verfügbarkeit einer Netzinfrastruktur Benutzung gemeinsamer Speichermedien und Datenbanken Datenintegration Integration auf Datenebene Alle Systeme arbeiten mit den selben Daten Eine gemeinsame Datenhaltung oder Jedes System verfügt über eine eigene Kopie der Daten Notwendigkeit von Synchronisations- und Kontrollmechanismen 8.2 Integrationsaspekte Funktionsintegration Integration auf funktionaler Ebene Ein System kann die Funktion eines anderen Systems nutzen Die Funktionen verschiedener Systeme müssen kontextsensitiv zusammenarbeiten können Semantikintegration Integration auf semantischer Ebene Nutzung von kontrollierten Vokabularen Notwendigkeit der Standardisierung der Bezugssysteme Aufgaben Koordiniert die Kommunikation zwischen Anwendungssystemen Wickelt die Kommunikation ab Konvertiert Datenformate Minimiert den Aufwand für die Implementierung und Verwaltung von Kommunikationsbeziehungen in einem heterogenen Informationssystem Minimiert die Anzahl der Schnittstellen zwischen den Anwendungssystemen Minimierung der Schnittstellenanzahl S2 S1 E3 E1 E2 S2 S1 E3 KS E1 E2 Funktionen Unterstützung verschiedener Transportprotokolle zur technischen Kopplung Unterstützung eines asynchronen und synchronen Datenaustausches Unterstützung relevanter Kommunikationsstandards Umcodierung von Inhalten auf Basis von Übersetzungsdefinitionen Versorgung mehrerer Empfänger mit Daten aus einer Quelle (auch inhaltsabhängig) Versorgung eines Empfängers mit Daten aus mehreren Quellen 4

5 Funktionen Zwischenspeicherung von kommunizierten Daten (zur Protokollierung oder Pufferung) Verfügbarkeit eines Data Repositorys für Nachrichtentypen und Kommunikationsbeziehungen Fehlerbehandlung Verschlüsselung Grafischer Netzmonitor zur Überwachung der Kommunikationsbeziehungen Administration des Kommunikationsservers Festlegung von Kommunikationsbeziehungen (wer mit wem?) Festlegung von Datenübertragungsverbindungen (wie?) Festlegung von Syntax und Protokoll der Nachrichtenübertragung (Aufbau und Handshake) Überwachung der Kommunikation Verwaltung des Data Repositories Stichwort: EAI Enterprise Application Integration EAI umfasst die Planung, diemethoden und die Software, um heterogene, autonome Anwendungssysteme ggf. unter Einbeziehung von externen Anwendungssystemen prozessorientiert zu integrieren. EAI ist somit die prozessorientierte Integration von Anwendungssystemen in heterogenen IT- Anwendungsarchitekturen. Im Gegensatz zu anderen Integrationstechniken, wie der Funktionsintegration oder der Datenintegration, werden beim EAI-Ansatz die Implementationen der einzelnen Geschäftsfunktionen nicht verändert. Alle funktionalen Schnittstellen werden mittels Adaptern (Schnittstellenumsetzer) abstrahiert. Aufgaben: Festlegung der Syntax und der Semantik durch Verwendung von Nachrichtentypen Zusätzliche Vereinbarung von organisatorischen und technischen Regeln für die Kommunikation Nachrichtentypen bestehen i.d.r. aus Kopfteil (Header) Inhaltsteil Header: Enthält Angaben zur Logistik Nachrichtennummer Absender Empfänger Zeitstempel (Generierung, Absendung) Bezüge auf vorhergehende Nachrichten Nachrichtentyp Nachrichtentyp steuert, welche Inhalte mit dem nachfolgenden Inhaltsteil übermittelt werden Implementierungsvarianten für den Inhaltsteil: Festes Satzformat Jede übermittelte Nachricht des gleichen Typs ist identisch aufgebaut Segmentbasiertes Satzformat Die verschiedenen Segmenttypen können enthalten sein oder fehlen Sonderzeichen für Beginn eines Segments Variables Satzformat Jede Angabe in der Nachricht beginnt mit ihrem Feldname Mischformen Wiederholungen 5

6 Beispiel für ein festes Satzformat Beispiel für ein Segmentbasiertes Satzformat Beispiel für ein Variables Satzformat Kommunikationsstandards in der Medizin (Health Level 7 ( )) Segmente sind aus Feldern zusammengesetzt Reihenfolge der Felder pro Segment sind festgelegt Reihenfolge der Segmente sind pro Nachrichtentyp festgelegt Segmente und Felder sind durch definierbare Zeichen getrennt Verwendung interner Datentypen (z.b. Adresse) Standard enthält in Vers Nachrichtentypen 150 Segmente 2000 Felder Version 3 basiert auf XML Ereignisse lösen Nachrichten aus Beispiele für Ereignistypen A01: Aufnahme eines Patienten A02: Verlegung eines Patienten A03: Entlassung eines Patienten R01: Fertigstellung eines Befundes Beispiele für Nachrichtentypen ORU: Segmentreihenfolge zur Übermittlung von Ergebnissen (z.b. einem Befund) 6

7 Beispiele für Segmenttypen des Nachrichtentyps ORU MSH: message header segment PID: patient identification segment PV1: patient visit segment ORC: common order segment OBX: observation result segment Beispielnachricht Beispielnachricht Kommunikationsstandards in der Medizin xdt ( ) Seit den 80er Jahren im ambulanten Bereich in Gebrauch Vom Zentralinstitut der Kassenärztlichen Bundesvereinigung definiert und eingeführt ADT: Abrechnungsdatenträger (Ärztl.Leistungen) AODT: Qualitätssicherung ambulantes Operieren BDT: Behandlungsdatenträger (Kommunikation von Praxen) KVDT: Datenaustausch zwischen Arztpraxis und KV LDT: Labordatenträger (Leistungskommunikation mit Labor) GDT: Gerätedatenträger (Ansteuerung medizintechn. Geräte) ODT: Onkologischer Datenträger (Tumordokumentation) xdt Zusammensetzung aus bezeichneten Feldern Z.B. BDT: 3101 (Patientenname), 3102 (Pat.vorname) Diktionärbasierte variable Satzstruktur Überführung in XML ist in Vorbereitung LDT-Satzarten Struktur eines Datenfeldes: Feldteil Länge Bedeutung Länge 3 Bytes Feldlänge in Bytes Kennung 4 Bytes Feldkennung Inhalt variabel Abrechnungsinformationen Ende 2 Bytes ASCII-Wert 13 = CR(Wagenrücklauf) + ASCII-Wert 10 = LF(Zeilenvorschub) 7

8 LDT-Feldlistenauszug Kommunikationsstandards in der Medizin DICOM ( Digital Imaging and Communications in Medicine ( ) offener Standard zum Austausch von digitalen Bildern in der Medizin zur Vernetzung von bildgebenden Verfahren untereinander oder mit Informationssystemen standardisiert sowohl das Format zur Speicherung von Bilddaten, als auch das Kommunikationsprotokoll zum Austausch der Bilder Bereitstellung einer Architektur mit definierten Operationen Hole Bild Speichere Bild Etc. DICOM Hersteller, die DICOM-konforme Medizinprodukte anbieten, müssen ein sog. Conformance Statement für ihre Produkte anbieten Form und Inhalt des Conformance Statements sind ebenfalls in DICOM standardisiert DICOM Beispielnachricht im Internet unter hip.png Kommunikationsstandards in der Medizin VITAL ( Vital Signs Information Representation ( ) Seit 1994 von CEN TC251 entwickelt Standard ENV13734 Zur Vernetzung von medizin-technischen Geräten mit Informationssystemen XML Extensible markup language Standard zur Modellierung von halbstrukturierten Daten in Form einer Baumstruktur vom World Wide Web Consortium (W3C) definiert definiert Regeln für den Aufbau von Dokumenten, die Daten enthalten, die zum Teil einer fest vorgegebenen Struktur entsprechen, teilweise aber auch Elemente beinhalten, die nicht diesem statischen Schema entsprechen. XML als Rahmenkonzept lässt offen, ob und wie ein konkretes XML-Dokument automatisiert verarbeitet werden kann. 8

9 XML XML-Dokumente besitzen einen physischen und einen logischen Aufbau. Der physische Aufbau eines XML-Dokumentes besteht aus Entitäten. Die erste Entität ist die Hauptdatei des XML- Dokuments. Der logische Aufbau eines XML-Dokumentes ist eine Baumstruktur und damit hierarchisch strukturiert. Als Baumknoten gibt es: Elemente Attribute Verarbeitungsanweisungen Text XML - Beispiele XML - Beispiele XML Wohlgeformtheitsregeln: 1. Zeile enthält XML-Version uns Zeichenkodierung Dokument muß genau ein Wurzeldokument haben (hier: Patient) Strukturelemente (tags) dürfen hierarchisch geschachtelt sein Patient Laborwert, Blutdruck Attribute (wie Datum) müssen in einfachen Anführungsstrichen stehen Attribute (wie Datum) dürfen in einem öffnendem tag nur einmal verwendet werden IHE-Initiative Integrating the Healthcare Enterprise Übersichtsvortrag von TimBecker, Universitätsklinikum Schleswig-Holstein 9