Como evitar cadastro duplicado do paciente quando o CRM e a agenda estão integrados?

"Como evitar cadastro duplicado do paciente quando o CRM e a agenda estão integrados?"

A integração funcionou. O problema começou aí.

Antes, o CRM tinha lead e a agenda tinha paciente, cada um no seu canto. Depois que os dois passaram a conversar, o mesmo senhor de 58 anos virou dois registros: um com CPF e sem telefone, outro com telefone e sem CPF, e nenhum dos dois com o histórico completo.

Cadastro duplicado não é falha de digitação. É falha de governança de identidade: dois sistemas passaram a escrever na mesma pessoa e ninguém definiu quem é o dono dela.

A boa notícia é que isso é um problema com solução conhecida, régua de medição publicada e ordem de execução clara. A má notícia é que quase ninguém mede.

Neste guia você vai ver:

• A diferença entre duplicata, overlay e overlap (e por que cada uma tem tratamento diferente)
• Como eleger o sistema dono da identidade e qual direção de sincronização usar
• A chave de identidade que funciona no Brasil, inclusive para o paciente sem CPF
• As duas taxas que você precisa medir (estoque e criação) e como calcular cada uma
• Como fazer o mutirão de merge sem perder histórico clínico, financeiro e legal

O que conta como cadastro duplicado (e o que não é)

Comece pelo vocabulário, porque tratar tudo como "duplicata" faz você aplicar o remédio errado.

A AHIMA, associação norte-americana de gestão de informação em saúde, separa três falhas distintas de identificação de paciente no documento "A Realistic Approach to Achieving a 1% Duplicate Record Error Rate".

Duplicata. Dois ou mais números de prontuário criados para a mesma pessoa. No exemplo da própria AHIMA, a recepção não encontra o registro do paciente com a informação que ele forneceu, gera um número novo e cria a duplicata.

Overlay. O paciente errado é registrado ou documentado dentro do registro de outro paciente. O exemplo do documento é direto: a base funde por engano John Clark, nascido em 10/5/81, com o registro de John Clark, nascido em 5/10/81. Agora os dois estão misturados na mesma ficha.

Overlap. A mesma pessoa tem mais de um identificador único em unidades diferentes da mesma rede. A AHIMA cita a fusão de duas instituições: os registros das duas não foram conectados no nível da rede, e cada paciente em comum passou a existir duas vezes.

Repare na assimetria de risco:

Falha	O que aconteceu	Risco principal	Como se corrige
Duplicata	Duas fichas, uma pessoa	Histórico partido, decisão tomada com metade da informação	Merge dos dois registros
Overlay	Uma ficha, duas pessoas	Informação clínica de um paciente atribuída a outro	Separação (mais difícil e mais grave que o merge)
Overlap	Um paciente, identificadores diferentes por unidade	A rede não enxerga o paciente como único	Camada de identidade acima das unidades

Fonte das definições e dos exemplos: AHIMA.

Duplicata você resolve juntando. Overlay você resolve separando, e separar é muito pior, porque você precisa decidir, linha a linha, qual informação pertence a quem.

Lembre: o objetivo não é "zerar duplicata". É não trocar duplicata por overlay. Um sistema que funde demais troca um problema administrativo por um problema clínico.

Por que a duplicata aparece depois que você integra o CRM com a agenda

A integração não cria pacientes novos. Ela cria caminhos novos para um paciente entrar.

Antes da integração, existia uma porta: a recepção abria a ficha no sistema de gestão. Depois da integração, existem três ou quatro: a recepção abre no sistema de gestão, o robô do WhatsApp cria contato no CRM, o formulário do site cria lead, e o sync devolve tudo isso para o outro lado.

Quatro portas, nenhuma com porteiro.

A própria AHIMA sinaliza isso na fase de medição do ciclo que recomenda: interfaces bidirecionais complexas podem aumentar a taxa de criação de duplicatas, e por isso devem ser monitoradas de perto. Não é opinião de fornecedor, é recomendação da entidade que publica o método.

E tem um agravante que é só nosso: no Brasil, a porta que mais abre ficha é o WhatsApp, onde o identificador natural é o telefone, que é a chave mais frágil que existe. Voltamos nisso adiante.

O padrão que você vai reconhecer na sua clínica é sempre o mesmo:

1. O paciente antigo manda mensagem de um número novo.
2. O robô não acha o cadastro e cria um contato.
3. O sync empurra esse contato para o sistema de gestão como paciente novo.
4. A recepção agenda nele, porque é o que apareceu na busca.
5. O histórico continua na ficha antiga, que ninguém abriu.

Se você quer o mapa completo de onde a automação quebra quando os dois sistemas não se entendem, vale ler onde a automação quebra quando CRM e agenda não conversam.

Quem manda no cadastro: elegendo o sistema dono da identidade

Essa é a decisão que destrava todas as outras, e é uma decisão de dono, não de TI.

