Desidentificación de imágenes médicas mediante la API de Cloud Healthcare

Introducción

En este documento, se explica cómo los investigadores, científicos de datos, organizaciones de ciencias de la salud y ciencias biológicas o equipos de TI pueden usar la API de Cloud Healthcare para quitar información de identificación personal (PII) y de información de salud protegida (PHI) de datos de Imágenes digitales y comunicación en medicina (DICOM). Este proceso, conocido como desidentificación, ayuda a garantizar la privacidad de los pacientes y a preparar los datos DICOM para su uso en la investigación, el uso compartido de datos y el aprendizaje automático.

En el instructivo adjunto, Usa la API de Cloud Healthcare para desidentificar imágenes médicas, se te guía a través de dos casos prácticos de desidentificación de datos de imágenes médicas mediante la API de Cloud Healthcare.

Cómo funciona la desidentificación de datos DICOM

Las imágenes médicas adquiridas con fines médicos pueden tener usos secundarios importantes en proyectos de investigación y bibliotecas de enseñanza. Sin embargo, es posible que debas quitar o modificar los elementos de datos sensibles (PII o PHI) de las imágenes de DICOM antes de analizarlas o compartirlas con colaboradores autorizados.

En el siguiente diagrama, se muestran varias canalizaciones de imágenes médicas de fuentes locales que se enrutan a Google Cloud y, luego, se anonimizan mediante la operación de desidentificación de la API de Cloud Healthcare.

Canalización de desidentificación de DICOM.

Primero, sube imágenes médicas con formato DICOM a Cloud Storage y, luego, a la API de Cloud Healthcare. Como alternativa, puedes subir imágenes DICOM directamente a la API de Cloud Healthcare. Luego, las imágenes médicas, que se guardan en un almacén DICOM en la API de Cloud Healthcare, se enrutan a través del proceso de desidentificación de la API de Cloud Healthcare para anonimizar las imágenes y los metadatos asociados.

Por ejemplo, como investigador médico, es posible que tengas acceso a imágenes de rayos X de fracturas de columna de pacientes en un sistema de archivo y comunicación de imágenes (PACS). Puedes mover los datos de píxeles de imagen a Cloud Storage con el Servicio de transferencia de almacenamiento, el Transfer Appliance o uno de los productos de conectividad híbrida. Luego, puedes copiar o mover los datos de Cloud Storage a la API de Cloud Healthcare. Una vez que los datos están en la API de Cloud Healthcare, puedes usarlos como copia de seguridad, verlos de forma remota o permitir que accedan a servicios y apps en la nube de terceros aprobados.

En otra situación, puedes enviar imágenes DICOM desidentificadas a AutoML Vision para entrenar un modelo que ayude a los equipos de atención médica a detectar fracturas de columna en rayos X. De esta manera, puedes crear una herramienta de asistencia para la toma de decisiones clínicas con tus propios datos.

API de Cloud Healthcare

La API de Cloud Healthcare ofrece una solución administrada para almacenar y acceder a datos de atención médica en Google Cloud, lo que proporciona un puente crítico entre los sistemas y las aplicaciones de atención médica existentes alojados en Google Cloud.

Dentro de un proyecto de Google Cloud, los datos transferidos a través de la API de Cloud Healthcare se almacenan en un conjunto de datos, que reside en una ubicación geográfica correspondiente a una región de Google Cloud. La API de Cloud Healthcare admite las regiones enumeradas en Regiones. Para obtener una lista de los productos de Google Cloud y las regiones en las que se implementan, consulta Ubicaciones de la nube.

Debido a que cada modo de datos de atención médica, como, por ejemplo, DICOM, recursos de interoperabilidad para atención médica rápida (FHIR) y HL7v2, tiene características de procesamiento y estructura específicas. Los conjuntos de datos se dividen entre almacenes de modalidad específica.

En el siguiente diagrama, se muestra cómo la API de Cloud Healthcare organiza los datos clínicos por ubicación, conjunto de datos y almacén.

Organización de la API de Cloud Healthcare de datos clínicos.

Cada conjunto de datos contiene uno o más almacenes que brindan servicios de modalidades iguales o diferentes según lo requiera la app. El uso de varios almacenes en el mismo conjunto de datos podría ser apropiado si una app procesa diferentes tipos de datos. Por ejemplo, es posible que desees separar los datos según el hospital, clínica o departamento de origen. Una app puede acceder a tantos conjuntos de datos o almacenes como sea necesario sin penalización de rendimiento. Es importante diseñar tu conjunto de datos general y la arquitectura del almacén para cumplir con los objetivos generales de tu organización, como la proximidad a los recursos de procesamiento o a los usuarios finales, la partición o el control de acceso.

