ElevenAgents voor de zorg: bouw een agent voor inkomende afspraken
- Geschreven door
- Nathan Pogue
- Gepubliceerd
- Laatst bijgewerkt
LuisterenLuister naar dit artikel
De telefoon is nog altijd de voordeur van de zorg, en die staat vast. Mayo Clinic onderzoek en Epic casestudy-gegevens laten beide zien dat ongeveer 30% van de afspraken buiten reguliere openingstijden wordt gepland. Gesprekken die op de voicemail belanden, zijn afspraken die stilletjes niet doorgaan, terwijl receptiemedewerkers die ze zouden moeten opvangen overbelast zijn en snel vertrekken. Voice agents zijn de demofase voorbij als manier voor klinieken om dat gat te dichten, en afsprakenplanning is het meest voorkomende startpunt: grote volumes, repetitief, voorspelbaar en een aanzienlijk deel van het werk aan de receptie waarvoor geen klinisch oordeel nodig is.
Afsprakenplanning in de zorg legt de lat ook hoger. Een verkeerd tijdslot of verkeerd verstaan reden voor het bezoek is niet alleen een slechte ervaring - het is een incident op het gebied van veiligheid en compliance. Een planningsagent voor de receptie heeft meer nodig dan een prettige stem: betrouwbare identiteitsverificatie, strikte guardrails, een duidelijke escalatieroute naar een medewerker, de juiste compliance-aanpak voor beschermde gezondheidsinformatie en de mogelijkheid om boekingen daadwerkelijk te voltooien, wijzigen of annuleren in een echt planningssysteem.
Deze handleiding bouwt precies dat met ElevenAgents: een agent die via telefonie toegankelijk is, gekoppeld aan een voorbeeld-EHR, die afspraken van begin tot eind boekt, verzet en annuleert en escaleert wanneer dat nodig is. Je krijgt de workflow, guardrails, tests en analyses om alles binnen de kaders te houden - ingezet op infrastructuur die is gebouwd voor gereguleerde zorg.
Hier is een demo waarin de agent die je gaat bouwen een live gesprek van begin tot eind afhandelt:
Vereisten
Om aan de slag te gaan, heb je het volgende nodig:
- Een ElevenLabs-account, met toegang tot het ElevenAgents-platform en onze stemmen.
- Een Twilio-account en een nummer.
- Toegang tot Twilio Verify.
- Een sandbox- of ontwikkelaarsomgeving voor EHR's. In deze handleiding gebruiken we HAPI FHIR, een open-source referentie-implementatie voor het HL7 FHIR-formaat, om te valideren aan de hand van synthetische patiëntgegevens.
- De agenda-applicatie van je praktijk. Voor deze handleiding gebruiken we de native integratie van ElevenLabs met Cal.com.
Optioneel
Als je geen toegang hebt tot sandboxgegevens, of de handleiding volgt voor demo-doeleinden, gebruiken we de HAPI FHIR R4-sandboxserver en vullen die met een fictief patiëntdossier dat je tijdens de verificatiefase kunt gebruiken. Voer daarvoor de volgende API-opdracht met fictieve gegevens uit in je terminal:
Een overeenkomst wordt alleen bevestigd als de query precies één dossier retourneert - nul resultaten betekent geen overeenkomst, en meer dan één betekent dat de zoekparameters niet specifiek genoeg waren om veilig door te gaan.
Architectuur
In deze handleiding bouw je een planningsagent die via een Twilio-nummer werkt en native is geïntegreerd met je ElevenAgent. Wanneer het inkomende gesprek wordt verbonden, helpt de agent de patiënt via de beschikbare tools om verificatie- en afspraakgegevens vast te leggen - of de beller nu een nieuw bezoek wil boeken, een bestaande afspraak wil verzetten of annuleren - en kan de agent het gesprek indien nodig doorschakelen naar een medewerker.