Regra: um sistema CRIA o identificador do paciente. Todos os outros apenas LEEM e referenciam.

Na clínica odontológica, o dono natural da identidade é o sistema onde o prontuário vive (software de gestão ou agenda clínica). Três motivos:

1. Ele carrega a obrigação legal. O prontuário tem dever de elaboração e manutenção, e prazo de guarda longo. Quem guarda o documento precisa ser dono do registro.
2. Ele tem o histórico de anos. O CRM tem meses de funil; a agenda tem o tratamento inteiro.
3. Ele já tem o CPF. Cadastro clínico e financeiro exige documento; cadastro de lead não.

O CRM fica com o que é dele: o lead, o funil comercial, a origem da campanha, a conversa. Quando o lead vira paciente, o CRM não cria paciente. Ele pede o paciente ao sistema dono, recebe o identificador de volta e guarda esse identificador no próprio registro de lead.

O teste de uma frase: se alguém pergunta "qual é o ID do paciente João Silva?", tem que existir UMA resposta, e ela tem que vir de UM sistema. Se a resposta depende de onde você olhou, você não tem dono de identidade, tem dois cadastros concorrentes.

Essa decisão anda junto com a de propriedade do dado, que tem implicação de contrato e de saída de fornecedor. Vale ver quem é dono do dado quando você automatiza a integração.

Mão única ou mão dupla: a direção da sincronização decide o tamanho do problema

Depois de eleger o dono, decida para que lado o dado anda. São três desenhos possíveis, com risco crescente.

Mão única, do clínico para o comercial. O sistema de gestão cria o paciente e empurra para o CRM. O CRM nunca cria paciente. É o desenho mais seguro e o que quase toda clínica deveria começar usando.

Mão única, do comercial para o clínico, com aprovação. O CRM propõe um paciente novo, mas o registro só nasce depois que alguém (ou uma regra) confirma que não existe ficha. É útil quando o volume de entrada é alto e a recepção vira gargalo.

Mão dupla. Os dois lados criam e atualizam. É o desenho que produz eco: um registro criado de um lado volta do outro como se fosse novo, e o sistema cria o gêmeo.

O eco tem uma assinatura reconhecível: duplicatas que nascem em pares, com diferença de segundos entre elas, sempre no mesmo horário do job de sincronização.

Direção	Quem cria o paciente	Risco de duplicata	Quando usar
Clínico para comercial	Só o sistema de gestão	Baixo	Padrão para começar
Comercial para clínico com aprovação	CRM propõe, sistema confirma	Médio	Volume alto de entrada
Mão dupla	Os dois	Alto (eco e replicação)	Só com regra de identidade idêntica dos dois lados e teste de eco

Se você vai mesmo para mão dupla, três travas são obrigatórias:

1. Chave de idempotência. Todo evento de sincronização carrega um identificador de origem, e o destino recusa o mesmo identificador duas vezes.
2. Marca de origem no payload. O registro que chega pelo sync é marcado como vindo do sync, e o sync ignora o que ele mesmo escreveu.
3. Teste de eco antes de ligar em produção. Crie um paciente de teste de cada lado e conte quantos registros existem cinco minutos depois. Se der mais que um, não ligue.

A chave de identidade: CPF, data de nascimento e telefone normalizado

Você não consegue evitar duplicata sem definir, no papel, o que faz duas linhas serem a mesma pessoa.

CPF é a chave forte. É único por pessoa, estável ao longo da vida e verificável por dígito. Deve ser o primeiro critério, sempre.

Data de nascimento é a chave de validação. Sozinha não identifica ninguém, mas combinada com nome derruba a maior parte dos falsos pareamentos. É exatamente o papel que a AHIMA descreve no algoritmo determinístico: um identificador único acompanhado de um número limitado de identificadores não únicos, como a data de nascimento, para validação adicional.

Telefone é a chave fraca, e é a que mais se usa. Normalize sempre no padrão internacional E.164 (código do país, DDD, número, sem espaço, sem parêntese, sem hífen). O mesmo celular gravado como "43 98888-1234", "(43)988881234" e "+5543988881234" são três strings diferentes e zero pareamentos.

Normalizar telefone é a correção de menor esforço e maior efeito de toda esta lista. Faça antes de qualquer outra coisa.

A régua mínima que funciona no consultório:

1. CPF igual (com dígito verificador válido) igual mesma pessoa.
2. Sem CPF: telefone em E.164 igual mais data de nascimento igual igual mesma pessoa.
3. Sem CPF e sem data de nascimento: não decida sozinho. Marque como possível duplicata e mande para fila humana.

O item 3 é o que separa clínica organizada de clínica que mistura prontuário.

O paciente sem CPF: menor, dependente e estrangeiro

Toda régua de identidade quebra na exceção, e a exceção aqui é previsível.