En el siguiente diagrama, se muestran dos conjuntos de datos que contienen almacenes HL7v2, DICOM y FHIR.

Arquitectura de conjuntos de datos con almacenes de HL7v2 y DICOM

Puedes copiar imágenes de DICOM en un almacén de DICOM o almacenarlas en un conjunto de datos de una variedad de fuentes. Para obtener más información, consulta Crea y administra almacenes de DICOM.

Desidentificar los datos de DICOM

La API de Cloud Healthcare incluye herramientas de desidentificación que pueden ocultar (quitar) o modificar de forma escalable el contenido sensible en las imágenes y el texto, en función de la configuración especificada.

Estas herramientas operan en imágenes y textos codificados en formatos de historias clínicas específicas, como DICOM y FHIR. Cuando trabajas con instancias de DICOM, los componentes de una llamada a la API de desidentificación son los siguientes:

  • Fuente: Un conjunto de datos o un almacén de DICOM que contiene una o más instancias de DICOM con datos sensibles. En el instructivo adjunto, se usa un conjunto de datos, pero puedes modificar los ejemplos para que funcionen en un solo almacén de DICOM.
  • Qué desidentificar: Parámetros de configuración que especifican cómo procesar el conjunto de datos. Puedes configurar la operación de desidentificación de DICOM para desidentificar los metadatos de las instancias de DICOM si usas palabras clave de etiquetas, si ocultas el texto grabado en las imágenes de DICOM o si haces ambas acciones.
  • Destino: La desidentificación no afecta el conjunto de datos original ni sus datos. En cambio, las copias procesadas de los datos originales se escriben en un nuevo conjunto de datos o almacén de DICOM, llamado destino. En el instructivo adjunto, se usa un conjunto de datos, pero puedes modificar los ejemplos para que funcionen en un almacén de DICOM.

En las dos siguientes imágenes, se muestra una imagen de rayos X de muestra antes y después de la desidentificación, en la que el objetivo es quitar o modificar todos los metadatos y el texto grabado asociado a la imagen.

En la primera imagen, se muestra una imagen de rayos X con datos de PII y PHI de muestra que aparecen tanto en metadatos como en texto grabado.

Imagen de rayos X de muestra antes de la desidentificación (con datos de muestra).

En la segunda imagen, se muestra la misma imagen de rayos X con todos los metadatos de PII y PHI de muestra ocultados o sin estos.

Imagen de rayos X de muestra después de la desidentificación (con datos de muestra).

Después de la desidentificación, se quitan todos los metadatos de la imagen y todo el texto grabado en la imagen se oculta con un rectángulo opaco. Esta configuración de desidentificación es útil cuando necesitas solo los datos de píxeles de imagen para un análisis, un entrenamiento de modelos de aprendizaje automático (AA) o una inferencia más detallados.

Por ejemplo, es posible que desees entrenar un modelo de clasificación de imágenes para determinar si hay una fractura presente en una radiografía. Para entrenar este modelo, necesitas una gran cantidad de muestras de imágenes, algunas que incluyan huesos fracturados y otras que no. Sin embargo, no necesitarás información sensible, como el género, la edad o la fecha de nacimiento de los pacientes, ya que esta información no es relevante para el modelo.

O bien, es posible que desees analizar el progreso de una enfermedad determinada en una población de pacientes a medida que avanza su edad. En este caso, deberás conocer información como la edad y el género del paciente, así como la fecha de cada estudio, ya que esta información es relevante para el análisis clínico. Tienes la opción de conservar algunos de los metadatos y ocultar otra información identificable sobre los pacientes, como sus nombres y números de historia clínica.

Se recomienda cambiar las fechas en cualquier estudio con el fin de que se mantengan los cronogramas relativos, pero hacerlos coincidir con un paciente sea casi imposible. Para obtener más información, consulta cambio de fecha.

Acceso requerido y funciones de Identity and Access Management

En Google Cloud, el acceso a los recursos se administra a través de las funciones de la Identity and Access Management (IAM). El acceso a la API de Cloud Healthcare requiere que tu cuenta (de IAM) tenga las funciones adecuadas para la función que quieres realizar.

Puedes usar una cuenta de usuario (la que usas para acceder a la consola de Google Cloud) o una cuenta de servicio de Cloud IAM. En el instructivo adjunto, se usa una cuenta de servicio, excepto para la visualización de imágenes médicas, en cuyo caso debes usar una cuenta de usuario. La información general que se presenta aquí se aplica a todos los tipos de cuenta.

