Vai al contenuto

ElevenAgents per la sanità: crea un agente per la gestione delle prenotazioni telefoniche

Scritto da
Nathan Pogue
Pubblicato
Ultimo aggiornamento

AscoltaAscolta questo articolo

Il telefono è ancora la porta d'accesso alla sanità, ed è congestionato. Mayo Clinic ricerca ed Epic caso di studio mostrano entrambi che circa il 30% delle prenotazioni di appuntamenti avviene al di fuori dell'orario lavorativo. Le chiamate che finiscono in segreteria sono appuntamenti che, senza clamore, non vengono fissati, mentre il personale di reception incaricato di gestirle è sovraccarico e cambia rapidamente. Gli agenti vocali hanno superato la fase delle demo e aiutano le cliniche a colmare questo divario; la prenotazione è il punto di ingresso più comune: un'attività ad alto volume, ripetitiva, prevedibile e che rappresenta una parte significativa del lavoro di reception senza richiedere giudizio clinico.

La prenotazione di appuntamenti in ambito sanitario alza ulteriormente l'asticella. Uno slot errato o il motivo della visita compreso male non sono soltanto una cattiva esperienza: sono un problema di sicurezza e conformità normativa. Un agente di reception per le prenotazioni necessita di più di una voce gradevole: verifica affidabile dell'identità, guardrail rigorosi, un percorso chiaro di escalation verso una persona, misure di conformità per gestire informazioni sanitarie protette e la capacità di completare, modificare o annullare prenotazioni in un sistema di pianificazione reale.

Questa guida ti mostra come creare esattamente questo con ElevenAgents: un agente accessibile via telefono, collegato a un EHR di esempio, che prenota, riprogramma e annulla appuntamenti dall'inizio alla fine e trasferisce la chiamata quando necessario. Avrai a disposizione workflow, guardrail, test e analisi per farlo operare entro limiti definiti, su un'infrastruttura progettata per il settore sanitario regolamentato.

Ecco una demo dell'agente che creerai mentre gestisce una chiamata in tempo reale dall'inizio alla fine:

Prerequisiti

Per iniziare, ti serviranno:

  • Un account ElevenLabs, con accesso alla piattaforma ElevenAgents e alle nostre voci.
  • Un account Twilio e un numero.
  • Accesso a Twilio Verify.
  • Un ambiente EHR sandbox o per sviluppatori. In questa guida useremo HAPI FHIR, un'implementazione di riferimento open source per il formato HL7 FHIR, per verificare record sintetici dei pazienti.
  • L'applicazione di calendario del tuo studio. Ai fini di questa guida, utilizziamo l'integrazione nativa di ElevenLabs con Cal.com

Facoltativo

Se non hai accesso a dati sandbox o stai seguendo la guida a scopo dimostrativo, useremo il server sandbox HAPI FHIR R4 e lo popoleremo con un record fittizio di un paziente da utilizzare durante la fase di verifica. Per farlo, esegui il seguente comando API con dati fittizi dal terminale:

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)"
  }'

La corrispondenza è confermata soltanto se la query restituisce esattamente un record: zero risultati indicano nessuna corrispondenza, mentre più di un risultato significa che i parametri di ricerca non erano abbastanza specifici per procedere in sicurezza. 

Architettura

In questa guida creerai un agente per le prenotazioni che opera tramite un numero Twilio, integrato nativamente con il tuo ElevenAgent. Quando arriva una chiamata in entrata, l'agente assisterà il paziente usando gli strumenti disponibili per raccogliere i dati di verifica e dell'appuntamento, sia che chi chiama voglia prenotare una nuova visita, riprogrammarne una o annullarne una esistente, con la possibilità di trasferire la chiamata a una persona quando necessario.

Patient sends OTP via Twilio to an ElevenLabs Agent, which uses tools or transfers to front desk.