Criança e adolescente. Muitas vezes chega sem CPF próprio e com o telefone do responsável. Dois filhos do mesmo responsável, cadastrados pelo telefone, viram um overlay esperando para acontecer.

Dependente de titular. O mesmo telefone, o mesmo endereço, às vezes o mesmo sobrenome. É o cenário clássico de pareamento errado.

Paciente estrangeiro. Sem CPF, com passaporte ou documento de outro país, e com nome que a recepção digita de três jeitos diferentes.

O que resolve:

• Campo de responsável explícito. O cadastro do menor aponta para o responsável em vez de herdar o telefone como se fosse dele. Telefone do responsável fica marcado como telefone de contato, não como identificador do paciente.
• Documento alternativo com tipo. Um campo "tipo de documento" mais "número do documento" (passaporte, RNE, certidão de nascimento) em vez de enfiar tudo no campo de CPF.
• Bloqueio de pareamento automático quando falta CPF e a data de nascimento está vazia. Sem esses dois, nenhuma fusão automática. Só fila humana.
• Regra de família. Quando dois cadastros compartilham telefone mas têm nome e data de nascimento diferentes, o sistema não sugere merge. Sugere vínculo familiar.

Como a recepção digita: a padronização que fecha metade da porta

A AHIMA é clara sobre onde o erro nasce: treinamento iterativo em gestão de identidade é crítico para toda a força de trabalho, porque os erros podem ocorrer em qualquer ponto da jornada do paciente, do primeiro contato ao pós-atendimento.

Traduzindo para a recepção: sem padrão de digitação, o melhor algoritmo do mundo não acha o paciente que já existe.

Escreva uma folha de uma página e cole ao lado do monitor. Ela precisa responder:

1. Nome completo ou como o paciente se apresenta? Padrão: nome completo como está no documento. "Zé do Posto" vai no campo de apelido, nunca no campo de nome.
2. Acento entra ou não? Padrão: entra, digitado corretamente. E a busca do sistema precisa ignorar acento (buscar "Jose" tem que achar "José").
3. Nome de casada. Padrão: grave o nome atual do documento e registre o nome anterior no campo de nome social ou de observação. É uma das origens mais comuns de duplicata em paciente antigo.
4. Abreviação de sobrenome. Padrão: nunca abreviar. "Maria S. Oliveira" e "Maria Silva Oliveira" não pareiam em algoritmo determinístico.
5. Ordem do sobrenome. Padrão: exatamente a ordem do documento, sem inverter para ordem alfabética.
6. Sufixo e partícula. "Júnior", "Neto", "de", "da", "dos" entram sempre, no mesmo lugar.

Duas regras a mais que valem ouro:

• Campo obrigatório é inimigo da qualidade quando o dado não existe. Se o CPF é obrigatório e o paciente não tem, a recepção digita 000.000.000-00. Aí você tem vinte pacientes com o mesmo CPF, que é pior que nenhum. Permita ausência e marque como pendente.
• Nunca cadastre com dado provisório. "Paciente do Dr. Fulano", "não informado", "WhatsApp 9999" viram fichas fantasma que ninguém mais acha.

Busca antes de cadastrar: o fluxo obrigatório de dez segundos

Essa é a intervenção de maior retorno da lista inteira, porque ataca a duplicata na origem descrita pela AHIMA: a recepção não encontra o registro do paciente com a informação fornecida, um número novo é gerado, e a duplicata nasce.

Repare que a origem não é "a recepção cadastrou de novo". É "a recepção não encontrou".

O fluxo que fecha essa porta tem quatro passos e leva menos de dez segundos:

1. Busque por CPF. Se achar, use a ficha. Fim.
2. Não achou? Busque por telefone, com o sistema normalizando o que você digitou. Se achar, confirme a data de nascimento com o paciente e use a ficha.
3. Não achou? Busque por nome parcial mais data de nascimento. Digite só o primeiro nome e o ano. Nome completo errado não retorna nada; nome parcial retorna.
4. Só agora abra ficha nova, e o sistema deve mostrar uma tela de possíveis correspondências antes de salvar.

Três exigências de produto que tornam esse fluxo viável:

• Busca tolerante. Ignora acento, ignora maiúscula, casa por prefixo, aceita telefone com ou sem máscara.
• Tela de candidatos antes do salvar. Nenhum cadastro novo é gravado sem o operador ver a lista de quem já se parece com ele.
• Botão de "é a mesma pessoa" na própria tela. Se a recepção precisa abrir chamado para fundir, ela não vai fundir.

E vale para o robô também. Se a sua automação de WhatsApp cria contato sem antes consultar o sistema de gestão por telefone normalizado, ela é a maior fábrica de duplicata da clínica, trabalhando 24 horas por dia.

Determinístico ou probabilístico: como o sistema decide que são a mesma pessoa

Agora a parte que o fornecedor raramente explica. A AHIMA descreve três famílias de algoritmo de pareamento de paciente.

