Suíte de testes clínico-conversacionais para validar IA, prontuário e agenda

Uma suíte de testes clínico-conversacionais valida, em conjunto, a interpretação da conversa, a consulta ao prontuário, a disponibilidade da agenda e o registro do resultado no CRM. Ela não verifica apenas se uma mensagem foi enviada. O objetivo é provar que a IA conduziu o paciente ao próximo passo correto, preservando contexto, consentimento e consistência dos dados.

Uma clínica pode ter uma integração tecnicamente ativa e ainda perder agendamentos. Isso ocorre quando o sistema consulta horários desatualizados, cria pacientes duplicados, registra uma confirmação como tentativa de follow-up ou encaminha para a recepção uma situação que poderia ser resolvida dentro do fluxo autorizado.

O teste deve reproduzir a operação real, incluindo mensagens incompletas, mudanças de intenção, conflitos de horário, faltas, pedidos de cancelamento e transferência para uma pessoa. Para gestores, o resultado mais relevante é uma trilha verificável entre conversa iniciada, decisão tomada, evento enviado, retorno do sistema clínico e desfecho no agendamento.

A avaliação também precisa separar falhas de integração de falhas conversacionais. Um retorno HTTP 200 não comprova que o horário foi reservado, assim como uma resposta bem escrita não comprova que o dado foi persistido no sistema correto.

Antes de definir a bateria, consulte o checklist técnico e runbook para validar integrações clínicas em escala. Ele ajuda a organizar ambientes, responsáveis, critérios de aprovação e tratamento de incidentes sem misturar teste de aceitação com operação diária.

O script abaixo representa uma verificação de contrato usando Python e uma biblioteca HTTP. Em um ambiente real, substitua o endereço pelo ambiente de homologação, use credenciais armazenadas em cofre e aplique dados fictícios ou anonimizados. Nunca execute testes destrutivos diretamente na base de produção.

import os
import uuid
import requests

BASE_URL = os.environ["INTEGRACAO_URL"]
TOKEN = os.environ["INTEGRACAO_TOKEN"]

payload = {
 "event_type": "appointment_marked",
 "event_version": "1.0",
 "event_id": str(uuid.uuid4()),
 "correlation_id": "teste_regressao_001",
 "patient_reference": "paciente_teste_001",
 "appointment": {
 "external_id": "agenda_teste_001",
 "specialty": "dermatologia",
 "professional_id": "prof_teste_001",
 "unit_id": "unidade_teste_001",
 "start_at": "2026-10-05T09:00:00-03:00",
 "status": "confirmed"
 },
 "idempotency_key": "teste_regressao_001|agenda_teste_001"
}

headers = {
 "Authorization": f"Bearer {TOKEN}",
 "Content-Type": "application/json",
 "Idempotency-Key": payload["idempotency_key"]
}

first = requests.post(f"{BASE_URL}/events", json=payload, headers=headers, timeout=15)
second = requests.post(f"{BASE_URL}/events", json=payload, headers=headers, timeout=15)

assert first.status_code in (200, 201, 202)
assert second.status_code in (200, 201, 202, 409)
assert first.json().get("external_id") == second.json().get("external_id")

O teste de idempotência deve comprovar que repetir a mesma requisição não cria uma segunda vaga ou um segundo paciente. Se o conector responder 409, documente o significado e confirme que o recurso externo continua único. O código de resposta, isoladamente, não basta: consulte o sistema clínico e compare a quantidade de registros.

Para testar reversão, crie um agendamento em homologação, force uma falha na etapa de atualização do CRM e confirme a ação definida pela operação. Dependendo do contrato, o comportamento pode ser compensação, fila para reprocessamento ou transferência para a recepção, mas nunca uma confirmação textual sem estado consistente.

Um pseudoteste de rollback pode ser descrito assim:

DADO paciente_teste_001 sem agendamento
QUANDO a agenda confirmar agenda_teste_001
E o registro do CRM falhar
ENTÃO o evento deve ficar pendente ou ser compensado
E a agenda não pode apresentar confirmação divergente
E a conversa deve informar que a confirmação depende de validação
E o alerta deve conter correlation_id e event_id

Ao validar conectores nativos para Feegow ou Amplimed, repita a bateria para consulta de disponibilidade, criação de paciente, atualização de status, cancelamento e leitura de agenda. A integração nativa versus conector genérico deve ser julgada pela consistência observada nos casos de borda, não apenas pela existência de uma conexão inicial.

A perda de contexto aparece quando a IA mistura pacientes, troca a unidade solicitada, afirma que uma vaga está disponível sem confirmação ou transforma uma pergunta clínica em conclusão médica. O teste precisa avaliar a resposta e a ação de bastidor, pois uma mensagem convincente pode esconder uma gravação incorreta.

Crie um conjunto de asserções proibitivas. Exemplos: nunca confirmar horário sem retorno positivo da agenda; nunca afirmar convênio aceito sem fonte autorizada; nunca preencher CPF com valor inferido; nunca enviar follow-up depois de consentimento revogado; nunca alterar um agendamento sem registrar o motivo e o identificador da conversa.

Use também testes de consistência temporal. Se a agenda retornar 10h, a mensagem não pode informar 10h30; se o atendimento for cancelado, o CRM não pode permanecer como confirmado; se a conversa for transferida, o agente de follow-up não deve disparar uma nova abordagem antes da resolução.

Uma amostra de avaliação pode atribuir pontuação para contexto, factualidade, ação autorizada, segurança e recuperação de erro. Por exemplo, uma clínica pode exigir 100% de precisão em consentimento e confirmação de agenda, e aceitar uma taxa menor em classificação de intenção, desde que os casos incertos sejam encaminhados para validação humana.

Para aprofundar a revisão de respostas inventadas, use o guia para auditar alucinações em atendimentos automatizados por IA. A auditoria deve preservar entrada, saída, fontes consultadas, eventos gerados, versão do agente e decisão final.