Medizinische Bilder über die Cloud Healthcare API de-identifizieren

Einführung

In diesem Dokument wird beschrieben, wie Forscher, Data Scientists, IT-Teams und Organisationen im Gesundheitswesen und den Biowissenschaften die Cloud Healthcare API verwenden können, um personenidentifizierbare Informationen (Personally Identifying information – PII) und geschützte Gesundheitsdaten (Protected Health Information – PHI) aus DICOM-Daten (Digital Imaging and Communications in Medicine) zu entfernen. Dieser Prozess, der als De-Identifikation bezeichnet wird, trägt dazu bei, den Datenschutz für Patienten zu gewährleisten und DICOM-Daten für die Forschung, Datenfreigabe und maschinelles Lernen vorzubereiten.

In der zugehörigen Anleitung Cloud Healthcare API zum De-Identifizieren medizinischer Bilder verwenden werden Sie durch zwei Anwendungsfälle der De-Identifikation von medizinischen Bilddaten mithilfe der Cloud Healthcare API geführt.

Funktionsweise der De-Identifikation von DICOM-Daten

Für klinische Zwecke aufgenommene medizinische Bilder können wichtige sekundäre Verwendungszwecke in Forschungsprojekten und Teaching Libraries haben. Möglicherweise müssen Sie jedoch vertrauliche Datenelemente (PII oder PHI) aus DICOM-Bildern entfernen oder ändern, bevor Sie sie analysieren oder für autorisierte Mitbearbeiter freigeben.

Das folgende Diagramm zeigt mehrere Pipelines von medizinischen Bildern aus lokalen Quellen, die an Google Cloud weitergeleitet und dann durch den De-Identifikationsvorgang der Cloud Healthcare API anonymisiert werden.

Pipeline für die DICOM-De-Identifikation

Laden Sie zuerst DICOM-formatierte medizinische Bilder in Cloud Storage und dann in die Cloud Healthcare API hoch. Alternativ können Sie DICOM-Bilder direkt in die Cloud Healthcare API hochladen. Die medizinischen Bilder, die in einem DICOM-Speicher in der Cloud Healthcare API gespeichert sind, werden dann durch den De-Identifikationsprozess der Cloud Healthcare API weitergeleitet, um die Bilder und die zugehörigen Metadaten zu anonymisieren.

Als medizinischer Forscher haben Sie beispielsweise Zugriff auf Röntgenaufnahmen von Wirbelfrakturen der Patienten in einem lokalen Bildarchivierungs- und Kommunikationssystem (picture archiving and communication system, PACS). Sie können die Bildpixeldaten mithilfe des Storage Transfer Service, der Transfer Appliance oder eines der Produkte für Hybridkonnektivität nach Cloud Storage verschieben. Anschließend können Sie die Daten aus Cloud Storage in die Cloud Healthcare API kopieren oder verschieben. Nachdem sich die Daten in der Cloud Healthcare API befinden, können Sie sie als Sicherung verwenden, aus der Ferne aufrufen oder den Zugriff für genehmigte Clouddienste und -anwendungen von Drittanbietern zulassen.

In einem anderen Szenario ist es vorstellbar, dass Sie de-identifizierte DICOM-Bilder an AutoML Vision senden, um ein Modell zu trainieren, das Teams im Gesundheitswesen dabei hilft, Wirbelfrakturen in Röntgenaufnahmen zu erkennen. So können Sie mithilfe Ihrer eigenen Daten ein Tool zur Unterstützung bei der Entscheidungsfindung erstellen.

Cloud Healthcare API

Die Cloud Healthcare API bietet eine verwaltete Lösung zum Speichern und Abrufen von Gesundheitsdaten in Google Cloud und stellt eine wichtige Brücke zwischen bestehenden Versorgungssystemen und Anwendungen dar, die in Google Cloud gehostet werden.

Innerhalb eines Google Cloud-Projekts werden über die Cloud Healthcare API aufgenommene Daten in einem Dataset gespeichert, das sich an einem geografischen Standort befindet, der einer Google Cloud-Region entspricht. Die Cloud Healthcare API unterstützt die unter Regionen aufgeführten Regionen. Eine Liste der Google Cloud-Produkte und der Regionen, in denen sie implementiert sind, finden Sie unter Cloud-Standorte.

Da jede Modalität von Gesundheitsdaten – etwa DICOM, Fast Healthcare Interoperability Resources (FHIR) und HL7v2 – unterschiedliche strukturelle und Verarbeitungsmerkmale hat, werden Datasets in modalitätsspezifische Speicher unterteilt.

