ElevenAgents för vården: Bygg en agent för inkommande tidsbokning

Telefonen är fortfarande ingången till vården, och där är det fullt. Mayo Clinic forskning och Epic fallstudie visar båda att omkring 30 % av tidsbokningarna sker utanför ordinarie öppettider. Samtal som hamnar i röstbrevlådan blir bokningar som tyst uteblir, medan receptionspersonalen som ska fånga upp dem är hårt belastad och slutar i snabb takt. Röstassistenter har gått längre än demostadiet och hjälper kliniker att täppa till det här gapet. Tidsbokning är den vanligaste ingångspunkten: hög volym, repetitivt, förutsägbart och en betydande del av receptionsarbetet som inte kräver klinisk bedömning.

Tidsbokning inom vården ställer också högre krav. En felaktig tid eller feluppfattad besöksorsak är inte bara en dålig upplevelse – det är en säkerhets- och efterlevnadsincident. En bokningsagent i receptionen behöver mer än en behaglig röst: tillförlitlig identitetsverifiering, tydliga skyddsräcken, en enkel väg att eskalera till en människa, rätt efterlevnadsnivå för att hantera skyddade hälsouppgifter och förmågan att faktiskt genomföra, ändra eller avboka tider i ett verkligt bokningssystem.

I den här guiden bygger vi precis det med ElevenAgents: en telefonitillgänglig agent, kopplad till ett exempel på ett EHR-system, som bokar, ombokar och avbokar tider från början till slut och eskalerar när den ska. Du får workflow, skyddsräcken, testning och analys som håller den inom ramarna – distribuerad på infrastruktur för reglerad sjukvård.

Här är en demo av agenten du ska bygga, som hanterar ett pågående samtal från början till slut:

Förutsättningar

För att komma igång behöver du följande:

• Ett ElevenLabs-konto med åtkomst till ElevenAgents-plattformen och våra röster.
• Ett Twilio-konto och ett telefonnummer.
• Åtkomst till Twilio Verify.
• En sandbox- eller utvecklingsmiljö för EHR. I den här guiden använder vi HAPI FHIR, en öppen källkodsbaserad referensimplementation för HL7 FHIR-formatet, för validering mot syntetiska patientjournaler.
• Din mottagnings kalenderapp. I den här guiden använder vi ElevenLabs inbyggda integration med Cal.com. 

Valfritt

Om du inte har åtkomst till sandboxdata, eller följer med i demosyfte, använder vi HAPI FHIR R4-sandboxservern och lägger in en simulerad patientjournal som du kan använda under verifieringssteget. Kör följande API-kommando med simulerade data från din 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)"
  }'

En träff bekräftas endast när sökningen returnerar exakt en journalpost – noll resultat innebär ingen träff, och fler än en innebär att sökparametrarna inte var tillräckligt specifika för att fortsätta på ett säkert sätt. 

Arkitektur

I den här guiden bygger du en bokningsagent som körs via ett Twilio-nummer och är inbyggt integrerad med din ElevenAgent. När det inkommande samtalet kopplas fram hjälper agenten patienten genom sina tillgängliga verktyg att samla in verifierings- och bokningsuppgifter – oavsett om uppringaren vill boka ett nytt besök, boka om eller avboka ett befintligt besök – och kan vid behov koppla samtalet till en människa.

Med den här arkitekturen och dessa verktyg består ett lyckat samtalsflöde av följande steg:

1. Samtalet startar: en patient ringer Twilio-numret som är kopplat till agenten. Agenten hälsar patienten välkommen och fångar upp ärendet.
2. EHR-validering: agenten validerar patientens uppgifter mot patientjournalen i EHR-systemet.
3. Verifiering: agenten skickar ett engångslösenord (OTP) till patientens telefonnummer för slutlig verifiering med sitt SMS-verktyg.
4. Bokning eller ändring: agenten utför det registrerade ärendet i kalendern – för en ny tid samlar den in bokningsuppgifter och kontrollerar tillgänglighet; för en ombokning hämtar den den befintliga tiden och hittar en ny; för en avbokning bekräftar och tar den bort den befintliga tiden.
5. Överföring: om bokningen eller ändringen misslyckas, patienten ber om att få prata med en människa eller agenten registrerar något annat ärende som den inte kan hantera, överförs samtalet till en mänsklig handläggare.
6. Bekräftelse och avslut: efter en lyckad bokning, ombokning eller avbokning sammanfattar agenten samtalets detaljer och avslutar vänligt.

