ElevenAgents pour la santé : créez un agent de planification des rendez-vous entrants

Le téléphone reste la porte d’entrée des soins de santé, et elle est encombrée. Les recherches de la Mayo Clinic recherches et l’étude de cas d’Epic étude de cas montrent toutes deux qu’environ 30 % des prises de rendez-vous ont lieu en dehors des heures ouvrables. Les appels qui aboutissent sur une messagerie sont autant de rendez-vous qui n’ont discrètement jamais lieu, tandis que le personnel d’accueil censé les traiter est débordé et se renouvelle rapidement. Agents vocaux ont dépassé le stade de la démonstration pour aider les cliniques à combler ce manque. La prise de rendez-vous est leur point d’entrée le plus courant : un volume élevé, des tâches répétitives et prévisibles, et une part importante de la charge d’accueil qui ne requiert aucun jugement clinique.

La prise de rendez-vous dans le secteur de la santé exige aussi davantage de rigueur. Un mauvais créneau ou un motif de consultation mal entendu ne constituent pas seulement une mauvaise expérience : c’est un incident de sécurité et de conformité. Un agent de prise de rendez-vous à l’accueil a besoin de plus qu’une voix agréable : une vérification fiable de l’identité, des garde-fous stricts, un parcours d’escalade clair vers un humain, les garanties de conformité nécessaires au traitement des informations de santé protégées, et la capacité d’effectuer, modifier ou annuler des réservations dans un véritable système de planification.

Ce guide vous montre comment créer cela avec ElevenAgents : un agent accessible par téléphone, connecté à un exemple de DSE, qui prend, reprogramme et annule des rendez-vous de bout en bout, et transmet l’appel lorsque nécessaire. Vous disposerez du workflow, des garde-fous, des tests et des analyses pour le maintenir dans le cadre prévu, sur une infrastructure conçue pour un secteur de santé réglementé.

Voici une démonstration de l’agent que vous allez créer, gérant un appel en direct de bout en bout :

Prérequis

Pour commencer, vous aurez besoin des éléments suivants :

• Un compte ElevenLabs, avec accès à la plateforme ElevenAgents et à nos voix.
• Un compte Twilio et un numéro.
• Un accès à Twilio Verify.
• Un environnement DSE sandbox ou développeur. Dans ce guide, nous utiliserons HAPI FHIR, une implémentation de référence open source du format HL7 FHIR, afin de valider les données par rapport à des dossiers patients synthétiques.
• L’application de calendrier de votre cabinet. Pour ce guide, nous utilisons l’intégration native d’ElevenLabs avec Cal.com. 

Facultatif

Si vous n’avez pas accès à des données sandbox, ou si vous suivez ce guide à des fins de démonstration, nous utiliserons le serveur sandbox HAPI FHIR R4 et l’initialiserons avec un dossier patient fictif à utiliser lors de l’étape de vérification. Pour cela, exécutez la commande API suivante avec des données fictives depuis votre terminal :

curl -X POST "https://hapi.fhir.org/baseR4/Patient" \
  -H "Content-Type: application/fhir+json" \
  -H "Accept: application/fhir+json" \
  -d '{
    "resourceType": "Patient",
    "identifier": [
      { "system": "http://hospital.example.org/mrn", "value": "<YOUR-FAKE-MRN-NUMBER>" }
    ],
    "name": [ { "use": "official", "family": "<YOUR-FAKE-FAMILY-NAME>", "given": [ "<YOUR-FAKE-GIVEN-NAME>" ] } ],
    "gender": "<male or female>",
    "birthDate": "<YOUR-FAKE-DOB> (in YYYY-MM-DD format)"
  }'

Une correspondance n’est confirmée que si la requête renvoie exactement un dossier : zéro résultat signifie qu’il n’y a aucune correspondance, et plusieurs résultats indiquent que les paramètres de recherche ne sont pas assez précis pour poursuivre en toute sécurité. 

Architecture