Das folgende Diagramm zeigt, wie die Cloud Healthcare API die Daten nach Standort, Dataset und Speicher organisiert.

Organisation medizinischer Daten in der Cloud Healthcare API

Jedes Dataset enthält einen oder mehrere Speicher, die je nach Anwendung die gleiche oder mehrere Modalitäten verarbeiten. Die Verwendung mehrerer Speicher in demselben Dataset kann sinnvoll sein, wenn eine Anwendung verschiedene Datentypen verarbeitet. Sie können die Daten beispielsweise nach ihrem Ursprung unterteilen, also nach einzelnen Krankenhäusern, Kliniken oder Abteilungen. Eine Anwendung kann ohne Leistungseinbußen auf beliebig viele Datasets oder Speicher zugreifen. Es ist wichtig, die gesamte Dataset- und Speicherarchitektur so zu gestalten, dass sie die allgemeinen Ziele Ihrer Organisation erfüllt, z. B. die Nähe zu Rechenressourcen oder Endnutzern, Partitionierung oder Zugriffssteuerung.

Das folgende Diagramm zeigt zwei Datasets mit HL7v2-, DICOM- und FHIR-Speichern.

Architektur von Datasets mit HL7v2- und DICOM-Speichern

Sie können DICOM-Bilder aus verschiedenen Quellen in einen DICOM-Speicher oder mehrere Speicher innerhalb eines Datasets kopieren. Weitere Informationen finden Sie unter DICOM-Speicher erstellen und verwalten.

DICOM-Daten de-identifizieren

Die Cloud Healthcare API enthält De-Identifikationstools, mit denen vertrauliche Inhalte gemäß der angegebenen Konfiguration skalierbar entfernt oder geändert werden können.

Diese Tools können mit Text und Bildern verwendet werden, die in bestimmten Krankenaktenformaten wie DICOM und FHIR codiert sind. Wenn Sie mit DICOM-Instanzen arbeiten, sind die Komponenten eines API-Aufrufs zur De-Identifikation so:

  • Quelle: Ein Dataset oder DICOM-Speicher, der eine oder mehrere DICOM-Instanzen mit sensiblen Daten enthält. In der zugehörigen Anleitung wird ein Dataset verwendet. Sie können die Beispiele jedoch so ändern, dass sie mit einem einzelnen DICOM-Speicher funktionieren.
  • Zu de-identifizierende Elemente:Konfigurationsparameter, die angeben, wie das Dataset verarbeitet werden soll. Sie können den DICOM-De-Identifikationsvorgang so konfigurieren, dass sie die Metadaten der DICOM-Instanz de-identifizieren, indem Sie Tag-Keywords verwenden, entweder den eingebrannten Text in DICOM-Bildern oder beides beibehalten.
  • Ziel: Die De-Identifikation wirkt sich nicht auf das ursprüngliche Dataset oder seine Daten aus. Stattdessen werden verarbeitete Kopien der ursprünglichen Daten in ein neues Dataset oder einen neuen DICOM-Speicher geschrieben, der als Ziel bezeichnet wird. In der zugehörigen Anleitung wird ein Dataset verwendet. Sie können die Beispiele jedoch ändern, um mit einem DICOM-Speicher zu arbeiten.

Die folgenden beiden Abbildungen zeigen ein Beispiel für eine Röntgenaufnahme vor und nach der De-Identifikation, bei der alle mit dem Bild verknüpften Metadaten und sämtlicher eingebrannte Text entfernt oder geändert werden sollen.

Das erste Bild zeigt eine Röntgenaufnahme mit PII- und PHI-Beispieldaten, die sowohl in Metadaten als auch eingebranntem Text erscheinen.

Beispiel-Röntgenaufnahme vor der De-Identifikation (mit Beispieldaten)

Die zweite Abbildung zeigt dieselbe Röntgenaufnahme, wobei alle PII- und PHI-Beispielmetadaten entfernt oder verdeckt wurden.

Beispiel-Röntgenaufnahme nach der De-Identifikation (mit Beispieldaten)

Nach der De-Identifikation werden alle Bildmetadaten entfernt und der gesamte in das Bild eingebrannte Text wird durch ein undurchsichtiges Rechteck verdeckt. Diese Konfiguration der De-Identifikation ist nützlich, wenn Sie nur die Bildpixeldaten für weitere Analysen, ML-Modelltraining oder Inferenz benötigen.

