ElevenAgents para a área da saúde: crie um agente de agendamento de consultas recebidas

O telefone ainda é a porta de entrada para a saúde, e está congestionado. Dados da Mayo Clinic pesquisa e um estudo de caso da Epic mostram que cerca de 30% dos agendamentos de consultas acontecem fora do horário comercial. Chamadas que caem na caixa postal são consultas que simplesmente deixam de acontecer, enquanto a equipe da recepção, responsável por atendê-las, trabalha no limite e tem alta rotatividade. Os agentes de voz já passaram da fase de demonstração como forma de as clínicas reduzirem essa lacuna, e o agendamento é o ponto de entrada mais comum: alto volume, repetitivo, previsível e uma parcela significativa do trabalho da recepção que não exige julgamento clínico.

O agendamento de consultas na área da saúde também eleva o nível de exigência. Um horário incorreto ou um motivo de consulta entendido errado não é apenas uma experiência ruim — é um incidente de segurança e conformidade. Um agente de agendamento na recepção precisa de mais do que uma voz agradável: verificação de identidade confiável, limites rígidos, um caminho claro de escalonamento para uma pessoa, condições de conformidade para lidar com informações de saúde protegidas e a capacidade de realmente concluir, alterar ou cancelar agendamentos em um sistema real.

Este guia mostra como criar exatamente isso com o ElevenAgents: um agente acessível por telefone, conectado a um prontuário eletrônico de saúde (EHR) de exemplo, que agenda, reagenda e cancela consultas de ponta a ponta, além de encaminhar o atendimento quando necessário. Você terá o workflow, as barreiras de segurança, os testes e as análises para mantê-lo dentro dos limites — implantado em uma infraestrutura desenvolvida para o setor de saúde regulamentado.

Veja uma demonstração do agente que você criará atendendo uma chamada ao vivo de ponta a ponta:

Pré-requisitos

Para começar, você precisará do seguinte:

• Uma conta da ElevenLabs, com acesso à plataforma ElevenAgents e às nossas vozes.
• Uma conta Twilio e um número.
• Acesso ao Twilio Verify.
• Um ambiente de sandbox ou de desenvolvedor de EHR. Neste guia, usaremos o HAPI FHIR, uma implementação de referência de código aberto do formato HL7 FHIR, para validar registros sintéticos de pacientes.
• O aplicativo de calendário do seu consultório. Para este guia, usamos a integração nativa da ElevenLabs com o Cal.com. 

Opcional

Se você não tem acesso a dados de sandbox ou está acompanhando apenas para fins de demonstração, usaremos o servidor sandbox HAPI FHIR R4 e vamos criar nele um registro de paciente fictício que você poderá usar durante a etapa de verificação. Para isso, execute o seguinte comando de API com dados fictícios no seu 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)"
  }'

Uma correspondência só é confirmada quando a consulta retorna exatamente um registro — zero resultados significa que não houve correspondência, e mais de um significa que os parâmetros de busca não foram específicos o suficiente para prosseguir com segurança. 

Arquitetura

Neste guia, você criará um agente de agendamento executado por um número Twilio e integrado nativamente ao seu ElevenAgent. Quando a chamada recebida for conectada, o agente ajudará o paciente usando as ferramentas disponíveis para obter os dados de verificação e da consulta — seja para marcar uma nova consulta, remarcar ou cancelar uma existente — e poderá transferir a chamada para uma pessoa quando necessário.

Com essa arquitetura e essas ferramentas, um fluxo de chamada bem-sucedido envolverá as seguintes etapas:

1. Início da chamada: um paciente liga para o número Twilio vinculado ao agente, que o cumprimenta e identifica sua intenção.
2. Validação no EHR: o agente valida os dados do paciente em relação ao seu registro no EHR.
3. Verificação: o agente envia uma senha de uso único (OTP) para o número de telefone do paciente, para a verificação final, usando sua ferramenta de SMS.
4. Agendamento ou alteração: o agente executa a intenção identificada no calendário — para uma nova consulta, coleta os detalhes e verifica a disponibilidade; para uma remarcação, localiza a consulta existente e encontra um novo horário; para um cancelamento, confirma e remove a consulta existente.
5. Transferência: se o agendamento ou a alteração não for bem-sucedido, o paciente pedir para falar com uma pessoa ou houver outra intenção que o agente não consiga atender, a chamada será transferida para um atendente humano.
6. Confirmação e encerramento: após um agendamento, uma remarcação ou um cancelamento bem-sucedido, o agente recapitula os detalhes da chamada e encerra de forma cordial.

