Meu sistema de prontuário não tem API aberta: dá para integrar CRM e agenda ou preciso trocar de sistema?

"Meu sistema de prontuário não tem API aberta. Ainda dá para integrar o CRM com a agenda ou eu preciso trocar de sistema primeiro?"

Você recebeu um "não" do suporte e agora está com uma decisão estrutural na mesa por causa de uma frase de atendimento de primeiro nível.

O problema não é a API. O problema é que a sua operação comercial ficou refém de uma resposta que ninguém auditou.

Na prática, a integração que o seu comercial precisa é bem menor do que o projeto que te venderam na cabeça. Você não precisa sincronizar prontuário. Você precisa que o lead novo apareça no CRM e que a disponibilidade real da agenda volte para quem atende.

E isso quase sempre tem caminho, mesmo com o sistema atual.

Neste guia você vai ver:

• O que "não tem API aberta" realmente significa (são 4 estados diferentes, e só um deles é sem saída)
• O diagnóstico de 30 minutos que confirma se o "não" do suporte é verdade
• Os 7 caminhos possíveis, com custo, prazo, fragilidade e risco jurídico de cada um
• O que a LGPD exige de quem constrói essa ponte, e o que nunca fazer
• Os 5 critérios objetivos que dizem quando trocar de sistema é de fato a resposta

A resposta direta: trocar de sistema é o último caminho, não o primeiro

Você não precisa trocar o prontuário para integrar o comercial. Precisa separar duas camadas que a maioria das clínicas trata como uma coisa só.

A camada clínica é o prontuário: anamnese, evolução, imagem, plano de tratamento. Ela é sensível, regulada e não tem por que ser tocada por um CRM.

A camada de disponibilidade é a agenda: quem atende, em qual sala, em qual horário, e o que está livre. Ela é operacional e pode ser espelhada, exportada ou consultada sem que nenhuma informação clínica saia do lugar.

Quando você integra só a segunda camada, o escopo cai, o risco cai e o prazo cai junto.

Lembre: o objetivo não é "ter integração". É reduzir o tempo entre o paciente pedir horário e alguém confirmar um horário que existe de verdade. Se um caminho simples entrega isso, ele venceu o caminho elegante.

O que "não tem API aberta" realmente significa: os 4 estados possíveis

"Não tem API" é uma frase que esconde quatro situações muito diferentes. O caminho que você vai seguir depende de qual delas é a sua.

Estado	O que está acontecendo	O que você faz
1. Não existe API	O sistema é antigo, monolítico, sem camada de serviço. Costuma ser instalado na própria clínica.	Vai de exportação agendada, leitura de banco ou agenda-espelho.
2. Existe, mas só leitura	Você consegue consultar dados, não gravar. Comum em sistemas que abriram relatório antes de abrir escrita.	Basta para mostrar disponibilidade. O agendamento final continua sendo confirmado por quem atende.
3. Existe sob contrato ou parceria fechada	A API é real, mas liberada só para parceiros homologados, com taxa ou com NDA.	Vira negociação comercial, não projeto técnico. Peça as condições por escrito.
4. Existe e o fornecedor não libera	A capacidade técnica está lá, a decisão de não abrir é de negócio.	O enquadramento muda: você negocia com prazo e contrapartida, não pede favor.

Repare no que muda entre eles. Só o estado 1 é uma limitação de engenharia. Os estados 3 e 4 são decisão comercial, e decisão comercial se negocia.

E aqui está o dado que reposiciona a conversa. No 2025 State of the API Report da Postman, pesquisa feita com organizações que desenvolvem software, 82% adotaram algum nível de abordagem API-first e 25% operam como totalmente API-first, uma alta de 12% frente a 2024, enquanto 65% já geram receita com suas APIs.

Essa pesquisa não mede o mercado brasileiro de software odontológico, e vale ser honesto sobre isso. Mas ela mostra a direção: para boa parte da indústria de software, API deixou de ser luxo técnico e virou produto e fonte de receita. Quando o seu fornecedor diz que não tem, a pergunta legítima é por quê.

Diagnóstico de 30 minutos: como confirmar se o seu sistema tem API

Antes de aceitar o "não", reserve meia hora e faça esta verificação você mesmo. O suporte de primeiro nível quase sempre responde por roteiro, não por conhecimento da arquitetura.

