Michael JohnsonLes organisations de santé pourront confier à une plateforme d’IA le traitement de données issues de différents systèmes et le lancement de processus cliniques et administratifs en plusieurs étapes. Google Cloud a annoncé Gemini for Healthcare le 10 novembre 2026 ; le produit est disponible en préversion pour les organismes de santé et les régimes d’assurance maladie.
Le changement concret consiste à passer de la recherche d’informations à l’exécution d’une suite d’actions. Le service peut rassembler le dossier d’un patient, préparer les éléments nécessaires à une consultation ou aider à vérifier la couverture d’assurance et à obtenir une autorisation préalable. Google présente le système comme une plateforme agentique qui s’appuie sur des compétences spécialisées et des connecteurs pour déterminer l’étape suivante, selon des règles définies et sous supervision humaine.
Quelles données le service réunit-il ?
Dans les établissements de santé, les informations nécessaires à une décision sont souvent réparties entre le dossier médical électronique, la facturation, les recommandations cliniques et les bases de données administratives. Gemini for Healthcare connecte ces sources et les interprète conjointement. Pour les dossiers médicaux électroniques, Google a annoncé des intégrations avec Epic via les API open.epic et avec Oracle Health via les API Ignite pour FHIR. Ces connexions sont en lecture seule : les données sont extraites dans le contexte de travail, sans possibilité de les réécrire dans le système de dossiers médicaux.
Cette séparation a une utilité pratique. Le personnel peut consulter une synthèse des informations pour préparer une consultation ou examiner une demande, tandis que le dossier original reste dans le système source. L’entreprise a indiqué que la connexion à NextGen Healthcare était en cours de développement et devrait être lancée dans les prochains mois : à la date de l’annonce, il s’agissait d’une intégration à venir, et non d’une fonctionnalité disponible.
Outre les dossiers médicaux, l’annonce mentionne des sources de données réglementaires et de référence : des documents des Centers for Medicare & Medicaid Services, le registre National Provider Identifier, RxNorm et ICD-10. Les connecteurs de partenaires doivent élargir l’accès aux applications médicales et aux systèmes administratifs. L’étendue des connexions disponibles dépend de chaque intégration : Google a ainsi décrit l’intégration d’Optum Network Eligibility and Coordination of Benefits comme étant en diffusion limitée et en phase de test.
À qui la préversion est-elle ouverte ?
Parmi les organisations participant au lancement de la préversion, Google a cité Blue Cross Blue Shield of Massachusetts, Hartford HealthCare, HCA Healthcare, Highmark Health, Northwell Health, Optum et Stanford School of Medicine. Il s’agit de partenaires et de clients de lancement, et non de la preuve que le service est déjà disponible pour tous les organismes de santé. Google précise que Gemini for Healthcare est destiné aux clients de Gemini Enterprise Standard et Plus.
Les règles d’accès aux données annoncées sont importantes pour les équipes informatiques. Google indique que les connecteurs conservent les autorisations fondées sur les rôles déjà définies dans les systèmes de l’organisation et que les réponses peuvent inclure des liens vers les dossiers médicaux, les guides et les sources utilisés. Selon l’entreprise, les données des clients — notamment les dossiers médicaux, les requêtes et les réponses — restent dans l’environnement cloud dédié de l’organisation et ne servent pas à entraîner les modèles de base de Google.
Ces mécanismes constituent une base pour le contrôle, mais imposent des exigences concrètes lors du déploiement : l’organisation doit définir les sources autorisées pour chaque cas d’usage, désigner les personnes chargées de vérifier la réponse et déterminer qui valide les décisions à conséquences importantes. Pour les décisions médicales, Google prévoit explicitement l’intervention de professionnels qualifiés ; l’automatisation aide à rassembler le contexte et à exécuter le processus, tandis que la décision professionnelle revient au personnel responsable.
Ce qui change pour les établissements de santé et les équipes d’assurance
Pour les équipes cliniques, le cas d’usage annoncé consiste à rassembler plus rapidement le dossier du patient à partir de plusieurs systèmes et à le préparer pour une consultation. Pour les équipes d’assurance et d’administration, il s’agit de relier les informations de couverture, les règles et les documents lors de l’examen d’une demande. L’IA ne se limite ainsi plus à une fenêtre autonome de questions-réponses : elle devient une couche qui coordonne les actions entre les outils existants.
Google cite une estimation selon laquelle les cliniciens consacrent près de 28 heures par semaine à la documentation et aux tâches administratives. Il s’agit d’un élément de contexte fourni par l’entreprise et renvoyant à une étude de Harris Poll et Google Cloud, et non d’un gain mesuré de Gemini for Healthcare. L’annonce ne présente pas encore de résultats de déploiement indiquant le temps que la plateforme fait réellement gagner aux premiers clients.
Pour un acheteur potentiel, une première étape utile consiste à faire correspondre un processus précis à ses sources de données et à ses limites d’autorité : par exemple, vérifier si la préparation d’une consultation peut s’appuyer sur les dossiers Epic, quelles recommandations peuvent être prises en compte et quel membre du personnel valide la synthèse finale. Il convient ensuite de vérifier la disponibilité des intégrations nécessaires et de contrôler quelles sources sont citées dans la réponse. Ce test permet d’évaluer la pertinence de la préversion pour le processus de travail sans confondre l’automatisation promise avec des résultats déjà confirmés.
C’est l’association de données cliniques, de sources administratives et de tâches encadrées en plusieurs étapes qui distingue ce lancement d’un assistant conversationnel classique. Au départ, le service s’adresse aux organisations prêtes à tester la préversion sur des cas d’usage limités ; pour les autres, les repères essentiels sont les intégrations déjà disponibles et la manière dont la plateforme justifie ses réponses.