Met deze architectuur en tools bestaat een succesvol gespreksverloop uit de volgende stappen:
- Gesprek starten: een patiënt belt het Twilio-nummer dat aan de agent is gekoppeld. De agent begroet de patiënt en achterhaalt de intentie.
- EHR-validatie: de agent valideert de gegevens van de patiënt aan de hand van het dossier in het EHR.
- Verificatie: de agent verstuurt met de SMS-tool een eenmalig wachtwoord (OTP) naar het telefoonnummer van de patiënt voor de definitieve verificatie.
- Boeken of wijzigen: de agent handelt de vastgelegde intentie af in de agenda - voor een nieuwe afspraak worden boekingsgegevens verzameld en beschikbaarheid gecontroleerd; voor een verplaatsing wordt de bestaande afspraak opgehaald en een nieuw tijdslot gezocht; voor een annulering wordt de bestaande afspraak bevestigd en verwijderd.
- Doorverbinden: als het boeken of wijzigen niet lukt, de patiënt met een medewerker wil spreken of een andere intentie wordt vastgelegd die de agent niet kan afhandelen, wordt het gesprek doorverbonden met een medewerker.
- Bevestiging en afsluiten: na een geslaagde boeking, verplaatsing of annulering vat de agent de gespreksdetails samen en sluit deze het gesprek vriendelijk af.
System prompt en agentinstellingen
De eerste stap bij het bouwen van een effectieve ElevenAgent zit in de system prompt. Volgens de ElevenLabs-prompting guide structureren we die in de belangrijkste bouwstenen die voor elke productieagent worden aanbevolen - persoonlijkheid, doel, toon, tools en guardrails - elk in een eigen duidelijk gelabelde sectie in plaats van één doorlopend instructieblok.
Voor een planningsagent in de zorg moet die structuur rekening houden met wie er werkelijk aan de andere kant van de lijn zit: iemand die ouder is, pijn heeft, slechthorend is of gewoon bezorgd is over de reden van het gesprek. De secties over persoonlijkheid en toon zorgen voor een warm, rustig tempo en houden antwoorden kort en conversationeel, met datums, tijden en getallen uitgesproken zoals iemand ze zou zeggen in plaats van ze van een scherm voor te lezen. De doelsectie doorloopt de flow als een geordende reeks - identiteit verifiëren en vervolgens, afhankelijk van of de beller wil boeken, verzetten of annuleren, de beschikbaarheid controleren en het tijdslot bevestigen, de bestaande afspraak opzoeken en verplaatsen, of de te verwijderen afspraak bevestigen - en tools worden gedocumenteerd met de exacte invoer in gesproken formaat die ze verwachten. Guardrails bevatten de regels die uniek zijn voor dit domein: toon nooit meer PHI dan de beller al heeft gedeeld, verzin nooit beschikbaarheid of afspraakdetails wanneer een tool faalt, wijs klinische vragen af ten gunste van de eigen zorgverlener van de beller en escaleer direct als iemand urgente symptomen of een medisch noodgeval beschrijft. Identiteitsverificatie vóór elke afspraakactie is de ene regel die wordt herhaald in plaats van één keer vermeld. Dat is de regel die de agent zich het minst kan veroorloven te laten vallen.
Vanaf hier kun je aanvullende agentconfiguraties toevoegen, zoals het eerste bericht, verschillende talen (zorg dat de detect language system tool is ingeschakeld), de LLM van je keuze, een conversationeel ElevenLabs-text-to-speech model en een ElevenLabs-stem.
Een voorbeeld van een system prompt vind je hier.

