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

Telefonen är fortfarande ingången till vården, och det är fullt tryck. Mayo Clinic forskning och Epic fallstudie visar båda att omkring 30 % av all tidsbokning sker utanför ordinarie öppettider. Samtal som hamnar i röstbrevlådan blir bokningar som aldrig blir av, medan receptionspersonalen som ska fånga upp dem är hårt belastad och slutar i snabb takt. Röstagenter har gått bortom demostadiet som ett sätt för kliniker att täppa till det här glappet, och tidsbokning är den vanligaste startpunkten: stora volymer, 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 anledning till besöket ä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 smidig väg att eskalera till en människa, rätt efterlevnad för att hantera skyddade hälsouppgifter och förmågan att faktiskt slutföra, ändra eller avboka tider i ett riktigt bokningssystem.

Den här guiden bygger precis det med ElevenAgents: en telefonianpassad 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 det behövs. Du får arbetsflödet, skyddsräcken, testning och analys som håller den inom ramarna – driftsatt på infrastruktur byggd för reglerad vård.

Här är en demo av agenten du bygger när den hanterar ett riktigt samtal från början till slut:

Förutsättningar

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

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

Valfritt

Om du inte har tillgång till sandboxdata, eller följer guiden i demosyfte, använder vi HAPI FHIR R4-sandboxservern och fyller den med en testpatientjournal som du kan använda under verifieringssteget. Kör följande API-kommando med testdata i terminalen:

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 bara när frågan returnerar exakt en journal – noll resultat betyder ingen träff, och fler än en betyder att sökparametrarna inte är 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 med sina tillgängliga verktyg för att samla in verifierings- och bokningsuppgifter – oavsett om personen vill boka ett nytt besök, boka om eller avboka ett befintligt – och kan vid behov koppla samtalet till en människa.

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

1. Samtalsstart: en patient ringer Twilio-numret som är kopplat till agenten, som hälsar patienten välkommen och fångar upp ärendet.
2. EHR-validering: agenten validerar patientens uppgifter mot journalen 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 agerar utifrån 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 att få tala med en människa eller agenten fångar upp ett annat ärende som den inte kan hantera, överförs samtalet till en mänsklig agent.
6. Bekräftelse och avslut: efter en lyckad bokning, ombokning eller avbokning sammanfattar agenten samtalets uppgifter och avslutar på ett varmt sätt.

Systemprompt och agentinställningar

Det första steget för att bygga en effektiv ElevenAgent finns i dess systemprompt. Enligt ElevenLabs guide för prompting 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 får en egen tydligt märkt sektion i stället för ett sammanhängande instruktionsblock.

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

Härifrån kan du lägga till ytterligare agentkonfigurationer, till exempel det första meddelandet, olika språk (se till att systemverktyget för språkidentifiering är aktiverat), valfri LLM, en konversationsbaserad ElevenLabs text-till-tal-modell och en ElevenLabs-röst.

Ett exempel på en systemprompt hittar du här.

Skyddsräcken

Systempromptens avsnitt om skyddsräcken omfattar regler på instruktionsnivå och ges stor vikt av modellen. Men en prompt är fortfarande ett icke-deterministiskt lager som kan glida iväg under ett långt samtal. ElevenAgents kompletterar detta med oberoende tillämpning under 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 den som ringer hör det. Varje skyddsräcke konfigureras med ett körläge – streaming för nästan ingen fördröjning eller blocking för att hålla kvar ett svar tills det godkänns – och en exitstrategi för vad som händer när det utlöses: avsluta samtalet eller försök 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 vård- eller klinikspecifika regler: blockera diagnostisering av tillstånd eller rekommendationer om behandling, blockera faktureringsfrågor, blockera doseringsråd för läkemedel och blockera allt som ersätter råd från legitimerad vårdpersonal. Vid 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 talar med patienten.

Verktyg för EHR-verifiering

För att verifiera patienten mot dess journal i EHR-systemet använder vi API-åtgärden FHIR GET /Patient. Lägg till den som ett webhook-verktyg som pekar mot din HAPI FHIR-bas-URL, med family, given, identifier och birthdate inställda som parametrar som fylls i av LLM:en. Verifieringsstegets första verktygsanrop anropar slutpunkten med den som ringerens 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 bara när frågan returnerar exakt en journal, och agenten kan bara gå vidare till bokningssteget om detta villkor är uppfyllt.

Ett exempel på verktygets JSON hittar du här.