Dans ce guide, vous créerez un agent de prise de rendez-vous fonctionnant via un numéro Twilio et intégré nativement à votre ElevenAgent. Lorsqu’un appel entrant est établi, l’agent accompagne le patient à l’aide des outils disponibles pour recueillir les informations de vérification et de rendez-vous, qu’il souhaite prendre un nouveau rendez-vous, reprogrammer ou annuler un rendez-vous existant, avec la possibilité de transférer l’appel à un humain si nécessaire.

Avec cette architecture et ces outils, le déroulement d’un appel réussi comprend les étapes suivantes :

1. Début de l’appel : un patient appelle le numéro Twilio associé à l’agent, qui le salue et recueille son intention.
2. Validation DSE : l’agent valide les informations du patient par rapport à son dossier dans le DSE.
3. Vérification : l’agent envoie un mot de passe à usage unique (OTP) au numéro de téléphone du patient pour une vérification finale, à l’aide de son outil SMS.
4. Réservation ou modification : l’agent agit selon l’intention recueillie dans le calendrier : pour un nouveau rendez-vous, il recueille les détails de réservation et vérifie les disponibilités ; pour une reprogrammation, il retrouve le rendez-vous existant et cherche un nouveau créneau ; pour une annulation, il confirme et supprime le rendez-vous existant.
5. Transfert : si la réservation ou la modification échoue, si le patient demande à parler à un humain ou si l’agent recueille toute autre intention qu’il ne peut pas traiter, l’appel est transféré à un agent humain.
6. Confirmation et clôture : après une réservation, une reprogrammation ou une annulation réussie, l’agent récapitule les détails de l’appel et conclut chaleureusement.

Prompt système et paramètres de l’agent

La première étape pour créer un ElevenAgent efficace réside dans son prompt système. En suivant le guide de prompting d’ElevenLabs, nous le structurons autour des éléments fondamentaux recommandés pour tout agent en production : personnalité, objectif, ton, outils et garde-fous, chacun dans sa propre section clairement identifiée plutôt que dans un bloc d’instructions unique.

Pour un agent de prise de rendez-vous dans le secteur de la santé, cette structure doit tenir compte de la personne réellement au bout du fil : une personne âgée, souffrante, malentendante ou simplement anxieuse quant à la raison de son appel. Les sections consacrées à la personnalité et au ton instaurent un rythme chaleureux et sans précipitation, avec des réponses courtes et conversationnelles ; les dates, heures et nombres sont énoncés comme une personne les dirait, et non lus à l’écran. La section Objectif décrit le flux dans un ordre précis : vérifier l’identité, puis, selon que l’appelant veut prendre, reprogrammer ou annuler un rendez-vous, vérifier les disponibilités et confirmer le créneau, rechercher et déplacer le rendez-vous existant, ou confirmer le rendez-vous à supprimer. Les outils sont documentés avec les données d’entrée exactes qu’ils attendent sous forme orale. Les garde-fous regroupent les règles propres à ce domaine : ne jamais divulguer plus d’informations de santé protégées que l’appelant n’en a déjà communiquées, ne jamais inventer de disponibilité ou de détail de rendez-vous lorsqu’un outil échoue, refuser les questions cliniques au profit du professionnel de santé de l’appelant, et escalader immédiatement lorsqu’une personne décrit des symptômes urgents ou une urgence médicale. La vérification de l’identité avant toute action sur un rendez-vous est la seule règle répétée plutôt qu’énoncée une fois. C’est celle que l’agent ne peut le moins se permettre d’omettre.

Vous pouvez ensuite ajouter des configurations d’agent supplémentaires, telles que le premier message, différentes langues (vérifiez que l’outil système de détection de langue est activé), le LLM de votre choix, un modèle de synthèse vocale conversationnel d’ElevenLabs et une voix ElevenLabs.

Vous trouverez un exemple de prompt système ici.

Garde-fous