Guardrails
De sectie Guardrails van de system prompt omvat regels op instructieniveau, waaraan het model veel gewicht toekent. Maar een prompt blijft een niet-deterministische laag die tijdens een lang gesprek kan afwijken. ElevenAgents ondersteunt deze met onafhankelijke runtimehandhaving via de eigen Guardrails. Deze omvatten de Focus Guardrail, die de system prompt versterkt naarmate gesprekken langer duren, Manipulation Guardrails die pogingen tot prompt injection onderscheppen voordat de agent antwoordt, en Content en Custom Guardrails die elk antwoord realtime beoordelen en het kunnen blokkeren voordat de beller het hoort. Elke guardrail wordt geconfigureerd met een uitvoeringsmodus - streaming voor vrijwel geen vertraging, of blocking om een antwoord vast te houden tot het is goedgekeurd - en een exitstrategie voor wat er bij een trigger gebeurt: het gesprek beëindigen of opnieuw proberen met corrigerende feedback die in de volgende beurt wordt ingevoegd.
Voor deze agent kunnen we custom guardrails definiëren voor de zorg- of kliniekspecifieke regels: blokkeer het diagnosticeren van aandoeningen of het aanbevelen van behandelingen, blokkeer vragen over facturering, blokkeer advies over medicijndoseringen en blokkeer alles wat advies van een bevoegde zorgverlener vervangt. Stel bij urgente symptomen de exitstrategie in op opnieuw proberen met feedback die het gesprek doorverbindt naar een medewerker, zodat de guardrail het gesprek overdraagt aan medewerkers in plaats van het alleen te beëindigen.