1. Procure o portal de desenvolvedor. Busque o nome do sistema junto com "API", "developer", "documentação" e "integração". Muito fornecedor tem documentação pública que o atendimento nunca leu.

2. Verifique se o sistema já envia dados para a RNDS. Este é o teste mais poderoso da lista. O Guia de Integração da RNDS, do Ministério da Saúde, afirma que para um Sistema de Informação em Saúde trocar informações com a RNDS é preciso fazer uso de padrões, e que usar o padrão adotado pelo Brasil significa empregar uma API e esquemas de dados bem estabelecidos para transferir e obter informações em saúde. O mesmo guia registra que o software do sistema e a RNDS são independentes e podem evoluir separadamente, com tecnologias e linguagens distintas.

Traduzindo para a sua realidade: se o seu sistema já cumpre obrigação de envio para a RNDS, existe camada de API funcionando por dentro dele, ainda que voltada para a RNDS e não para você. Isso não prova que há uma API aberta para terceiros, mas derruba o argumento de que o sistema "não fala API". A pergunta deixa de ser "é tecnicamente possível?" e vira "o que falta para isso ficar disponível para mim?".

3. Veja se existe relatório agendado ou exportação programada. Sistema que envia planilha por e-mail toda manhã já tem um canal de saída de dados. É pouco elegante e resolve muito caso.

4. Procure webhook de saída. Alguns sistemas disparam aviso quando um agendamento é criado ou cancelado. Isso já é meio caminho da sincronização.

5. Leia o contrato. Procure cláusula sobre integração, propriedade do dado e exportação em caso de rescisão. É onde o "não" costuma estar escrito de verdade.

6. Escale acima do primeiro nível. Peça a resposta por escrito, do time de produto, na forma: "o sistema possui API? se sim, quais são as condições comerciais de acesso?". Pergunta escrita e específica derruba muito "não" genérico.

Quando o "não" é comercial e não técnico: o efeito information blocking

Existe nome para a barreira que não é técnica. O ONC, autoridade de TI em saúde do governo dos Estados Unidos, define information blocking como uma prática de um ator do setor de saúde que provavelmente interfere no acesso, na troca ou no uso de informação eletrônica de saúde.

O Brasil não tem uma regra equivalente com esse nome, e é importante ser honesto sobre isso: o conceito veio do arcabouço regulatório americano. Mas ele te dá um vocabulário útil para a mesa de negociação.

O que isso muda na prática:

• Você para de pedir favor técnico e passa a discutir condição comercial, com prazo e contrapartida.
• Você pede a recusa por escrito. Fornecedor que não abre API costuma evitar registrar isso formalmente.
• Você usa a renovação de contrato como alavanca, não a ameaça vazia de troca.
• Você para de pagar consultoria para "descobrir se dá", quando o que falta é uma decisão do fornecedor.

Um ajuste de expectativa: acontece de o fornecedor liberar acesso poucas semanas depois de uma pergunta formal por escrito. Custa uma reunião tentar antes de abrir projeto de troca.

O escopo mínimo real: a integração que importa tem só 2 fluxos

A maior parte dos projetos de integração morre por escopo inflado. Alguém desenha sincronização bidirecional de paciente, plano de tratamento, financeiro e imagem, o orçamento explode e nada é entregue.

O comercial precisa de dois fluxos. Só.

Fluxo A: o lead novo entra no CRM. Toda pessoa que chamou no WhatsApp, preencheu formulário, clicou no anúncio ou ligou precisa existir como registro com origem, horário e responsável. Esse fluxo não toca o prontuário em nada.

Fluxo B: a disponibilidade real volta para quem atende. Quem responde o paciente precisa enxergar o que está livre, sem abrir outro sistema e sem adivinhar.

Todo o resto é escopo inflado até prova em contrário:

• Sincronizar histórico clínico com o CRM: não precisa, e ainda aumenta o risco de LGPD.
• Espelhar financeiro: outro projeto, outro momento.
• Criar paciente no prontuário direto pelo robô: só depois que o fluxo básico estiver estável.

Se você entregar só o A e o B, já resolve o gargalo comercial. Vale ler também onde a automação quebra quando CRM e agenda não conversam.

Os critérios de avaliação (antes de olhar a lista de caminhos)

