Supprimer l'identification des images médicales à l'aide de l'API Cloud Healthcare

Présentation

Ce document explique comment les chercheurs, les data scientists, les équipes informatiques ou les organisations du secteur de la santé et des sciences de la vie peuvent utiliser l'API Cloud Healthcare pour supprimer les informations personnelles et les données de santé protégées des données DICOM (Digital Imaging and Communications in Medicine, données numériques d'imagerie et de communication dans le cadre médical). Ce processus, désigné par le terme "anonymisation", contribue à garantir la confidentialité des données des patients et à préparer les données DICOM pour une utilisation dans le cadre de travaux de recherche, du partage de données et du machine learning.

Le tutoriel associé, intitulé Utiliser l'API Cloud Healthcare pour anonymiser des images médicales, vous guide tout au long de deux cas d'utilisation exploitant l'API Cloud Healthcare pour anonymiser des données d'imagerie médicale.

Fonctionnement de l'anonymisation des données DICOM

Les images médicales acquises à des fins cliniques peuvent avoir des utilisations secondaires importantes dans le cadre de projets de recherche et de bibliothèques d'enseignement. Toutefois, vous devrez peut-être supprimer ou modifier des éléments de données sensibles (informations personnelles ou données de santé protégées) dans des images DICOM avant de pouvoir les analyser ou les partager avec des collaborateurs autorisés.

Le schéma suivant illustre plusieurs pipelines de traitement d'images médicales qui sont acheminées depuis des sources sur site vers Google Cloud, puis anonymisées par l'opération d'anonymisation de l'API Cloud Healthcare.

Pipeline d'anonymisation de DICOM.

Pour commencer, les images médicales au format DICOM sont importées dans Cloud Storage, avant d'être transférées à l'API Cloud Healthcare. Vous pouvez également importer des images DICOM directement dans l'API Cloud Healthcare. Les images médicales, qui sont conservées dans un magasin DICOM au sein de l'API Cloud Healthcare, sont ensuite conduites à travers le processus de l'API Cloud Healthcare dédié à l'anonymisation des images et des métadonnées associées.

Par exemple, en tant que chercheur dans le domaine médical, vous pouvez avoir accès à des radiographies de fractures de la colonne vertébrale de patients, qui sont stockées dans un système sur site d'archivage et de transmission d'images (picture archiving and communication system ou PACS). Vous pouvez déplacer les données de pixel d'image vers Cloud Storage à l'aide du service de transfert de stockage, d'un appareil Transfer Appliance ou de l'un des produits de connectivité hybride. Vous pouvez ensuite copier ou déplacer les données depuis Cloud Storage vers l'API Cloud Healthcare. Une fois les données stockées dans l'API Cloud Healthcare, vous pouvez les utiliser comme sauvegarde, les consulter à distance ou autoriser des services et applications cloud tiers validés à y accéder.

Un autre scénario consiste à envoyer des images DICOM anonymisées à AutoML Vision afin d'entraîner un modèle visant à aider les équipes de santé à détecter les fractures vertébrales dans des images radiographiques. Vous pouvez ainsi créer un outil d'aide à la prise de décisions cliniques en utilisant vos propres données.

API Cloud Healthcare

L'API Cloud Healthcare offre une solution gérée pour le stockage et l'accès aux données de santé dans Google Cloud, créant ainsi un lien essentiel entre les systèmes de soins existants et les applications basées sur Google Cloud.

Dans un projet Google Cloud, les données ingérées via l'API Cloud Healthcare sont stockées dans un ensemble de données qui réside dans un emplacement géographique correspondant à une région Google Cloud. L'API Cloud Healthcare est compatible avec les régions répertoriées sur la page Régions. Pour obtenir la liste des produits Google Cloud et des régions dans lesquelles ils sont mis en œuvre, consultez la page Emplacements Cloud.