Twilio-verktyg för SMS-verifiering

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 sker. Det kräver tre steg:

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

2. Ange mottagaren med en systemvariabel.ElevenAgents tillhandahåller systemvariabler som automatiskt fyller system__caller_id med den som ringerens telefonnummer i alla röstsamtal, så skicka {{system_caller_id}} som To-parameter i stället för att be personen läsa upp ett nummer. I en produktionsmiljö integrerad med ett aktivt EHR-system skulle koden i stället skickas till telefonnumret i patientens journal, inte till uppringaridentifieraren.

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

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

Ett exempel på JSON för båda verktygen hittar du här och här.

Kalenderintegrationsverktyg

Bokningssteget behöver kontrollera tillgänglighet, boka, boka om och avboka i en riktig kalender. Att ställa in Cal.com-integrationen kräver tre steg:

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

2. Lås händelsetypen. Varje kalenderverktyg tar emot ett händelsetyp-ID som anger för Cal.com vilken händelse som ska bokas. 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 ange din egen adress som en fast parameter så att bekräftelserna hamnar i din inkorg. I produktion med ett riktigt EHR-system fyller du i den från e-postadressen i patientens journal i stället för att hårdkoda den.

Därefter beror bokningsflödet på ärendet som fångades upp i Greeting. Vid en ny bokning anropar agenten calcom_get_available_slots för att söka efter lediga tider innan den erbjuder en, och därefter calcom_create_booking när den som ringer bekräftar – alltid i den ordningen, eftersom en tillgänglighetskontroll först undviker dubbelbokning. Vid ombokning eller avbokning hittar den först den som ringerens befintliga tid med calcom_find_bookings_by_attendee, bekräftar den specifika bokningen med personen och tar sedan antingen bort den med calcom_cancel_booking eller, vid ombokning, bokar den nya tiden innan den avbokar den gamla.

Ö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 detta som ett systemverktyg på agentnivå så att det kan nås från både Greeting, Verification och Booking. Lägg till mottagarens telefonnummer i E.164-format och ett villkor på klarspråk som beskriver när överföringen ska ske. LLM:en avgör när och vart den ska överföra baserat på dessa villkor tillsammans med verktygets beskrivning. Behåll överföringstypen Conference, som är standard, eftersom den stöder ett varmt överlämningsmeddelande som förklarar för den mänskliga operatören varför samtalet kopplas fram.

Strukturera patientresan

Arbetsflöden är visuella, grafbaserade samtalsflöden som byggs av några få nodtyper: underagentnoder som lägger en systemprompt, verktyg och kunskapsbas ovanpå basagenten orchestrator för en fas i samtalet; dispatch tool-noder som säkerställer att ett specifikt verktyg körs och förgrenas vid lyckat eller misslyckat resultat; agentöverförings- och transfer-to-number-noder för överlämningar; samt en slutnod som avslutar samtalet. Noder kopplas samman av 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 som ska tas. Vi bygger agenten med fem underagentnoder – Greeting, Verification, Booking, Transfer Notice och Close – var och en begränsad till sina egna verktyg, samt en Phone Number Transfer-nod som kan nås från Transfer Notice.

Hälsning är ingångspunkten: den svarar på samtalet, presenterar kliniken och fångar upp patientens ärende innan den lämnar över – inga egna verktyg, bara tillräckligt med sammanhang för att styra rätt.

Verifiering hanterar tvåfaktorskontrollen ovan med FHIR-verktyget GET /Patient för att bekräfta att den som ringer matchar en journal i EHR-systemet, och sedan verktygen send_SMS_verification och check_SMS_verification för att skicka och kontrollera en engångskod innan personen kan gå vidare. Endast personer som klarar båda kontrollerna går vidare; övriga får en framåtkant till Transfer Notice.

Bokning ä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. Noden faller också öppet vidare till Transfer Notice – om ingen tid i kalendern passar, personen inte kan matchas mot en befintlig bokning eller vill tala med personal i stället, dirigeras kanten dit i stället för att samtalet fastnar.

Meddelande om överföring ligger mellan resten av workflowet och själva överlämningen – en kort underagent vars enda uppgift är att tala om för den som ringer att ett samtal kopplas vidare (t.ex. ”Jag kopplar dig till någon i vårt team nu”) innan samtalet faktiskt lämnar agenten. Genom att först dirigera alla överföringsvillkor genom den här noden, i stället för att aktivera transfer_to_number direkt från Greeting, Verification eller Booking, säkerställs att personen alltid hör den meningen i stället för att bli tyst vidarekopplad om formuleringen råkar variera mellan underagenter.