Antes de escolher, defina como você vai comparar. Estes são os seis critérios que decidem na prática:

1. Custo de implantação: o que você paga para colocar de pé.
2. Custo de manutenção: o que você paga todo mês para continuar funcionando. É aqui que a maioria erra.
3. Prazo até o primeiro resultado: dias ou meses.
4. Fragilidade: o que quebra a solução (atualização do fornecedor, troca de layout, pessoa de férias).
5. Risco jurídico e contratual: garantia do software, cláusula de uso indevido, exposição de dado sensível.
6. Reversibilidade: quanto custa desfazer se você trocar de sistema daqui a um ano.

Um caminho barato e frágil pode ser a escolha certa por seis meses. Um caminho caro e sólido pode ser errado se você já decidiu trocar de sistema. Contexto manda.

Os 7 caminhos para integrar CRM e agenda sem trocar o prontuário

Aqui está a lista completa, do mais simples ao mais elaborado. Cada um tem uma lacuna honesta, e ela está escrita.

Caminho 1. Ponte humana estruturada (a recepção ou o CRC como conector)

A pessoa é a integração. O CRC recebe o lead no CRM, consulta a agenda no sistema de prontuário e devolve a confirmação.

Parece atraso, mas é o caminho mais subestimado da lista. Ele só funciona quando é estruturado, e não improvisado:

• SLA de digitação: todo lead entra no CRM em até X minutos, definido por você e medido.
• Campo obrigatório: origem, procedimento de interesse e horário oferecido não são opcionais.
• Janela de resposta: quem cobre a consulta de agenda em cada faixa do dia, inclusive no início da noite.
• Fila única: uma lista visível, não a memória de uma pessoa.

Quando basta: clínica de uma unidade, volume moderado, equipe estável, e quando você precisa de resultado nesta semana.

A lacuna honesta: não escala e não cobre madrugada nem fim de semana. Quando a pessoa falta, a integração falta junto.

Caminho 2. Exportação e importação agendada (CSV, relatório programado, e-mail automático)

O sistema cospe um arquivo de horários em intervalo fixo, e uma rotina lê esse arquivo e atualiza a visão de disponibilidade do CRM.

Funciona de hora em hora, às vezes a cada quinze minutos. Não é tempo real, e para agenda odontológica isso costuma ser suficiente.

Quando basta: o sistema tem relatório agendado ou exportação programada, e a sua agenda não muda a cada minuto.

A lacuna honesta: existe uma janela de defasagem entre a exportação e a realidade. Você precisa tratar isso no discurso de quem atende, oferecendo horário como proposta a confirmar, não como reserva garantida.

Caminho 3. Webhook de saída do CRM + link de agendamento (sem tocar no prontuário)

Aqui a direção se inverte. Em vez de tentar ler o prontuário, você deixa o CRM avisar e o paciente escolher dentro de uma janela que você controla.

Na prática: o CRM dispara um evento quando o lead chega, a automação manda um link com horários pré-liberados, e a recepção só transfere o que foi escolhido para o sistema.

Quando basta: quando o gargalo é velocidade de resposta e não visibilidade completa da agenda. Você libera blocos por tipo de procedimento e por profissional.

A lacuna honesta: exige disciplina para liberar e bloquear janelas. Se ninguém atualizar os blocos, o overbooking volta pela porta dos fundos.

Caminho 4. Leitura direta do banco de dados (quando o sistema é instalado na clínica)

Sistema on-premise mora no seu servidor, e o banco de dados está fisicamente com você. Dá para criar um usuário somente leitura e consultar a tabela de agendamentos.

Tecnicamente é o caminho mais direto de todos. Juridicamente é o que exige mais cuidado.

Quando faz sentido: sistema instalado localmente, contrato que não proíbe acesso ao banco, e um profissional de tecnologia responsável identificado.

A lacuna honesta: três riscos reais. Primeiro, muitos contratos de licença tratam acesso direto ao banco como uso indevido e isso pode derrubar suporte e garantia. Segundo, atualização do fornecedor muda o esquema do banco sem aviso. Terceiro, você está lendo um repositório que contém dado clínico, então o recorte precisa ser cirúrgico e o acesso precisa ser registrado.

Faça esse caminho com autorização por escrito, usuário exclusivo com permissão mínima e leitura restrita às tabelas de agenda.