Étant donné que chaque modalité de données de santé (par exemple, DICOM, Fast Healthcare Interoperability Resources (FHIR) ou HL7v2) possède ses propres caractéristiques de structure et de traitement, les ensembles de données sont divisés en magasins spécifiques à une modalité.

Le schéma suivant illustre la manière dont l'API Cloud Healthcare organise les données cliniques par emplacement, ensemble de données et magasin.

Organisation des données cliniques dans Cloud Healthcare.

Chaque ensemble de données contient un ou plusieurs magasins, suivant les besoins de l'application, chacun de ces magasins étant dédié à une modalité unique. L'utilisation de plusieurs magasins au sein d'un même ensemble de données peut être appropriée si une application doit traiter différents types de données. Par exemple, vous pouvez souhaiter séparer les données en fonction de leur hôpital, clinique ou service d'origine. Une application peut accéder à autant d'ensembles de données ou de magasins que nécessaire sans que ses performances en soient affectées. Il est important de concevoir l'architecture globale de vos ensembles de données et magasins pour répondre aux objectifs généraux de votre organisation, tels que la proximité des ressources de calcul ou des utilisateurs finaux, le partitionnement ou encore le contrôle des accès.

Le schéma suivant illustre deux ensembles de données contenant des magasins HL7v2, DICOM et FHIR.

Architecture des ensembles de données comportant des magasins HL7v2 et DICOM.

Vous pouvez copier des images DICOM vers un ou plusieurs magasins DICOM au sein d'un ensemble de données, en provenance de différentes sources. Pour en savoir plus, consultez la page Créer et gérer des magasins DICOM.

Anonymiser des données DICOM

L'API Cloud Healthcare inclut des outils d'anonymisation permettant de masquer (supprimer) ou de modifier le contenu sensible dans le texte et les images, en fonction de la configuration spécifiée.

Ces outils traitent le texte et les images encodés dans les formats de dossiers médicaux spécifiques tels que DICOM et FHIR. Lorsque vous travaillez sur des instances DICOM, les composants nécessaires à un appel d'API d'anonymisation sont les suivants :

  • La source : ensemble de données ou magasin DICOM contenant une ou plusieurs instances DICOM présentant des données sensibles. Le tutoriel associé utilise un ensemble de données, mais vous pouvez modifier les exemples pour qu'ils traitent un magasin DICOM unique.
  • Les éléments ciblés par l'anonymisation : paramètres de configuration spécifiant comment traiter l'ensemble de données. Vous pouvez configurer l'opération d'anonymisation des données DICOM pour anonymiser des métadonnées d'instance DICOM à l'aide de mots clés de tags, en masquant le texte incrusté dans les images DICOM, ou en combinant les deux méthodes.
  • La destination : l'anonymisation n'a aucune incidence sur l'ensemble de données d'origine ou ses données. À la place, des copies anonymisées des données d'origine sont écrites dans un nouvel ensemble de données ou magasin DICOM, appelé destination. Le tutoriel associé utilise un ensemble de données, mais vous pouvez modifier les exemples pour qu'ils traitent un magasin DICOM.

Les deux images suivantes illustrent un exemple d'image radiographique avant et après une opération d'anonymisation ayant pour objectif de supprimer ou modifier toutes les métadonnées associées à l'image ainsi que le texte incrusté dans l'image.

La première image montre la radiographie avec les informations personnelles et données de santé protégées apparaissant à la fois dans les métadonnées et dans le texte incrusté dans l'image.