Prompt de sistema e configurações do agente

O primeiro passo para criar um ElevenAgent eficaz está no prompt de sistema. Seguindo o guia de prompting da ElevenLabs, estruturamos o prompt nos blocos fundamentais recomendados para qualquer agente em produção — personalidade, objetivo, tom, ferramentas e guardrails —, cada um em sua própria seção claramente identificada, em vez de um bloco contínuo de instruções.

Para um agente de agendamento na área da saúde, essa estrutura precisa considerar quem realmente está do outro lado da ligação: alguém que pode ser idoso, estar com dor, ter dificuldade para ouvir ou simplesmente estar ansioso sobre o motivo da chamada. As seções de personalidade e tom estabelecem um ritmo acolhedor e sem pressa, com respostas curtas e conversacionais, além de datas, horários e números falados como uma pessoa os diria, e não como se fossem lidos de uma tela. A seção de objetivo descreve o fluxo em uma sequência ordenada: verificar a identidade e, então, conforme a pessoa queira agendar, remarcar ou cancelar, verificar a disponibilidade e confirmar o horário, localizar e mover a consulta existente ou confirmar a consulta que será removida. As ferramentas são documentadas com as entradas exatas no formato falado que esperam receber. Os guardrails incluem regras específicas desse contexto: nunca mostrar mais PHI do que a pessoa já compartilhou, nunca inventar disponibilidade ou detalhes de consulta quando uma ferramenta falhar, recusar perguntas clínicas em favor do próprio profissional de saúde da pessoa e escalar imediatamente se alguém descrever sintomas urgentes ou uma emergência médica. A verificação de identidade antes de qualquer ação sobre uma consulta é a única regra repetida, em vez de ser mencionada uma só vez. É a regra que o agente menos pode deixar de cumprir.

A partir daí, você pode adicionar configurações adicionais do agente, como a primeira mensagem, diferentes idiomas (confirme que a ferramenta de sistema de detecção de idioma esteja ativada), o LLM de sua escolha, um modelo conversacional de text-to-speech da ElevenLabs e uma voz da ElevenLabs.

Você encontra um exemplo de prompt de sistema aqui.

Proteções

A seção Guardrails do prompt de sistema cobre regras no nível das instruções, e o modelo dá bastante peso a elas. Mas um prompt ainda é uma camada não determinística e pode se desviar durante uma chamada longa. O ElevenAgents reforça essas regras com aplicação independente em tempo de execução por meio de seus próprios Proteções. Eles incluem o Focus Guardrail, que reforça o prompt de sistema à medida que as conversas se prolongam; os Manipulation Guardrails, que detectam tentativas de injeção de prompt antes de o agente responder; e os Content e Custom Guardrails, que avaliam cada resposta em tempo real e podem bloqueá-la antes que a pessoa que ligou a ouça. Cada guardrail é configurado com um modo de execução — streaming, para latência próxima de zero, ou blocking, para reter uma resposta até que ela seja liberada — e uma estratégia de saída para quando for acionado: encerrar a chamada ou tentar novamente com feedback corretivo inserido no próximo turno.

Para esse agente, podemos definir guardrails personalizados para regras específicas da área da saúde ou da clínica: bloquear diagnósticos de condições ou recomendações de tratamento, perguntas sobre cobrança, orientações de dosagem de medicamentos e qualquer conteúdo que substitua a orientação de um profissional de saúde habilitado. Para sintomas urgentes, defina a estratégia de saída como uma nova tentativa com feedback que transfira a chamada para uma pessoa, para que o guardrail encaminhe a chamada à equipe em vez de simplesmente encerrá-la.

Ferramentas

Cada etapa do fluxo exigirá ferramentas de webhook e integração específicas para executar ações enquanto fala com o paciente.

Ferramenta de verificação do EHR

Para verificar o paciente em relação ao seu registro no EHR, usaremos a ação da API FHIR GET /Patient. Adicione-a como uma ferramenta de webhook que aponta para a URL base do seu HAPI FHIR, com family, given, identifier e birthdate definidos como parâmetros preenchidos pelo LLM. A primeira chamada de ferramenta da etapa de verificação acessa o endpoint com o nome e a data de nascimento de quem ligou em uma única consulta:

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