Caminho 5. RPA e automação de tela (o robô que digita no sistema)

O robô abre o sistema, faz login, navega até a agenda e lê ou digita como se fosse uma pessoa. É a solução que mais impressiona na demonstração e a que mais decepciona no sexto mês.

Quando faz sentido: quando não existe nenhuma outra saída de dados, o volume repetitivo é alto e você aceita conviver com manutenção recorrente.

A lacuna honesta: o custo real não está na construção, está na manutenção. Toda atualização de interface do fornecedor pode quebrar o robô, e a clínica descobre isso pela pior via possível, com o paciente esperando. Some a isso o problema de credencial: robô normalmente roda com login de alguém, e login compartilhado destrói a rastreabilidade de quem fez o quê.

Se for por esse caminho, exija credencial própria do robô, escopo mínimo de permissão e alerta automático quando a automação falhar.

Caminho 6. Agenda-espelho (calendário intermediário como camada de disponibilidade)

Você cria um calendário intermediário que representa só a disponibilidade, sem nenhum dado clínico. Ele é a fonte que o CRM e a automação consultam, e a recepção mantém a correspondência com o sistema de prontuário.

Esse desenho tem uma vantagem que passa despercebida: ele isola a camada comercial da camada clínica de forma permanente. Se você trocar de prontuário depois, o comercial não desaba junto.

Quando faz sentido: clínica que já sabe que vai reavaliar o sistema, ou que tem vários profissionais com regras diferentes de agenda.

A lacuna honesta: você passa a ter duas agendas, e duas agendas sem dono viram conflito. Precisa de regra clara sobre qual delas manda e de rotina de conferência.

Caminho 7. Middleware ou iPaaS como orquestrador

Uma camada intermediária conecta CRM, WhatsApp e a fonte de agenda, aplica as regras (qual profissional, qual procedimento, qual janela) e registra tudo que passou.

É o caminho mais completo e o único que envelhece bem. Ele também é o único que sobrevive à troca de qualquer uma das pontas, porque a regra de negócio mora no meio, não dentro de um sistema.

Quando faz sentido: múltiplas unidades, mais de uma origem de lead, atendimento por IA no WhatsApp, ou clínica que já tentou dois caminhos frágeis e cansou.

A lacuna honesta: custo maior e dependência de quem mantém a camada. Sem documentação e sem dono, o middleware vira caixa-preta.

Se a sua dor é encaixe de horário vago em cima da hora, vale ver como funciona a integração de CRM e agenda em tempo real para preencher cadeira vazia.

Matriz de decisão: custo, prazo, fragilidade e risco de cada caminho

Compare lado a lado antes de escolher. Os valores são relativos entre os caminhos, não faixas de mercado.

Caminho	Custo de implantação	Prazo	Fragilidade	Risco jurídico/contratual	Melhor cenário
1. Ponte humana estruturada	Muito baixo	Dias	Alta (depende de pessoa)	Baixo	Unidade única, resultado imediato
2. Exportação agendada	Baixo	Dias a semanas	Média	Baixo	Sistema com relatório programado
3. Webhook do CRM + link	Baixo	Semanas	Média	Baixo	Gargalo é velocidade de resposta
4. Leitura direta do banco	Médio	Semanas	Média (quebra em update)	Alto (garantia e dado sensível)	On-premise com autorização escrita
5. RPA / automação de tela	Médio	Semanas	Muito alta	Médio a alto (credencial)	Última saída, volume repetitivo
6. Agenda-espelho	Baixo a médio	Semanas	Média	Baixo	Quem vai reavaliar o sistema
7. Middleware / iPaaS	Alto	Semanas a meses	Baixa	Médio (contrato de operador)	Multiunidade, IA no WhatsApp

Leitura rápida da tabela: se você precisa de resultado nesta semana, comece pelo 1 e pelo 2. Se você quer algo que sobreviva à troca de sistema, vá para o 6 ou o 7. O caminho 5 é o último recurso, não o primeiro atalho.

O que nunca fazer nessa integração

Estas cinco práticas aparecem em quase toda clínica que tentou resolver sozinha. Todas criam um problema maior do que resolvem.

1. Credencial compartilhada de usuário administrador. Um login que a automação, o suporte e três pessoas usam apaga a rastreabilidade. Em sistema de saúde, saber quem acessou o quê não é preciosismo, é obrigação.

