Integración con lectores médicos DICOM

En esta página, se explican los conceptos y prácticas recomendadas para integrar un visor de imágenes médico de terceros en la API de Cloud Healthcare. La API de Cloud Healthcare está integrada por varios visores, incluido el visor de Open Health Imaging Foundation (OHIF) y el visor de Weasis.

Antes de comenzar

Si no almacenaste ninguna imagen de DICOM para usar en el visualizador, consulta Almacena datos de DICOM y Importa y exporta datos de DICOM con Cloud Storage para comenzar.

Autoriza y autentica solicitudes mediante OAuth 2.0

Las API de Google Cloud admiten el protocolo OAuth 2.0 para la autenticación y la autorización.

Un visor médico necesita controlar la autenticación y la autorización para acceder a los datos de DICOM que se almacenaron en la API de Cloud Healthcare. Puedes otorgar estos permisos de dos maneras. Cada método tiene sus propios costos y beneficios:

Usa el flujo de OAuth 2.0 de Google Identity Services

  • Los usuarios finales se autentican a través del visor médico en la API de Cloud Healthcare.
  • El visor médico accede a la API de Cloud Healthcare en nombre del usuario final.
  • Los permisos se administran a nivel del usuario y las acciones del usuario se registran en Cloud Audit Logs con el identificador único del usuario.
  • El uso del flujo de Google Identity Services es más complejo que el uso de una cuenta de servicio. Por ejemplo, tu aplicación necesita controlar devoluciones de llamadas para almacenar el token de autorización, lo que puede agregar complejidad innecesaria a una aplicación simple.

Usa una cuenta de servicio

  • Configura el visor médico para que use su propio método de autorización y control de acceso a fin de determinar si un usuario final puede ver un recurso de la API de Cloud Healthcare determinado. Es útil usar una cuenta de servicio, si ya tienes un visor que realiza sus propias verificaciones de autenticación y administración de usuarios.
  • Las acciones realizadas en el visor se registran en Cloud Audit Logs, pero no puedes ver los registros a nivel de los usuarios finales individuales.
  • La autenticación con una cuenta de servicio es más sencilla que usar el flujo de Google Identity Services. Por ejemplo, no es necesario solicitarle al usuario que acceda y, por lo tanto, no es necesario almacenar un token de acceso.

Autoriza mediante el flujo de OAuth 2.0 de Google Identity Services

Puedes autorizar a un visor médico para que acceda a los datos de DICOM almacenados en la API de Cloud Healthcare en nombre del usuario mediante el flujo de OAuth 2.0 de Google Identity Services. Según tu aplicación, hay flujos disponibles para las siguientes aplicaciones:

En la siguiente descripción para el flujo de acceso, suponemos que el usuario que accede al visor creó un almacén de DICOM y almacenó instancias de DICOM en el almacén.

  1. Un usuario abrirá tu aplicación de visor médico. El visor muestra una ventana de consentimiento de Google que muestra el nombre de tu aplicación y los servicios de la API de Google a los que solicita permiso para acceder con las credenciales de autorización del usuario. El usuario puede conceder o denegar el acceso a la aplicación.
  2. Se envía al usuario a una página de Google Identity Services. Si el usuario le otorga a tu aplicación el acceso solicitado, tu aplicación obtiene permiso para acceder a los datos del usuario.

No almacenes tokens de actualización en el visor. Los tokens de acceso que otorgó el usuario deben ser de corta duración y solo deben intercambiarse cuando venzan.

Los tokens de actualización también son innecesarios por los siguientes motivos:

  • El usuario siempre está presente cuando usa el visor
  • Usar tokens de actualización requiere trabajo adicional para almacenar el token de forma segura.

Autoriza mediante una cuenta de servicio

Puedes administrar la autenticación y la autorización a nivel de visor médico, en lugar de hacerlo a nivel del usuario final mediante OAuth 2.0 con una cuenta de servicio.

Si deseas obtener instrucciones para usar una cuenta de servicio para autenticar un visor médico en la API de Cloud Healthcare, consulta Autentica la API.

Funciones requeridas