Determinístico. Envolve um identificador único, às vezes acompanhado de um número limitado de identificadores não únicos, como a data de nascimento, para validação adicional, comparados para identificar correspondências exatas. As comparações costumam usar nome, data de nascimento, número de identificação e, às vezes, sexo. A AHIMA considera o algoritmo básico de pareamento.

Baseado em regras. Cada elemento de dado recebe um peso conforme o quanto ele é essencial para parear um registro. Mesmo que nem todos os elementos batam exatamente, os registros são considerados pareados se elementos suficientes forem idênticos. O exemplo da AHIMA: registros pareiam se nome, sobrenome, data de nascimento e sexo baterem, ou se sobrenome, endereço e data de nascimento baterem.

Probabilístico. Compara vários valores de campos não únicos entre registros, atribuindo um peso que reflete o quanto os dois valores se aproximam. Os pesos são somados entre os campos para indicar a probabilidade de correspondência real. A AHIMA classifica como algoritmo intermediário ou avançado.

Tipo	Como decide	Força	Fraqueza
Determinístico	Identificador único, comparação exata	Simples, auditável, quase não gera overlay	Perde o paciente sem CPF ou com digitação diferente
Baseado em regras	Conjuntos de campos com peso, combinações pré-definidas	Cobre mais casos que o exato	Depende de quem escreveu as regras
Probabilístico	Soma de pesos e probabilidade de match	Maior alcance, acha o que os outros perdem	Exige régua de corte, e régua errada mistura prontuário

Fonte: AHIMA.

Um detalhe prático que a AHIMA registra e que pega muita clínica de surpresa: edições ou modificações nos algoritmos de pareamento podem não ser permitidas por causa da tecnologia proprietária do sistema. Ou seja: dependendo do software, essa régua não é sua para ajustar. Descobrir isso depois de comprar é caro.

Falso positivo e falso negativo: onde colocar a régua de corte

Todo sistema de pareamento erra dos dois lados, e você escolhe para que lado ele erra.

Falso negativo (não pareia o que era a mesma pessoa). Resultado: duplicata. Custo: histórico partido, retrabalho, confirmação dobrada, relatório sujo.

Falso positivo (pareia gente diferente). Resultado: overlay. Custo: prontuário misturado, informação clínica de um paciente dentro da ficha de outro.

Não são erros equivalentes. O exemplo da própria AHIMA para overlay é a fusão indevida de dois John Clark com datas de nascimento invertidas, 10/5/81 e 5/10/81. É o tipo de coisa que um algoritmo agressivo faz sozinho e que ninguém percebe até doer.

A política que recomendo, e que é conservadora de propósito:

1. Fusão automática só com CPF idêntico válido. Nada além disso funde sem humano.
2. Score alto sem CPF vai para fila de sugestão, com os dois registros lado a lado na tela e um humano decidindo.
3. Score médio vira alerta no momento do cadastro, não fusão.
4. Score baixo não aparece. Fila cheia de ruído é fila que ninguém trabalha.

E uma trava de segurança que evita o pior: fusão precisa de desfazer. Se o merge não tem botão de reverter com histórico, você não tem merge, tem destruição de dado.

Lembre: um sistema que nunca funde cria duplicata, que é chato. Um sistema que funde demais mistura prontuário, que é grave. Na dúvida, erre para o lado chato e ponha gente na fila.

Como medir: taxa de erro por duplicidade e taxa de criação de duplicatas

Aqui está o buraco maior. A AHIMA registra, na 2020 Patient Identification Survey, que 29% dos respondentes não sabiam qual era a própria taxa de erro por duplicidade, o que segundo a entidade reforça a necessidade de priorizar a gestão de identidade do paciente.

Na mesma pesquisa, 22% dos respondentes relataram ter alcançado taxa de erro por duplicidade de 1% ou menos no prontuário eletrônico.

Contexto obrigatório antes de você usar esses números: a pesquisa é de 2020, os respondentes são organizações de saúde dos Estados Unidos e a medição é do índice mestre de pacientes do prontuário eletrônico. Não é uma referência de clínica odontológica brasileira, e não existe uma. O que transfere para a sua clínica é o método de medir, não o número.

E são dois números, não um. A AHIMA recomenda as seguintes contas para uma base única:

Indicador	O que mede	Conta	Exemplo da AHIMA
Taxa de erro por duplicidade	Estoque: o tamanho do problema hoje	Registros duplicados confirmados dividido pelo total de registros na base	10.000 registros duplicados numa base de 100.000 dá 1%
Taxa de criação	Fluxo: o quanto você está piorando	Duplicatas confirmadas num período dividido pelo total de eventos de cadastro no mesmo período	3.000 duplicatas confirmadas no trimestre em 200.000 eventos de cadastro dá 1,5%

Fonte: AHIMA.

Por que os dois importam, e o que cada um te diz:

• Estoque alto e criação baixa: o passado está sujo e o presente está controlado. Sua tarefa é mutirão de limpeza, não mudança de processo.
• Estoque baixo e criação alta: você limpou recentemente e o processo continua quebrado. Sua tarefa é a porta de entrada, e limpar de novo é desperdício até consertar.
• Os dois altos: você precisa parar a hemorragia antes de limpar. Consertar a busca e a sincronização vem primeiro.

A AHIMA também dá a cadência: comparar a taxa de erro por duplicidade contra o benchmark trimestralmente, e definir metas ambiciosas.

Uma nota de honestidade: a própria AHIMA lembra que mesmo a taxa de 1% ainda representa erros de paciente trocado. Meta baixa não é meta zero, e a diferença entre as duas aparece justamente nos casos que mais doem.

O campo de origem: quem escreveu esse registro

Esse é o pré-requisito invisível de tudo que veio antes. Sem ele, você não consegue nem descobrir de onde a duplicata está saindo.

Todo registro de paciente e toda alteração precisam gravar:

1. Quem escreveu: humano (qual usuário), robô (qual automação) ou sincronização (qual sistema de origem).
2. Quando escreveu: data e hora com fuso.
3. Por qual canal: recepção, WhatsApp, formulário do site, importação, API do parceiro.
4. Com qual identificador de origem: o ID que aquele registro tem no sistema de onde veio.

Com isso você responde em minutos perguntas que hoje levam uma tarde:

• As duplicatas de outubro vieram da recepção ou do sync?
• Aquele lote de 40 fichas gêmeas nasceu no mesmo minuto? Então foi job, não gente.
• O robô do WhatsApp cria mais duplicata na madrugada, quando não tem recepção para conferir?

Sem campo de origem, toda investigação vira opinião. Com ele, vira consulta.

E existe um efeito colateral bom: origem é também o que permite auditar quem alterou o prontuário, que é uma exigência de outra natureza e que você vai precisar cumprir de qualquer forma.

O lead do WhatsApp virando paciente sem virar cadastro novo

Esse é o ponto onde a clínica brasileira sangra mais, porque o canal de entrada dominante usa a chave mais fraca.

O telefone falha de quatro jeitos previsíveis:

1. O paciente trocou de número. Cadastro antigo tem o número velho. Chegou mensagem de um número que não existe na base.
2. O número é da família. Mãe, filho e cônjuge no mesmo celular. Três pacientes, um telefone.
3. O paciente tem dois números. Pessoal e trabalho, e usa o que estiver na mão.
4. O número foi reciclado. A operadora devolveu o número ao mercado e outra pessoa está usando.

Some a isso o horário. Segundo dados internos da Odonto Results (2026), 46,0% dos leads de clínica odontológica chegam fora do horário comercial. Base: 16.719 leads na primeira mensagem do WhatsApp. Janela: 25 de março a 25 de agosto de 2026. Quase metade da entrada acontece quando não tem ninguém na recepção para conferir se aquela pessoa já existe.

Quem confere, então, é a automação. Ela precisa de um fluxo próprio:

1. Normalize o telefone para E.164 antes de qualquer busca.
2. Consulte o sistema dono da identidade, não a base do CRM.
3. Achou um paciente? Confirme com uma pergunta simples na conversa ("posso confirmar sua data de nascimento para localizar seu cadastro?") e vincule a conversa ao paciente existente.
4. Achou mais de um? Não escolha. Marque para a recepção e siga o atendimento sem criar ficha.
5. Não achou? Crie um LEAD, não um paciente. Lead vira paciente só quando alguém confirma identidade.

Esse item 5 é a regra de ouro: conversa no WhatsApp não gera prontuário. Ela gera intenção. O prontuário nasce quando a identidade é confirmada, por humano ou por CPF.

O que a duplicata quebra na prática: agenda, financeiro e régua de marketing

Se a conversa sobre duplicata morre em "dado sujo", ela nunca vira prioridade. Ela vira quando você coloca preço no estrago.

Na agenda

• Dois históricos de falta. O paciente que faltou três vezes aparece com uma falta em cada ficha. Sua régua de overbooking e a sua política de confirmação leem esse paciente como confiável.
• Confirmação enviada duas vezes. O paciente recebe o mesmo lembrete de dois cadastros e liga irritado. Pior: em alguns sistemas, responder "confirmo" em um não confirma o outro.
• Remarcação perdida. A recepção remarca na ficha A, o dentista abre a ficha B e vê o horário antigo.
• Bloqueio de retorno. O alerta de retorno de seis meses dispara na ficha que não tem o procedimento.

No financeiro

• Orçamento em uma ficha, pagamento na outra. O paciente pagou, e o sistema mostra dívida.
• Inadimplência fantasma. O relatório de inadimplentes lista gente que está em dia, e a equipe cobra quem não deve. Isso queima relacionamento com paciente de alto ticket.
• Faturamento por paciente irreal. O caso de alto ticket aparece como dois pacientes de valor menor, e a sua curva de ticket mente justamente na faixa que paga a clínica.