Sie können beispielsweise ein Bildklassifizierungsmodell daraufhin trainieren, dass es feststellt, ob in einer Röntgenaufnahme eine Fraktur vorhanden ist. Zum Trainieren dieses Modells benötigen Sie eine große Anzahl von Beispielbildern. Einige enthalten frakturierte Knochen und andere nicht. Sie brauchen jedoch keine vertraulichen Informationen wie Geschlecht, Alter oder Geburtsdatum des Patienten, da diese Informationen für das Modell nicht relevant sind.

Oder Sie möchten die Entwicklung einer bestimmten Krankheit in einer Patientengruppe mit fortschreitendem Alter der Patienten analysieren. In diesem Fall müssen Sie Informationen wie das Alter und Geschlecht des Patienten sowie das Datum jeder Studie kennen, da diese Informationen für die medizinische Analyse relevant sind. Sie haben die Möglichkeit, einige der Metadaten beizubehalten und gleichzeitig andere personenbezogene Informationen über Patienten zu entfernen, z. B. deren Namen und Krankenaktennummern.

Als Best Practice empfiehlt sich, die Daten in einer Studie so zu ändern, dass zwar die relativen Zeitachsen beibehalten werden, es aber so gut wie unmöglich ist, sie einem Patienten zuzuordnen. Weitere Informationen finden Sie unter Datumsverschiebung.

Erforderlicher Zugriff und Identity and Access Management-Rollen

In Google Cloud wird der Zugriff auf Ressourcen über IAM-Rollen (Identity and Access Management) verwaltet. Für den Zugriff auf die Cloud Healthcare API muss Ihr IAM-Konto die entsprechenden Rollen für die Funktion haben, die Sie ausüben möchten.

Sie können entweder ein Nutzerkonto (das Konto, mit dem Sie auf die Google Cloud Console zugreifen) oder ein IAM-Dienstkonto verwenden. In der zugehörigen Anleitung wird ein Dienstkonto verwendet, außer bei der Anzeige von medizinischen Bildern, für die Sie ein Nutzerkonto benötigen. Die hier aufgeführten allgemeinen Informationen gelten für alle Kontotypen.

Zum Erstellen des Ziel-Datasets benötigen Sie mindestens die Berechtigung healthcare.datasets.deidentify für das Quell-Dataset und die Berechtigung healthcare.datasets.create für das Google Cloud-Projekt. Die IAM-Rolle "Healthcare-Dataset-Administrator" umfasst beide Berechtigungen.

Informationen zum Steuern des Zugriffs auf Datasets und DICOM-Speicher finden Sie unter Zugriff auf Cloud Healthcare API-Ressourcen steuern. Informationen zu den erforderlichen Berechtigungen für Dataset-Methoden finden Sie unter Zugriffssteuerung oder in der Cloud Healthcare API.

Anzeigetools für medizinische Bilder

Die folgenden DICOM-Anzeigetools sind in die Cloud Healthcare API integriert und können zum Anzeigen von Bildern vor und nach der De-Identifikation verwendet werden:

Damit das Anzeigetool ordnungsgemäß funktioniert, müssen Ihre Anmeldedaten die Rolle healthcare.dicomViewer haben.

API-Struktur

Sie können auf Daten in Cloud Healthcare API-Datasets und -Speichern zugreifen und diese verwalten. Verwenden Sie dafür eine REST API, die jeden Speicher durch sein Google Cloud-Projekt, seinen Standort, sein Dataset, seinen Speichertyp und seinen Speichernamen identifiziert. Die Cloud Healthcare API implementiert modalitätsspezifische Zugriffsstandards, die den Branchenstandards für die jeweilige Modalität entsprechen. Beispielsweise bietet die Cloud Healthcare API nativ Vorgänge für das Lesen von DICOM-Studien und -Serien, die dem DICOMweb-Standard entsprechen.

Vorgänge, die auf einen modalitätsspezifischen Speicher zugreifen, verwenden einen Anfragepfad, der aus einem Basispfad und einem modalitätsspezifischen Anfragepfad besteht. Verwaltungsvorgänge, die normalerweise nur für Standorte, Datasets und Datenspeicher ausgeführt werden, verwenden möglicherweise nur den Basispfad.

Wenn Sie auf einen bestimmten Speicher in einem Cloud Healthcare API-Dataset verweisen, verwenden Sie einen Basispfad, der so aufgebaut ist:

 /projects/project/locations/location/datasets/dataset/store-type/store-name

Dabei gilt:

  • project: Ihr Google Cloud-Projekt
  • location: die Zone, in der sich Ihre Ressourcen befinden
  • dataset: der Name Ihres Datasets.
  • store-type: der Datenspeichertyp
  • store-name: der Name Ihres Datenspeichers

