Integração com um visualizador médico DICOM

Esta página explica os conceitos e as práticas recomendadas para integrar um visualizador de imagens médicas de terceiros com a Cloud Healthcare API. A Cloud Healthcare API está integrada com vários visualizadores, incluindo o visualizador da Open Health Imaging Foundation (OHIF) e o visualizador Weasis.

Antes de começar

Se não tiver armazenado imagens DICOM para usar no visualizador, consulte os artigos Armazene dados DICOM e Importar e exportar dados DICOM com o Cloud Storage para começar.

Autorizar e autenticar pedidos através do OAuth 2.0

Google Cloud As APIs suportam o protocolo OAuth 2.0 para autenticação e autorização.

Um visualizador médico tem de processar a autenticação e a autorização para aceder aos dados DICOM armazenados na Cloud Healthcare API. Pode conceder estas autorizações de duas formas. Cada método tem os seus próprios custos e vantagens:

Usar o fluxo OAuth 2.0 dos serviços de identidade da Google

  • Os utilizadores finais autenticam-se através do visualizador médico na API Cloud Healthcare.
  • O visualizador médico acede à Cloud Healthcare API em nome do utilizador final.
  • As autorizações são geridas ao nível do utilizador e as ações do utilizador são registadas nos registos de auditoria do Google Cloud com o identificador exclusivo do utilizador.
  • A utilização do fluxo dos serviços de identidade da Google é mais complexa do que a utilização de uma conta de serviço. Por exemplo, a sua aplicação tem de processar callbacks para armazenar o token de autorização, o que pode adicionar complexidade desnecessária a uma aplicação simples.

Usar uma conta de serviço

  • Configura o visualizador médico para usar o seu próprio método de autorização e controlo de acesso para determinar se um utilizador final pode ver um determinado recurso da Cloud Healthcare API. A utilização de uma conta de serviço é útil se já tiver um visualizador que execute as suas próprias verificações de autenticação e gestão de utilizadores.
  • As ações realizadas no visualizador são registadas nos registos de auditoria da nuvem, mas não pode ver registos ao nível dos utilizadores finais individuais.
  • A autenticação através de uma conta de serviço é mais simples do que usar o fluxo dos Google Identity Services. Por exemplo, não é necessário pedir a um utilizador para iniciar sessão e, por isso, não é necessário armazenar uma chave de acesso.

Autorizar através do fluxo OAuth 2.0 dos serviços de identidade da Google

Pode autorizar um visualizador médico a aceder aos dados DICOM armazenados na Cloud Healthcare API em nome de um utilizador através do fluxo do OAuth 2.0 dos serviços de identidade Google. Dependendo da sua aplicação, existem fluxos disponíveis para as seguintes aplicações:

A descrição seguinte do fluxo de início de sessão pressupõe que o utilizador que acede ao visualizador criou um arquivo DICOM e armazenou instâncias DICOM no arquivo:

  1. Um utilizador abre a sua aplicação de visualização médica. O visualizador apresenta uma janela de consentimento da Google que mostra o nome da sua aplicação e os serviços da API Google para os quais está a pedir autorização de acesso com as credenciais de autorização do utilizador. Em seguida, o utilizador pode dar ou recusar o consentimento para conceder acesso à sua aplicação.
  2. O utilizador é enviado para uma página dos Serviços de identidade Google. Se o utilizador conceder à sua aplicação o acesso pedido, a aplicação recebe autorização para aceder aos dados do utilizador.

Não armazene tokens de atualização no visualizador. Os tokens de acesso concedidos ao visualizador pelo utilizador devem ter uma duração curta e só devem ser trocados quando os tokens expiram.

Os tokens de atualização também são desnecessários pelos seguintes motivos:

  • O utilizador está sempre presente quando usa o visualizador.
  • A utilização de tokens de atualização requer trabalho adicional para armazenar o token de forma segura.

Autorizar através de uma conta de serviço

Pode gerir a autenticação e a autorização ao nível do visualizador médico, em vez de ao nível de um utilizador final, através do OAuth 2.0 com uma conta de serviço.

Para obter instruções sobre como usar uma conta de serviço para autenticar um visualizador médico na API Cloud Healthcare, consulte o artigo Autenticação na API.