Tools
Elke stap in de flow vereist specifieke webhook- en integratietools om tijdens het gesprek met de patiënt specifieke acties uit te voeren.
Tool voor EHR-verificatie
Om de patiënt te verifiëren aan de hand van het dossier in het EHR, gebruiken we de FHIR GET /Patient API-actie. Voeg deze toe als webhooktool die naar je HAPI FHIR-basis-URL verwijst, met family, given, identifier en birthdate ingesteld als door de LLM ingevulde parameters. De eerste toolaanroep in de verificatiefase raakt het endpoint met de naam en geboortedatum van de beller in één query:
Een overeenkomst wordt alleen bevestigd als de query precies één dossier retourneert. De agent kan alleen doorgaan naar de boekingsfase als aan deze voorwaarde is voldaan.
Een voorbeeld-JSON van de tool vind je hier.
Twilio-tools voor SMS-verificatie
Zodra een overeenkomst in het EHR is bevestigd, gaat de verificatiefase door met een tweede factor: de patiënt een eenmalige code sms'en en die bevestigen voordat er iets anders gebeurt. Dit stel je in drie stappen in:
1. Maak SMS-webhooktools. Configureer twee tools, send_SMS_verification en check_SMS_verification, die beide naar je Twilio Verify-service verwijzen. Elke tool heeft de Verify Service SID nodig (de VA... -waarde uit de instellingen van je Verify-service) in het URL-pad, en een Basic-auth-header die is opgebouwd met je Account SID en Auth Token, opgeslagen als secret.
2. Stel de ontvanger in met een systeemvariabele. ElevenAgents bieden systeemvariabelen die system__caller_id bij elk spraakgesprek automatisch vullen met het telefoonnummer van de beller. Geef daarom {{system_caller_id}} door als de To-parameter, in plaats van de beller te vragen een nummer hardop voor te lezen. In een productieomgeving die is geïntegreerd met een live EHR, wordt de code in plaats daarvan verstuurd naar het telefoonnummer dat in het dossier van de patiënt staat, niet naar de identificatie van de beller.
3. Schakel skip_turn. in. Door deze system tool naast de webhooktools toe te voegen, kan de agent stil wachten terwijl de beller het sms-bericht zoekt, in plaats van door de stilte heen te praten.
Alleen een beller die zowel de EHR-zoekopdracht als de OTP-controle doorstaat, mag door naar de boekingsfase.
Een voorbeeld-JSON van beide tools vind je hier en hier.
Agenda-integratietools
De boekingsfase moet beschikbaarheid controleren en afspraken boeken, verzetten en annuleren in een echte agenda. Het instellen van de Cal.com-integratie bestaat uit drie stappen:
1. Koppel de integratie. Voeg op het tabblad Tools van de agent de Cal.com-integratie toe en klik op Connect.
2. Zet het gebeurtenistype vast. Elke agendatool heeft een event type ID nodig dat Cal.com vertelt voor welke gebeurtenis een afspraak moet worden geboekt. Stel dit als vaste parameter in de gekoppelde tools in met de ID uit je Cal.com-dashboard.
3. Stel het e-mailadres van de deelnemer in. De boekingstools hebben ook een e-mailadres van een deelnemer nodig. Zet dit voor demo-doeleinden als vaste parameter op je eigen adres, zodat bevestigingen in je inbox terechtkomen. In productie met een echt EHR vul je dit in met het e-mailadres uit het dossier van de patiënt, in plaats van met een hardcoded adres.
Vanaf hier hangt de boekingsflow af van de intentie die bij Greeting is vastgelegd. Voor een nieuwe afspraak roept de agent calcom_get_available_slots aan om vrije tijden op te vragen voordat er een wordt aangeboden, en daarna calcom_create_booking zodra de beller bevestigt - altijd in die volgorde, omdat eerst de beschikbaarheid controleren voorkomt dat een tijdslot dubbel wordt geboekt. Voor een verplaatsing of annulering zoekt de agent eerst de bestaande afspraak van de beller op met calcom_find_bookings_by_attendee, bevestigt de specifieke boeking met de beller en verwijdert deze vervolgens met calcom_cancel_booking of boekt, bij een verplaatsing, het nieuwe tijdslot voordat de oude afspraak wordt geannuleerd.
Doorverbinden met een medewerker
Om door te verbinden met een medewerker, kunnen we de ElevenLabs-transfer_to_number system tool gebruiken. Voeg deze als system tool toe op agentniveau, zodat deze vanuit Greeting, Verification en Booking bereikbaar is. Voeg voor de doorverbindingsregel het telefoonnummer van de bestemming toe in E.164-formaat en een voorwaarde in gewone taal die beschrijft wanneer de regel moet worden geactiveerd. De LLM bepaalt op basis van die voorwaarden en de beschrijving van de tool wanneer en waarheen moet worden doorverbonden. Laat het doorverbindingstype op Conference staan, de standaardwaarde, omdat dit een warm overdrachtsbericht ondersteunt dat de medewerker uitlegt waarom het gesprek wordt doorverbonden.
De patiëntreis structureren
Workflows zijn visuele, op grafen gebaseerde gespreksflows die zijn opgebouwd uit enkele typen nodes: subagent-nodes die een system prompt, tools en kennisbank boven op de orchestrator base agent plaatsen voor één fase van het gesprek; dispatch tool-nodes die garanderen dat een specifieke tool wordt uitgevoerd en vertakken op succes of mislukking; agent transfer- en transfer-to-number-nodes voor overdrachten; en een end-node om het gesprek af te sluiten. Nodes zijn verbonden door edges, en forward edges kunnen een LLM-voorwaarde bevatten - een regel in gewone taal die het model realtime beoordeelt om te bepalen welk pad het moet nemen. We bouwen de agent met vijf subagent-nodes - Greeting, Verification, Booking, Transfer Notice en Close - die elk zijn beperkt tot eigen tools, plus één Phone Number Transfer-node die bereikbaar is vanuit Transfer Notice.
Greeting is het startpunt: deze beantwoordt het gesprek, introduceert de kliniek en achterhaalt de intentie van de patiënt voordat er wordt overgedragen - zonder eigen tools, alleen genoeg context om correct te routeren.
Verification voert de eerdere tweefactorcontrole uit, met de FHIR-GET /Patient-tool om te bevestigen dat de beller overeenkomt met een dossier in het EHR, gevolgd door de tools send_SMS_verification en check_SMS_verification om een eenmalige code te verzenden en te controleren voordat de beller kan doorgaan. Alleen een beller die beide controles doorstaat gaat verder; iedereen die dat niet doet krijgt een forward edge naar Transfer Notice.
Booking bevat de agendatools uit de vorige sectie, en de bij Greeting vastgelegde intentie bepaalt het pad: beschikbaarheid controleren en boeken voor een nieuwe afspraak, de bestaande boeking opzoeken en opnieuw boeken vóór annulering bij een verplaatsing, of bevestigen en annuleren bij een annulering. Deze node faalt ook open naar Transfer Notice — als niets in de agenda past, de beller niet aan een bestaande afspraak kan worden gekoppeld of de beller liever met medewerkers spreekt, routeert de edge daarheen in plaats van het gesprek vast te laten lopen.
Transfer Notice zit tussen de rest van de workflow en de overdracht zelf - een korte subagent met als enige taak de beller te vertellen dat er een doorverbinding plaatsvindt (bijv. "Ik verbind je nu door met iemand uit ons team") voordat het gesprek de agent werkelijk verlaat. Door elke doorverbindingsvoorwaarde eerst via deze node te routeren, in plaats van transfer_to_number rechtstreeks vanuit Greeting, Verification of Booking aan te roepen, hoort de beller die zin altijd, in plaats van stilzwijgend te worden doorverbonden als de bewoording per subagent verschilt.
Phone Number Transfer, gebouwd op de transfer_to_number-tool, is de node waar Transfer Notice altijd naartoe doorstuurt. De regels combineren een bestemmingsnummer met dezelfde voorwaarden die vanuit eerdere nodes worden doorgegeven - een mislukte verificatie, een expliciet verzoek, een boeking die niet kan worden voltooid - en voeren de daadwerkelijke overdracht uit nadat de beller al is verteld dat deze eraan komt.
Close wordt alleen bereikt na een geslaagde boeking: deze vat de afspraakdetails voor de beller samen en beëindigt het gesprek op een warme manier.
Een voorbeeld-JSON-template van de workflow vind je hier.