Das folgende Beispiel zeigt einen Basispfad:

/projects/MyProj/locations/us-central1/datasets/dataset1/dicomStores/dicomstore1

Das vorherige Pfadbeispiel verweist auf einen DICOM-Speicher der Cloud Healthcare API im Google Cloud-Projekt MyProj, in der Region US-central, in einem Dataset namens dataset1 und mit dem Namen dicomstore1.

Für den Zugriff auf ein Datenelement kombinieren Sie den Basispfad mit einem Anfragepfad, der nach dem entsprechenden Modalitätsformat formatiert ist. DICOMweb-Anfragen an einen DICOM-Speicher können beispielsweise so aussehen:

 base-path/dicomWeb/studies/{study_id}/series?PatientName={patient_name}

Der Teil base-path des Pfads stellt einen Basispfad dar, der für diese Anfrage spezifisch ist. Der Teil {study_id} des Pfads identifiziert eine bestimmte DICOM-Studie und der Name des Patienten wird durch {patient_name} angegeben. Im vorherigen Beispiel entspricht die Pfadspezifikation der DICOMweb-Standardpfadstruktur.

De-Identifikation mithilfe von Tags und Konfiguration zum Entfernen von Bilddaten

Die De-Identifikation von DICOM-Daten umfasst zwei Prozesse:

  • DICOM-Metadaten de-identifizieren
  • Eingebrannten Text in Bildern entfernen

In der Cloud Healthcare API basiert die De-Identifikation von Metadaten auf DICOM-Tags. Eingebrannte Texte werden über die Option TextRedactionMode entfernt.

Tags und Profile zur De-Identifikation verwenden

Sie können DICOM-Instanzen anhand von Tag-Keywords in den DICOM-Metadaten de-identifizieren. Die folgenden Tag-Filtermethoden stehen im Objekt DicomConfig verfügbar:

  • keepList: eine Liste der Tags, die beibehalten werden sollen. Entfernt alle anderen Tags.
  • removeList: eine Liste der zu entfernenden Tags. Alle anderen Tags werden beibehalten.
  • TagFilterProfile: ein Tag-Filterprofil, das angibt, welche Tags beibehalten oder entfernt werden sollen.

DICOM-Mindestattribut-Tags

Die folgenden Tags sind die Mindestattribute einer gültigen DICOM-Instanz innerhalb der Cloud Healthcare API:

  • StudyInstanceUID
  • SeriesInstanceUID
  • SOPInstanceUID
  • TransferSyntaxUID
  • MediaStorageSOPInstanceUID
  • MediaStorageSOPClassUID
  • PixelData
  • Rows
  • Columns
  • SamplesPerPixel
  • BitsAllocated
  • BitsStored
  • Highbit
  • PhotometricInterpretation
  • PixelRepresentation
  • NumberOfFrames

keepList

Wenn Sie die Tag-Filtermethode keepList verwenden möchten, müssen Sie eine Liste mit Tag-Namen angeben. Diese Tags sind die einzigen, die in den de-identifizierten Ressourcen beibehalten werden. Wenn Sie ein keeplist-Tag im Objekt DicomConfig angeben, werden standardmäßig DICOM-Mindestattribut-Tags hinzugefügt.

Wenn keine keeplist-Tags angegeben sind, werden keine DICOM-Tags aus dem Dataset entfernt. Im Allgemeinen wird ein Tag, das beibehalten wird, in der Ausgabe im Vergleich zum Original unverändert angezeigt. Die Tags StudyInstanceUID, SeriesInstanceUID, SOPInstanceUID und MediaStorageSOPInstanceUID werden jedoch mit neuen, eindeutigen Werten in der Ausgabe neu generiert.

removeList

Sie können ein removeList-Tag im Objekt DicomConfig angeben. Beim De-Identifikationsvorgang werden nur die in der Liste angegebenen Tags entfernt. Wenn keine removeList-Tags angegeben sind, wird der De-Identifikationsvorgang wie gewohnt fortgesetzt, aber es werden keine DICOM-Tags im Ziel-Dataset entfernt.

DICOM-Mindestattribut-Tags können nicht zu einer "removeList" hinzugefügt werden.

TagFilterProfile

Anstatt anzugeben, welche Tags beibehalten oder entfernt werden sollen, können Sie das Profil TagFilterProfile verwenden. Dieses vordefinierte Profil bestimmt, wie Tags verarbeitet und geändert werden. Das Profil MINIMAL_KEEP_LIST_PROFILE behält beispielsweise nur die Tags bei, die zur Erstellung gültiger DICOM-Ressourcen erforderlich sind, und entfernt alle anderen Tags. Weitere Informationen finden Sie in der Dokumentation zu TagFilterProfile.

