Cette page présente les concepts et les bonnes pratiques liés à l'intégration d'une visionneuse d'imagerie médicale tierce à 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.
Avant de commencer
Si vous n'avez pas stocké d'images DICOM à utiliser dans votre visionneuse, consultez les sections Stocker des données DICOM et Importer et exporter des données DICOM à l'aide de Cloud Storage pour commencer.
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 :
Utiliser le flux OAuth 2.0 de Google Identity Services
- 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 Google Identity Services 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.
- 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 à l'aide d'un compte de service est plus simple que d'utiliser le flux Google Identity Services. 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 Identity Services 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 Identity Services OAuth 2.0. Selon votre application, des flux sont disponibles pour les applications suivantes :
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 :
- 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.
- L'utilisateur est redirigé vers une page Google Identity Services. 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 DICOMroles/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 :
projects.list: répertorie les projets visibles par l'utilisateur et répondant à un filtre spécifié.projects.locations.list: répertorie les informations sur les emplacements compatibles avec l'API Cloud Healthcare.projects.locations.datasets.list: répertorie les ensembles de données de l'API Cloud Healthcare dans un projet.projects.locations.datasets.dicomStores.list: répertorie les stores DICOM d'un ensemble de données.
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
- Visionneuse 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 l'ensemble de méthodes Transaction de récupération. Les méthodes Transaction de récupération 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 récupération acceptent également le transcodage entre différentes syntaxes de transfert.
Reportez-vous à la déclaration de conformité DICOM de l'API Cloud Healthcare pour plus de détails sur la mise en œuvre des méthodes de recherche et de récupération des transactions 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.