Analyse en testen
Het grootste deel van het werk bij een voice agent voor de zorg zit niet in het ideale scenario - maar in alles wat correct moet gebeuren wanneer het gesprek niet volgens script verloopt. ElevenAgents is gemaakt voor testen en analyse die native zijn aan het platform. Dat betekent dat dezelfde evaluatiecriteria die je gebruikt voor tests vóór de lancering, elk gesprek in productie beoordelen, zonder aparte tool die je moet koppelen of afstemmen.
Succescriteria
Definieer succescriteria om specifieke evaluatiecriteria vast te leggen die aansluiten bij je zakelijke en operationele doelen. Op het tabblad Analysis is elk criterium een prompt in gewone taal die een LLM op het transcript uitvoert en success, failure of unknown met een toelichting retourneert. Voor deze agent kunnen dat bijvoorbeeld de volgende criteria zijn:
patient_verified: "Markeer als succesvol als de agent de identiteit van de beller heeft bevestigd via zowel de EHR-zoekopdracht als de eenmalige sms-code voordat deze doorging met boeken."appointment_booked: "Markeer als succesvol als de afspraak van de patiënt is geboekt"appointment_changed: "Markeer als succesvol als de patiënt vroeg om een bestaande afspraak te verzetten of annuleren en de agent die wijziging heeft voltooid - door de agenda-afspraak bij te werken of te verwijderen - en de uitkomst aan de beller heeft bevestigd."call_escalated_when_requested: "Markeer als succesvol als de beller vroeg om met een medewerker te spreken en de agent het gesprek heeft doorverbonden; markeer als mislukt als de beller erom vroeg en de agent niet doorverbond."
Gegevensverzameling
Je kunt deze combineren met velden voor gegevensverzameling. Voeg bijvoorbeeld requested_action (boeken, verzetten of annuleren), appointment_date of appointment_type toe. Deze worden als gestructureerde tekenreeks-, boolean- of getalswaarden uit elk transcript gehaald en via een post-call webhook doorgegeven aan het systeem dat gespreksuitkomsten bijhoudt.