La section Garde-fous du prompt système couvre les règles au niveau des instructions et le modèle lui accorde un poids important. Mais un prompt reste une couche non déterministe susceptible de dériver au cours d’un long appel. ElevenAgents les complète par une application indépendante à l’exécution via ses propres Guardrails. Ces derniers comprennent le Focus Guardrail, qui renforce le prompt système au fil des conversations longues, les Manipulation Guardrails, qui détectent les tentatives d’injection de prompt avant que l’agent réponde, et les Content et Custom Guardrails, qui évaluent chaque réponse en temps réel et peuvent la bloquer avant que l’appelant ne l’entende. Chaque garde-fou est configuré avec un mode d’exécution : streaming pour une latence quasi nulle, ou blocking pour retenir une réponse jusqu’à sa validation, ainsi qu’une stratégie de sortie en cas de déclenchement : mettre fin à l’appel ou réessayer en injectant un retour correctif au tour suivant.

Pour cet agent, vous pouvez définir des garde-fous personnalisés pour les règles propres au secteur de la santé ou à la clinique : bloquer le diagnostic de pathologies ou les recommandations de traitement, les questions de facturation, les conseils de posologie et tout ce qui se substitue à l’avis d’un clinicien agréé. En cas de symptômes urgents, configurez la stratégie de sortie pour réessayer avec un retour qui transférera l’appel à un humain, afin que le garde-fou transmette l’appel au personnel plutôt que de simplement y mettre fin.

Outils

Chaque étape du flux nécessitera des outils de webhook et d’intégration spécifiques pour effectuer certaines actions tout en parlant avec le patient.

Outil de vérification DSE

Pour vérifier le patient par rapport à son dossier dans le DSE, nous utiliserons l’action API FHIR GET /Patient. Ajoutez-la comme outil de webhook pointant vers votre URL de base HAPI FHIR, avec family, given, identifier et birthdate définis comme paramètres renseignés par le LLM. Le premier appel d’outil de l’étape Vérification atteint le point de terminaison avec le nom et la date de naissance de l’appelant dans une requête unique :

GET /baseR4/Patient?family={lastName}&given={firstName}&birthdate={YYYY-MM-DD}

Une correspondance n’est confirmée que si la requête renvoie exactement un dossier, et l’agent ne peut passer à l’étape Réservation que si cette condition est remplie.

Vous trouverez un exemple JSON de l’outil ici.

Outils de vérification SMS Twilio

Une fois la correspondance DSE confirmée, l’étape Vérification passe à un second facteur : envoyer au patient un code à usage unique par SMS et le confirmer avant toute autre action. La configuration s’effectue en trois étapes :

1. Créez des outils de webhook SMS. Configurez deux outils, send_SMS_verification et check_SMS_verification, tous deux pointant vers votre service Twilio Verify. Chacun nécessite le SID du service Verify (la valeur VA... dans les paramètres de votre service Verify) dans le chemin de l’URL, ainsi qu’un en-tête d’authentification Basic créé à partir de votre Account SID et de votre Auth Token, stocké comme secret.

2. Définissez le destinataire avec une variable système. ElevenAgents fournit des variables système qui renseignent automatiquement system__caller_id avec le numéro de téléphone de l’appelant lors de tout appel vocal. Transmettez donc {{system_caller_id}} comme paramètre To plutôt que de demander à l’appelant d’énoncer un numéro. Dans un environnement de production intégré à un DSE réel, le code serait plutôt envoyé au numéro de téléphone enregistré dans le dossier du patient qu’à l’identifiant de l’appelant.

3. Activez skip_turn. L’ajout de cet outil système aux côtés des outils de webhook permet à l’agent d’attendre silencieusement pendant que l’appelant trouve le SMS, plutôt que de parler pendant cette pause.

Seul un appelant qui réussit à la fois la recherche DSE et la vérification OTP peut passer à l’étape Réservation. 

Vous trouverez un exemple JSON des deux outils ici et ici.

Outils d’intégration au calendrier