Uma correspondência só é confirmada quando a consulta retorna exatamente um registro, e o agente só poderá avançar para a etapa de agendamento se essa condição for atendida.

Você encontra um exemplo do JSON da ferramenta aqui.

Ferramentas de verificação por SMS da Twilio

Com uma correspondência no EHR confirmada, a etapa de verificação passa para um segundo fator: enviar ao paciente um código de uso único por mensagem de texto e confirmá-lo antes de qualquer outra ação. A configuração tem três etapas:

1. Crie ferramentas de webhook para SMS. Configure duas ferramentas, send_SMS_verification e check_SMS_verification, ambas apontando para o seu serviço Twilio Verify. Cada uma precisa do Verify Service SID (o valor VA... nas configurações do serviço Verify) no caminho da URL e de um cabeçalho de autenticação Basic criado com seu Account SID e Auth Token armazenados como segredo.

2. Defina o destinatário com uma variável de sistema. O ElevenAgents fornece variáveis de sistema que preenchem automaticamente system__caller_id com o número de telefone de quem ligou em qualquer chamada de voz. Portanto, passe {{system_caller_id}} como parâmetro To, em vez de pedir para a pessoa ler um número em voz alta. Em um ambiente de produção integrado a um EHR ao vivo, o código seria enviado ao número de telefone armazenado no registro do paciente, e não ao identificador de quem ligou.

3. Ative skip_turn. Adicionar essa ferramenta de sistema junto às ferramentas de webhook permite que o agente espere em silêncio enquanto a pessoa encontra a mensagem, em vez de falar durante a pausa.

Somente quem passar pela consulta ao EHR e pela verificação de OTP poderá avançar para a etapa de agendamento. 

Você encontra um exemplo do JSON das duas ferramentas aqui e aqui.

Ferramentas de integração de calendário

A etapa de agendamento precisa verificar a disponibilidade, agendar, remarcar e cancelar em um calendário real. Configurar a integração com o Cal.com exige três etapas:

1. Conecte a integração. Na aba Tools do agente, adicione a integração com o Cal.com e clique em Connect.

2. Fixe o tipo de evento. Cada ferramenta de calendário recebe um ID de tipo de evento que informa ao Cal.com qual evento deve ser agendado. Defina-o como parâmetro fixo nas ferramentas conectadas usando o ID do painel do seu Cal.com.

3. Defina o e-mail do participante. As ferramentas de agendamento também precisam de um e-mail do participante. Para fins de demonstração, fixe-o como parâmetro no seu próprio endereço, para que as confirmações cheguem à sua caixa de entrada. Em produção, com um EHR real, você o preencheria com o e-mail do registro do paciente, em vez de usar um valor fixo.

A partir daí, o fluxo de agendamento depende da intenção identificada em Greeting. Para uma nova consulta, o agente chama calcom_get_available_slots para consultar horários disponíveis antes de oferecer um, e então calcom_create_booking quando a pessoa confirma — sempre nessa ordem, pois verificar a disponibilidade primeiro evita o agendamento duplicado de um horário. Para uma remarcação ou cancelamento, ele primeiro localiza a consulta existente usando calcom_find_bookings_by_attendee, confirma o agendamento específico com a pessoa e, então, o remove usando calcom_cancel_booking ou, no caso de uma remarcação, agenda o novo horário antes de cancelar o anterior.

Transferência para uma pessoa

Para transferir para uma pessoa, podemos usar a transfer_to_number ferramenta de sistema da ElevenLabs. Adicione-a como uma ferramenta de sistema no nível do agente para que possa ser acessada a partir de Greeting, Verification ou Booking. Na regra de transferência, adicione o número de destino no formato E.164 e uma condição em linguagem simples que descreva quando ela deve ser acionada. O LLM decide quando e para onde transferir com base nessas condições e na descrição da ferramenta. Mantenha o tipo de transferência como Conference, o padrão, pois ele permite uma mensagem de passagem contextualizada que informa ao atendente humano por que a chamada está sendo transferida.

Estruturando a jornada do paciente