Na régua de marketing

Aqui a duplicata não só polui: ela inverte a leitura da campanha.

Segundo dados internos da Odonto Results (2026), 12% dos leads viram agendamento dentro do WhatsApp (faixa 9% a 15%), sem contar telefone. Base: 21.433 leads. Janela: 25 de março a 25 de agosto de 2026.

Agora suponha que 10% da sua base seja duplicata e que boa parte dela entre como lead novo. O denominador do funil cresce, o numerador não. A taxa cai, o custo por agendamento sobe no relatório, e você conclui que a campanha piorou.

Ela não piorou. A sua contagem quebrou.

O mesmo acontece com o custo de aquisição: o paciente que já era seu, contado como lead novo, é atribuído à campanha e infla o volume. Você paga para "adquirir" quem já estava na sua base.

Área	Sintoma que você já viu	Causa raiz
Agenda	Faltante que aparece como pontual	Histórico de falta dividido entre duas fichas
Agenda	Paciente reclamando de mensagem repetida	Duas fichas na régua de confirmação
Financeiro	Cobrança de quem já pagou	Pagamento lançado na ficha irmã
Financeiro	Ticket médio menor do que a realidade	Um paciente contado como dois
Marketing	Taxa de agendamento caindo sem motivo	Denominador inflado por lead repetido
Marketing	Custo por paciente novo subindo	Paciente antigo contado como aquisição

Mutirão de merge: como fundir sem perder histórico

Em algum momento você vai precisar limpar o que já existe. A AHIMA descreve um ciclo de cinco etapas para isso: identificar, limpar, medir, mitigar e remediar, executado de forma iterativa, e não como projeto de uma vez só.

Traduzindo para a rotina de uma clínica:

1. Identificar. Rode todos os relatórios de possíveis duplicatas que o sistema oferece e calcule a taxa de erro inicial. A AHIMA recomenda que, se houver falta de confiança nesses resultados, você faça uma análise dos dados da base para ter mais detalhe sobre o número e os tipos de duplicata.

2. Limpar. Crie um plano de limpeza antes de fundir a primeira ficha. Uma orientação específica da AHIMA que evita retrabalho: ao limpar, garanta que múltiplos registros com o mesmo número de prontuário sejam identificados e resolvidos ao mesmo tempo.

3. Decidir quem vence. Antes do mutirão, escreva a regra de ficha vencedora. A minha recomendação de ordem:

1. A ficha com CPF válido vence a sem CPF.
2. Entre duas com CPF, vence a que tem prontuário clínico com registro mais recente.
3. Empate: vence a mais antiga (ela carrega mais história).

4. Fundir com preservação. O que precisa sobreviver ao merge, em ordem de gravidade:

• Registros clínicos (anamnese, evolução, exames, imagens) de AMBAS as fichas, com data original preservada.
• Lançamentos financeiros e contratos das duas.
• Histórico de agendamento, comparecimento e falta das duas, somados.
• Termos de consentimento assinados.
• O identificador antigo, guardado como alias, para que qualquer link externo antigo continue achando o paciente.

5. Registrar o merge. Quem fundiu, quando, quais fichas, e qual foi o critério. Se o merge estiver errado, você precisa conseguir reconstruir.

A AHIMA é explícita sobre a mentalidade aqui: os fluxos de fusão de registros devem sublinhar a importância da exatidão em primeiro lugar. Velocidade de mutirão não vale overlay.

Uma cadência que funciona: duas horas por semana, sempre no mesmo dia, uma pessoa fixa, começando pelos pacientes com agendamento marcado nos próximos 30 dias. Você resolve primeiro quem vai aparecer, que é onde o erro custa na hora.

LGPD, Código de Ética e o prazo de guarda da ficha perdedora

Cadastro duplicado não é só bagunça operacional. Ele toca duas obrigações diferentes.

LGPD: qualidade do dado é princípio, não boa prática. A Lei 13.709/2018, no Art. 6º, inciso V, estabelece o princípio da qualidade dos dados como "garantia, aos titulares, de exatidão, clareza, relevância e atualização dos dados, de acordo com a necessidade e para o cumprimento da finalidade de seu tratamento". O princípio se dirige a quem trata o dado, e na clínica quem trata é a própria clínica, como controladora.

No mesmo texto, o Art. 18, inciso III, dá ao titular o direito de obter do controlador "correção de dados incompletos, inexatos ou desatualizados". Um paciente com duas fichas conflitantes pode exigir a correção, e a obrigação de atender recai sobre a clínica. Para o desdobramento completo disso no dia a dia, veja LGPD na clínica odontológica.