L’étape Réservation doit vérifier les disponibilités, prendre, reprogrammer et annuler des rendez-vous dans un véritable calendrier. La configuration de l’intégration Cal.com s’effectue en trois étapes :

1. Connectez l’intégration. Dans l’onglet Outils de l’agent, ajoutez l’intégration Cal.com et cliquez sur Connecter.

2. Épinglez le type d’événement. Chaque outil de calendrier utilise un ID de type d’événement qui indique à Cal.com l’événement pour lequel réserver. Définissez-le comme paramètre fixe dans les outils connectés à l’aide de l’ID de votre Dashboard Cal.com.

3. Définissez l’e-mail du participant. Les outils de réservation nécessitent également l’e-mail d’un participant. À des fins de démonstration, définissez-le comme paramètre fixe avec votre propre adresse afin que les confirmations arrivent dans votre boîte de réception. En production avec un DSE réel, renseignez-le à partir de l’e-mail présent dans le dossier patient plutôt que de le coder en dur.

À partir de là, le flux Réservation dépend de l’intention recueillie dans Greeting. Pour un nouveau rendez-vous, l’agent appelle calcom_get_available_slots pour interroger les créneaux disponibles avant d’en proposer un, puis calcom_create_booking une fois que l’appelant confirme, toujours dans cet ordre, car vérifier d’abord les disponibilités évite de réserver deux fois le même créneau. Pour une reprogrammation ou une annulation, il localise d’abord le rendez-vous existant de l’appelant avec calcom_find_bookings_by_attendee, confirme la réservation concernée avec l’appelant, puis la supprime avec calcom_cancel_booking ou, pour une reprogrammation, réserve le nouveau créneau avant d’annuler l’ancien.

Transfert à un humain

Pour transférer à un humain, vous pouvez utiliser l’transfer_to_number outil système d’ElevenLabs. Ajoutez-le comme outil système au niveau de l’agent afin qu’il soit accessible depuis Greeting, Verification ou Booking. Pour la règle de transfert, ajoutez le numéro de téléphone de destination au format E.164 ainsi qu’une condition en langage clair décrivant son déclenchement. Le LLM décide du moment et de la destination du transfert à partir de ces conditions et de la description de l’outil. Conservez le type de transfert Conference, la valeur par défaut, car il prend en charge un message de transmission qui indique à l’opérateur humain la raison de l’appel.

Structurer le parcours patient

Workflows sont des flux de conversation visuels basés sur des graphes, créés à partir de quelques types de nœuds : des nœuds de sous-agent qui ajoutent un prompt système, des outils et une base de connaissances à l’agent de base orchestrateur pour une phase de l’appel ; des nœuds d’outil de répartition qui garantissent l’exécution d’un outil spécifique et créent des branches selon la réussite ou l’échec ; des nœuds de transfert d’agent et de transfert vers un numéro pour les transmissions ; et un nœud de fin pour clôturer l’appel. Les nœuds sont reliés par des arêtes, et les arêtes sortantes peuvent inclure une condition LLM : une règle en langage naturel que le modèle évalue en temps réel pour déterminer le chemin à emprunter. Nous créons l’agent avec cinq nœuds de sous-agent : Greeting, Verification, Booking, Transfer Notice et Close, chacun limité à ses propres outils, ainsi qu’un nœud unique Phone Number Transfer accessible depuis Transfer Notice.

Greeting est le point d’entrée : il répond à l’appel, présente la clinique et recueille l’intention du patient avant de transmettre l’appel. Il n’utilise aucun outil propre, seulement le contexte nécessaire pour orienter correctement l’appel.

Verification effectue la vérification à deux facteurs décrite plus haut, à l’aide de l’outil FHIR GET /Patient pour confirmer que l’appelant correspond à un dossier dans le DSE, puis des outils send_SMS_verification et check_SMS_verification pour envoyer et vérifier un code à usage unique avant que l’appelant puisse continuer. Seul un appelant qui franchit ces deux étapes progresse ; les autres sont dirigés vers Transfer Notice.