Con questa architettura e questi strumenti, un flusso di chiamata riuscito prevede i seguenti passaggi:

  1. Avvio della chiamata: un paziente chiama il numero Twilio associato all'agente, che lo saluta e ne rileva l'intento.
  2. Convalida EHR: l'agente verifica i dati del paziente rispetto al suo record nell'EHR.
  3. Verifica: l'agente invia una password monouso (OTP) al numero di telefono del paziente per la verifica finale tramite il suo strumento SMS.
  4. Prenotazione o modifica: l'agente agisce in base all'intento rilevato sul calendario: per un nuovo appuntamento, raccoglie i dettagli della prenotazione e controlla la disponibilità; per una riprogrammazione, recupera l'appuntamento esistente e trova un nuovo slot; per un annullamento, conferma e rimuove l'appuntamento esistente.
  5. Trasferimento: se la prenotazione o la modifica non riesce, il paziente chiede di parlare con una persona oppure viene rilevato un altro intento che l'agente non può gestire, la chiamata viene trasferita a un operatore umano.
  6. Conferma e chiusura: dopo una prenotazione, riprogrammazione o annullamento riuscito, l'agente riepiloga i dettagli della chiamata e la conclude cordialmente.

System prompt e impostazioni dell'agente

Il primo passo per creare un ElevenAgent efficace è il suo system prompt. Seguendo la guida al prompting di ElevenLabs, lo strutturiamo nei componenti fondamentali consigliati per ogni agente in produzione — personalità, obiettivo, tono, strumenti e guardrail — ciascuno in una sezione chiaramente etichettata, anziché in un unico blocco continuo di istruzioni.

Per un agente di prenotazione in ambito sanitario, questa struttura deve considerare chi c'è davvero dall'altra parte della chiamata: una persona anziana, che prova dolore, ha difficoltà uditive o è semplicemente preoccupata del motivo della chiamata. Le sezioni sulla personalità e sul tono definiscono un ritmo accogliente e senza fretta e mantengono le risposte brevi e conversazionali, con date, orari e numeri pronunciati come farebbe una persona anziché letti da uno schermo. La sezione dell'obiettivo illustra il flusso in sequenza: verifica dell'identità, poi, a seconda che chi chiama voglia prenotare, riprogrammare o annullare, controllo della disponibilità e conferma dello slot, ricerca e spostamento dell'appuntamento esistente oppure conferma dell'appuntamento da rimuovere. Gli strumenti sono documentati con gli input esatti nel formato parlato previsto. I guardrail includono le regole specifiche del settore: non mostrare mai più PHI di quanto chi chiama abbia già condiviso, non inventare mai disponibilità o dettagli dell'appuntamento quando uno strumento non funziona, rifiutare le domande cliniche indirizzando il chiamante al proprio medico e inoltrare subito la chiamata se qualcuno descrive sintomi urgenti o un'emergenza medica. La verifica dell'identità prima di qualsiasi azione sull'appuntamento è l'unica regola ripetuta, anziché indicata una sola volta. È il limite che l'agente non può permettersi di oltrepassare.

A questo punto puoi aggiungere ulteriori configurazioni dell'agente, come il primo messaggio, diverse lingue (assicurati che lo strumento di sistema per il rilevamento della lingua sia abilitato), l'LLM che preferisci, un modello ElevenLabs conversazionale di sintesi vocale e una voce ElevenLabs.

Puoi trovare un esempio di system prompt qui.

ElevenLabs voice agent setup screen for configuring a healthcare scheduling assistant.

Guardrail

La sezione Guardrail del system prompt comprende regole a livello di istruzioni, a cui il modello attribuisce un peso elevato. Tuttavia, un prompt rimane un livello non deterministico e può deviare durante una chiamata lunga. ElevenAgents le supporta con un'applicazione indipendente a runtime attraverso i propri Guardrail. Tra questi ci sono il Focus Guardrail, che rafforza il system prompt quando le conversazioni si prolungano, i Manipulation Guardrails, che intercettano i tentativi di prompt injection prima che l'agente risponda, e i Content e Custom Guardrails, che valutano ogni risposta in tempo reale e possono bloccarla prima che chi chiama la senta. Ogni guardrail è configurato con una modalità di esecuzione — streaming per una latenza quasi nulla oppure blocking per trattenere una risposta fino al superamento del controllo — e una strategia di uscita per quando viene attivato: terminare la chiamata oppure riprovare con feedback correttivo inserito nel turno successivo.

