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

Il telefono è ancora la porta d’ingresso 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 del normale orario di lavoro. Le chiamate che finiscono in segreteria sono appuntamenti che silenziosamente non avvengono, mentre il personale della reception che dovrebbe gestirle è sovraccarico e cambia rapidamente. Agenti vocali hanno superato la fase dimostrativa come strumento con cui le cliniche colmano questa lacuna, e la gestione degli appuntamenti è il punto di ingresso più comune: alto volume, ripetitiva, prevedibile e una parte significativa del carico di lavoro della reception che non richiede alcun giudizio clinico.

La gestione degli appuntamenti in ambito sanitario alza ulteriormente l’asticella. Uno slot errato o un motivo della visita frainteso non rappresentano solo una cattiva esperienza: sono un incidente di sicurezza e conformità normativa. Un agente per la gestione degli appuntamenti alla reception ha bisogno di più di una voce gradevole: verifica affidabile dell’identità, guardrail rigorosi, un chiaro percorso di escalation verso un operatore, misure di conformità per gestire le informazioni sanitarie protette e la capacità di completare, modificare o annullare prenotazioni in un sistema di pianificazione reale.

Questa guida ti mostra come creare tutto questo con ElevenAgents: un agente accessibile telefonicamente, collegato a un EHR di esempio, che prenota, riprogramma e annulla appuntamenti dall’inizio alla fine e passa a un operatore quando necessario. Avrai workflow, guardrail, test e analisi per mantenerlo entro i limiti, implementato su un’infrastruttura progettata per il settore sanitario regolamentato.

Ecco una demo dell’agente che creerai mentre gestisce una chiamata dal vivo 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 convalidare i dati rispetto a record sintetici dei pazienti.
• L’applicazione calendario del tuo studio. Ai fini di questa guida, usiamo l’integrazione nativa di ElevenLabs con Cal.com. 

Facoltativo

Se non hai accesso a dati sandbox, o se stai seguendo la guida a scopo dimostrativo, useremo il server sandbox HAPI FHIR R4 e lo popoleremo con un record paziente fittizio che potrai usare 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)"
  }'

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

Architettura

In questa guida creerai un agente per la gestione degli appuntamenti che opera tramite un numero Twilio, integrato nativamente con il tuo ElevenAgent. Quando si connette una chiamata in entrata, l’agente assisterà il paziente usando gli strumenti disponibili per acquisire i dati di verifica e dell’appuntamento, sia che chi chiama voglia prenotare una nuova visita, riprogrammare o annullare una visita esistente, con la possibilità di trasferire la chiamata a un operatore quando necessario.

Con questa architettura e questi strumenti, un flusso di chiamata completato con successo comprende i seguenti passaggi:

1. Avvio della chiamata: un paziente chiamerà il numero Twilio associato all’agente, che lo saluterà e ne acquisirà l’intento.
2. Convalida EHR: l’agente convaliderà i dati del paziente rispetto al suo record nell’EHR.
3. Verifica: l’agente invierà una password monouso (OTP) al numero di telefono del paziente per la verifica finale usando il suo strumento SMS.
4. Prenotazione o modifica: l’agente agirà sull’intento acquisito nel calendario: per un nuovo appuntamento, raccoglierà i dettagli della prenotazione e verificherà la disponibilità; per una riprogrammazione, recupererà l’appuntamento esistente e troverà un nuovo slot; per un annullamento, confermerà e rimuoverà l’appuntamento esistente.
5. Trasferimento: se la prenotazione o la modifica non va a buon fine, il paziente chiede di parlare con un operatore o viene acquisito un altro intento che l’agente non è in grado di gestire, la chiamata verrà trasferita a un operatore.
6. Conferma e chiusura: dopo una prenotazione, riprogrammazione o annullamento riuscito, l’agente riepilogherà i dettagli della chiamata e chiuderà cordialmente.

System prompt e impostazioni dell’agente