Överföring till telefonnummer, som bygger på verktyget transfer_to_number, är noden som Transfer Notice alltid skickar vidare till. Dess regler kopplar ett mottagarnummer till samma villkor som förs vidare från tidigare steg – misslyckad verifiering, en uttrycklig begäran eller en bokning som inte kan slutföras – och genomför den faktiska överlämningen när personen redan har fått veta att den kommer.

Avsluta nås bara efter en lyckad bokning: den sammanfattar bokningsuppgifterna för den som ringer och avslutar samtalet på ett varmt sätt.

Ett exempel på en JSON-mall för workflowet hittar du här.

Analys och testning

Större delen av arbetet med en röstagent inom vården handlar inte om det ideala flödet – utan om allt som måste fungera korrekt när samtalet inte följer manuset. ElevenAgents är byggt för testning och analys direkt i plattformen, vilket innebär att samma utvärderingskriterier som du använder för tester före lansering poängsätter varje samtal i produktion, utan något separat verktyg att koppla in 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 Analysis är varje kriterium en prompt på klarspråk som en LLM kör mot transkriptet och returnerar lyckades, misslyckades eller okänt med en motivering. För den här agenten kan kriterierna exempelvis vara:

• patient_verified: ”Markera som lyckat om agenten bekräftade den som ringerens identitet både genom 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 raderade kalenderhändelsen – och bekräftade resultatet för den som ringer.” 
• call_escalated_when_requested: ”Markera som lyckat om den som ringer bad att få tala med en människa och agenten överförde samtalet; markera som misslyckat om personen 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 transkript och skickas vidare via webhook efter samtal till det system som spårar 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 framför en patient. Conversation Simulation API simulerar realistiska scenarier för den som ringer, både från början till slut och i avgränsade delar, och poängsätter automatiskt resultaten med samma kriterier som körs i produktion – exakt de patient_verified- och appointment_booked-kontroller som definieras ovan, inte en separat testmodell. 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 ä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 bortom det ideala flödet: en person vars namn inte matchar någon EHR-journal, någon som anger OTP-koden fel två gånger, en patient som vill boka om i stället för att boka och en person som uttryckligen ber att få tala med en människa mitt under verifieringen – tydliga, fokuserade scenarier som täcker specialfall, verktygsanvändning och reservlogik i stället för att hoppas att de dyker upp i produktion.

Anslut ditt Twilio-telefonnummer

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

1. Gå till Telefonnummer i ElevenLabs-dashboarden och klicka på Importera nummer.
2. Ange en Etikett, Telefonnummer samt din Twilio Account SID och Auth Token
3. När numret har importerats tilldelar du det till din agent från 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 agent för patientbokning som gör mer än att svara i telefon: den verifierar identiteten mot ett EHR-system och en OTP-kod som andra faktor innan den öppnar en journal, bokar, bokar om och avbokar direkt i en aktiv kalender via Cal.com-API:et och vet när den ska kliva åt sidan och lämna över till en människa. Det deterministiska workflowet, skyddsräcken under körning och utvärderingskriterierna ger team det granskningsunderlag och det repeterbara testmönster som vårddriftsättningar kräver.

Det är vid lansering som det här mönstret visar sitt värde. Utvärderingskriterierna som definierades under bygget blir tröskeln för lansering – när agenten uppfyller dem konsekvent och måtten 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 skiftar lärandet från simulerade tester till produktionsutskrifter. Vi beskriver dessa metoder, från stegvisa utrullningar till att veta när du ska sluta iterera, i ett tidigare blogginlägg.

Ett viktigt steg mot HIPAA-efterlevnad är datahantering. När du aktiverarZero Retention Mode raderas samtalsinspelningar, transkript och metadata med PII så snart samtalet avslutas, vilket eliminerar den största källan till efterlevnadsrisk i en telefonbaserad driftsättning. Tillsammans med en webhook efter samtal försvinner inte insynen – 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 agentisk 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 användas för patientintag, receptförnyelser, fakturering och uppföljningar efter besök – varje sådant samtal behöver inte längre hamna i röstbrevlådan efter öppettid. Vårt Forward Deployed Engineering-team samarbetar nära med vårdorganisationer för att omvandla driftsättningar som denna till konkreta produktfunktioner. Om du vill ta ett patientnära workflow till ElevenAgents med den efterlevnad som vården kräver, prova det här tillvägagångssättet och berätta vad du tycker.