2. Scraping logado com a senha do dentista. Além do risco de segurança, você coloca em nome de um profissional registrado toda ação feita por um robô. Se algo der errado no prontuário, o log aponta para ele.

3. Planilha paralela sem dono. A planilha começa como solução temporária e vira a fonte de verdade que ninguém mantém. Quando ela diverge da agenda real, o paciente descobre primeiro que você.

4. IA agendando sem enxergar a agenda real. Este é o erro mais caro da lista. Automação que confirma horário sem consultar disponibilidade gera overbooking, e overbooking queima o paciente logo no primeiro contato. Se a IA não vê a agenda, ela oferece janela como proposta a confirmar, nunca como reserva fechada.

5. Ligar o comercial ao prontuário sem necessidade. Todo campo clínico que trafega para fora aumenta a superfície de risco sem melhorar o agendamento.

LGPD aplicada à integração: dado de saúde é dado sensível

Aqui a conversa deixa de ser técnica. Qualquer ponte entre sistemas em clínica odontológica passa pela Lei 13.709/2018.

Dado de saúde é dado pessoal sensível. O art. 5º, inciso II, da LGPD coloca o dado referente à saúde na categoria de dado sensível, que tem regime de tratamento mais restrito que dado comum. Nome e telefone de lead já são dado pessoal; associá-los a um procedimento odontológico os aproxima do dado sensível.

Medidas de segurança são obrigação, não boa prática. O art. 46 determina que os agentes de tratamento adotem medidas de segurança, técnicas e administrativas, aptas a proteger os dados pessoais de acessos não autorizados e de situações acidentais ou ilícitas, e exige que essas medidas sejam observadas desde a fase de concepção do serviço até a sua execução. Na ponte que você vai construir, isso se traduz em coisas concretas: credencial exclusiva por sistema, permissão mínima, registro de acesso, transporte cifrado e nada de planilha solta em nuvem pessoal.

Saiba quem é controlador e quem é operador. A clínica, que decide o que tratar e por quê, é a controladora. O fornecedor de software, o middleware e a agência que operam o dado em nome dela são operadores. Isso precisa estar escrito no contrato, com finalidade, prazo e obrigação de eliminação ao fim.

A sanção existe. O art. 52 prevê sanções administrativas que vão de advertência a multa simples de até 2% do faturamento no Brasil, limitada a R$50 milhões, além de bloqueio, eliminação de dados e suspensão da atividade de tratamento. O ponto para você não é o valor, é a existência do risco: gambiarra sem dono é exposição sem seguro.

Um lembrete prático de continuidade: quem depende de uma ponte frágil precisa saber o que fazer quando ela cai. Vale ter um plano de contingência para quando o sistema de prontuário sai do ar.

Prontuário eletrônico e as regras do conselho: a agenda não toca o conteúdo clínico

Existe uma razão regulatória forte para manter a integração longe do conteúdo clínico.

O prontuário eletrônico no Brasil está sujeito a exigências de certificação de sistemas de registro em saúde, com níveis de garantia de segurança. O nível mais exigente (referido no meio como NGS2) envolve assinatura digital com certificado da ICP-Brasil, e é o que permite eliminar o papel. Mexer nessa camada com uma automação improvisada coloca em xeque a validade do registro.

A boa notícia é que a integração comercial não precisa disso. Agenda é dado operacional. Se o seu projeto lê disponibilidade e grava nome e horário, ele fica fora do regime de conteúdo clínico.

Desenhe a fronteira explicitamente:

• Pode trafegar: nome, contato, origem do lead, procedimento de interesse (em categoria ampla), horário e profissional.
• Não deve trafegar: anamnese, evolução, imagem, laudo, plano de tratamento detalhado, informação financeira do tratamento.

Essa fronteira também resolve a discussão de acesso interno. Vale combinar com a regra de controle de acesso ao prontuário entre dentistas e equipe.

Por que a agenda precisa ser consultável fora do horário comercial

Muita clínica trata a integração como conveniência de recepção. Ela é, na verdade, uma questão de captação.

Na base de clínicas atendidas pela Odonto Results, 43,8% dos leads chegam fora do horário comercial (segunda a sexta, das 8h às 18h), e a primeira resposta da IA de Agendamento no WhatsApp sai em 4,4 segundos na mediana, dados internos da Odonto Results.