Fluxos de trabalho são fluxos visuais de conversa baseados em grafos, criados com alguns tipos de nós: nós de subagentes que combinam um prompt de sistema, ferramentas e base de conhecimento sobre o agente base orquestrador para uma fase da chamada; nós de ferramentas de despacho que garantem a execução de uma ferramenta específica e criam ramificações para sucesso ou falha; nós de transferência de agente e de transferência para número para encaminhamentos; e um nó final para encerrar a chamada. Os nós são conectados por arestas, e as arestas de avanço podem incluir uma condição de LLM — uma regra em linguagem natural que o modelo avalia em tempo real para decidir qual caminho seguir. Criamos o agente com cinco nós de subagentes — Greeting, Verification, Booking, Transfer Notice e Close —, cada um limitado às suas próprias ferramentas, além de um único nó Phone Number Transfer acessível a partir de Transfer Notice.

Saudação é o ponto de entrada: atende a chamada, apresenta a clínica e identifica a intenção do paciente antes de transferir — sem ferramentas próprias, apenas a coleta de contexto necessária para direcionar corretamente.

Verificação realiza a verificação de dois fatores mencionada anteriormente, usando a ferramenta FHIR GET /Patient para confirmar que quem ligou corresponde a um registro no EHR e, em seguida, as ferramentas send_SMS_verification e check_SMS_verification para enviar e verificar um código de uso único antes que a pessoa possa prosseguir. Apenas quem passar pelas duas verificações avança; quem não passar segue por uma aresta de avanço para Transfer Notice.

Agendamento é onde ficam as ferramentas de calendário da seção anterior, e a intenção identificada em Greeting determina o caminho: verificar a disponibilidade e agendar uma nova consulta, localizar o agendamento existente e fazer um novo antes de cancelar em caso de remarcação, ou confirmar e cancelar em caso de cancelamento. Esse nó também direciona para Transfer Notice caso não consiga prosseguir — se nenhum horário no calendário servir, não for possível associar a pessoa a uma consulta existente ou ela quiser falar com a equipe, a aresta a direcionará para lá em vez de interromper a chamada.

Aviso de transferência fica entre o restante do workflow e o encaminhamento em si — um breve subagente cuja única função é informar a quem ligou que uma transferência está acontecendo (por exemplo, "Agora vou conectar você a alguém da nossa equipe") antes que a chamada realmente saia do agente. Direcionar primeiro cada condição de transferência por esse nó, em vez de acionar transfer_to_number diretamente a partir de Greeting, Verification ou Booking, garante que a pessoa sempre ouça essa mensagem, em vez de ser transferida em silêncio caso a redação varie entre os subagentes.

Transferência de número de telefone, criado com base na ferramenta transfer_to_number, é o nó para o qual Transfer Notice sempre encaminha. Suas regras combinam um número de destino com as mesmas condições trazidas das etapas anteriores — uma verificação com falha, um pedido explícito, um agendamento que não pôde ser concluído — e executam o encaminhamento depois que a pessoa já foi informada de que ele acontecerá.

Encerramento só é alcançado após um agendamento bem-sucedido: ele recapitula os detalhes da consulta para a pessoa e encerra a chamada de forma cordial.

Você encontra um modelo de exemplo em JSON do workflow aqui.

Análise e testes

A maior parte do trabalho em um agente de voz para a área da saúde não está no caminho ideal — está em tudo o que precisa acontecer corretamente quando a chamada não segue o roteiro. O ElevenAgents foi criado para testes e análises nativos da plataforma. Isso significa que os mesmos critérios de avaliação usados nos testes antes do lançamento avaliam cada chamada em produção, sem uma ferramenta separada para configurar ou conciliar.

Critérios de sucesso

Defina critérios de sucesso para capturar critérios de avaliação específicos, alinhados aos seus objetivos operacionais e de negócio. Na aba Analysis, cada critério é um prompt em linguagem simples que um LLM executa sobre a transcrição, retornando sucesso, falha ou desconhecido com uma justificativa. Para este agente, eles podem incluir critérios como:

• patient_verified: "Marque como bem-sucedido se o agente confirmou a identidade de quem ligou por meio da consulta ao EHR e do código de uso único por SMS antes de prosseguir para o agendamento."
• appointment_booked: "Marque como bem-sucedido se a consulta do paciente foi agendada"
• appointment_changed: "Marque como bem-sucedido se o paciente pediu para remarcar ou cancelar uma consulta existente, o agente concluiu a alteração — atualizando ou excluindo o evento do calendário — e confirmou o resultado para quem ligou." 
• call_escalated_when_requested: "Marque como bem-sucedido se quem ligou pediu para falar com uma pessoa e o agente transferiu a chamada; marque como falha se a pessoa pediu e o agente não transferiu."