Per questo agente possiamo definire guardrail personalizzati per le regole specifiche della sanità o della clinica: bloccare la diagnosi di condizioni o le raccomandazioni di trattamento, le domande di fatturazione, le indicazioni sul dosaggio dei farmaci e qualsiasi contenuto che sostituisca il parere di un medico abilitato. In caso di sintomi urgenti, imposta la strategia di uscita su riprova con un feedback che trasferisca la chiamata a una persona, così il guardrail passa la chiamata al personale anziché limitarvisi a terminarla.

Guardrails dashboard showing active Focus, Manipulation, Content, and Custom policies.
Guardrails settings panel showing five enabled custom clinical safety guardrails.

Strumenti

Ogni fase del flusso richiede specifici strumenti webhook e di integrazione per eseguire azioni specifiche mentre parli con il paziente.

Strumento di verifica EHR

Per verificare il paziente rispetto al suo record nell'EHR, utilizzeremo l'azione API FHIR GET /Patient. Aggiungila come strumento webhook che punta al tuo URL di base HAPI FHIR, con family, given, identifier e birthdate impostati come parametri compilati dall'LLM. La prima chiamata allo strumento della fase di verifica raggiunge l'endpoint con il nome e la data di nascita di chi chiama in un'unica query:

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

La corrispondenza è confermata solo quando la query restituisce esattamente un record e l'agente può procedere alla fase di prenotazione soltanto se questa condizione è soddisfatta.

Puoi trovare un esempio JSON dello strumento qui.

Strumenti di verifica SMS Twilio

Una volta confermata la corrispondenza nell'EHR, la fase di verifica passa a un secondo fattore: inviare via SMS al paziente un codice monouso e confermarlo prima di procedere. La configurazione richiede tre passaggi:

1. Crea gli strumenti webhook SMS. Configura due strumenti, send_SMS_verification e check_SMS_verification, entrambi diretti al tuo servizio Twilio Verify. Ciascuno richiede il Verify Service SID (il valore VA... dalle impostazioni del servizio Verify) nel path dell'URL e un header di autenticazione Basic creato con Account SID e Auth Token, archiviati come segreto.

2. Imposta il destinatario con una variabile di sistema. ElevenAgents fornisce variabili di sistema che popolano automaticamente system__caller_id con il numero di telefono di chi chiama in qualsiasi chiamata vocale; passa quindi {{system_caller_id}} come parametro To invece di chiedere a chi chiama di leggere il numero ad alta voce. In un ambiente di produzione integrato con un EHR attivo, il codice verrebbe invece inviato al numero di telefono memorizzato nel record del paziente, anziché all'identificatore del chiamante.

3. Abilita skip_turn. Aggiungendo questo strumento di sistema insieme agli strumenti webhook, l'agente può attendere in silenzio mentre chi chiama cerca il messaggio, anziché parlare durante la pausa.

Può accedere alla fase di prenotazione soltanto chi supera sia la ricerca nell'EHR sia il controllo OTP. 

Puoi trovare un esempio JSON di entrambi gli strumenti qui e qui.

Strumenti di integrazione del calendario

La fase di prenotazione deve controllare la disponibilità, prenotare, riprogrammare e annullare in un calendario reale. La configurazione dell'integrazione Cal.com richiede tre passaggi:

1. Collega l'integrazione. Nella scheda Strumenti dell'agente, aggiungi l'integrazione Cal.com e fai clic su Connetti.