Simulaties en tests
In de zorg moet een agent vertrouwen verdienen vóór het eerste echte gesprek - foutscenario's moeten tijdens het testen naar voren komen, niet bij een patiënt. De Conversation Simulation API simuleert realistische scenario's voor bellers, zowel van begin tot eind als in gerichte segmenten, en beoordeelt resultaten automatisch met dezelfde criteria die in productie draaien - precies de hierboven gedefinieerde controles patient_verified en appointment_booked, geen aparte rubric die alleen voor tests geldt. Voer volledige simulaties uit voor het hele gesprek, of gedeeltelijke simulaties die halverwege het gesprek beginnen om één beslispunt te valideren. Dat is de snellere manier om één node te verbeteren zonder de hele flow opnieuw uit te voeren.
Voor deze agent betekent dat dat je scenario's uitschrijft die verder gaan dan het ideale pad: een beller wiens naam niet overeenkomt met een EHR-dossier, iemand die de OTP twee keer verkeerd invoert, een patiënt die wil verzetten in plaats van boeken en een beller die halverwege de verificatie expliciet om een medewerker vraagt - duidelijke, gerichte scenario's die dekking bieden voor edge cases, toolgebruik en fallbacklogica, in plaats van te hopen dat ze in productie optreden.
Koppel je Twilio-telefoonnummer
Nu de agent is gebouwd, kost het koppelen aan een live nummer slechts enkele minuten:
- Ga in het ElevenLabs-dashboard naar Phone Numbers en klik op Import number.
- Voer een Label, het Phone Number en je Twilio-Account SID en Auth Token
- Wijs het nummer na het importeren via de dropdown toe aan je agent
- Bel het nummer om het te testen en controleer daarna het dashboard met de gesprekshistorie om te bevestigen dat de eerste gesprekken zich gedroegen zoals verwacht.
Klaar voor echte patiënten
Wat we hebben gebouwd, is een agent voor patiëntplanning die meer doet dan de telefoon opnemen: deze verifieert de identiteit met een EHR en een OTP als tweede factor voordat een dossier wordt geraadpleegd, en boekt, verzet en annuleert rechtstreeks in een live agenda via de API van Cal.com, en weet wanneer deze ruimte moet maken en een beller aan een medewerker moet overdragen. De deterministische workflow, runtimeguardrails en evaluatiecriteria bieden teams het controlespoor en het herhaalbare testpatroon dat zorgimplementaties vereisen.
Bij livegang bewijst dat patroon zijn waarde. De tijdens het bouwen gedefinieerde evaluatiecriteria worden de drempel voor livegang - wanneer de agent ze consequent haalt en de metrics zijn gestabiliseerd, heb je vertrouwen om te lanceren in plaats van alleen een inschatting - en na de lancering verschuift het leerproces van gesimuleerde tests naar transcripties uit productie. We behandelen deze werkwijzen, van gefaseerde uitrol tot weten wanneer je moet stoppen met itereren, in een eerdere blog.
Een belangrijke stap richting HIPAA-compliance is gegevensverwerking. Door Zero Retention Mode in te schakelen, worden gespreksopnames, transcripties en metadata met PII verwijderd zodra een gesprek eindigt. Daarmee wordt de grootste bron van compliancerisico bij een telefonie-implementatie weggenomen. In combinatie met een post-call webhook blijft alle zichtbaarheid behouden - elke boekingsuitkomst, elk verificatieresultaat en elke evaluatiescore wordt realtime naar je eigen systeem gestuurd wanneer het gesprek wordt afgesloten.
Je hebt nu een template om agentic voice AI bij de voordeur van je kliniek in te zetten. Afsprakenplanning is de plek met het hoogste volume om te beginnen, en hetzelfde patroon is uit te breiden naar patiëntintake, herhaalrecepten, facturering en follow-ups na een bezoek - elk een gesprek dat buiten openingstijden niet langer op de voicemail hoeft te belanden. Ons Forward Deployed Engineering-team werkt nauw samen met zorgorganisaties om implementaties zoals deze om te zetten in concrete productmogelijkheden. Als je een patiëntgerichte workflow naar ElevenAgents wilt brengen met de compliance-aanpak die de zorg vereist, probeer dan deze aanpak en laat ons weten wat je ervan vindt.
Nathan werkt in het Forward Deployed Engineering-team van ElevenLabs en helpt klanten bij het bouwen en opschalen van hun voice agents. Daarvoor werkte hij drie jaar bij AWS met klanten in de publieke gezondheidszorg.