Wir empfehlen das Profil TagFilterProfile als Tag-Filtermethode, insbesondere für Nutzer ohne technischen Hintergrund, da es mithilfe des vorausgewählten Profils nicht erforderlich ist, alle DICOM-Tags und deren Inhalte zu prüfen und zu verstehen.

Häufig verwendete Profile

Mit dem Profil ATTRIBUTE_CONFIDENTIALITY_BASIC_PROFILE können Sie einen der branchenüblichen Anwendungsfälle für die De-Identifikation durchführen: das Entfernen von Tags basierend auf dem Profil des DICOM-Standards für die Attributvertraulichkeit.

Ein weiteres, häufig verwendetes Profil ist DEIDENTIFY_TAG_CONTENTS, womit Metadaten in den Tag-Inhalten geprüft und vertraulicher Text ersetzt wird. Wenn Sie das Profil DEIDENTIFY_TAG_CONTENTS verwenden, können Sie auch Konfigurationen wie Informationstypen und primitive Transformationen anwenden. Informationstypen und primitive Transformationen können nicht auf die anderen Profile angewendet werden.

Sie können Informationstypen verwenden, um zu definieren, welche Daten gescannt werden, wenn Sie De-Identifikationen mit Tags durchführen. Bei einem Informationstyp handelt es sich um eine Art sensibler Daten wie den Namen eines Patienten, eine E-Mail-Adresse, Telefonnummer, Identifikationsnummer oder Kreditkartennummer. Weitere Informationen finden Sie unter InfoTypes und infoType-Detektoren.

Primitive Transformationen sind Regeln, die Sie zum Transformieren eines Eingabewerts verwenden. Sie können die De-Identifikation von DICOM-Tags anpassen, indem Sie eine primitive Transformation auf den Informationstyp jedes Tags anwenden. Sie können beispielsweise den Nachnamen eines Patienten de-identifizieren und durch eine Reihe von Sternchen ersetzen. Informationen zu primitiven Transformationen finden Sie unter Optionen für primitive Transformationen.

Die zugehörige Anleitung enthält einen Anwendungsfall für das Profil MINIMAL_KEEP_LIST_PROFILE.

Standard-Informationstypen

Das Profil DEIDENTIFY_TAG_CONTENTS verarbeitet standardmäßig die folgenden Informationstypen:

  • AGE
  • CREDIT_CARD_NUMBER
  • DATE
  • EMAIL_ADDRESS
  • IP_ADDRESS
  • LOCATION
  • MAC_ADDRESS
  • PERSON_NAME
  • PHONE_NUMBER
  • SWIFT_CODE
  • US_DRIVERS_LICENSE_NUMBER
  • US_PASSPORT
  • US_SOCIAL_SECURITY_NUMBER
  • US_VEHICLE_IDENTIFICATION_NUMBER
  • US_INDIVIDUAL_TAXPAYER_IDENTIFICATION_NUMBER

Wenn Sie nur die Informationstypen in der vorherigen Liste ändern müssen, können Sie das Profil DEIDENTIFY_TAG_CONTENTS ohne zusätzliche Parameter verwenden.

Eingebrannten Text aus Bildern entfernen

Die Cloud Healthcare API kann vertraulichen eingebrannten Text aus Bildern entfernen. Sensible Daten wie PII oder PHI werden von der Cloud Healthcare API erkannt, die sie dann durch ein undurchsichtiges Rechteck verdeckt. Die Cloud Healthcare API gibt dieselben DICOM-Bilder als Eingabe zurück, aber jeder Text, der gemäß Ihren Kriterien vertrauliche Informationen enthält, wird entfernt.

Sie können eingebrannten Text aus Bildern entfernen, indem Sie eine TextRedactionMode-Option in einem ImageConfig-Objekt angeben:

  • REDACT_ALL_TEXT: entfernt den gesamten eingebrannten Text aus DICOM-Bildern in einem Dataset
  • REDACT_SENSITIVE_TEXT: entfernt vertraulichen eingebrannten Text aus DICOM-Bildern in einem Dataset.

Wenn Sie REDACT_SENSITIVE_TEXT angeben, entfernen Sie default infoTypes und custom infoType als Patienten-IDs. Informationen wie Krankenaktennummern (medical record numbers, MRNs) werden aus Bildern entfernt.

Weitere Informationen zur Konfiguration zum Entfernen von Bilddaten finden Sie unter Eingebrannten Text aus Bildern entfernen.

Nächste Schritte