Código de Ética Odontológica: o dever de manter o prontuário, e a quem ele se dirige. O Código de Ética Odontológica traz, no Art. 9º, inciso X, entre os deveres fundamentais dos inscritos, o de "elaborar e manter atualizados os prontuários na forma das normas em vigor, incluindo os prontuários digitais". E o Art. 17 determina que "é obrigatória a elaboração e a manutenção de forma legível e atualizada de prontuário e a sua conservação em arquivo próprio seja de forma física ou digital".

E atenção ao alcance, porque é onde muita gente erra: o Código não fica só no profissional. O Art. 1º diz que ele "regula os direitos e deveres do cirurgião-dentista, profissionais técnicos e auxiliares, e pessoas jurídicas que exerçam atividades na área da Odontologia, em âmbito público e/ou privado". E o Art. 29 estende as disposições do Código e as normas dos Conselhos "a todos àqueles que exerçam a Odontologia, ainda que de forma indireta, sejam pessoas físicas ou jurídicas, tais como: clínicas, policlínicas, cooperativas, planos de assistência à saúde", entre outras entidades.

Ou seja: a clínica não fica de fora do dever de prontuário por ser empresa.

O prazo de guarda decide o que você faz com a ficha perdedora. A Lei 13.787/2018, no Art. 6º, determina que, decorrido o prazo mínimo de 20 anos a partir do último registro, os prontuários em suporte de papel e os digitalizados poderão ser eliminados. O mesmo artigo prevê que, alternativamente à eliminação, o prontuário pode ser devolvido ao paciente.

A conclusão operacional é direta: merge não é exclusão. A ficha perdedora vira um registro inativo, sem poder receber agendamento novo, apontando para o cadastro vencedor, com o conteúdo clínico preservado e com rastro de quem fundiu, quando e por quê.

Se o seu software "resolve duplicata" deletando a ficha secundária, você tem um problema maior que a duplicata.

Quem é dono da fila: papéis e responsabilidade

Processo sem dono não roda. E a AHIMA já registra que recurso é o gargalo: na 2020 Patient Identification Survey, feita com organizações de saúde dos Estados Unidos, 27% dos respondentes apontaram falta de recursos para corrigir duplicatas como um desafio que enfrentam na gestão dos respectivos índices mestres de pacientes.

Nenhuma clínica vai montar um time de integridade de dados. Mas ela consegue nomear pessoas:

Papel	O que responde	O que NÃO responde
Recepção e CRC	Executar busca antes de cadastrar, seguir o padrão de digitação, marcar possível duplicata	Decidir fusão de prontuário
Responsável pela fila de duplicatas (uma pessoa nomeada)	Trabalhar a fila semanalmente, executar os merges aprovados, reportar a taxa	Mudar regra de identidade sozinho
Responsável técnico	Aprovar a regra de ficha vencedora, validar merge que envolve conteúdo clínico	Operar a fila no dia a dia
Dono ou gestor	Definir a meta de taxa, garantir as duas horas semanais, cobrar o fornecedor	Digitar
Fornecedor do software	Busca por API, endpoint de merge, log de origem, relatório de duplicidade	Decidir quem é o mesmo paciente

A linha mais importante da tabela é a última coluna da primeira linha. Recepção não decide fusão de prontuário. Ela sinaliza. A decisão sobe.

E a formação precisa ser recorrente, não de admissão: a AHIMA fala em treinamento iterativo para toda a força de trabalho, justamente porque o erro pode nascer em qualquer ponto da jornada.

Governança contínua: o relatório semanal que impede a volta

Mutirão sem governança é ciclo de recaída: limpa, comemora, e um ano depois está igual.

O ciclo da AHIMA é explicitamente iterativo, e a etapa de mitigação traz a recomendação mais operacional do documento inteiro: operacionalizar um processo rigoroso e diário de trabalho da fila de erros de duplicidade, executado em paralelo com a limpeza da base.

O desenho mínimo para uma clínica:

1. Relatório semanal de possíveis duplicatas, gerado automaticamente e entregue a uma pessoa nomeada. Se ele chega para "a equipe", ele não chega para ninguém.
2. Fila com prioridade por agendamento próximo. Quem tem horário marcado nos próximos 30 dias entra primeiro.
3. Meta de taxa revisada por trimestre, na cadência que a AHIMA recomenda para comparação contra benchmark.
4. As duas taxas na mesma tela do dono: estoque e criação. Estoque diz o tamanho da dívida; criação diz se você ainda está se endividando.
5. Revisão de causa a cada mês. Pegue as dez duplicatas mais recentes e responda, pelo campo de origem, de onde vieram. Se sete saíram do robô do WhatsApp, o conserto é lá, não na recepção.

A AHIMA também recomenda algo que costuma faltar em clínica: planejar e permitir interrupção, e instituir períodos de carência quando dados de fora entram na base por fusão, aquisição ou outra necessidade de integração. Traduzindo: no mês seguinte a uma migração, a sua taxa vai piorar, e isso é esperado. O erro é tratar o pico como fracasso e abandonar a medição.

