Intégrer un lecteur médical DICOM

Cette page explique comment intégrer un lecteur d'imagerie médicale tiers à l'API Cloud Healthcare. L'API Cloud Healthcare est intégrée à plusieurs lecteurs, y compris le lecteur Open Health Imaging Foundation (OHIF) et le lecteur Weasis.

Autoriser et authentifier des requêtes à l'aide d'OAuth 2.0

Les API Google Cloud sont compatibles avec le protocole OAuth 2.0 pour l'authentification et l'autorisation.

Un lecteur médical doit gérer l'authentification et l'autorisation d'accéder aux données DICOM stockées dans l'API Cloud Healthcare. Vous pouvez accorder ces autorisations de deux manières. Chaque méthode présente ses propres coûts et avantages:

Utilisation du flux Google sign-in OAuth 2.0

  • Les utilisateurs finaux s'authentifient dans l'API Cloud Healthcare via le lecteur médical.
  • Le lecteur médical accède à l'API Cloud Healthcare pour le compte de l'utilisateur final.
  • Les autorisations sont gérées au niveau de l'utilisateur et ses actions sont consignées dans les journaux d'audit Cloud avec l'identifiant unique de l'utilisateur.
  • L'utilisation du flux de connexion Google est plus complexe que l'utilisation d'un compte de service. Par exemple, votre application doit gérer les rappels pour stocker le jeton d'autorisation, ce qui peut inutilement transformer une application simple en application complexe.

Utiliser un compte de service

  • Vous configurez le lecteur médical pour qu'il utilise sa propre méthode d'autorisation et de contrôle des accès afin de déterminer si un utilisateur final peut afficher une ressource d'API Cloud Healthcare donnée. L'utilisation d'un compte de service est utile si un lecteur effectue déjà ses propres contrôles de gestion des utilisateurs et d'authentification.
  • Les actions effectuées dans le lecteur sont consignés dans des journaux d'audit Cloud, mais vous ne pouvez pas afficher les journaux au niveau des utilisateurs finaux individuels.
  • L'authentification via un compte de service est plus simple que via le flux Google Sign-In. Par exemple, il n'est pas nécessaire d'inviter un utilisateur à se connecter et donc inutile de stocker un jeton d'accès.

Autorisation à l'aide du flux Google sign-in OAuth 2.0.

Vous pouvez autoriser un lecteur médical à accéder aux données DICOM stockées dans l'API Cloud Healthcare au nom d'un utilisateur à l'aide du flux Google Sign-In OAuth 2.0. Selon votre application, des flux sont disponibles pour les applications de serveur Web, les applications mobiles et de bureau, les applications Web JavaScript, etc.

La description du flux de connexion ci-dessous suppose que l'utilisateur accédant au lecteur a créé un magasin DICOM et y a stocké des instances DICOM .

En général, le flux de connexion comprend les étapes suivantes:

  1. Un utilisateur ouvre votre application de lecteur médical. Le lecteur affiche une fenêtre de consentement Google indiquant le nom de votre application et les services de l'API Google auxquels il demande l'autorisation d'accéder à l'aide des identifiants de l'utilisateur. L'utilisateur peut alors accepter ou refuser d'accorder l'accès à votre application.
  2. L'utilisateur est redirigé vers une page de connexion Google. Si l'utilisateur accorde à votre application l'accès demandé, celle-ci obtient l'autorisation d'accéder aux données de l'utilisateur.

Ne stockez pas de jetons d'actualisation dans le lecteur. Les jetons d'accès accordés au lecteur par l'utilisateur doivent être de courte durée et échangés uniquement lorsque les jetons expirent.

Les jetons d'actualisation sont également inutiles pour les raisons suivantes:

  • L'utilisateur est toujours présent lors de l'utilisation du lecteur.
  • L'utilisation des jetons d'actualisation nécessite un travail supplémentaire pour stocker le jeton en toute sécurité

Accorder l'autorisation à l'aide d'un compte de service

Vous pouvez gérer l'authentification et l'autorisation au niveau du lecteur médical, plutôt qu'au niveau d'un utilisateur final, en utilisant OAuth 2.0 avec un compte de service.

Pour obtenir des instructions sur l'utilisation d'un compte de service pour authentifier un lecteur médical auprès de l'API Cloud Healthcare, consultez la page S'authentifier auprès de l'API.