Coleta de dados

Você pode combiná-los com campos de coleta de dados. Por exemplo, adicionando requested_action (agendar, remarcar ou cancelar), appointment_date ou appointment_type, que são extraídos como valores estruturados de texto, booleanos ou numéricos de cada transcrição e enviados para outros sistemas por meio de um webhook pós-chamada para qualquer sistema que acompanhe os resultados das chamadas. 

Simulações e testes

Na área da saúde, um agente precisa conquistar confiança antes da primeira chamada real — os modos de falha precisam aparecer nos testes, não diante de um paciente. A API de Simulação de Conversas simula cenários realistas de pessoas que ligam, tanto de ponta a ponta quanto em trechos específicos, e avalia os resultados automaticamente usando os mesmos critérios em execução na produção — exatamente as verificações patient_verified e appointment_booked definidas acima, e não uma rubrica separada apenas para testes. Execute simulações completas para toda a chamada ou simulações parciais que começam no meio da conversa para validar um único ponto de decisão. Essa é a forma mais rápida de iterar em um nó sem executar novamente todo o fluxo. 

Para esse agente, isso significa criar cenários que vão além do caminho ideal: alguém cujo nome não corresponde a nenhum registro no EHR, alguém que erra o OTP duas vezes, um paciente que pede para remarcar em vez de agendar e alguém que pede explicitamente para falar com uma pessoa no meio da verificação — cenários claros e focados, que dão cobertura para casos extremos, uso de ferramentas e lógica de fallback, em vez de esperar que surjam em produção.

Conecte seu número de telefone Twilio

Com o agente criado, conectá-lo a um número ativo leva apenas alguns minutos:

1. No painel da ElevenLabs, acesse Números de telefone e clique em Importar número.
2. Insira um Rótulo, o Número de telefone e seu SID da conta e Token de autenticação
3. Depois da importação, atribua o número ao seu agente no menu suspenso
4. Ligue para o número para testá-lo e, em seguida, verifique o painel de histórico de Conversations para confirmar que as primeiras chamadas se comportaram como esperado.

Pronto para pacientes reais

O que criamos é um agente de agendamento para pacientes que faz mais do que atender o telefone: verifica a identidade no EHR e por meio de um OTP de segundo fator antes de acessar um registro, agenda, remarca e cancela diretamente em um calendário ativo pela API do Cal.com e sabe quando deve dar lugar a uma pessoa. O workflow determinístico, os guardrails em tempo de execução e os critérios de avaliação oferecem às equipes a trilha de auditoria e o padrão de testes repetíveis exigidos pelas implementações na área da saúde.

É na entrada em produção que esse padrão mostra seu valor. Os critérios de avaliação definidos durante a criação se tornam o limite para o lançamento — quando o agente os atende de forma consistente e as métricas se estabilizam, você tem confiança para lançar, em vez de depender de uma decisão subjetiva. Após o lançamento, o aprendizado passa dos testes simulados para as transcrições de produção. Abordamos essas práticas, desde lançamentos graduais até saber quando parar de iterar, em um blog anterior.

Uma etapa importante rumo à conformidade com a HIPAA é o tratamento de dados. Ativar o Modo de Retenção Zero remove gravações de chamadas, transcrições e metadados com PII assim que a chamada termina, eliminando a maior fonte de risco de conformidade em uma implementação baseada em telefone. Combinado a um webhook pós-chamada, você mantém toda a visibilidade: cada resultado de agendamento, verificação e pontuação de avaliação é enviado ao seu próprio sistema em tempo real quando a chamada é encerrada.

Agora você tem um modelo para colocar a IA de voz agêntica na porta de entrada da sua clínica. O agendamento é o ponto de partida com maior volume, e o mesmo padrão se estende à admissão de pacientes, renovação de receitas, cobrança e acompanhamentos pós-consulta — cada um deles uma chamada que não precisa mais cair na caixa postal fora do horário comercial. Nossa equipe de Forward Deployed Engineering trabalha em parceria próxima com organizações de saúde para transformar implementações como essa em recursos concretos de produto. Se você quer levar um workflow voltado para pacientes ao ElevenAgents com o nível de conformidade que a área da saúde exige, experimente essa abordagem e conte para nós o que achou.