Il primo passo per creare un ElevenAgent efficace risiede nel suo system prompt. Seguendo la guida al prompting di ElevenLabs, lo strutturiamo nei blocchi fondamentali consigliati per qualsiasi 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 gestione degli appuntamenti sanitari, questa struttura deve tenere conto di chi si trova realmente dall’altra parte della chiamata: qualcuno che potrebbe essere anziano, soffrire, avere difficoltà uditive o semplicemente essere preoccupato per il motivo della chiamata. Le sezioni dedicate a personalità e tono stabiliscono un ritmo cordiale e senza fretta e mantengono le risposte brevi e conversazionali, con date, orari e numeri pronunciati come li direbbe una persona anziché letti da uno schermo. La sezione dell’obiettivo descrive il flusso come una sequenza ordinata: verifica dell’identità, quindi, a seconda che chi chiama voglia prenotare, riprogrammare o annullare, verifica 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 nell’esatto formato parlato che si aspettano. I guardrail includono le regole specifiche di questo settore: non mostrare mai più PHI di quanto chi chiama abbia già condiviso, non inventare mai disponibilità o dettagli dell’appuntamento quando uno strumento fallisce, rifiutare le domande cliniche rimandando al medico del chiamante ed eseguire subito l’escalation se qualcuno descrive sintomi urgenti o un’emergenza medica. La verifica dell’identità prima di qualsiasi azione sull’appuntamento è l’unica regola che viene ripetuta anziché enunciata una sola volta. È il limite che l’agente non può permettersi di oltrepassare.

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

Puoi trovare un esempio di system prompt qui.

Guardrail

La sezione Guardrail del system prompt copre le regole a livello di istruzioni, a cui il modello attribuisce grande peso. Ma un prompt rimane un livello non deterministico e soggetto a deviazioni nel corso di una chiamata lunga. ElevenAgents li supporta con un’applicazione indipendente a runtime tramite i propri Guardrail. Questi includono 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 finché non viene approvata; e una strategia di uscita per ciò che accade in caso di attivazione: terminare la chiamata oppure riprovare con feedback correttivo inserito nel turno successivo.

Per questo agente, possiamo definire guardrail personalizzati per le regole specifiche dell’assistenza sanitaria o della clinica: bloccare la diagnosi di patologie o la raccomandazione di trattamenti, bloccare le domande sulla fatturazione, bloccare indicazioni sul dosaggio dei farmaci e bloccare tutto ciò che sostituisce il parere di un professionista sanitario abilitato. Per i sintomi urgenti, imposta la strategia di uscita su retry con un feedback che trasferisca la chiamata a un operatore, così il guardrail passa la chiamata al personale anziché limitarvisi a terminarla.

Strumenti

Ogni passaggio del flusso richiederà specifici strumenti webhook e di integrazione per eseguire azioni specifiche durante la conversazione con il paziente.

Strumento di verifica EHR

Per verificare il paziente rispetto al suo record nell’EHR, useremo 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 dello strumento nella 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}

Una corrispondenza viene confermata solo quando la query restituisce esattamente un record e l’agente può passare alla fase di prenotazione soltanto se questa condizione è soddisfatta.

Puoi trovare un esempio di JSON dello strumento qui.

Strumenti di verifica SMS Twilio

Una volta confermata la corrispondenza EHR, la fase di verifica passa a un secondo fattore: inviare al paziente un codice monouso via SMS 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 puntati al tuo servizio Twilio Verify. Ciascuno richiede il Verify Service SID (il valore VA... nelle impostazioni del tuo servizio Verify) nel path dell’URL e un header Basic auth creato con Account SID e Auth Token archiviati come secret.

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 anziché chiedere a chi chiama di leggere un numero ad alta voce. In un ambiente di produzione integrato con un EHR reale, il codice verrebbe invece inviato al numero di telefono memorizzato nel record del paziente anziché all’identificatore del chiamante.

3. Abilita skip_turn. Aggiungere questo strumento di sistema insieme agli strumenti webhook consente all’agente di attendere in silenzio mentre chi chiama cerca il messaggio, anziché parlare durante la pausa.