2. Fissa il tipo di evento. Ogni strumento del calendario accetta un ID del tipo di evento che indica a Cal.com per quale evento effettuare la prenotazione. Impostalo come parametro fisso negli strumenti collegati utilizzando l'ID della tua dashboard Cal.com.

3. Imposta l'email del partecipante. Gli strumenti di prenotazione richiedono anche un'email del partecipante. A scopo dimostrativo, impostala come parametro fisso sul tuo indirizzo, così le conferme arriveranno nella tua casella di posta. In produzione con un EHR reale, la ricaveresti dall'email nel record del paziente anziché impostarla in modo statico.

Da qui, il flusso di prenotazione dipende dall'intento rilevato in Greeting. Per un nuovo appuntamento, l'agente chiama calcom_get_available_slots per cercare gli orari disponibili prima di proporne uno, quindi calcom_create_booking dopo la conferma di chi chiama, sempre in quest'ordine, poiché controllare prima la disponibilità evita di prenotare due volte lo stesso slot. Per una riprogrammazione o un annullamento, individua prima l'appuntamento esistente di chi chiama con calcom_find_bookings_by_attendee, conferma con chi chiama la prenotazione specifica, quindi la rimuove con calcom_cancel_booking oppure, in caso di riprogrammazione, prenota il nuovo slot prima di annullare quello precedente.

Trasferimento a una persona

Per trasferire la chiamata a una persona, possiamo usare lo transfer_to_number strumento di sistema di ElevenLabs. Aggiungilo come strumento di sistema a livello dell'agente, così sarà raggiungibile da Greeting, Verification e Booking. Per la regola di trasferimento, aggiungi il numero di telefono di destinazione in formato E.164 e una condizione in linguaggio naturale che descriva quando deve attivarsi. L'LLM decide quando e dove trasferire in base a queste condizioni e alla descrizione dello strumento. Lascia il tipo di trasferimento su Conference, l'impostazione predefinita, poiché supporta un messaggio di passaggio che informa l'operatore umano sul motivo della chiamata.

Strutturare il percorso del paziente

Workflow sono flussi di conversazione visivi basati su grafi, creati da alcuni tipi di nodi: nodi subagente che aggiungono un system prompt, strumenti e knowledge base all'agente di base orchestratore per una fase della chiamata; nodi dispatch tool che garantiscono l'esecuzione di uno strumento specifico e si diramano in base a successo o fallimento; nodi di trasferimento dell'agente e transfer-to-number per i passaggi di consegna; e un nodo di fine per chiudere la chiamata. I nodi sono collegati da archi e quelli in avanti possono contenere una condizione LLM: una regola in linguaggio naturale che il modello valuta in tempo reale per decidere quale percorso seguire. Creiamo l'agente con cinque nodi subagente — Greeting, Verification, Booking, Transfer Notice e Close — ciascuno circoscritto ai propri strumenti, più un singolo nodo Phone Number Transfer raggiungibile da Transfer Notice.

Saluto è il punto di ingresso: risponde alla chiamata, presenta la clinica e rileva l'intento del paziente prima di passare il controllo, senza strumenti propri, ma con un contesto sufficiente per instradare correttamente.

Verifica esegue il controllo a due fattori descritto in precedenza, utilizzando lo strumento FHIR GET /Patient per confermare che chi chiama corrisponda a un record nell'EHR, quindi gli strumenti send_SMS_verification e check_SMS_verification per inviare e verificare un codice monouso prima che chi chiama possa procedere. Avanza soltanto chi supera entrambi i controlli; per tutti gli altri è previsto un arco in avanti verso Transfer Notice.

Prenotazione contiene gli strumenti di calendario della sezione precedente e l'intento rilevato in Greeting determina il percorso: controllare la disponibilità e prenotare un nuovo appuntamento, cercare la prenotazione esistente e riprenotare prima di annullarla per una riprogrammazione oppure confermare e annullare per un annullamento. Questo nodo può anche passare a Transfer Notice: se nessuna opzione nel calendario è adatta, chi chiama non può essere associato a un appuntamento esistente oppure preferisce parlare con il personale, l'arco lo instrada lì invece di bloccare la chiamata.