Para crear el conjunto de datos de destino, debes tener al menos el permiso healthcare.datasets.deidentify en el conjunto de datos de origen y el permiso healthcare.datasets.create en el proyecto de Google Cloud. En la función de IAM de administrador de conjunto de datos de atención médica, se incluyen ambos permisos.

Para obtener información sobre cómo controlar el acceso a los conjuntos de datos y almacenes de DICOM, consulta Controla el acceso a los recursos de la API de Cloud Healthcare. Si deseas obtener información sobre los permisos necesarios para los métodos del conjunto de datos, consulta Control de acceso o la API de Cloud Healthcare.

Visualizadores de imágenes médicas

Los siguientes visualizadores de DICOM están integrados a la API de Cloud Healthcare y puedes usarlos para ver imágenes antes y después de la desidentificación:

Para que el visualizador funcione de forma correcta, tus credenciales de acceso deben tener la función healthcare.dicomViewer.

Estructura de la API

Puedes acceder y administrar los datos en los conjuntos de datos y almacenes de la API de Cloud Healthcare mediante una API de REST que identifique cada almacén por su proyecto de Google Cloud, ubicación, conjunto de datos, tipo de almacén y nombre de almacén. La API de Cloud Healthcare implementa estándares de acceso de modalidad específica que son coherentes con los estándares de la industria para cada una de las modalidades respectivas. Por ejemplo, la API de Cloud Healthcare proporciona operaciones de forma nativa para leer series y estudios de DICOM que son coherentes con el estándar de DICOMweb.

Las operaciones que acceden a un almacén de modalidad específica usan una ruta de solicitud que consiste en una ruta base y una ruta de solicitud de modalidad específica. En las operaciones administrativas, que, en general, operan solo en ubicaciones, conjuntos de datos y almacenes de datos, solo se puede usar la ruta base.

Para hacer referencia a un almacén en particular dentro de un conjunto de datos de la API de Cloud Healthcare, usa una ruta base estructurada de la siguiente manera:

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

Reemplaza lo siguiente:

  • project: es tu proyecto de Google Cloud
  • location: Es la zona donde se encuentran tus recursos.
  • dataset: Es el nombre de tu conjunto de datos.
  • store-type: Es el tipo de almacén de datos.
  • store-name: Es el nombre de tu almacén de datos.

A continuación, se muestra un ejemplo de una ruta base:

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

En el ejemplo de ruta de acceso anterior, se hace referencia a un almacén de DICOM de la API de Cloud Healthcare en el proyecto de Google Cloud MyProj, en la región US-central, en un conjunto de datos llamado dataset1 y con el nombre de dicomstore1.

Para acceder a un dato, debes combinar la ruta base con una ruta de solicitud que tenga un formato acorde al estándar de modalidad adecuado. Por ejemplo, las solicitudes de DICOMweb a un almacén de DICOM podrían verse de la siguiente manera:

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

La parte base-path de la ruta representa una ruta base específica para esta solicitud. La parte {study_id} de la ruta identifica un estudio de DICOM en particular, y el nombre del paciente se especifica mediante {patient_name}. En el ejemplo anterior, la especificación de ruta es coherente con la estructura de ruta estándar de DICOMweb.

Desidentificación mediante etiquetas y configuración de ocultamiento de imágenes

En la desidentificación de datos de DICOM, se incluyen dos procesos:

  • Desidentificación de metadatos de DICOM
  • Ocultamiento de texto grabado en imágenes

En la API de Cloud Healthcare, la desidentificación de metadatos se basa en etiquetas de DICOM y el ocultamiento de texto grabado se realiza a través de la opción TextRedactionMode.

Usa etiquetas y perfiles para la desidentificación

Puedes desidentificar las instancias de DICOM según las palabras clave de etiqueta en los metadatos de DICOM. Los siguientes métodos de filtrado de etiquetas están disponibles en el objeto DicomConfig:

  • keepList: Es una lista de etiquetas que se conservarán. Quita todas las demás etiquetas.
  • removeList: Es una lista de etiquetas que se quitarán. Conserva todas las demás etiquetas.
  • TagFilterProfile: Es un perfil de filtrado de etiquetas que especifica qué etiquetas se conservarán o se quitarán.

Etiquetas de atributos mínimos de DICOM

Las siguientes etiquetas son los atributos mínimos de una instancia de DICOM válida dentro de la API de Cloud Healthcare:

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

keepList

Para usar el método de filtrado de etiquetas keepList, debes proporcionar una lista de nombres de etiquetas. Estas etiquetas son las únicas que se conservan en los recursos desidentificados. Cuando especificas una etiqueta keeplist en el objeto DicomConfig, las etiquetas de atributo mínimo de DICOM se agregan de forma predeterminada.