Para que el visor funcione de forma correcta, un usuario debe tener las siguientes funciones:

  • roles/healthcare.dicomViewer: para ver los recursos de DICOM
  • roles/healthcare.dicomEditor: para ver, editar y crear recursos de DICOM

En el flujo de acceso, se espera que el usuario ya haya configurado estas funciones y que el visor no tenga que hacer nada más. Cuando usas una cuenta de servicio, las funciones deben configurarse en la cuenta de servicio. El visor debe mostrar los errores PERMISSION_DENIED adecuados a los usuarios que no tienen los permisos necesarios para acceder a sus almacenes de DICOM.

Accede a los extremos de DICOMweb

Después de que el usuario se autentica en el visor, este puede realizar solicitudes a los extremos de DICOMweb. Cada almacén de DICOM expone un único extremo de DICOMweb.

Cuando el usuario está en el visor, debe especificar a qué proyectos y almacenes de DICOM quiere acceder. El proceso más simple es pedirle al usuario que proporcione los ID para el proyecto, el conjunto de datos y el almacén de DICOM al que desea acceder. Sin embargo, proporcionar cada valor individual puede llevar mucho tiempo al usuario.

Como alternativa, puedes proporcionar una combinación de entrada del usuario y autocompletar en el visor. Por ejemplo, es posible que el usuario ingrese un ID del proyecto y, luego, el visor propaga automáticamente una lista de los conjuntos de datos y almacenes de DICOM en ese proyecto. O bien, puedes proporcionar un solo campo de entrada que propague de automáticamente los proyectos, los conjuntos de datos y los almacenes de DICOM a los que tiene acceso el usuario. Los siguientes métodos de API pueden ser útiles cuando configuras cualquiera de estas alternativas:

Te recomendamos considerar también la propagación previa de una lista de recursos de un usuario. Sin embargo, si un usuario tiene cientos o miles de conjuntos de datos o almacenes de DICOM, es posible que no se pueda propagar previamente y mostrar la lista.

Accede a los recursos en el visor mediante DICOMweb

La API de Cloud Healthcare admite el estándar de DICOMweb. Para permitir que los usuarios accedan a sus datos, el visor debe implementar los métodos HTTP RESTful de DICOMweb en lugar de los protocolos DIMSE heredados.

Hay dos componentes principales para cualquier visualizador:

  • El proveedor de la lista de trabajo
  • El visualizador de imágenes

Puedes usar el estándar de DICOMweb con ambos componentes.

Visualiza el proveedor de listas de trabajo

Por lo general, lo primero que ve un usuario cuando abre un visor es una lista de todos los estudios disponibles en cada almacén de DICOM. El espectador puede recuperar estos estudios con la Transacción de búsqueda.

Consulta la Declaración de conformidad de DICOM de la API de Cloud Healthcare si deseas obtener detalles para implementar la transacción de búsqueda en la API de Cloud Healthcare.

Visualiza instancias

Una vez que el usuario está en el proveedor de la lista de trabajo, por lo general, seleccionará un estudio para visualizarlo. Para procesar el estudio, el espectador debe acceder a los bytes por píxeles sin procesar del estudio y a los metadatos de DICOM. El visualizador puede recuperar esta información mediante el conjunto de métodos de la transacción de recuperación. Los métodos de transacción de recuperación te permiten recuperar un archivo DICOM sin procesar o los datos de píxeles sin procesar del archivo. Los métodos de transacción de recuperación también admiten la transcodificación entre diferentes sintaxis de transferencia.

Consulta la declaración de conformidad de DICOM de la API de Cloud Healthcare para obtener detalles sobre cómo se implementan los métodos de transacción de recuperación y búsqueda en la API de Cloud Healthcare.

Maximiza la capacidad de procesamiento de la red

A veces, como cuando se procesa una tomografía computarizada, es posible que un visor necesite descargar varias instancias a la vez para procesar la imagen. Para obtener mejores resultados, recupera cada instancia en paralelo mediante una gran cantidad de solicitudes simultáneas (como 50 o más). La cantidad exacta depende del ancho de banda de la aplicación y la red.