Avviso di trasferimento si trova tra il resto del workflow e il passaggio di consegne vero e proprio: un breve subagente il cui unico compito è comunicare a chi chiama che sta per avvenire un trasferimento (ad esempio: "Ora ti metto in contatto con un membro del nostro team") prima che la chiamata lasci effettivamente l'agente. Instradare prima ogni condizione di trasferimento attraverso questo nodo, anziché attivare transfer_to_number direttamente da Greeting, Verification o Booking, garantisce che chi chiama senta sempre quel messaggio invece di essere trasferito senza avviso se la formulazione varia tra i subagenti.

Trasferimento al numero di telefono, basato sullo strumento transfer_to_number, è il nodo verso cui Transfer Notice inoltra sempre la chiamata. Le sue regole associano un numero di destinazione alle stesse condizioni provenienti dai nodi precedenti — verifica non riuscita, richiesta esplicita, prenotazione non completabile — ed eseguono il passaggio effettivo dopo che chi chiama è già stato informato.

Chiusura viene raggiunto soltanto dopo una prenotazione riuscita: riepiloga a chi chiama i dettagli dell'appuntamento e conclude la chiamata in modo cordiale.

Puoi trovare un modello JSON di esempio del workflow qui.

Call workflow: greeting, verification, booking for verified callers, or transfer; then close.

Analisi e test

La maggior parte del lavoro su un agente vocale per la sanità non riguarda il percorso ideale, ma tutto ciò che deve funzionare correttamente quando la chiamata non segue lo script. ElevenAgents è progettato per test e analisi nativi della piattaforma: questo significa che gli stessi criteri di valutazione usati per i test prima del lancio valutano ogni chiamata in produzione, senza strumenti separati da collegare o riconciliare.

Criteri di successo

Definisci criteri di successo per acquisire criteri di valutazione specifici, in linea con i tuoi obiettivi aziendali e operativi. Nella scheda Analisi, ciascun criterio è un prompt in linguaggio naturale che un LLM esegue sulla trascrizione e restituisce successo, errore o sconosciuto con una motivazione. Per questo agente, potrebbero includere criteri come:

  • patient_verified: "Contrassegna come riuscito se l'agente ha confermato l'identità di chi chiama sia tramite la ricerca nell'EHR sia tramite il codice monouso SMS prima di procedere alla prenotazione."
  • appointment_booked: "Contrassegna come riuscito se l'appuntamento del paziente è stato prenotato"
  • appointment_changed: "Contrassegna come riuscito se il paziente ha chiesto di riprogrammare o annullare un appuntamento esistente e l'agente ha completato la modifica, aggiornando o eliminando l'evento del calendario, e ne ha confermato l'esito a chi chiama." 
  • call_escalated_when_requested: "Contrassegna come riuscito se chi chiama ha chiesto di parlare con una persona e l'agente ha trasferito la chiamata; contrassegna come fallito se chi chiama l'ha chiesto e l'agente non ha effettuato il trasferimento."

Raccolta dei dati

Puoi abbinarli a campi di raccolta dati. Ad esempio, aggiungendo requested_action (prenota, riprogramma o annulla), appointment_date o appointment_type, estratti da ogni trascrizione come valori strutturati di tipo stringa, booleano o numerico e inviati a valle tramite webhook post-chiamata a qualsiasi sistema che monitora gli esiti delle chiamate. 

Analysis settings screen showing model, language, feature toggles, criteria, and data points.

Simulazioni e test