Booking contient les outils de calendrier de la section précédente, et l’intention recueillie dans Greeting détermine le parcours : vérifier les disponibilités et réserver pour un nouveau rendez-vous, rechercher la réservation existante et effectuer une nouvelle réservation avant d’annuler pour une reprogrammation, ou confirmer et annuler pour une annulation. Ce nœud bascule aussi vers Transfer Notice : si aucun créneau du calendrier ne convient, si l’appelant ne peut pas être associé à un rendez-vous existant ou s’il préfère parler au personnel, l’arête l’y dirige plutôt que de bloquer l’appel.

Transfer Notice se situe entre le reste du workflow et la transmission elle-même : un court sous-agent dont le seul rôle est d’indiquer à l’appelant qu’un transfert est en cours (par ex. « Je vous mets maintenant en relation avec un membre de notre équipe ») avant que l’appel ne quitte réellement l’agent. Faire passer chaque condition de transfert par ce nœud, plutôt que de déclencher transfer_to_number directement depuis Greeting, Verification ou Booking, garantit que l’appelant entend toujours ce message, au lieu d’être transféré sans avertissement si la formulation varie selon le sous-agent.

Phone Number Transfer, créé à partir de l’outil transfer_to_number, est le nœud vers lequel Transfer Notice dirige systématiquement l’appel. Ses règles associent un numéro de destination aux mêmes conditions héritées des étapes précédentes : échec de vérification, demande explicite, réservation impossible à finaliser, et exécutent la transmission une fois que l’appelant a été averti.

Close n’est atteint qu’après une réservation réussie : il récapitule les détails du rendez-vous à l’appelant et met fin à l’appel sur une note chaleureuse.

Vous trouverez un exemple de modèle JSON du workflow ici.

Analyse et tests

Dans un agent vocal destiné au secteur de la santé, l’essentiel du travail ne concerne pas le scénario idéal, mais tout ce qui doit se dérouler correctement lorsque l’appel ne suit pas le script. ElevenAgents est conçu pour les tests et l’analyse natives à la plateforme : les mêmes critères d’évaluation utilisés avant le lancement évaluent chaque appel en production, sans outil distinct à connecter ou à réconcilier.

Critères de réussite

Définissez des critères de réussite pour capturer des critères d’évaluation spécifiques alignés sur vos objectifs métier et opérationnels. Dans l’onglet Analyse, chaque critère est un prompt en langage clair qu’un LLM exécute sur la transcription et renvoie success, failure ou unknown avec une justification. Pour cet agent, les critères peuvent notamment inclure :

• patient_verified: « Marquer comme réussi si l’agent a confirmé l’identité de l’appelant à la fois via la recherche DSE et le code à usage unique par SMS avant de passer à la réservation. »
• appointment_booked: « Marquer comme réussi si le rendez-vous du patient a été pris. »
• appointment_changed: « Marquer comme réussi si le patient a demandé à reprogrammer ou annuler un rendez-vous existant, et que l’agent a effectué cette modification — mise à jour ou suppression de l’événement de calendrier — puis confirmé le résultat à l’appelant. » 
• call_escalated_when_requested: « Marquer comme réussi si l’appelant a demandé à parler à un humain et que l’agent a transféré l’appel ; marquer comme échec si l’appelant l’a demandé et que l’agent n’a pas transféré l’appel. »

Collecte de données

Vous pouvez les associer à des champs de collecte de données. Par exemple, ajoutez requested_action (réserver, reprogrammer ou annuler), appointment_date ou appointment_type, extraits de chaque transcription sous forme de valeurs structurées de type chaîne, booléen ou nombre, puis envoyés en aval via un webhook post-appel vers le système qui suit les résultats des appels. 

Simulations et tests