Rôles requis

Pour que le lecteur fonctionne correctement, un utilisateur doit disposer des rôles suivants:

  • roles/healthcare.dicomViewer (pour afficher les ressources DICOM)
  • roles/healthcare.dicomEditor (pour afficher, modifier et créer des ressources DICOM)

Dans le flux de connexion, l'utilisateur devrait déjà avoir configuré ces rôles et le lecteur ne devrait avoir rien d'autre à faire. Lorsque vous utilisez un compte de service, les rôles doivent être définis dans le compte de service. Le lecteur doit renvoyer les erreurs PERMISSION_DENIED appropriées aux utilisateurs ne disposant pas des autorisations requises pour accéder aux magasins DICOM.

Accéder aux points de terminaison DICOMweb

Une fois que l'utilisateur s'est authentifié auprès du lecteur, celui-ci peut envoyer des requêtes aux points de terminaison DICOMweb. Chaque magasin DICOM expose un seul point de terminaison DICOMweb.

Lorsque l'utilisateur a accès au lecteur, il doit spécifier les projets et les magasins DICOM auxquels il souhaite accéder. Le processus le plus simple consiste à demander à l'utilisateur de fournir les ID du projet, de l'ensemble de données et du magasin DICOM auxquels il souhaite accéder. Cependant, la saisie de chaque valeur peut prendre beaucoup de temps.

Vous pouvez également combiner la saisie utilisateur et la saisie semi-automatique dans le lecteur. Par exemple, vous pouvez demander à l'utilisateur de saisir un ID de projet, puis le lecteur renseignera automatiquement une liste des ensembles de données et des magasins DICOM de ce projet. Vous pouvez également fournir un seul champ de saisie qui renseigne automatiquement les projets, les ensembles de données et les magasins DICOM auxquels l'utilisateur a accès. Les méthodes d'API suivantes peuvent être utiles pour configurer l'une de ces alternatives:

Vous pouvez également envisager de préremplir la liste des ressources d'un utilisateur. Toutefois, si un utilisateur possède des centaines ou des milliers de magasins ou d'ensembles de données DICOM, il peut être impossible de préremplir et d'afficher la liste.

Accéder aux ressources du lecteur à l'aide de DICOMweb

L'API Cloud Healthcare est compatible avec la norme DICOMweb. Pour permettre aux utilisateurs d'accéder à leurs données, le lecteur doit mettre en œuvre les méthodes HTTP RESTful DICOMweb au lieu d'utiliser les anciens protocoles DIMSE.

Chaque lecteur comporte deux composants principaux: le fournisseur de liste de travail et le lecteur d'images. Vous pouvez utiliser la norme DICOMweb avec les deux composants.

Afficher le fournisseur de liste de travail

Généralement, la première chose qu'un utilisateur voit lorsqu'il ouvre un lecteur est une liste de toutes les études disponibles dans chaque magasin DICOM. Le lecteur peut récupérer ces études à l'aide de la transaction de recherche.

Consultez la déclaration de conformité DICOM de l'API Cloud Healthcare pour en savoir plus sur la manière dont la transaction de recherche est mise en œuvre dans l'API Cloud Healthcare.

Afficher les instances

Une fois que l'utilisateur a accès au fournisseur de liste de travail, il sélectionne généralement une étude à afficher. Pour afficher l'étude, le lecteur doit accéder aux octets de pixels bruts et aux métadonnées DICOM de l'étude. Le lecteur peut récupérer ces informations à l'aide de la famille de méthodes "Transaction de recherche". Les méthodes Transaction de recherche vous permettent de récupérer l'intégralité d'un fichier DICOM brut ou les données de pixel brutes du fichier. Les méthodes de transaction de recherche acceptent également le transcodage entre différentes syntaxes de transfert.

Consultez la déclaration de conformité DICOM de l'API Cloud Healthcare pour en savoir plus sur la mise en œuvre de cette méthode dans l'API Cloud Healthcare.

Maximiser le débit du réseau

Parfois, par exemple, lors du rendu d'une analyse, un lecteur peut avoir besoin de télécharger plusieurs instances à la fois pour afficher l'image. Pour de meilleurs résultats, récupérez chaque instance en parallèle en utilisant un nombre élevé de requêtes simultanées (50 ou plus). Le nombre exact dépend de votre application et de la bande passante réseau.