In ambito sanitario, un agente deve conquistare fiducia prima della prima chiamata reale: le modalità di errore devono emergere nei test, non davanti a un paziente. La API di simulazione delle conversazioni simula scenari realistici per chi chiama, sia end-to-end sia in segmenti mirati, e valuta automaticamente i risultati usando gli stessi criteri in esecuzione in produzione: gli esatti controlli patient_verified e appointment_booked definiti sopra, non una griglia di valutazione separata per i test. Esegui simulazioni complete per l'intera chiamata oppure simulazioni parziali che iniziano a metà conversazione per convalidare un singolo punto decisionale: è il modo più rapido per iterare su un nodo senza rieseguire l'intero flusso. 

Per questo agente, significa creare script con scenari che vanno oltre il percorso ideale: una persona il cui nome non corrisponde ad alcun record EHR, qualcuno che sbaglia l'OTP due volte, un paziente che chiede di riprogrammare anziché prenotare e una persona che chiede esplicitamente di parlare con un operatore a metà della verifica. Sono scenari chiari e mirati che ti offrono copertura per casi limite, uso degli strumenti e logica di fallback, invece di sperare che emergano in produzione.

Collega il tuo numero di telefono Twilio

Dopo aver creato l'agente, collegarlo a un numero attivo richiede pochi minuti:

  1. Nella dashboard ElevenLabs, vai a Numeri di telefono e fai clic su Importa numero.
  2. Inserisci un'Etichetta, il Numero di telefono e i tuoi SID dell'account e Token di autenticazione
  3. Dopo l'importazione, assegna il numero al tuo agente dal menu a discesa
  4. Chiama il numero per testarlo, quindi controlla la dashboard della cronologia Conversazioni per verificare che le prime chiamate si siano comportate come previsto.

Pronto per pazienti reali

Abbiamo creato un agente per la pianificazione degli appuntamenti dei pazienti che fa più che rispondere al telefono: verifica l'identità rispetto a un EHR e a un OTP come secondo fattore prima di accedere a un record, prenota, riprogramma e annulla direttamente su un calendario attivo tramite l'API di Cal.com e sa quando farsi da parte e passare la chiamata a una persona. Il workflow deterministico, i guardrail a runtime e i criteri di valutazione offrono ai team la traccia di audit e il modello di test ripetibile richiesti dalle implementazioni sanitarie.

Il lancio in produzione è il momento in cui questo modello dimostra il suo valore. I criteri di valutazione definiti durante la creazione diventano la soglia per il go-live: quando l'agente li supera con costanza e le metriche si stabilizzano, hai la sicurezza per lanciare il prodotto invece di dover decidere a intuito. Dopo il lancio, l'apprendimento passa dai test simulati alle trascrizioni di produzione. Trattiamo queste pratiche, dai rilasci graduali fino a capire quando smettere di iterare, in un precedente articolo del blog.

Un passaggio fondamentale verso la conformità HIPAA è la gestione dei dati. L'attivazione di Modalità Zero Retention elimina registrazioni delle chiamate, trascrizioni e metadati contenenti PII non appena una chiamata termina, rimuovendo la principale fonte di rischio di conformità nelle implementazioni telefoniche. Insieme a un webhook post-chiamata, non perdi alcuna visibilità: ogni esito di prenotazione, risultato della verifica e punteggio di valutazione viene inviato al tuo sistema in tempo reale alla conclusione della chiamata.

Ora hai un modello per mettere l'IA vocale agentica all'ingresso della tua clinica. La pianificazione degli appuntamenti è il punto di partenza con il volume più alto, e lo stesso modello si estende all'accettazione dei pazienti, ai rinnovi delle prescrizioni, alla fatturazione e ai follow-up post-visita: tutte chiamate che non devono più finire in segreteria fuori orario. Il nostro team di Forward Deployed Engineering collabora strettamente con le organizzazioni sanitarie per trasformare implementazioni come questa in funzionalità concrete del prodotto. Se vuoi portare un workflow rivolto ai pazienti su ElevenAgents con le misure di conformità richieste dalla sanità, prova questo approccio e facci sapere cosa ne pensi.

Articoli simili

Crea con l'audio IA della massima qualità