Dans le secteur de la santé, un agent doit gagner la confiance avant son premier appel réel : les modes d’échec doivent apparaître lors des tests, et non face à un patient. L’API de simulation de conversation simule des scénarios d’appel réalistes, de bout en bout comme sur des segments ciblés, et évalue automatiquement les résultats à l’aide des mêmes critères qu’en production : les vérifications exactes patient_verified et appointment_booked définies ci-dessus, et non une grille d’évaluation distincte réservée aux tests. Exécutez des simulations complètes pour l’ensemble de l’appel, ou des simulations partielles commençant en milieu de conversation afin de valider un seul point de décision : une manière plus rapide d’itérer sur un nœud sans relancer tout le flux. 

Pour cet agent, cela signifie écrire des scénarios qui vont au-delà du cas idéal : un appelant dont le nom ne correspond à aucun dossier DSE, une personne qui se trompe deux fois dans l’OTP, un patient qui demande une reprogrammation plutôt qu’une réservation, ou un appelant qui demande explicitement à parler à un humain au cours de la vérification. Des scénarios clairs et ciblés qui couvrent les cas limites, l’utilisation des outils et la logique de repli, au lieu d’espérer qu’ils apparaissent en production.

Connectez votre numéro de téléphone Twilio

Une fois l’agent créé, sa connexion à un numéro actif ne prend que quelques minutes :

1. Dans le Dashboard ElevenLabs, accédez à Phone Numbers et cliquez sur Import number.
2. Saisissez un Label, le Phone Number et vos identifiants Twilio Account SID et Auth Token
3. Une fois importé, attribuez le numéro à votre agent depuis le menu déroulant
4. Appelez le numéro pour le tester, puis consultez l’historique des conversations dans le Dashboard afin de vérifier que les premiers appels se sont déroulés comme prévu.

Prêt pour de vrais patients

Vous disposez désormais d’un agent de prise de rendez-vous patient qui fait plus que répondre au téléphone : il vérifie l’identité dans un DSE et avec un OTP à second facteur avant d’accéder à un dossier, prend, reprogramme et annule directement des rendez-vous dans un calendrier actif via l’API de Cal.com, et sait quand se retirer pour transmettre l’appel à un humain. Le workflow déterministe, les garde-fous à l’exécution et les critères d’évaluation fournissent aux équipes la piste d’audit et le modèle de tests reproductibles requis pour les déploiements dans le secteur de la santé.

La mise en production est le moment où cette approche démontre sa valeur. Les critères d’évaluation définis lors de la création deviennent le seuil de mise en service : lorsque l’agent les satisfait de manière constante et que les métriques se stabilisent, vous pouvez lancer avec confiance plutôt que de vous en remettre à votre jugement. Après le lancement, l’apprentissage passe des tests simulés aux transcriptions de production. Nous abordons ces pratiques, des déploiements progressifs au moment où il faut cesser d’itérer, dans un article précédent.

Une étape clé vers la conformité HIPAA concerne le traitement des données. L’activation du Zero Retention Mode supprime les enregistrements d’appels, les transcriptions et les métadonnées contenant des informations personnelles identifiables dès la fin de l’appel, éliminant la principale source de risque de conformité dans un déploiement téléphonique. Associé à un webhook post-appel, vous ne perdez aucune visibilité : chaque résultat de réservation, de vérification et d’évaluation est envoyé à votre propre système en temps réel à la fin de l’appel.

Vous disposez maintenant d’un modèle pour placer l’IA vocale agentique à l’entrée de votre clinique. La prise de rendez-vous est le cas d’usage au plus fort volume pour commencer, et le même modèle s’étend à l’accueil des patients, aux renouvellements d’ordonnance, à la facturation et aux suivis après consultation : autant d’appels qui n’ont plus à aboutir sur une messagerie en dehors des heures ouvrables. Notre équipe Forward Deployed Engineering travaille étroitement avec les organisations de santé pour transformer des déploiements comme celui-ci en capacités produit concrètes. Si vous souhaitez déployer un workflow destiné aux patients sur ElevenAgents avec les garanties de conformité qu’exige le secteur de la santé, essayez cette approche et partagez-nous votre avis.