Si no se proporcionan etiquetas keeplist, no se quitan las etiquetas de DICOM del conjunto de datos. Por lo general, cuando una etiqueta se conserva, aparece sin cambios en el resultado si se compara con el original. Sin embargo, las etiquetas StudyInstanceUID, SeriesInstanceUID, SOPInstanceUID y MediaStorageSOPInstanceUID se vuelven a generar con valores nuevos y únicos en la salida.

removeList

Puedes especificar una etiqueta removeList en el objeto DicomConfig. La operación de desidentificación quita solo las etiquetas especificadas en la lista. Si no se proporcionan etiquetas removeList, la operación de desidentificación continúa como de costumbre, pero no se ocultan las etiquetas de DICOM en el conjunto de datos de destino.

No se pueden agregar etiquetas de atributos mínimos de DICOM a una removeList.

TagFilterProfile

En lugar de especificar qué etiquetas se conservarán o se quitarán, puedes usar el perfil TagFilterProfile. Este perfil predefinido determina cómo se manejan y modifican las etiquetas. Por ejemplo, el perfil MINIMAL_KEEP_LIST_PROFILE conserva solo las etiquetas necesarias para producir recursos de DICOM válidos y quita todas las demás etiquetas. Para obtener más información, consulta la documentación de TagFilterProfile.

Recomendamos el perfil TagFilterProfile como un método de filtrado de etiquetas, en especial en el caso de usuarios que no sean técnicos, ya que para el perfil preseleccionado no es necesario revisar y comprender todas las etiquetas de DICOM y su contenido.

Perfiles de uso frecuente

Mediante el perfil ATTRIBUTE_CONFIDENTIALITY_BASIC_PROFILE, puedes realizar uno de los casos prácticos de desidentificación comunes de la industria: eliminación de etiquetas según los DICOM Standard's attribute confidentiality profiles (Perfiles de confidencialidad del atributo del estándar de DICOM).

Otro perfil de uso frecuente es DEIDENTIFY_TAG_CONTENTS, que inspecciona los metadatos dentro del contenido de la etiqueta y reemplaza el texto sensible. Cuando usas el perfil DEIDENTIFY_TAG_CONTENTS, también puedes aplicar parámetros de configuración como tipos de información y transformaciones básicas. Los tipos de información y las transformaciones básicas no se pueden aplicar a los otros perfiles.

Puedes usar tipos de información para definir qué datos se analizan cuando se realiza la desidentificación con etiquetas. Un tipo de información es un tipo de datos sensibles, como el nombre de un paciente, dirección de correo electrónico, número de teléfono, número de identificación o número de tarjeta de crédito. Para obtener más información, consulta InfoTypes y detectores de infoType.

Las transformaciones básicas son reglas que usas para transformar un valor de entrada. Puedes personalizar la forma en la que se desidentifican las etiquetas DICOM si aplicas una transformación básica al tipo de información de cada etiqueta. Por ejemplo, puede desidentificar el apellido de un paciente y reemplazarlo por una serie de asteriscos. Para obtener información sobre las transformaciones básicas, consulta las opciones de transformación básicas.

En el instructivo adjunto, se proporciona un caso práctico para el perfil MINIMAL_KEEP_LIST_PROFILE.

Tipos de información predeterminados

De forma predeterminada, el perfil DEIDENTIFY_TAG_CONTENTS maneja los siguientes tipos de información:

  • 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 necesitas modificar solo los tipos de información de la lista anterior, puedes usar el perfil DEIDENTIFY_TAG_CONTENTS sin ningún parámetro adicional.

Oculta el texto grabado de las imágenes

La API de Cloud Healthcare puede ocultar el texto grabado sensible de las imágenes. La API de Cloud Healthcare detecta datos sensibles, como PII o PHI, y, luego, los oculta con un rectángulo opaco. La API de Cloud Healthcare muestra las mismas imágenes de DICOM que la entrada, pero cualquier texto identificado que contenga información sensible, de acuerdo con tus criterios, se oculta.

Puedes ocultar el texto grabado de las imágenes si especificas una opción TextRedactionMode dentro de un objeto ImageConfig:

  • REDACT_ALL_TEXT: Oculta todo el texto grabado de las imágenes de DICOM en un conjunto de datos.
  • REDACT_SENSITIVE_TEXT: Oculta el texto grabado sensible de las imágenes de DICOM en un conjunto de datos.

Cuando especificas REDACT_SENSITIVE_TEXT, ocultas default infoTypes y custom infoType como identificadores de pacientes. La información, como los números de la historia clínica (MRN), se oculta de las imágenes.

Para obtener más información sobre la configuración de ocultamiento de imágenes, consulta Oculta el texto grabado de las imágenes.

¿Qué sigue?