Agora junte as duas coisas. Suponha que o atendimento responda em segundos no fim da noite, mas a única pessoa que enxerga a agenda só chegue na manhã seguinte: você criou uma expectativa que a operação não cumpre.

No recorte de atendimento dentro do WhatsApp dessa mesma base (IA de Agendamento mais equipe, sem contar telefone), cerca de 23% dos leads que respondem viram agendamento na conversa (mediana entre clínicas, faixa típica de 20% a 33%), e entre quem agenda o tempo mediano da primeira mensagem até o agendamento fica em 2h57, dados internos da Odonto Results. Esse ritmo só existe quando quem responde tem algum tipo de visão de disponibilidade.

É por isso que o caminho 3 e o caminho 6 valem tanto: eles entregam disponibilidade consultável mesmo sem API. Um bloco de horários pré-liberados resolve a madrugada melhor do que um projeto de integração perfeito que ainda não existe.

O custo escondido de trocar de sistema

Quando alguém propõe trocar o prontuário para "resolver a integração", a conta apresentada é a mensalidade do software novo. A conta real tem mais linhas.

• Migração de histórico. Levar anos de registro de um sistema para outro raramente é um botão. Costuma envolver mapeamento de campos, dado que não tem equivalente e conferência manual.
• Guarda do prontuário. O prontuário tem prazo legal de guarda longo, então o sistema antigo não pode simplesmente ser desligado no dia da virada. Você mantém acesso ao acervo, e isso tem custo.
• Retreinamento da equipe. Toda a produtividade que a equipe construiu no sistema atual zera. A curva de aprendizado bate no meio do expediente, com paciente na cadeira.
• Convivência dos dois sistemas. Existe um período em que a clínica opera nos dois ao mesmo tempo. É a fase de maior risco de erro de agenda e de registro duplicado.
• Custo de oportunidade. Enquanto o projeto de troca consome a atenção da gestão, o gargalo comercial continua aberto.

Se você já está no meio de uma virada de sistema, vale ver como migrar prontuário sem parar a clínica.

Quando trocar de sistema é de fato a resposta certa: 5 critérios objetivos

Trocar não é errado. É errado trocar por frustração. Use estes cinco critérios, e trate a troca como decisão quando pelo menos três aparecerem juntos.

1. O fornecedor recusa integração por escrito. Não é "não temos ainda". É "não vamos abrir". Isso é uma decisão estratégica dele que limita a sua.
2. O sistema derruba a operação em horário de pico. Instabilidade recorrente em horário cheio custa mais que qualquer mensalidade.
3. Não existe nenhum caminho confiável de saída de dado. Sem API, sem exportação, sem relatório, sem acesso a banco. Aí você está preso mesmo.
4. O custo de manter as gambiarras passou o custo do sistema novo. Some manutenção de RPA, horas de digitação dupla e retrabalho. Quando essa soma vira mensalidade, a conta virou.
5. A clínica vai crescer para um formato que o sistema não suporta. Nova unidade, novo modelo de agenda, atendimento por IA em escala. Trocar antes de crescer é mais barato que trocar durante.

Se um único critério aparece, resolva com um dos sete caminhos e siga medindo.

HL7 FHIR e RNDS: o padrão que deve decidir a sua próxima compra

Se você vai trocar de sistema um dia, compre olhando interoperabilidade, não tela bonita. Dois nomes definem esse critério.

HL7 FHIR. O HL7 International descreve o FHIR como um padrão para troca eletrônica de informação em saúde, construído para que os registros do paciente sejam disponíveis, descobríveis e compreensíveis, e para que os dados sejam estruturados e padronizados. O próprio HL7 registra que o FHIR foi informado por anos de lições ao definir e implementar HL7 V2, HL7 v3 e CDA, e que busca simplificar a implementação sem sacrificar a integridade da informação.

RNDS. No Brasil, o Guia de Integração da RNDS registra que o conector usa o padrão FHIR, adotado pelo país. Sistema que já fala FHIR para cumprir obrigação com a RNDS tem, por consequência, a base técnica para falar com outros sistemas.

O que fazer com isso na prática: transforme interoperabilidade em critério de compra explícito, com peso no comparativo, do mesmo jeito que você avalia preço e suporte.