Systemprompt och agentinställningar

Det första steget för att bygga en effektiv ElevenAgent är systemprompten. Enligt ElevenLabs guide för promptning strukturerar vi den i de grundläggande byggblock som rekommenderas för alla produktionsagenter – personlighet, mål, ton, verktyg och skyddsräcken – där varje del har en tydlig egen rubrik i stället för att ingå i ett enda sammanhängande instruktionsblock.

För en bokningsagent inom vården måste den strukturen ta hänsyn till vem som faktiskt är i andra änden av samtalet: någon som kan vara äldre, ha ont, höra dåligt eller helt enkelt känna oro över varför de ringer. Avsnitten om personlighet och ton skapar ett varmt, lugnt tempo och håller svaren korta och samtalsmässiga, med datum, tider och siffror uttalade som en person skulle säga dem i stället för att läsa dem från en skärm. Målavsnittet beskriver flödet som en ordnad sekvens – verifiera identiteten och, beroende på om uppringaren vill boka, boka om eller avboka, kontrollera tillgänglighet och bekräfta tiden, söka upp och flytta den befintliga tiden eller bekräfta tiden som ska tas bort – och verktygen dokumenteras med exakt de talade inmatningsformat som de förväntar sig. Skyddsräcken omfattar reglerna som är unika för området: visa aldrig mer PHI än uppringaren redan har lämnat, hitta aldrig på tillgänglighet eller bokningsuppgifter när ett verktyg misslyckas, avstå från kliniska frågor och hänvisa i stället till uppringarens egen vårdgivare, och eskalera omedelbart om någon beskriver akuta symtom eller ett medicinskt nödläge. Identitetsverifiering före varje bokningsåtgärd är den enda regeln som upprepas i stället för att bara anges en gång. Det är den regel agenten minst har råd att missa.

Härifrån kan du lägga till ytterligare agentkonfigurationer, som första meddelande, olika språk (se till att systemverktyget för språkidentifiering är aktiverat), valfri LLM, en konversationsanpassad ElevenLabs-text-to-speech-modell och en ElevenLabs-röst.

Ett exempel på en systemprompt finns här.

Skyddsräcken

Avsnittet Skyddsräcken i systemprompten omfattar regler på instruktionsnivå, och modellen lägger stor vikt vid det. Men en prompt är fortfarande ett icke-deterministiskt lager och kan glida iväg under ett långt samtal. ElevenAgents kompletterar detta med oberoende tillämpning vid körning genom sina egna Skyddsräcken. Dessa omfattar Focus Guardrail, som förstärker systemprompten när samtalen blir långa, Manipulation Guardrails, som fångar försök till promptinjektion innan agenten svarar, samt Content och Custom Guardrails, som utvärderar varje svar i realtid och kan blockera det innan uppringaren hör det. Varje skyddsräcke konfigureras med ett körläge – streaming för nästintill noll latens eller blocking för att hålla tillbaka ett svar tills det godkänns – och en exitstrategi för vad som ska hända när det utlöses: avsluta samtalet eller försöka igen med korrigerande återkoppling som läggs in i nästa tur.

För den här agenten kan vi definiera anpassade skyddsräcken för regler som gäller vården eller den specifika kliniken: blockera diagnoser av tillstånd eller behandlingsrekommendationer, blockera faktureringsfrågor, blockera doseringsråd för läkemedel och blockera allt som ersätter råd från legitimerad vårdpersonal. För akuta symtom ställer du in exitstrategin på att försöka igen med återkoppling som överför samtalet till en människa, så att skyddsräcket lämnar över samtalet till personal i stället för att bara avsluta det.

Verktyg

Varje steg i flödet kräver specifika webhook- och integrationsverktyg för att utföra specifika åtgärder medan agenten pratar med patienten.

Verktyg för EHR-verifiering

För att verifiera patienten mot patientjournalen i EHR-systemet använder vi API-åtgärden FHIR GET /Patient. Lägg till den som ett webhook-verktyg som pekar på din HAPI FHIR-bas-URL, med family, given, identifier och birthdate inställda som LLM-ifyllda parametrar. Det första verktygsanropet i verifieringssteget anropar slutpunkten med uppringarens namn och födelsedatum i en enda fråga:

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