Solo chi supera sia la ricerca EHR sia il controllo OTP può accedere alla fase di prenotazione. 

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

Strumenti di integrazione del calendario

La fase di prenotazione deve verificare la disponibilità, prenotare, riprogrammare e annullare in un calendario reale. Configurare l’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 richiede un ID del tipo di evento che indica a Cal.com per quale evento effettuare la prenotazione. Impostalo come parametro fisso negli strumenti collegati usando l’ID dalla dashboard di Cal.com.

3. Imposta l’email del partecipante. Gli strumenti di prenotazione richiedono anche un’email del partecipante. A scopo dimostrativo, fissala come parametro al tuo indirizzo, così le conferme arriveranno nella tua casella di posta. In produzione con un EHR reale, la compileresti con l’email nel record del paziente anziché con un valore hardcoded.

Da qui, il flusso di prenotazione dipende dall’intento acquisito 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é verificare 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 la prenotazione specifica con chi chiama, quindi la rimuove con calcom_cancel_booking oppure, nel caso di una riprogrammazione, prenota il nuovo slot prima di annullare quello precedente.

Trasferimento a un operatore

Per trasferire la chiamata a un operatore, 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 tali condizioni e alla descrizione dello strumento. Lascia il tipo di trasferimento impostato su Conference, quello predefinito, poiché supporta un messaggio di passaggio cordiale che informa l’operatore sul motivo della chiamata.

Strutturare il percorso del paziente

Workflow sono flussi conversazionali visivi basati su grafi, creati con alcuni tipi di nodi: nodi subagent che combinano system prompt, strumenti e knowledge base con l’agente base orchestratore per una fase della chiamata; nodi dispatch tool che garantiscono l’esecuzione di uno strumento specifico e diramano in base a successo o fallimento; nodi di trasferimento dell’agente e transfer-to-number per i passaggi di consegne; e un nodo finale per chiudere la chiamata. I nodi sono collegati da edge e gli edge 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 subagent — Greeting, Verification, Booking, Transfer Notice e Close — ciascuno limitato ai propri strumenti, più un singolo nodo Phone Number Transfer raggiungibile da Transfer Notice.

Greeting è il punto di ingresso: risponde alla chiamata, presenta la clinica e acquisisce l’intento del paziente prima del passaggio di consegne; non ha strumenti propri, ma raccoglie il contesto sufficiente per instradare correttamente.

Verification esegue il controllo a due fattori descritto in precedenza, usando 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. Solo chi supera entrambi i controlli avanza; gli altri ricevono un edge in avanti verso Transfer Notice.

Booking contiene gli strumenti del calendario della sezione precedente e l’intento acquisito in Greeting determina il percorso: verifica della disponibilità e prenotazione per un nuovo appuntamento, ricerca della prenotazione esistente e nuova prenotazione prima dell’annullamento per una riprogrammazione, oppure conferma e annullamento per una cancellazione. Questo nodo passa anche a Transfer Notice in caso di errore: se nessun orario del calendario è adatto, chi chiama non può essere associato a un appuntamento esistente o preferisce parlare con il personale, l’edge instrada lì invece di bloccare la chiamata.