Checklist de RFP: as perguntas exatas para o fornecedor (o atual e o novo)

Mande estas perguntas por escrito e exija resposta por escrito. As respostas viram anexo do contrato.

1. Existe API pública documentada? Onde está a documentação?
2. Quais recursos a API cobre: agenda, cadastro de paciente, status de agendamento, cancelamento?
3. A API permite escrita ou é só leitura?
4. Existe webhook de saída para eventos de agenda (criado, alterado, cancelado)?
5. Qual o limite de chamadas por período e o que acontece ao ultrapassar?
6. Existe ambiente de teste (sandbox) sem dado real?
7. O sistema fala HL7 FHIR? Ele já integra com a RNDS?
8. Qual o custo de acesso à API: incluso, adicional, ou por parceiro homologado?
9. Existe programa de parceiros e qual o prazo médio de homologação?
10. Quem é o proprietário do dado, e como funciona a exportação completa em caso de rescisão?
11. Em que formato sai a exportação completa e ela inclui o histórico clínico?
12. O contrato proíbe acesso direto ao banco de dados em instalação local?
13. Qual o compromisso de aviso prévio antes de mudanças que quebrem integração?
14. O fornecedor assina termo como operador de dados, com finalidade e prazo definidos?

Resposta evasiva em qualquer um desses pontos é previsão do problema que você vai ter no ano dois.

Como medir se a integração funcionou: 4 indicadores

Integração sem medição vira opinião. Meça estes quatro números antes e depois, no mesmo período de dias.

Indicador	O que ele revela	Como medir
Tempo até a primeira resposta	Se a velocidade prometida existe fora do expediente	Mediana entre a chegada do lead e a primeira mensagem enviada
Percentual de lead que vira agendamento	Se a disponibilidade visível está convertendo	Agendamentos dividido por leads no período
Conflitos de horário e overbooking	Se a fonte de agenda está confiável	Contagem de choques e remarcações por erro de agenda
Minutos de digitação dupla por dia	Quanto a operação ainda paga em trabalho manual	Amostragem cronometrada da recepção por alguns dias

Duas referências internas ajudam a calibrar a expectativa: na base de clínicas atendidas pela Odonto Results, a primeira resposta da IA de Agendamento no WhatsApp sai em 4,4 segundos na mediana e, entre quem agenda, o tempo mediano da primeira mensagem até o agendamento fica em 2h57, dados internos da Odonto Results. Compare o seu número com o seu próprio ponto de partida, não com o teto.

A ordem correta: integre o fluxo comercial primeiro, decida a troca depois

Esta é a inversão que economiza mais dinheiro no ano.

A clínica típica faz assim: sente a dor da agenda, culpa o sistema, entra em projeto de troca, gasta meses e descobre no sistema novo que o problema real era falta de processo comercial.

O caminho que funciona é o contrário:

1. Integre o comercial com o caminho mais simples que resolve hoje. Ponte humana estruturada, exportação agendada ou link com blocos liberados.
2. Meça por um ciclo completo. Tempo de resposta, conversão em agendamento, conflitos, digitação dupla.
3. Só então decida sobre o sistema, com número na mão e com os cinco critérios objetivos.

Assim, se a troca acontecer, ela acontece por evidência. E o comercial já estará funcionando, o que reduz o risco da virada.

Lembre: trocar de sistema com o comercial desorganizado só muda o lugar da desorganização. Processo primeiro, plataforma depois.

Seu próximo passo

1. Faça o diagnóstico de 30 minutos ainda esta semana. Procure documentação pública, verifique se o sistema já envia para a RNDS, cheque exportação agendada e peça a resposta do fornecedor por escrito. Você vai descobrir em qual dos quatro estados está.
2. Escolha um caminho de curto prazo e ligue em dias, não em meses. Comece pelo mais simples que resolve os dois fluxos (lead no CRM e disponibilidade visível), e defina quem é o dono da rotina.
3. Meça um ciclo completo antes de decidir sobre o sistema. Tempo até a primeira resposta, conversão em agendamento, conflitos de horário e minutos de digitação dupla. Com esses números, a decisão de trocar (ou não) deixa de ser opinião.

Quer que o seu comercial pare de depender de uma resposta do suporte para funcionar? Agende uma apresentação.