En träff bekräftas endast när sökningen returnerar exakt en journalpost, och agenten kan bara gå vidare till bokningssteget om det villkoret uppfylls.

Ett exempel på verktygets JSON finns här.

Twilio SMS-verifieringsverktyg

När en EHR-träff har bekräftats går verifieringssteget vidare till en andra faktor: att skicka en engångskod via sms till patienten och bekräfta den innan något annat händer. Konfigurationen görs i tre steg:

1. Skapa SMS-webhook-verktyg. Konfigurera två verktyg, send_SMS_verification och check_SMS_verification, som båda pekar på din Twilio Verify-tjänst. Båda behöver Verify Service SID (VA... -värdet från inställningarna för din Verify-tjänst) i URL-sökvägen samt en Basic auth-header som bygger på ditt Account SID och Auth Token, lagrade som en hemlighet.

2. Ange mottagaren med en systemvariabel. ElevenAgents tillhandahåller systemvariabler som automatiskt fyller i system__caller_id med uppringarens telefonnummer vid alla röstsamtal, så skicka {{system_caller_id}} som parametern To i stället för att be uppringaren läsa upp ett nummer. I en produktionsmiljö integrerad med ett live-EHR skulle koden i stället skickas till telefonnumret som finns lagrat i patientjournalen, inte till uppringaridentifieraren.

3. Aktivera skip_turn. Genom att lägga till detta systemverktyg tillsammans med webhook-verktygen kan agenten vänta tyst medan uppringaren hittar sms:et, i stället för att prata över pausen.

Endast en uppringare som klarar både EHR-sökningen och OTP-kontrollen får gå vidare till bokningssteget. 

Exempel på JSON för båda verktygen finns här och här.

Kalenderintegrationsverktyg

Bokningssteget behöver kontrollera tillgänglighet, boka, boka om och avboka i en riktig kalender. Konfigurationen av Cal.com-integrationen görs i tre steg:

1. Anslut integrationen. Gå till fliken Verktyg för agenten, lägg till Cal.com-integrationen och klicka på Anslut.

2. Lås händelsetypen. Varje kalenderverktyg använder ett händelsetyp-ID som anger vilken händelse Cal.com ska boka. Ange det som en fast parameter i de anslutna verktygen med ID:t från din Cal.com-dashboard.

3. Ange deltagarens e-postadress. Bokningsverktygen behöver också en e-postadress till deltagaren. I demosyfte kan du låsa den som en fast parameter till din egen adress, så att bekräftelserna hamnar i din inkorg. I produktion med ett riktigt EHR-system skulle du hämta den från e-postadressen i patientjournalen i stället för att hårdkoda den.

Därefter beror bokningsflödet på ärendet som fångades upp i Greeting. För en ny tid anropar agenten calcom_get_available_slots för att söka efter lediga tider innan den erbjuder en, och sedan calcom_create_booking när uppringaren bekräftar – alltid i den ordningen, eftersom en kontroll av tillgängligheten först förhindrar dubbelbokning. Vid ombokning eller avbokning lokaliserar den först uppringarens befintliga tid med calcom_find_bookings_by_attendee, bekräftar den specifika bokningen med uppringaren och tar sedan antingen bort den med calcom_cancel_booking eller, vid ombokning, bokar den nya tiden innan den gamla avbokas.

Överföring till människa

För att överföra till en människa kan vi använda ElevenLabs transfer_to_number systemverktyg. Lägg till det som ett systemverktyg på agentnivå, så att det kan nås från Greeting, Verification och Booking. I överföringsregeln anger du mottagarens telefonnummer i E.164-format och ett villkor på klarspråk som beskriver när det ska utlösas. LLM:en avgör när och vart den ska överföra utifrån de villkoren och verktygets beskrivning. Låt överföringstypen vara Conference, standardinställningen, eftersom den stöder ett varmt överlämningsmeddelande som informerar den mänskliga handläggaren om varför samtalet kopplas vidare.

Strukturera patientresan

