Herausforderungen im
Forschungsdatenmanagement unter
Berücksichtigung medizinischer Standards und Datenschutzanforderungen
Andreas Thiel, OFFIS Institut für Informatik, Oldenburg
2 Ausgangslage: komplexer Abhängigkeiten
Laborbuch:
Was wie wo
Patient
Studie1: MR Studie2: MR Studie3:US
T2 gewichtetes Bild Diffusionsbild
Bild1
Bild 2...n
Bild1
Bild 2...n
Auswertungsergebnis
Berechnete Map
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?
C B
A
4 Systeme, 6 Schnittstellen
D
C A
5 Systeme,
10 Schnittstellen
B
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
C B
A
4 Systeme, 4 Schnittstellen
D
A C
5 Systeme,
5 Schnittstellen
B
8
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
Standards/Interoperabilität nach IEEE
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 18
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“)
Ausblick: DICOM Application Hosting
► Herstellerunabhängigkeit
► Dasselbe Plugin läuft auf unverändert auf Workstations verschiedener Hersteller
► Voraussetzung: Unterstützung für Application Hosting Schnittstelle
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
Normalerweise werden Medizinische Dokumente in „Prosa“ aufgeschrieben
Domänen-spezifische Terminologie CAD=„coronary artery disease“
LV=„left ventricular“
Numerische Werte und Einheiten Unklare Ausdrücke
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
Menschenlesbarer Name
Mehrere Synonyme
Eltern-Konzept Relation
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
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
38 Beispiel: IHE Scheduled Workflow
Patienten- Registrierung
ADT
Anforderung der Untersuchung
Order Placer
Abteilungssystem Order Filler / PPS-Manager
Bildarchiv Image Manager /
Archive Arbeitsplatz Image Display /
Image Creator
Arbeitsliste für die Modalität Modality Worklist
Vorgesehene Untersuchungen HL7 ORM
Archivierung DICOM Store Untersuchungsanforderung
HL7 ORM
Bilddarstellung DICOM Q/R
Bestätigung DICOM Storage Commit
Abgeschlossene Untersuchungen
DICOM MPPS Modalität
Modality KIS
RIS
PACS
Registrierung der Daten HL7 ADT
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
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 cross- referencing (PIX) liegen vor
IHE Clinical Trial Profile
Grundsätzlich gehen die IHE – Profile von einem gemeinsamen
Rechtsrahmen aus, kommunizierende Partner haben Patienteneinwilligungen
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
46 Beispiel: Typisches Krankenhaus-Szenario
Telemedizin
Befundungsarbeitsplatz Bildausgabe / Hardcopy
Bildarchiv PACS
Bildgebende Verfahren
RIS/KIS
47 Beispiel: Typisches Forschungsszenario
48 Beispiel: Typisches Krankenhaus-Szenario
Netzwerkstrukturen
Do-ParDo-GriDo-Kli / DMZDo-KliDo-Abt
Steuerrechner Lokales PACS
Proxy
Klinik PACS Klinischer
Arbeitsplatz
Interner Cluster Forschung PACS Forschung AP
Grid-Cluster Offener Cluster
Partner Modalität