Transfer Notice si trova tra il resto del workflow e il passaggio di consegne: un breve subagent il cui unico compito è comunicare a chi chiama che sta per essere trasferito (ad esempio, "Ora ti metto in contatto con qualcuno 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 anziché essere trasferito in silenzio nel caso in cui la formulazione vari tra i subagent.

Phone Number Transfer, basato sullo strumento transfer_to_number, è il nodo a cui Transfer Notice inoltra sempre. Le sue regole associano un numero di destinazione alle stesse condizioni provenienti dai nodi a monte — verifica non riuscita, richiesta esplicita, prenotazione non completabile — ed esegue l’effettivo passaggio di consegne dopo che chi chiama è già stato informato.

Close viene raggiunto solo dopo una prenotazione riuscita: riepiloga i dettagli dell’appuntamento a chi chiama e termina la chiamata cordialmente.

Puoi trovare un modello JSON di esempio del workflow qui.

Analisi e test

La maggior parte del lavoro per un agente vocale in ambito sanitario non riguarda il percorso ideale, ma tutto ciò che deve avvenire correttamente quando la chiamata non segue lo script. ElevenAgents è progettato per test e analisi native della piattaforma: questo significa che gli stessi criteri di valutazione usati per i test prima del lancio assegnano un punteggio a ogni chiamata in produzione, senza uno strumento separato da collegare o riconciliare.

Criteri di successo

Definisci criteri di successo per acquisire criteri di valutazione specifici e allineati ai tuoi obiettivi aziendali e operativi. Nella scheda Analisi, ogni criterio è un prompt in linguaggio naturale che un LLM esegue sulla trascrizione, restituendo success, failure o unknown 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 tramite sia la ricerca EHR sia 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 un operatore e l’agente ha trasferito la chiamata; contrassegna come failure se chi chiama lo ha chiesto e l’agente non ha effettuato il trasferimento."

Raccolta dati

Puoi abbinarli a campi di raccolta dati. Ad esempio, aggiungendo requested_action (prenotazione, riprogrammazione o annullamento), 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 qualunque sistema tenga traccia degli esiti delle chiamate. 

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 Conversation Simulation API simula scenari realistici per chi chiama, sia dall’inizio alla fine sia in segmenti mirati, e assegna automaticamente un punteggio ai 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 riservata ai 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 per scenari che vadano oltre il percorso ideale: una persona il cui nome non corrisponde a nessun record EHR, qualcuno che sbaglia l’OTP due volte, un paziente che chiede di riprogrammare anziché prenotare e una persona che chiede esplicitamente un operatore a metà della verifica. Sono scenari chiari e mirati che 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

Una volta creato l’agente, collegarlo a un numero attivo richiede pochi minuti:

1. Nella dashboard di ElevenLabs, vai a Phone Numbers e fai clic su Import number.
2. Inserisci un’etichetta, il numero di telefono e il tuo Account SID e Auth Token
3. Dopo l’importazione, assegna il numero al tuo agente dal menu a discesa
4. Chiama il numero per provarlo, quindi controlla la dashboard della cronologia delle conversazioni per confermare che le prime chiamate si siano comportate come previsto.

Pronto per pazienti reali

Quello che abbiamo creato è un agente per la gestione degli appuntamenti dei pazienti che fa più che rispondere al telefono: verifica l’identità tramite un EHR e un OTP come secondo fattore prima di accedere a un record, prenota, riprogramma e annulla direttamente in un calendario attivo tramite l’API di Cal.com, e sa quando farsi da parte e passare chi chiama a un operatore. 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 sono stabilizzate, hai la sicurezza necessaria per il lancio anziché dover fare affidamento su una valutazione soggettiva. Dopo il lancio, l’apprendimento passa dai test simulati alle trascrizioni di produzione. Trattiamo queste pratiche, dai rilasci graduali al capire quando smettere di iterare, in un precedente articolo del blog.

Un passaggio fondamentale verso la conformità HIPAA è la gestione dei dati. L’attivazione della Zero Retention Mode elimina registrazioni delle chiamate, trascrizioni e metadati contenenti PII non appena una chiamata termina, eliminando la principale fonte di rischio di conformità in un’implementazione telefonica. Abbinata a un webhook post-chiamata, la visibilità non viene meno: ogni esito di prenotazione, risultato di verifica e punteggio di valutazione viene inviato al tuo sistema in tempo reale al termine della chiamata.

Ora hai un modello per mettere l’IA vocale agentica all’ingresso della tua clinica. La gestione 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 a stretto contatto con le organizzazioni sanitarie per tradurre implementazioni come questa in funzionalità concrete del prodotto. Se vuoi portare un workflow rivolto ai pazienti su ElevenAgents con il livello di conformità normativa richiesto dalla sanità, prova questo approccio e facci sapere cosa ne pensi.