Workflows är visuella, grafbaserade samtalsflöden som byggs med några olika nodtyper: underagentnoder som lägger en systemprompt, verktyg och kunskapsbas ovanpå grundagenten för orkestrering för en fas av samtalet; dispatch-verktygsnoder som säkerställer att ett specifikt verktyg körs och förgrenar utifrån om det lyckas eller misslyckas; agentöverförings- och transfer-to-number-noder för överlämningar; samt en slutnod för att avsluta samtalet. Noder kopplas ihop med kanter, och framåtriktade kanter kan ha ett LLM-villkor – en regel på naturligt språk som modellen utvärderar i realtid för att avgöra vilken väg den ska ta. Vi bygger agenten med fem underagentnoder – Greeting, Verification, Booking, Transfer Notice och Close – som var och en har sina egna verktyg, samt en enda Phone Number Transfer-nod som kan nås från Transfer Notice.

Greeting är ingångspunkten: den besvarar samtalet, presenterar kliniken och fångar upp patientens ärende innan den lämnar över – utan egna verktyg, bara tillräckligt med informationsinsamling för att dirigera rätt.

Verification utför tvåfaktorskontrollen från tidigare genom att använda FHIR-verktyget GET /Patient för att bekräfta att uppringaren matchar en journalpost i EHR-systemet, och sedan verktygen send_SMS_verification och check_SMS_verification för att skicka och kontrollera en engångskod innan uppringaren kan fortsätta. Endast en uppringare som klarar båda kontrollerna går vidare; alla andra får en framåtriktad kant till Transfer Notice.

Booking är där kalenderverktygen från föregående avsnitt finns, och ärendet som fångades upp i Greeting avgör vägen: kontrollera tillgänglighet och boka en ny tid, sök upp den befintliga bokningen och boka om innan den avbokas, eller bekräfta och avboka. Den här noden faller också tillbaka till Transfer Notice – om inget i kalendern passar, uppringaren inte kan matchas med en befintlig bokning eller uppringaren hellre vill prata med personal, går kanten dit i stället för att samtalet fastnar.

Transfer Notice ligger mellan resten av workflowet och själva överlämningen – en kort underagent vars enda uppgift är att tala om för uppringaren att en överföring sker (t.ex. ”Jag kopplar dig nu till någon i vårt team”) innan samtalet faktiskt lämnar agenten. Genom att först dirigera alla överföringsvillkor via den här noden, i stället för att anropa transfer_to_number direkt från Greeting, Verification eller Booking, säkerställer du att uppringaren alltid hör den raden i stället för att tyst kopplas vidare om formuleringen skulle variera mellan underagenter.

Phone Number Transfer, som bygger på verktyget transfer_to_number, är noden som Transfer Notice alltid skickar vidare till. Dess regler kopplar ett destinationsnummer till samma villkor som kommer från tidigare steg – en misslyckad verifiering, en uttrycklig begäran eller en bokning som inte går att slutföra – och genomför själva överlämningen när uppringaren redan har fått veta att den kommer.

Close nås endast efter en lyckad bokning: den sammanfattar bokningsuppgifterna för uppringaren och avslutar samtalet på ett vänligt sätt.

En exempelmall i JSON för workflowet finns här.

Analys och testning

Merparten av arbetet med en röstagent inom vården handlar inte om det ideala scenariot – utan om allt som måste fungera korrekt när samtalet inte går enligt manus. ElevenAgents är byggt för testning och analys direkt på plattformen. Det innebär att samma utvärderingskriterier som du använder för att testa före lansering utvärderar alla samtal i produktion, utan något separat verktyg att ansluta eller stämma av.

Framgångskriterier

Definiera framgångskriterier för att fånga specifika utvärderingskriterier som stämmer överens med dina affärs- och verksamhetsmål. På fliken Analys är varje kriterium en prompt på klarspråk som en LLM kör mot transkriberingen och returnerar success, failure eller unknown med en motivering. För den här agenten kan det till exempel vara följande kriterier:

• patient_verified: ”Markera som lyckat om agenten bekräftade uppringarens identitet genom både EHR-sökningen och SMS-engångskoden innan den gick vidare till bokning.”
• appointment_booked: ”Markera som lyckat om patientens tid bokades”
• appointment_changed: ”Markera som lyckat om patienten bad om att boka om eller avboka en befintlig tid och agenten genomförde ändringen – uppdaterade eller tog bort kalenderhändelsen – och bekräftade resultatet för uppringaren.” 
• call_escalated_when_requested: ”Markera som lyckat om uppringaren bad om att få prata med en människa och agenten överförde samtalet; markera som misslyckat om uppringaren bad om det och agenten inte överförde.”

