Herausforderungen im Forschungsdatenmanagement unter Berücksichtigung medizinischer Standards und Datenschutzanforderungen, OFFIS Institut für Informatik, Oldenburg
2 Ausgangslage: komplexer Abhängigkeiten Patient Studie1: MR Studie2: MR Studie3:US T2 gewichtetes Bild Diffusionsbild Auswertungsergebnis Bild1 Bild1 Berechnete Map Bild 2...n Bild 2...n Laborbuch: Was wie wo
3 Problemstellung im klinischem Alltag Schutz der Patienteninformation Anonymisierung, Pseudonymisierung oder Komplettverschlüsselung der Patientendaten bei Speicherung, Transfer und Weiterverarbeitung Dokumentation Zusammenhänge zwischen Originaldaten und neu erzeugten Informationen dürfen nicht verloren gehen und müssen jederzeit rekonstruierbar sein Unterschiedliche Applikationen Informationen sollen automatisiert und maschinell verarbeitbar sein, auch wenn kein Einblick in die Identifikationsdaten möglich ist
4 Die Sicht der Forscher Schutz der Patienten-/Probandeninformation Sind doch nur Nummern! Und die Liste liegt doch bei mir in der Schublade. Dokumentation Ich habe meinen Verzeichnisbaum im Griff. Unterschiedliche Applikationen Da gibt es doch bestimmt einen Konverter für! Sonst schreib ich mir einen!
5 Warum standardisierte Schnittstellen? B 4 Systeme, 6 Schnittstellen A C B D A 5 Systeme, 10 Schnittstellen C E D
6 Warum standardisierte Schnittstellen? Systeme: Schnittstellen: 6 15 8 28 10 45 20 190 30 435 40 780 50 1225 100 4950 Dies ist unmöglich zu pflegen!
7 Standardisierte Schnittstellen B 4 Systeme, 4 Schnittstellen A D C B 5 Systeme, 5 Schnittstellen A C E D
8 Standards/Interoperabilität nach IEEE Eine koordinierte nachrichtenbasierte Verbindung zwischen zwei IT-Systemen, über die Informationen zwischen Anwendungsprogrammen zuverlässig ausgetauscht und verarbeitet werden können. Die Systeme informieren sich gegenseitig über Ereignisse und Statusänderungen Daten sind eindeutig formatiert, so dass die Empfänger sie korrekt interpretieren können. Software zur Verwaltung der Gesundheitsdaten (KIS, RIS usw.) Nachrichten kommen vollständig und fehlerfrei oder gar nicht an.
9 Interoperabilität Protokoll-Interoperabilität ( Protocol Interoperability ): Fähigkeit eines verteilten Systems, Protokolldateneinheiten (Datenpakete) über das zugrundeliegende Kommunikationssystem auszutauschen. Dienst-Interoperabilität ( Service Interoperability ): Fähigkeit eines verteilten Systems, Untermenge eines verteilten Diensts gemäß einer funktionalen Spezifikation anzubieten Anwendungs-Interoperabilität ( Application Interoperability, auch semantische Interoperabilität genannt): Fähigkeit eines verteilten Systems, eine konsistente Implementierung der Syntax und Semantik der ausgetauschten Daten zu gewährleisten Interop. aus Anwendersicht ( User Perceived Interoperability ): Gegeben, wenn der Anwender mittels des verteilten Systems Informationen austauschen kann
10 Standards im Gesundheitswesen ISO/IEEE 11073 Spezialisiert auf Austausch von Bio- und Signaldaten (z. B. EKG, Blutdruck, Atemfrequenz) Plug-n-Play (wichtig z. B. für bed-side devices in der Intensivmedizin, Infusionspumpen, Beatmungsgeräte, Monitore, usw.) xdt: x-datenträger Standards Datenaustauschformat entwickelt in den 1980ern und eingesetzt vornehmlich in Praxisverwaltungssystemen Für Abrechnungsdaten (ADT), Behandlungsdaten (BDT) usw. (rund zwei Dutzend xdts) Etabliert; wird aber langsam abgelöst durch HL7 und andere Formate CEN-Normen basierend auf UN-Standard EDIFACT Nicht sonderlich erfolgreich (trotz Verabschiedung als offizielle Europäischer Norm) Ausnahmen: Dänemark, Norwegen und Schweden
11 Standards im Gesundheitswesen DICOM: Digital Imaging and Communications in Medicine Kommunikation rund um die medizinische Bildgebung HL7: Health Level Seven Besonders relevant für Datenaustausch zwischen Informationssystemen im Gesundheitswesen Ausnahmen: Dänemark, Norwegen und Schweden DICOM und HL7 sicherlich die wichtigsten Standards im Gesundheitswesen
12 Der DICOM-Standard Weltweit akzeptierter Standard für med. Bildkommunikation Inzwischen über 5000 Seiten technische Dokumentation! (frei verfügbar) Spezifikation von Datenstrukturen und Diensten rund um medizinische Bildkommunikation Netzwerkdienste: Bildübertragung, Datenbankzugriff, Drucken, Workflow- Unterstützung, RIS/PACS-Kopplung Anwendungsprofile für den Austausch von DICOM-Objekten über Datenträger (z. B. Herzkatheterfilme auf CD-R) Weitere Dienste: Strukturierte Befundung, Sicherheit,... Herausgeber: Internationales DICOM-Komitee Hersteller (Modalitäten, PACS, RIS) sowie Anwender: DRG, SFR, ACR, ACC, ESC, CAP,... Verabschiedet als internationaler Standard (ISO und CEN) Greift selbst auf eine Vielzahl weiterer Standards zurück
13 Struktur medizinischer Daten (DICOM) Beispiel: hierarchischer Aufbau medizinischer Bilddaten
14 Der DICOM-Standard Alle denkbaren (Bild)formen möglich Viele sind inklusive Metadaten schon definiert Auch n-dimensionale Daten, Spektroskopie etc Bilder beinhalten Metadaten Aufnahme Parameter Demographische Daten PDF, CDA, MPG etc. auch integriert Strukturierte Berichte sind möglich Workflow Unterstützung Automatisierte Abläufe sind definierbar Dokumentation kann auf alle Daten verlinken Applikation Hosting Erweiterungsschnittstelle für Bildverarbeitungsanwendungen
15 Terminologie: Anonymisiert vs. Pseudonymisiert Anonymisierte Daten sind Daten ohne Personenbezug, sie lassen sich nur mit unverhältnismäßigem Zeit- und Arbeitsaufwand zuordnen Aber folgender Datensatz ist nicht anonym: männlich, 99 Jahre alt, wohnhaft auf der Insel Baltrum. Pseudonymisiert: Persondaten werden entfernt, es existiert ein Verfahren welches die Zuordnung zu der Person wieder ermöglicht Pseudonymisierte Daten sind Personenbezogene Daten und sind nach den meisten Datenschutzgesetzen formal juristisch der Nutzung von Klartextdaten gleichgestellt.
16 Beispiel Detailfrage: Standardkonforme UID DICOM UID besteht aus: Prefix: 1.3.12.2.1107.= Siemens 1.3.46.670589. = Phillips und vom Anwender eindeutig zur haltendes Postfix xxx.11.0.4.1996051510410006 Gerät / Seriennummer DICOM UID lassen die Herkunft der Bilder erkennen. Auch die UIDs müssten pseudonymisiert werden! Hierfür wird gibt es Hashverfahren, welches Verschlüsselte UID auf einen UID konformen Zeichenraum abbildet
17 Forderung für Forschungsdatenbanken Jede Lösung muss gleichzeitig nachfolgende Voraussetzungen erfüllen Auf Standards (DICOM, HL7) basierende Anwendungen Schnellen Zugriff auf große Datenmengen Integration in standardisierten klinischen Workflow (IHE) Datenschutzproblematik Hohe Nutzerfreundlichkeit und schnelle Bedienbarkeit Keine allgemeine Lösung für die Forschungsdatenbanken vorhanden. Standards können aber helfen.
18 Ausblick: DICOM Application Hosting Idee: Standardisierte Erweiterungsschnittstelle für Bildverarbeitungsanwendungen Zwischen Workstation-Software und Zusatz-Software Umsetzung in DICOM: Application Hosting Erweiterung des DICOM-Standards (DICOM Supplement 118) Beschreibt API (Application Programming Interface) zwischen Hosting System (Workstation) und Erweiterung ( Plugin, oder Hosted Application ) Herstellerunabhängigkeit Dasselbe Plugin läuft auf unverändert auf Workstations verschiedener Hersteller Voraussetzung: Unterstützung für Application Hosting Schnittstelle 11. Juni 2010
19 DICOM eine partielle Lösung? Wird in der Forschung nicht genutzt, weil? Software unterstützt es nicht. Datenschutz? Einstiegshürde, zu komplex? Tools für die Eingabe fehlen. Ist ja kein XML Format? Freie DICOM Bildarchive gibt es, inkl. Webzugriff
20 Semantik Befunde / Laborbücher Domänen-spezifische Terminologie CAD= coronary artery disease LV= left ventricular Normalerweise werden Medizinische Dokumente in Prosa aufgeschrieben Unklare Ausdrücke Numerische Werte und Einheiten
21 Semantik Formulare Ein großer Anteil strukturierter Informationen Keine Möglichkeit sie zu verarbeiten
22 Was ist gewünscht? Klare, eindeutige Aussagen Vergleich von Datensätzen Entscheidungsunterstützung Generierung von Alarmen Steuerung eines Workflows Auswahl der passenden medizinischen Leitlinie Extraktion von Daten für Forschung Data mining Ideal wären strukturierte und maschinenverarbeitbare Inhalte!
23 Das semantische Dreieck Menschen kommunizieren durch den Austausch von Symbolen (code) Symbole repräsentieren nie das Objekt (object) selbst, sondern immer nur eine Vorstellung des Objekts (concept) Liste von Konzepten für eine bestimmte Domäne zusammen mit maschinen-lesbaren Codes: Kontrolliertes Vokabular
24 Beispiel: ENV 13606-2 Terme für Überschriften Eindeutiger Code Menschenlesbarer Name Definition des Konzepts
25 Beispiel: DICOM Content Mapping Ressource Codes für EKG Kanäle Quell-Vokabular Eindeutiger Code Menschenlesbarer Name des Konzepts
26 Beispiel: SNOMED-CT Code für Bronchopneumonia Eindeutiger Code Menschenlesbarer Name Mehrere Synonyme Relation Eltern-Konzept Menschenlesbarer Name
27 Der kodierte Bericht Natürlich sprachlicher Ausgangsbericht Repräsentation in DICOM SR Ein Graph mit 7 Knoten und 7 Links 1 Block mit Menschenlesbarem Text 1 Nummer 13 maschinenlesbare Codes Maschinenverarbeitbare Dokumente Sind wesentlich aufwändiger zu erstellen Ärzte haben keinen unmittelbaren Nutzen von strukturierten Berichten
28 Beispiel eines SINR-Dokuments (dsrdump) Basic Text SR Document Patient : MEDICAL INSIGHT^SWF (O, 20080407, #20080407) Referring Physician: RSNA^IHE Manufacturer : Medical-Insight A/S Completion Flag : PARTIAL Verification Flag : UNVERIFIED Content Date/Time : 20080407 160422 <CONTAINER:(11528-7,LN,"Radiology Report")=SEPARATE> <has concept mod CODE:(121049,DCM,"Language of Content Item and Descendants") = (eng,iso639_2,"english")> <has obs context CODE:(121005,DCM,"Observer Type")=(121006,DCM,"Person")> <has obs context PNAME:(121008,DCM,"Person Observer Name")="Get the observers name"> <contains CONTAINER:(121060,DCM,"History")=SEPARATE> <contains TEXT:(121060,DCM,"History")="The patient showed severe signs of lung problems..."> <contains CONTAINER:(121070,DCM,"Findings")=SEPARATE> <contains TEXT:(121071,DCM,"Finding")="The x-ray feature have some characteristics of viral infection."> <inferred from IMAGE:(121080,DCM,"Best illustration of finding")=(ct image,)> <contains CONTAINER:(121076,DCM,"Conclusions")=SEPARATE> <contains TEXT:(121077,DCM,"Conclusion")="Looking at the x-ray it is clear that this is caused by influenza type XYZ.">
29 Beispiel eines SINR-Dokuments (HTML)
30 Benutzerakzeptanz Kann nur erreicht werden, wenn Die Benutzer einen Nutzen von der Kodierung haben Das Kodieren soweit wie möglich automatisiert ist Templates Automatisiertes retrieval der codes Präsentation der wichtigsten Codes Repräsentation einer menschenlesbaren Version des Reports Bislang ungelöstes Problem CDA / DICOM SR unterstützt menschenlesbaren und kodierten Report in einem Dokument
31 EHRcom ADL Beispiel: Blutdruck
32 Schematron Skript: CDA Medical Summary
33 DICOM SR Template: Measurement
34 Es gibt genug Standards im Gesundheitswesen, ist es damit getan? Nein, denn es gibt zu viele und zu flexible Standards! Welchen Standard wählen, wenn sich mehrere anbieten? Ein einzelner Standard ist flexibel. Welche Optionen wählen? Oft mehrere Wege möglich, ein Problem zu lösen Viele Datenfelder optional, jedoch für bestimmte Arbeitsabläufe notwendig Standard bietet Bausteine (z. B. anhand von Netzwerkdiensten, Datenstrukturen), nicht komplette Lösungsstrategien für komplexe Probleme
35 Es gibt genug Standards im Gesundheitswesen, ist es damit getan? Viele Arbeitsabläufe nicht durch einzelnen Standard abgedeckt: Wie greifen Standards ineinander? Z. B. kompletter Arbeitsablauf für die Radiologie: Aufnahme von Patienten, Erstellen eines Auftrags, Daten zur Modalität bringen, Bilder erstellen und im Archiv sichern, RIS informieren über durchgeführte Untersuchungen, Bilder aus Archiv laden und befunden, Befunde ablegen, Regelungen für Notfallpatienten (Name nicht bekannt), und viele Schritte mehr! Lösung: Der IHE weg!
36 IHE Ansatz: Für spezifisches Problem Standards auswählen und ggf. einschränken Dreiteiliger Ansatz von IHE (Integrating the Healthcare Enterprise) 1. Spezifikation eines Technical Framework Beschreibt die wichtigsten klinischen Anwendungsfälle in medizinischen Institutionen Schnittstellen zwischen beteiligten IT-Systemen werden auf der Basis von HL7, DICOM und einigen weiteren Standards präzise beschrieben Unterteilt in zehn allgemeine Bereiche, darunter weiter in so genannte Integrationsprofile Frei verfügbar unter http://www.ihe.net 2. Durchführung von Connect-a-thons Als Testplattform für Interoperabilitäts-Tests aller Hersteller In den USA, Europa und Japan (jeweils 1x jährlich) 3. Durchführung von öffentlichen Demonstrationen Deutscher Röntgenkongress, Hôpital Expo Intermedica,
37 IHE: Was ist IHE? IHE = Integrating the Healthcare Enterprise IHE ist kein Produkt, keine Firma, keine Standardisierungs- oder Zertifizierungseinrichtung, sondern eine Initiative von Anwendern, Industrie und Wissenschaft Ziel: Verbesserung des technischen Datenaustausches von IT-Systemen im Gesundheitswesen (RIS, PACS, Modalitäten...) Konsequenter Einsatz von Standards: DICOM, HL7, CCOW,... Gegründet in den USA 1998 durch RSNA und HIMSS, inzwischen eine internationale Initiative: IHE Europe, IHE Japan IHE-Deutschland Kick-off Meeting 2001, Träger sind dt. Röntgengesellschaft (DRG) und der Fachverband Elektromedizinische Technik im ZVEI e.v. Ziel: Verankerung europäischer und deutscher Bedingungen in den internationalen Konzepten Seit 2004 neue Organisationsform: IHE-Deutschland e.v.
38 Beispiel: IHE Scheduled Workflow KIS Patienten- Registrierung ADT Registrierung der Daten HL7 ADT Arbeitsplatz Image Display / Image Creator PACS Anforderung der Untersuchung Order Placer Bilddarstellung DICOM Q/R Untersuchungsanforderung HL7 ORM Bildarchiv Image Manager / Archive Abteilungssystem Order Filler / PPS-Manager Vorgesehene Untersuchungen HL7 ORM Bestätigung DICOM Storage Commit Archivierung DICOM Store RIS Abgeschlossene Untersuchungen DICOM MPPS Arbeitsliste für die Modalität Modality Worklist Modalität Modality
39 Vielen Dank für Ihre Aufmerksamkeit
40 UID Management von Forschungsdatensätzen Integration von Kontrollnummernbasierter ID Erzeugung in den Pseudonymisierung Prozess Verschlüsselte Hashwerte der Patienten identifizierende Daten Erzeugung von eindeutigen Forschungsgruppenweiten IDs (UID) Adaption von Projektergebnisse Artemis und @neurist DICOM UID sind oft nicht ausreichend pseudonymisiert Erstellung pseudonymisierter, reproduzierbarer, standardkonformer UID zur Verlinkung von Daten untereinander
41 Typen von kontrolliertem Vokabular I Kontrolliertes Vokabular Liste von Termen, die eindeutig identifiziert werden Werden normalerweise durch eine zentrale Instanz verwaltet Alle Terme sollten eindeutig sein Kann ein Term in einem anderen Kontext ein anderes Konzept bezeichnen, muss er weiterqualifiziert werden. Bezeichnen mehrere Terme das gleiche Konzept, muss der bevorzugte gefunden und die anderen als optionale Synonyme gekennzeichnet werden. Taxonomie / Klassifizierung Sammlung von Termen in einer hierarchischen Struktur
42 Typen von kontrolliertem Vokabular II Thesaurus Vernetzt Elemente von Taxonomien untereinander mit Relationen Formale Ontologie Kontrolliertes Vokabular ausgedrückt in einer ontology representation language (z.b. OWL) Explizite formale Spezifikation einer Konzeptualisierung Regeln beschreiben den Zusammenhang der Daten
43 IHE und Cross-Enterprise Sharing Integrating the Healthcare Enterprises (IHE): definiert Workflows innerhalb Kliniken und hat den Fokus auf die Nutzung existierender Standards (DICOM und HL7) Aktuell erweitert die IHE ihren Fokus auf den Sektor des Cross-Enterprise Dokumenten Austausches (XDS), inklusive Dokumente mit Bildanhängen (XDS-I) Cross-Enterprise User Authentication (XUA) und Patient identifier crossreferencing (PIX) liegen vor IHE Clinical Trial Profile Grundsätzlich gehen die IHE Profile von einem gemeinsamen Rechtsrahmen aus, kommunizierende Partner haben Patienteneinwilligungen und gemeinsame Policies, die diese Zugriffe im Vorfeld erlauben.
44 Cross-Enterprise Sharing und Forschungsumgebungen IHE Rechte Konzept ist nicht global umsetzbar In idealer Grid-Umgebung ist der Rechenknoten unbekannt Keine Vertragsbindung zwischen Arzt und Betreiber Admin / Nutzer könnten auf Klartextdaten zugreifen Globale Einverständniserklärung für die Nutzung auf fremden Rechner nicht realisierbar Daten müssen Pseudonymisiert / Verschlüsselt werden Applikationen müssen auf verschlüsselte Daten arbeiten Reintegration in med. Dokumentation muss gewährleistet sein
45 Fazit Es gibt standardisierte Schnittstellen für Bildformate Metadaten Workflows Warum diese einsetzen? Nachhaltigkeit Portabilität Zwischenlösung: Zumindest einen Im-/Exportfilter für das eigene System erstellen für die Integration innerhalb DICOM, HL7, IHE Profilen
46 Beispiel: Typisches Krankenhaus-Szenario RIS/KIS Bildarchiv PACS Bildgebende Verfahren Telemedizin Bildausgabe / Hardcopy Befundungsarbeitsplatz
47 Beispiel: Typisches Forschungsszenario
48 Beispiel: Typisches Krankenhaus-Szenario Netzwerkstrukturen Do-Par Do-Gri Do-Kli / DMZ Do-Kli Do-Abt Modalität Klinischer Arbeitsplatz Offener Cluster Steuerrechner Proxy Forschung AP Partner Lokales PACS Interner Cluster Klinik PACS Forschung PACS Grid-Cluster