Exemple de radiographie avant anonymisation (données d'exemple).

La deuxième image montre la même radiographie après suppression ou masquage de toutes les informations personnelles et données de santé protégées.

Exemple de radiographie après anonymisation (données d'exemple).

Après anonymisation, toutes les métadonnées d'image sont supprimées, et le texte incrusté dans l'image a été masqué par un rectangle opaque. Cette configuration d'anonymisation est utile lorsque vous n'avez besoin que des données de pixel d'image pour effectuer des analyses, entraîner un modèle de machine learning (ML) ou exécuter des inférences.

Par exemple, vous pouvez souhaiter entraîner un modèle de classification d'images afin de déterminer si une fracture est présente dans une radiographie. Pour entraîner ce modèle, vous aurez besoin d'un grand nombre d'images d'exemples, certaines contenant des fractures et d'autres non. Toutefois, vous n'avez pas besoin d'informations sensibles telles que le genre, l'âge ou la date de naissance du patient, car ces informations n'ont aucune pertinence pour le modèle.

Vous pouvez également souhaiter analyser la progression d'une maladie particulière en fonction de l'âge des patients d'une population donnée. Dans ce cas, vous avez besoin de connaître certaines informations telles que l'âge et le genre du patient, ainsi que la date de chaque étude, car ces informations sont pertinentes pour l'analyse clinique. Vous avez la possibilité de conserver certaines des métadonnées tout en supprimant d'autres informations identifiant les patients, telles que leur nom et leur numéro de dossier médical.

Une bonne pratique consiste à modifier les dates de toute étude afin de respecter la chronologie relative mais de rendre quasiment impossible toute correspondance avec un patient donné. Pour en savoir plus, consultez la page Changement de date.

Accès et rôles Identity and Access Management requis

Dans Google Cloud, l'accès aux ressources est géré à l'aide des rôles Identity and Access Management (IAM). L'accès à l'API Cloud Healthcare nécessite que votre compte IAM dispose des rôles appropriés pour la fonction que vous souhaitez exécuter.

Vous pouvez employer un compte utilisateur (celui avec lequel vous accédez à la console Google Cloud) ou un compte de service IAM. Le tutoriel associé utilise un compte de service, sauf pour la visualisation d'images médicales qui nécessite un compte utilisateur. Les informations générales présentées ici s'appliquent à tous les types de comptes.

Pour créer l'ensemble de données de destination, vous devez disposer au minimum des autorisations healthcare.datasets.deidentify sur l'ensemble de données source et healthcare.datasets.create sur le projet Google Cloud. Le rôle IAM "Administrateur d'ensembles de données Healthcare" inclut ces deux autorisations.

Pour plus d'informations sur le contrôle de l'accès aux ensembles de données et aux magasins DICOM, consultez la page Contrôler l'accès aux ressources de l'API Cloud Healthcare. Pour en savoir plus sur les autorisations requises pour les méthodes d'ensembles de données, consultez la documentation sur le Contrôle des accès ou celle de l'API Cloud Healthcare.

Visionneuses d'images médicales

Les visionneuses d'images DICOM suivantes sont intégrées à l'API Cloud Healthcare et vous pouvez vous en servir pour consulter les images avant et après anonymisation :

Pour que la visionneuse fonctionne correctement, vos identifiants de connexion doivent disposer du rôle healthcare.dicomViewer.

Structure d'API

Vous pouvez accéder aux données des ensembles de données et magasins utilisés par l'API Cloud Healthcare et gérer ces données à l'aide d'une API REST qui identifie chaque magasin en fonction du projet Google Cloud, de l'emplacement, de l'ensemble de données, du type et du nom qui lui sont associés. L'API Cloud Healthcare met en œuvre les normes d'accès spécifiques aux modalités en conformité avec les standards définis pour ces modalités dans l'industrie. Par exemple, l'API Cloud Healthcare fournit en natif des opérations permettant de lire les études et séries DICOM cohérentes avec le standard DICOMweb.

Les opérations qui accèdent à un magasin spécifique à une modalité utilisent un chemin de requête composé d'un chemin de base et d'un chemin de requête spécifique à cette modalité. Les opérations d'administration, qui ne concernent généralement que les emplacements, les ensembles de données et les magasins de données, peuvent n'utiliser que le chemin de base.

Pour désigner un magasin donné au sein d'un ensemble de données de l'API Cloud Healthcare, utilisez un chemin de base structuré comme suit :

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

Remplacez les éléments suivants :

  • project : projet Google Cloud
  • location : par la zone où se trouvent vos ressources
  • dataset : par le nom de votre ensemble de données
  • store-type : par le type de magasin de données
  • store-name : par le nom de votre magasin de données

Voici un exemple de chemin de base :

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

Cet exemple de chemin fait référence à un magasin DICOM de l'API Cloud Healthcare hébergé dans le projet MyProj, dans la région US-central, dans l'ensemble de données dataset1, et portant le nom dicomstore1.

Pour accéder à un élément de données, vous combinez le chemin de base avec un chemin de requête mis en forme suivant les standards correspondant à la modalité. Par exemple, les requêtes DICOMweb envoyées à un magasin DICOM peuvent se présenter comme suit :

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

La section base-path du chemin représente le chemin de base spécifique à cette requête. L'élément {study_id} du chemin identifie une étude DICOM donnée, et le nom du patient est spécifié dans l'élément {patient_name}. Dans l'exemple précédent, la spécification du chemin est cohérente avec la structure de chemin DICOMweb standard.

Anonymiser à l'aide d'une configuration à base de tags et de masquage d'image

La suppression de l'identification d'images DICOM inclut deux processus :

  • La suppression de l'identification des métadonnées DICOM
  • Le masquage du texte incrusté dans les images

Dans l'API Cloud Healthcare, l'anonymisation des métadonnées repose sur les tags DICOM, tandis que le masquage du texte incrusté dans les images utilise l'option TextRedactionMode.

Utiliser des tags et des profils à des fins d'anonymisation

Vous pouvez anonymiser des instances DICOM à l'aide de mots clés de tags dans les métadonnées DICOM. Les méthodes suivantes de filtrage de tags sont disponibles dans l'objet DicomConfig :

  • keepList : liste de tags à conserver. Tous les autres tags sont supprimés.
  • removeList : liste de tags à supprimer. Tous les autres tags sont conservés.
  • TagFilterProfile : profil de filtrage de tags, qui spécifie les tags à conserver ou à supprimer.

Tags d'attributs DICOM minimaux

Les tags suivants correspondent aux attributs minimaux d'une instance DICOM valide au sein de l'API Cloud Healthcare :

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

keepList

Pour utiliser la méthode keepList de filtrage des tags, vous devez fournir une liste de noms de tags. Ces tags sont les seuls à être conservés dans les ressources soumises à l'anonymisation. Lorsque vous spécifiez dans l'objet DicomConfig une liste keeplist de tags à conserver, les tags d'attributs DICOM minimaux sont ajoutés par défaut.

Si aucun tag n'est fourni pour keeplist, aucun tag DICOM n'est supprimé de l'ensemble de données. En règle générale, lorsqu'un tag est conservé, il apparaît dans la sortie de façon identique à l'original. Toutefois, des valeurs nouvelles et uniques sont générées dans la sortie pour les tags StudyInstanceUID, SeriesInstanceUID, SOPInstanceUID et MediaStorageSOPInstanceUID.

removeList

Vous pouvez spécifier un tag à supprimer dans la liste removeList de l'objet DicomConfig. L'opération d'anonymisation retire uniquement les tags figurant dans cette liste. Si aucun tag n'est fourni pour removeList, l'opération d'anonymisation se déroule comme à l'accoutumée, mais aucun tag DICOM n'est masqué dans l'ensemble de données de destination.

Il n'est pas possible d'ajouter des tags d'attributs DICOM minimaux à une liste "removeList".

TagFilterProfile

Au lieu de spécifier les tags à conserver ou à supprimer, vous pouvez utiliser le profil TagFilterProfile. Ce profil prédéfini détermine la manière dont les tags sont gérés et modifiés. Par exemple, le profil MINIMAL_KEEP_LIST_PROFILE ne conserve que les tags requis pour produire des ressources DICOM valides et supprime tous les autres tags. Pour en savoir plus, reportez-vous à la documentation de TagFilterProfile.

Nous recommandons d'utiliser le profil TagFilterProfile comme méthode de filtrage des tags, particulièrement pour les utilisateurs n'ayant pas un profil technique. En effet, le profil présélectionné fait qu'il n'est pas nécessaire d'examiner et de comprendre l'intégralité des tags DICOM et leur contenu.

Profils fréquemment utilisés

Le profil ATTRIBUTE_CONFIDENTIALITY_BASIC_PROFILE vous permet de mettre en œuvre l'un des cas d'utilisation courants d'anonymisation, à savoir supprimer des tags en fonction des profils de confidentialité des attributs selon la norme DICOM.

Le profil DEIDENTIFY_TAG_CONTENTS, qui inspecte les métadonnées figurant dans le contenu des tags et remplace le texte sensible, est lui aussi fréquemment utilisé. Lorsque vous utilisez le profil DEIDENTIFY_TAG_CONTENTS, vous pouvez également appliquer des configurations telles que des types d'information et des transformations primitives. Les types d'information et les transformations primitives ne peuvent pas être appliqués aux autres profils.

Vous pouvez utiliser des types d'information pour définir quelles données doivent être analysées lors de l'anonymisation à l'aide de tags. Un type d'information est un type de données sensibles, par exemple le nom d'un patient, son adresse e-mail, son numéro de téléphone, son numéro d'identification, son numéro de carte de crédit, etc. Pour en savoir plus, reportez-vous à la documentation sur les InfoTypes et détecteurs d'infoType.

Les transformations primitives sont des règles que vous utilisez pour transformer une valeur d'entrée. Vous pouvez personnaliser la manière dont les tags DICOM sont anonymisés en appliquant une transformation primitive au type d'information de chaque tag. Par exemple, vous pouvez supprimer le nom de famille d'un patient et le remplacer par une série d'astérisques. Pour en savoir plus sur les transformations primitives, consultez la section dédiée aux options des transformations primitives.

Le tutoriel associé fournit un cas d'utilisation du profil MINIMAL_KEEP_LIST_PROFILE.

Types d'informations par défaut

Par défaut, le profil DEIDENTIFY_TAG_CONTENTS gère les types d'informations suivants :

  • 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

Si vous souhaitez ne modifier que les types d'informations figurant dans la liste précédente, vous pouvez utiliser le profil DEIDENTIFY_TAG_CONTENTS sans paramètres supplémentaires.

Masquer du texte incrusté dans les images

L'API Cloud Healthcare peut masquer le texte sensible incrusté dans les images. Les données sensibles, telles que les informations personnelles ou les données de santé protégées, sont détectées par l'API Cloud Healthcare, qui applique ensuite un rectangle opaque pour les masquer. L'API Cloud Healthcare renvoie les mêmes images DICOM que celles fournies en entrée, mais tout texte identifié comme contenant des informations sensibles (selon les critères que vous avez définis) est masqué.

Vous pouvez masquer le texte incrusté dans les images en spécifiant une option TextRedactionMode dans un objet ImageConfig :

  • REDACT_ALL_TEXT : masque la totalité du texte incrusté dans les images DICOM d'un ensemble de données.
  • REDACT_SENSITIVE_TEXT : masque le texte sensible incrusté dans les images DICOM d'un ensemble de données.

Lorsque vous spécifiez l'option REDACT_SENSITIVE_TEXT, les types d'informations par défaut (default infoTypes) et personnalisés (custom infoType), considérés comme des identifiants de patients, sont masqués. Les informations telles que les numéros de dossiers médicaux sont masquées dans les images.

Pour en savoir plus sur la configuration du masquage d'images, consultez la section Masquer le texte incrusté des images.

Étape suivante