Funções necessárias

Para que o visualizador funcione corretamente, um utilizador tem de ter as seguintes funções:

  • roles/healthcare.dicomViewer: para ver recursos DICOM
  • roles/healthcare.dicomEditor: para ver, editar e criar recursos DICOM

No fluxo de início de sessão, espera-se que o utilizador já tenha configurado estas funções e o visualizador não precisa de fazer mais nada. Quando usar uma conta de serviço, as funções têm de ser definidas na conta de serviço. O visualizador deve devolver erros PERMISSION_DENIED adequados aos utilizadores que não têm as autorizações necessárias para aceder aos respetivos arquivos DICOM.

Aceder a pontos finais DICOMweb

Depois de o utilizador se autenticar no visualizador, este pode fazer pedidos a pontos finais DICOMweb. Cada loja DICOM expõe um único ponto final DICOMweb.

Quando o utilizador está no visualizador, tem de especificar os projetos e os arquivos DICOM aos quais quer aceder. O processo mais simples é pedir ao utilizador que faculte os IDs do projeto, do conjunto de dados e do arquivo DICOM aos quais quer aceder. No entanto, fornecer cada valor individual pode demorar muito tempo ao utilizador.

Em alternativa, pode fornecer uma combinação de introdução do utilizador e conclusão automática no visualizador. Por exemplo, pode pedir ao utilizador que introduza um ID do projeto e, em seguida, o visualizador preenche automaticamente uma lista dos conjuntos de dados e das lojas DICOM nesse projeto. Em alternativa, pode fornecer um único campo de entrada que preenche automaticamente os projetos, os conjuntos de dados e os arquivos DICOM aos quais o utilizador tem acesso. Os seguintes métodos da API podem ser úteis ao configurar qualquer uma destas alternativas:

Também pode considerar pré-preencher uma lista dos recursos de um utilizador. No entanto, se um utilizador tiver centenas ou milhares de conjuntos de dados ou armazenamentos DICOM, o pré-enchimento e a apresentação da lista podem ser inviáveis.

Aceder a recursos no visualizador através do DICOMweb

A API Cloud Healthcare suporta a norma DICOMweb. Para permitir que os utilizadores acedam aos respetivos dados, o visualizador tem de implementar os métodos HTTP RESTful DICOMweb em vez dos protocolos DIMSE antigos.

Existem dois componentes principais em qualquer visitante:

  • O fornecedor da lista de tarefas
  • O visualizador de imagens

Pode usar a norma DICOMweb com ambos os componentes.

Ver o fornecedor da lista de tarefas

Normalmente, a primeira coisa que um utilizador vê quando abre um visualizador é uma lista de todos os estudos disponíveis em cada loja DICOM. O visitante pode obter estes estudos através da transação de pesquisa.

Consulte a declaração de conformidade com a norma DICOM da Cloud Healthcare API para ver detalhes sobre como a transação de pesquisa é implementada na Cloud Healthcare API.

Visualizar instâncias

Depois de o utilizador estar no fornecedor da lista de trabalho, normalmente, seleciona um estudo para visualização. Para renderizar o estudo, o visualizador tem de aceder aos bytes de píxeis brutos do estudo e aos metadados DICOM. O visitante pode obter estas informações através do conjunto de métodos Retrieve Transaction. Os métodos Retrieve Transaction permitem-lhe obter um ficheiro DICOM não processado completo ou os dados de píxeis não processados do ficheiro. Os métodos Retrieve Transaction também suportam a transcodificação entre diferentes sintaxes de transferência.

Consulte a declaração de conformidade com a norma DICOM da Cloud Healthcare API para ver detalhes sobre como os métodos de transação de pesquisa e obtenção são implementados na Cloud Healthcare API.

Maximizar a taxa de transferência da rede

Por vezes, como ao renderizar uma tomografia axial computorizada, um visitante pode ter de transferir muitas instâncias de uma vez para renderizar a imagem. Para obter os melhores resultados, obtenha cada instância em paralelo com um número elevado de pedidos simultâneos (como 50 ou mais). O número exato depende da sua aplicação e da largura de banda da rede.