Datainsamling

Du kan kombinera dessa med datainsamlingsfält. Du kan till exempel lägga till requested_action (boka, boka om eller avboka), appointment_date eller appointment_type, som extraheras som strukturerade sträng-, booleska eller numeriska värden från varje transkribering och skickas vidare via en webhook efter samtalet till det system som följer upp samtalsresultat. 

Simuleringar och tester

Inom vården måste en agent förtjäna förtroende före sitt första riktiga samtal – felmoder måste upptäckas i testning, inte inför en patient. Conversation Simulation API simulerar realistiska uppringarscenarier, både från början till slut och i riktade segment, och utvärderar automatiskt resultat med samma kriterier som används i produktion – exakt kontrollerna patient_verified och appointment_booked som definierats ovan, inte en separat testmall. Kör fullständiga simuleringar för hela samtalet, eller partiella simuleringar som börjar mitt i samtalet för att validera en enskild beslutspunkt. Det går snabbare när du vill iterera på en nod utan att köra om hela flödet. 

För den här agenten innebär det att skriva scenarier som går längre än det ideala scenariot: en uppringare vars namn inte matchar någon EHR-journal, någon som misslyckas med OTP-koden två gånger, en patient som vill boka om i stället för att boka och en uppringare som uttryckligen ber om en människa mitt under verifieringen – tydliga, fokuserade scenarier som täcker gränsfall, verktygsanvändning och fallback-logik i stället för att du hoppas att de dyker upp i produktion.

Anslut ditt Twilio-telefonnummer

När agenten är byggd tar det bara några minuter att ansluta den till ett aktivt nummer:

1. Gå till Phone Numbers i ElevenLabs-dashboarden och klicka på Import number.
2. Ange en Label, Phone Number och ditt Twilio Account SID och Auth Token
3. När numret har importerats tilldelar du det till din agent i rullgardinsmenyn
4. Ring numret för att testa det och kontrollera sedan dashboarden för samtalshistorik för att bekräfta att de första samtalen fungerade som förväntat.

Redo för riktiga patienter

Det vi har byggt är en patientbokningsagent som gör mer än att svara i telefon: den verifierar identiteten mot ett EHR-system och en OTP-kod med en andra faktor innan den öppnar en journal, bokar, bokar om och avbokar direkt i en livekalender via Cal.coms API och vet när den ska kliva åt sidan och lämna över en uppringare till en människa. Det deterministiska workflowet, skyddsräckena vid körning och utvärderingskriterierna ger team den granskningshistorik och det upprepbara testmönster som vårddistributioner kräver.

När du går live visar det här mönstret sitt värde. Utvärderingskriterierna som definierades under bygget blir tröskeln för produktionssättning – när agenten klarar dem konsekvent och mätvärdena har stabiliserats kan du lansera med tillförsikt i stället för att göra en bedömning på känsla – och efter lanseringen flyttas lärandet från simulerade tester till produktionstranskriberingar. Vi beskriver dessa metoder, från stegvisa utrullningar till att veta när man ska sluta iterera, i ett tidigare blogginlägg.

Ett viktigt steg mot HIPAA-efterlevnad är datahantering. Genom att aktivera Zero Retention Mode tas samtalsinspelningar, transkriberingar och metadata som innehåller PII bort så fort ett samtal avslutas, vilket stänger den största källan till efterlevnadsrisk i en telefonibaserad lösning. Tillsammans med en webhook efter samtalet försvinner ingen insyn – varje bokningsresultat, verifieringsresultat och utvärderingspoäng skickas till ditt eget system i realtid när samtalet avslutas.

Du har nu en mall för att placera agentbaserad röst-AI vid ingången till din klinik. Tidsbokning är det område med högst volym att börja med, och samma mönster kan utvidgas till patientinskrivning, receptförnyelser, fakturering och uppföljningar efter besök – varje samtal behöver då inte längre hamna i röstbrevlådan efter öppettider. Vårt Forward Deployed Engineering-team samarbetar nära med vårdorganisationer för att omvandla distributioner som denna till konkreta produktfunktioner. Om du vill ta ett patientnära workflow till ElevenAgents med den efterlevnadsnivå som vården kräver, prova det här arbetssättet och berätta gärna vad du tycker.