Integrar un visor médico DICOM

En esta página se explican los conceptos y las prácticas recomendadas para integrar un visor de imagenología médica de terceros con la API Cloud Healthcare. La API Cloud Healthcare está integrada con varios visores, como el visor de Open Health Imaging Foundation (OHIF) y el visor de Weasis.

Antes de empezar

Si no has almacenado ninguna imagen DICOM para usarla en el visor, consulta Almacenar datos DICOM y Importar y exportar datos DICOM mediante Cloud Storage para empezar.

Autorizar y autenticar solicitudes mediante OAuth 2.0

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

Un visor médico debe gestionar la autenticación y la autorización para acceder a los datos DICOM almacenados en la API Cloud Healthcare. Puedes conceder estos permisos de dos formas. Cada método tiene sus propios costes y ventajas:

Usar el flujo de OAuth 2.0 de Servicios de Identidad de Google

  • Los usuarios finales se autentican a través del visor médico en la API Cloud Healthcare.
  • El visor médico accede a la API Cloud Healthcare en nombre del usuario final.
  • Los permisos se gestionan a nivel de usuario y las acciones de los usuarios se registran en Cloud Audit Logs con el identificador único del usuario.
  • Usar el flujo de Servicios de Identidad de Google es más complejo que usar una cuenta de servicio. Por ejemplo, tu aplicación debe gestionar las retrollamadas para almacenar el token de autorización, lo que puede añadir una complejidad innecesaria a una aplicación sencilla.

Usar una cuenta de servicio

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

Autorizar mediante el flujo de OAuth 2.0 de Servicios de Identidad de Google

Puedes autorizar a un visor médico para que acceda a los datos DICOM almacenados en la API Cloud Healthcare en nombre de un usuario mediante el flujo de OAuth 2.0 de los servicios de identidad de Google. En función de la aplicación, existen flujos disponibles para las siguientes aplicaciones:

En la siguiente descripción del flujo de inicio de sesión se da por sentado que el usuario que accede al visor ha creado un almacén DICOM y ha almacenado instancias DICOM en el almacén:

  1. Un usuario abre la aplicación de visor médico. El visor muestra una ventana de consentimiento de Google que contiene el nombre de la aplicación y los servicios de la API de Google para los que se solicita permiso de acceso con las credenciales de autorización del usuario. A continuación, el usuario puede aceptar o rechazar el acceso a la aplicación.
  2. Se redirige al usuario a una página de Servicios de Identidad de Google. Si el usuario concede el acceso solicitado a la aplicación, esta obtiene permiso para acceder a los datos del usuario.

No almacenes tokens de actualización en el visor. Los tokens de acceso concedidos por el usuario al visor deben ser de corta duración y solo deben intercambiarse cuando los tokens venzan.

Los tokens de actualización tampoco son necesarios por los siguientes motivos:

  • El usuario siempre estará presente al utilizar el visor.
  • El uso de tokens de actualización exige más trabajo para almacenarlos de forma segura.

Autorizar mediante una cuenta de servicio

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

Para obtener instrucciones sobre cómo usar una cuenta de servicio para autenticar un visor médico en la API Cloud Healthcare, consulta el artículo Autenticación en la API.

Roles obligatorios

Para que el visor funcione correctamente, el usuario debe contar con los siguientes roles:

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

En el flujo de inicio de sesión, se espera que el usuario ya haya configurado estos roles y que el visor no tenga que hacer nada más. Cuando se usa una cuenta de servicio, los roles deben definirse en la cuenta de servicio. El visor debería mostrar los errores PERMISSION_DENIED correspondientes a los usuarios que no tengan los permisos necesarios para acceder a sus almacenes DICOM.

Acceder a los puntos de conexión DICOMweb

Una vez que el usuario se autentica en el visor, este puede realizar solicitudes a los endpoints de DICOMweb. Cada almacén DICOM muestra un único punto de conexión DICOMweb.

Cuando el usuario se encuentra en el visor, debe especificar a qué proyectos y almacenes DICOM desea acceder. Lo más sencillo es pedirle al usuario que proporcione los IDs del proyecto, del conjunto de datos y del almacén DICOM a los que quiere acceder. Sin embargo, proporcionar cada valor individual puede llevar mucho tiempo al usuario.

Como alternativa, puedes ofrecer una combinación de datos que deberá introducir el usuario y valores autocompletados en el visor. Por ejemplo, puedes solicitar al usuario que introduzca un ID de proyecto, tras lo cual el visor rellenará automáticamente una lista de conjuntos de datos y almacenes DICOM de dicho proyecto. Otra opción consistiría en proporcionar un único campo de entrada de información que rellene automáticamente los proyectos, conjuntos de datos y almacenes DICOM a los que el usuario tiene acceso. Los siguientes métodos de API pueden resultar útiles para configurar cualquiera de estas alternativas:

También puedes plantearte la posibilidad de rellenar previamente una lista de los recursos del usuario. Sin embargo, si un usuario tiene cientos o miles de almacenes o conjuntos de datos DICOM, es posible que no sea viable rellenar previamente y mostrar la lista.

Acceder a los recursos del visor mediante DICOMweb

La API Cloud Healthcare es compatible con el estándar 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 antiguos.

Todo visor cuenta con dos componentes principales:

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

Puedes utilizar el estándar DICOMweb con ambos componentes.

Visualizar el proveedor de la lista de trabajo

Normalmente, lo primero que un usuario ve cuando abre un visor es una lista de todos los estudios disponibles en cada almacén DICOM. El visor puede recuperar estos estudios mediante la búsqueda de transacciones.

Consulta la declaración de conformidad de DICOM de la API Cloud Healthcare para obtener información específica sobre cómo se implementa la transacción de búsqueda en la API Cloud Healthcare.

Visualizar las instancias

Una vez que el usuario se encuentre en el proveedor de la lista de trabajo, lo más habitual es que seleccione un estudio para verlo. Para renderizar el estudio, el visor debe acceder a los bytes por píxel sin formato del estudio y a los metadatos DICOM. El visor puede recuperar esta información utilizando el conjunto de métodos Retrieve Transaction. Los métodos Retrieve Transaction permiten recuperar un archivo DICOM sin formato completo o los datos de píxel sin formato del archivo. Los métodos Retrieve Transaction también admiten la transcodificación entre diferentes sintaxis de transferencia.

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

Maximizar el rendimiento de la red

En algunos casos, como cuando se procesa una tomografía computarizada, es posible que un visor necesite descargar muchas instancias al mismo tiempo para procesar la imagen. Para lograr los mejores resultados, obtén cada instancia en paralelo utilizando un gran número de solicitudes simultáneas (por ejemplo, 50 o más). El número exacto dependerá de la aplicación y del ancho de banda de la red.