Integración con lectores médicos DICOM

En esta página, se explica cómo 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 Weasi.

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 acceso con Google de OAuth 2.0

  • 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.
  • Usa el flujo de acceso de Google es más complejo que usar 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 simple que con el flujo de acceso de Google. 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 acceso con Google de OAuth 2.0

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 acceso con Google de OAuth 2.0. Según tu aplicación, hay flujos disponibles para aplicaciones de servidor web, aplicaciones para dispositivos móviles y de computadora de escritorio, aplicaciones web de JavaScript y más.

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.

En un nivel alto, el flujo de acceso tiene los siguientes pasos:

  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 Acceso con Google. 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 las siguientes razones:

  • 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 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 en todo visor: el proveedor de la lista de trabajo y el visor 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 para obtener detalles sobre cómo se implementa 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 espectador puede recuperar esta información mediante la familia de métodos de transacción de búsqueda. Los métodos de transacción de búsqueda 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 búsqueda 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 implementa este método 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.