Die digitale medizinische Bildgebung im Gesundheitsbereich ist heutzutage zu einem grundlegenden Werkzeug für medizinische Diagnosen geworden. Es ist wichtig, Gesundheitsdaten mit größter Sorgfalt zu behandeln, denn sie stellen ein zentrales Thema dar. Zu diesem Zweck ist die Anonymisierung dieser Dateien der einfachste, aber auch der sicherste Lösungsansatz, um personenbezogenen Datenschutz zu ermöglichen. Dennoch gibt es einige Nuancen, die bei der Anonymisierung von DICOM-Dateien zu beachten sind.
Bilder nach DICOM-Standard
„Digital Imaging and Communications in Medicine (DICOM) wurde entwickelt, um medizinische Bilddaten zu standardisieren und einfach zwischen Computersystemen auszutauschen. Derzeit ist es der weltweite Standard für die Verwendung, Speicherung, den Druck und die Datenübertragung in der medizinischen Bildgebung. Ein DICOM-Bild besteht aus einem sogenannten DICOM-Header und dem sichtbaren Bild. Der DICOM-Header speichert Bilder und Angaben von Patienten, die u. a. Patienten-, Studien- und Institutionsdaten enthalten können.“
DICOM-Bilder anonymisieren für den Austausch und die Übertragung medizinischer Bilder
„Der Großteil der Gemeinschaft im Bereich der medizinischen Bildgebung wendet heute das DICOM-Dateiformat an, nicht nur für die klinische Praxis, sondern auch für die klinische Forschung, wodurch sich die Möglichkeit einer gemeinsamen Nutzung oder eines Datenaustauschs ergibt. Allerdings erfordert die Weitergabe vertraulicher medizinischer Bilddaten an Dritte den Schutz der Daten selbst, um die Datensicherheit und die Privatsphäre der Patienten zu gewährleisten“.1
Bei der Anonymisierung handelt es sich um einen Verarbeitungsvorgang, der darin besteht, eine Reihe von Techniken so zu verwenden, dass es praktisch unmöglich ist, eine Person mit irgendwelchen Mitteln und auf unumkehrbare Weise zu identifizieren. Es gibt aber Ausnahmen von dieser Unumkehrbarkeit: zum Beispiel im Rahmen der klinischen Forschung.
Die Problematik liegt in der Anonymisierung unter Wahrung der Werthaltigkeit des DICOM-Datensatzes.
Unter De-Identifizierung wird im DICOM der Schutz vertraulicher Attribute durch Löschung oder Verschlüsselung verstanden. Die Re-Identifizierung wird als der umgekehrte Vorgang der „schützenden Entfernung“ verstanden. Diese Definition ist jedoch nicht perfekt: Eine Re-Identifizierung wird nicht immer möglich sein, wenn die ursprünglichen Daten gelöscht oder bereinigt worden sind.
Es wird daher angestrebt, ein Gleichgewicht zwischen Anonymisierung, Pseudonymisierung, De- und Re-Identifizierung von DICOM herzustellen.
Selbstverständlich müssen wir nicht einfach vertrauliche Informationen wie Patientenidentifikation, Studiendaten usw. entfernen, sondern wir müssen auch vorsichtig mit den Informationen umgehen, die wir sammeln. Bestimmte Attribute sind erforderlich, und daher würde ihre Entfernung dazu führen, dass DICOM unbrauchbar wird.
DICOM - Die Datenelementtypen
| Type 1 | Er ist in der SOP-Instanz (Service Object Pair) erforderlich und muss einen gültigen Wert haben |
| Type 2 | Sie wird in der SOP-Instanz benötigt, kann aber den Wert „unbekannt“ oder einen Wert der Länge 0 enthalten |
| Type 3 | Fakultativ. Darf oder darf nicht eingeschlossen werden und kann einen Wert der Länge 0 enthalten |
| Type 1C | Bedingt. Wenn eine Bedingung erfüllt ist, dann ist sie vom Typ 1 (obligatorisch, kann nicht null sein). Wenn die Bedingung nicht erfüllt ist, dann wird das Tag nicht gesendet |
| Type 2C | Bedingt. Wenn die Bedingung erfüllt ist, handelt es sich um einen Typ 2 (erforderlich, Länge 0 ist OK). Wenn die Bedingung nicht erfüllt ist, wird der Tag nicht gesendet |
Aus dieser Tabelle geht hervor, um welche Datenelementtypen es sich handelt und wie sie verarbeitet werden.
SOP: Service Object Pair. Es geht um die Kombination eines „Information Object“ (z.B. ein Bild) mit einem „Service“ (z.B. der Druck dieses Bildes). Es werden somit in den SOP-Klassen die Typen der auszuführenden Dienste und die Informationen, die die DICOM-Dateien enthalten sollen, definiert. Beispiel eines Tags: 0010,0010. Falls die Bedingung nicht erfüllt ist, wird das Tag nicht in der DICOM-Metadatendatei gesendet.
Wie soll mit den „erforderlichen Attributen“ von DICOM Typ 1 umgegangen werden?
Wir haben es schon einmal gesehen: Für die Gültigkeit des DICOM muss ein „erforderliches Attribut“ zwar vorhanden sein, aber in etwas Nichtssagendes umgewandelt werden, das nichts mit dem ursprünglichen Identifikationswert zu tun hat (diese Anonymisierung mit Pseudo-Werten wird Pseudonymisierung genannt).
In Teil PS3.15 des DICOM-Standards2, der vor einigen Jahren veröffentlicht wurde, wurden bestehende Datenverschlüsselungstechniken für die Verwendung mit DICOM-Daten definiert.
Diese Techniken dienen drei wichtigen Zwecken: Datenverschlüsselung, Überprüfung der Datenherkunft und Überprüfung der Datenintegrität.
Das Attribute Confidentiality Profile (DICOM PS 3.15: Appendix E) stellt einen Standard für die De-Identifizierung von Bildern zur Verfügung, der die Komplexität der sicheren De-Identifizierung von DICOM-Bilddaten reduziert und gleichzeitig die Flexibilität zur Erhaltung bestimmter Informationen beibehält. Die Datenschutzprofile enthalten ein Basisprofil sowie einige optionale Profile. Sie bieten Anweisungen zur sicheren Bereinigung von DICOM-Elementen, die personenbezogene Daten enthalten können.
Das Grundprofil (Basic Application Level Confidentiality Profile) ist ein äußerst vorsichtiger Ansatz, der alle vertraulichen Daten in Bezug auf die folgenden Attribute verbirgt:
- Die Identität und Demographie des Patienten (z.B. Name des Patienten - 0010,0010, Alter des Patienten - 0010,1010, Geburtsdatum - 0010,0030),
- Die Identität der verantwortlichen Parteien oder Familienmitglieder (z.B. Name der Organisation des Beobachters - 121009),
- Die Identität des an dem Verfahren beteiligten Personals (z.B. Name des menschlichen Akteurs - 0040.4037),
- Die Identität der am Antrag oder an der Durchführung des Verfahrens beteiligten Organisationen (z.B. die ersuchende Dienststelle - 0032,1033)
- Alles, was zu den Beispielen passen könnte, wenn man ihnen Zugang zu den Originalen gewähren würde, wie z.B. UIDs, Datum und Uhrzeit;
- Private Attribute
Zur Anwendung dieses Profils müssen Sie mindestens die in der folgenden Tabelle aufgeführten Attribute nehmen, ihren ursprünglichen Wert mit einem Standard verschlüsseln (Verschlüsselungsalgorithmen wie RSA, AES und Triple-DES5 werden vom DICOM-Standard für die Konvertierung von DICOM-Originaldaten in ein geschütztes Format akzeptiert) und das Ergebnis der Verschlüsselung in der geänderten Attributfolge speichern, wobei die Werte an ihrem ursprünglichen Speicherort durch falsche und unbedeutende Werte ersetzt werden. Beispielsweise könnten wir WERNER^FELIX durch 7WNDAB^TALTH ersetzen, es im Attribut Patientenname (0010,0010) speichern und der ursprüngliche Wert von WERNER^FELIX würde verschlüsselt und dann in eine Attributsequenz gesetzt.
| Attribute Name | Tag | Attribute name | Tag |
| Instance Creator UID | (0008,0014) | Other Patient Ids | (0010,1000) |
| SOP Instance UID | (0008,0018) | Other Patient Names | (0010,1001) |
| Accession Number | (0008,0050) | Patient's Age | (0010,1010) |
| Institution Name | (0008,0080) | Patient's Size | (0010,1020) |
| Institution Address | (0008,0081) | Patient's Weight | (0010,1030) |
| Referring Physician's Name | (0008,0090) | Medical Record Locator | (0010,1090) |
| Referring Physician's Address | (0008,0092) | Ethnic Group | (0010,2160) |
| Referring Physician's Telephone numbers | (0008,0094) | Occupation | (0010,2180) |
| Station Name | (0008,1010) | Additional Patient's History | (0010,21B0) |
| Study Description | (0008,1030) | Patient Comments | (0010,4000) |
| Series Description | (0008,103E) | Device Serial Number | (0018,1000) |
| Institutional Department name | (0008,1040) | Protocol Name | (0018,1030) |
| Physician(s) of Record | (0008,1048) | Study Instance UID | (0020,000D) |
| Performing Physicians' Name | (0008,1050) | Series Instance UID | (0020,000E) |
| Name of Physician(s) Reading study | (0008,1060) | Study ID | (0020,0010) |
| Operator's Name | (0008,1070) | Frame of Reference UID | (0020,0052) |
| Admitting Diagnoses Description | (0008,1080) | Synchronization Frame of Reference UID | (0020,0200) |
| Referenced SOP Instance UID | (0008,1155) | Image Comments | (0020,4000) |
| Derivation Description | (0008,2111) | Request Attributes Sequence | (0040,0275) |
| Patient's Name | (0010,0010) | UID | (0040,A124) |
| Patient ID | (0010,0020) | Content Sequence | (0040,A730) |
| Patient's Birth Date | (0010,0030) | Storage Media File-set UID | (0088,0140) |
| Patient's Birth Time | (0010,0032) | Referenced Frame of Reference UID | (3006,0024) |
| Patient's Sex | (0010,0040) | Related Frame of Reference UID | (3006,00C2) |
Zusätzlich zum „Basic Application Level Confidentiality Profile“ hat das DICOM-Komitee „Basic Application Level Confidentiality Options“ veröffentlicht:
Die verschiedenen Optionen sind so definiert, dass sie auf das „Basic Application Level Confidentiality Profile“ angewendet werden können. Einige dieser Optionen erfordern die Löschung zusätzlicher Informationen, und andere erfordern die Aufbewahrung von Informationen, die sonst gelöscht würden.
Nachfolgend ist eine Liste von Optionen aufgeführt, bei denen zusätzliche Informationen gelöscht werden müssen:
- Option zur Bereinigung von Pixeldaten
- Option zur Bereinigung klarer und erkennbarer visueller Merkmale
- Option zur Bereinigung von Bildern
- Option zur Bereinigung strukturierter Inhalte
- Option zur Bereinigung von Deskriptoren
Die folgende Liste enthält Optionen, die die Aufbewahrung von Informationen erfordern, die andernfalls entfernt würden, die aber für bestimmte Zwecke benötigt werden:
- Option zur Beibehaltung der Längs-Zeitinformation mit vollständigen Daten
- Option zur Beibehaltung der Längs-Zeitinformation mit geänderten Daten
- Option zur Beibehaltung von Patientenmerkmalen
- Option zur Beibehaltung der Geräteidentität
- Option zur Beibehaltung der Identität der Institution
- Option zur Beibehaltung von UIDs (Benutzerkennung)
- Option zur Beibehaltung der privaten Sicherheit
Um sicherzugehen, dass Sie bei der Anonymisierung/Pseudonymisierung Ihrer DICOMs weltweit konform sind, empfiehlt IMAIOS, die Empfehlungen des DICOM standards Committee zu befolgen.
Ein Artikel wird später ausführlich erörtern, wie die Anonymisierung von DICOMs am Beispiel des IMAIOS-Verfahrens erfolgen kann.
1 Kadek Y. E. Aryanto, André Broekema, Matthijs Oudkerk, Peter M. A. van Ooijen (2012) Implementation of an anonymisation tool for clinical trials using a clinical trial processor integrated with an existing trial patient data information system
2 http://dicom.nema.org/medical/dicom/current/output/html/part15.html
3 RSA stands for the public key algorithm named after its inventors (Rivest-Shamir-Adleman); AES for Advanced Encryption Standard, and DES for Data Encryption Standard. Triple-DES applies DES three times for stronger encryption - Oleg S. Pianykh (2011) DICOM Security