Migração e troca de sistema: o evento que multiplica duplicata

Se existe um momento em que a duplicata explode, é a troca de software. E a AHIMA aponta exatamente esse cenário ao descrever o overlap: a rede adquire outra unidade, os registros das duas não são conectados no nível da rede, e cada paciente em comum passa a existir duas vezes.

Na clínica, o mesmo mecanismo aparece de três formas:

1. Importação sem deduplicação prévia. A base antiga já tinha duplicata, e você importou tudo. Agora tem a duplicata antiga mais a que a importação criou.
2. Duas rodadas de importação. Alguém rodou o script de novo "para pegar o que faltou", e a metade que já tinha entrado entrou outra vez.
3. Período de convivência dos dois sistemas. Durante o mês em que os dois rodam juntos, cada um cria paciente, e ninguém liga os dois depois.

O protocolo que evita isso:

• Dedupliquem a base ANTES de migrar, não depois. Migrar sujeira é pagar duas vezes pelo mesmo trabalho.
• Importação idempotente. Cada linha carrega uma chave de origem, e rodar de novo atualiza em vez de criar.
• Mede antes e depois. Calcule a taxa de erro por duplicidade na base antiga e na nova. Se a nova está pior, pare a virada.
• Congele a criação em um dos lados durante a convivência. Só um sistema cria paciente durante a transição, sempre.
• Conte o total. Se a base antiga tinha X pacientes e a nova tem muito mais que X sem que a clínica tenha captado esse tanto, você importou duplicata.

Esse planejamento tem implicação de automação também, porque o que estava ligado no sistema velho não migra sozinho. Vale ver como trocar o sistema de gestão sem perder a automação do CRM.

O que exigir do fornecedor no contrato

A maior parte das travas deste guia depende de recurso que o software tem ou não tem. Descobrir isso depois da assinatura é o erro caro.

A AHIMA recomenda, na etapa de identificação do ciclo, reunir-se proativamente com os fornecedores de tecnologia para entender como os algoritmos de pareamento funcionam e como são calculados. Faça isso ANTES de comprar, e coloque no contrato.

Exigência	Por que importa	Como testar na demonstração
Busca por CPF via API	É a chave forte, e o robô precisa consultá-la	Peça para buscar um CPF pela API na sua frente
Busca por telefone normalizado via API	É a chave do WhatsApp	Busque o mesmo número com e sem máscara, com e sem o código do país
Busca tolerante a acento e a nome parcial	A recepção erra digitação, sempre	Busque "Jose" e veja se retorna "José"
Tela de candidatos antes de salvar	É o que fecha a porta na origem	Tente cadastrar alguém que já existe
Endpoint de merge que preserva histórico	Sem ele, o mutirão vira trabalho manual eterno	Funda dois registros de teste e confira o que sobrou
Merge reversível com log	Erro de fusão vira overlay	Peça para desfazer a fusão que acabou de fazer
Campo de origem em cada registro	Sem ele, não dá para achar a causa	Veja o registro criado pela API e o criado na tela
Relatório de possíveis duplicatas	É o insumo da fila semanal	Peça o relatório na base de demonstração
Documentação do algoritmo de pareamento	A AHIMA recomenda entender como ele calcula	Pergunte quais campos pesam e se você pode ajustar
Exportação completa em formato aberto	É a sua saída se o fornecedor não entregar	Peça um export de teste

Duas cláusulas que valem a briga:

1. Prazo de correção para falha de deduplicação que o fornecedor introduza pela integração. Se o sync dele cria gêmeo, ele conserta em prazo definido.
2. Propriedade e portabilidade do dado, incluindo o mapa de identificadores. Sem o mapa de IDs, a sua próxima migração recomeça do zero.

Seu próximo passo

Você não precisa de projeto de seis meses. Precisa de três movimentos, em ordem.

1. Meça as duas taxas nesta semana. Rode o relatório de possíveis duplicatas do seu sistema e calcule o estoque (duplicatas confirmadas dividido pelo total de registros) e a criação (duplicatas confirmadas no último trimestre dividido pelos cadastros abertos no mesmo período), nas contas que a AHIMA recomenda. Sem esses dois números, qualquer decisão daqui para a frente é palpite.

2. Feche a porta antes de limpar o chão. Eleja o sistema dono da identidade, normalize telefone em E.164, obrigue a busca por CPF e telefone antes de qualquer cadastro novo (inclusive no robô do WhatsApp) e ligue o campo de origem. Só depois disso comece o mutirão, com duas horas fixas por semana e uma pessoa nomeada.

3. Cobre quem vende e quem opera. Leve a tabela de exigências ao seu fornecedor e peça a demonstração item por item. Se você quer que essa disciplina apareça também no funil comercial, com lead, agendamento e comparecimento contados uma vez só, agende uma apresentação e a gente mostra como medimos paciente na cadeira sem contar a mesma pessoa duas vezes.