← Voltar ao blog
Produto 1 de outubro de 2026 · 13 min de leitura

Migrar dados de pacientes sem perder o histórico

Guia prático para exportar dados de pacientes, validar o histórico e fazer testes antes de migrar para outro programa sem cortes na consulta.

Principais conclusões

  • Migrar bem não é «passar contactos»: exige garantir a continuidade do histórico, incluindo documentos, notas clínicas e episódios associados ao paciente certo.
  • Um formato de exportação CSV é útil para dados em tabela, mas não cobre bem anexos, consentimentos ou relatórios; planeie esses blocos à parte.
  • Os testes antes de migrar devem incluir casos reais: pacientes com pacotes de sessões, anulações, seguradoras, vários profissionais e faturas retificativas.
  • O critério-chave é a rastreabilidade: poder demonstrar o que foi exportado, quando, quem o validou e o que ficou de fora, por exigência operacional e de RGPD.

Mudar de programa sem perder informação é possível, mas não se improvisa. A migração afeta a agenda, os pagamentos, o processo clínico e o trabalho da receção; se falhar, nota-se logo no primeiro dia.

O que significa «não perder o histórico» numa clínica

Defina «histórico» de acordo com a sua forma de trabalhar

Numa clínica, o histórico não é apenas uma ficha com nome e telefone. Costuma incluir peças que estão repartidas pelo software atual e por pastas «paralelas»:

  • Identificação: dados pessoais, contacto, DNI/NIE (os documentos de identificação espanhóis), se os utilizarem, morada, data de nascimento.
  • Relação assistencial: episódios/visitas, notas por sessão, profissional que atendeu, motivo da consulta (se o registarem), encaminhamentos internos.
  • Documentação: consentimentos informados, relatórios, exames anexados, declarações, imagens, PDF.
  • Gestão: orçamentos, faturas, pagamentos, formas de pagamento, pacotes de sessões, sessões consumidas, valores em dívida, devoluções.
  • Operação: lembretes, comunicações, marcações anuladas/faltas, etiquetas internas («prefere manhãs», «ligar antes», «seguradora X»).

Ação aplicável (hoje): imprima ou partilhe uma «lista do histórico» da sua clínica e assinale o que é imprescindível migrar e o que pode ficar como arquivo consultável.

Decida de que continuidade precisa desde o dia 1

Nem todas as clínicas precisam do mesmo no primeiro dia após a mudança. A pergunta prática é: o que têm de conseguir ver a receção e o profissional numa chamada ou numa consulta?

Exemplo realista:

  • A receção atende uma chamada: precisa de ver a última visita, o saldo do pacote de sessões, as faturas pendentes e o telefone correto.
  • O profissional abre a sessão: precisa de ver as notas anteriores, os documentos relevantes e quem atendeu antes.

Ação aplicável (esta semana): defina um «mínimo operacional» para o arranque: 8–12 campos e 3–5 documentos-chave por paciente que não podem faltar.

O que costuma falhar ao exportar dados de pacientes

O CSV não é o histórico completo

Muitas ferramentas permitem exportar dados de pacientes num formato de exportação CSV. É útil, mas tem limites claros:

  • O CSV funciona bem para tabelas (pacientes, marcações, faturas).
  • Funciona mal ou não serve para anexos (PDF, imagens), assinaturas, consentimentos digitalizados ou documentos com várias versões.
  • Costuma perder relações complexas se não forem exportadas com chaves consistentes (por exemplo, visitas ligadas a um paciente através de um ID interno).

Ação aplicável: peça ao fornecedor atual uma lista das exportações disponíveis e assinale quais são CSV e quais são «pastas» ou «ficheiros soltos».

Campos «livres» e notas: o buraco negro típico

Se a sua equipa escreve muito em campos de texto livre («Observações», «Notas internas»), ao migrar podem acontecer três coisas:

  • São copiadas, mas ficam num campo diferente e ninguém as encontra.
  • São cortadas por limites de comprimento.
  • Misturam-se notas internas com notas do profissional, o que cria um problema de utilização e de privacidade interna.

Ação aplicável: escolha 20 pacientes ao acaso e verifique quantas decisões operacionais estão nas «notas» (por exemplo: «não ligar para o trabalho», «prefere WhatsApp»). Se forem muitas, defina onde devem ficar no novo sistema.

Duplicados e pacientes «parecidos»

Em clínicas com anos de atividade é habitual ter:

  • O mesmo paciente com duas fichas (um dia entrou com um telefone, outro dia com outro).
  • Apelidos com variantes, acentos ou dois apelidos.
  • Menores ligados a um tutor, mas com dados misturados.

O risco é migrar duplicados e, depois, o profissional ver o histórico partido.

Ação aplicável: antes de exportar, acorde uma regra de unificação (por exemplo: «se o DNI/NIE coincidir, funde-se; se não, revisão manual») e deixe registado quem valida.

Plano de migração por fases (sem parar a consulta)

Fase 1: inventário e mapa de dados

Aqui ainda não se mexe em nada. Decide-se o que existe e como se chama de cada lado.

  1. Inventário de módulos e «fontes reais»:
    • Programa atual
    • Excel de pacotes de sessões
    • Pasta de consentimentos digitalizados
    • Drive/Dropbox com relatórios
    • Terminal de pagamento/banco para pagamentos e devoluções
  2. Mapa de campos (origem → destino):
    • «Telefone 1» → «Telemóvel»
    • «Seguradora» → «Mútua»
    • «Observações receção» → «Notas administrativas»
  3. Regras: o que se migra tal como está, o que se limpa, o que não se migra.

Ação aplicável: crie uma tabela simples (Excel) com três colunas: Campo atual, Campo novo, Regra/nota. Que a assinem o gerente e o responsável da receção.

Fase 2: exportação controlada e cópia de segurança

Antes de mexer em qualquer coisa:

  • Faça uma cópia de segurança do sistema atual com data e responsável.
  • Exporte por blocos: pacientes, marcações, faturação, pacotes de sessões, comunicações, documentos.
  • Guarde a exportação num local controlado e com permissões limitadas.

Se trabalhar com um fornecedor, exija um registo de:

  • Data e hora da exportação
  • O que inclui e o que não inclui
  • Formato (por exemplo, CSV, PDF, ZIP de anexos)

Ação aplicável: nomeie um «guardião» dos ficheiros (normalmente a gerência ou a administração) e registe num documento interno onde estão e quem tem acesso.

Fase 3: carregamento num ambiente de testes

Peça (ou monte) um ambiente onde se possa importar sem afetar o trabalho diário. É aqui que se fazem os testes antes de migrar com casos reais.

Lista de verificação de testes operacionais:

  • Procurar um paciente por nome, telefone e DNI/NIE (se aplicável).
  • Ver a continuidade do histórico: últimas visitas, notas, documentos.
  • Criar uma marcação e verificar a disponibilidade por profissional e por gabinete/sala (se os utilizarem).
  • Registar um pagamento, uma fatura e uma devolução (se for o caso).
  • Ver um pacote de sessões: saldo correto e consumo ao registar a sessão.

Ação aplicável: defina 10 «casos-tipo» e atribua a cada um um validador: a receção valida a agenda; a administração valida as faturas; um profissional valida o processo clínico e os documentos.

Receção a rever fichas e ficheiros antes de migrar

Fase 4: migração final e janela de mudança

A migração final planeia-se com uma «janela» durante a qual:

  • Se minimizam as alterações no sistema antigo (para não gerar dados que depois não sejam migrados).
  • Se define o que fazer com marcações novas, anulações e pagamentos durante a janela.

Prática habitual:

  • Até uma hora combinada, trabalha-se normalmente.
  • A partir dessa hora, a receção aponta as alterações críticas num registo temporário (por exemplo, uma folha controlada) para as replicar no novo sistema depois do carregamento.

Ação aplicável: crie uma «folha de alterações» para a janela: paciente, ação (marcação/pagamento/anulação), hora, responsável.

Validação: como verificar a continuidade do histórico sem enlouquecer

Amostragem inteligente: não reveja «tudo», reveja o que dói

Rever paciente a paciente é inviável. O que funciona é uma amostragem que cubra a complexidade:

  • Pacientes com muitas visitas
  • Pacientes com documentos anexados
  • Pacientes com pacotes de sessões e consumos parciais
  • Pacientes com faturas retificativas ou devoluções
  • Pacientes atendidos por vários profissionais
  • Pacientes de seguradora (se aplicável) e particulares

Ação aplicável: prepare uma lista de 30–50 pacientes «de stress» (não pelo volume, mas pela casuística) e use-a como teste padrão.

Reconciliação básica: totais que têm de bater certo

Sem entrar em números públicos nem em promessas, há controlos simples que detetam falhas rapidamente:

  • Número de pacientes exportados vs. importados (qualquer diferença tem de ter explicação).
  • Número de marcações num intervalo de datas (por exemplo, o último mês fechado).
  • Número de faturas emitidas num período contabilístico fechado.
  • Número de documentos anexados e a sua acessibilidade.

Ação aplicável: peça ao fornecedor um relatório de importação com «importados / rejeitados / pendentes» e o motivo de cada rejeição.

Rastreabilidade e RGPD: não é burocracia, é proteção

A migração implica o tratamento de dados pessoais de saúde. Em Espanha aplica-se o RGPD e a LOPDGDD (a lei orgânica espanhola de proteção de dados pessoais e garantia dos direitos digitais). Além disso, se houver um fornecedor a ajudar, normalmente atua como subcontratante e é necessário um contrato adequado.

Na prática, isto traduz-se em:

  • Controlo de acessos aos ficheiros de exportação.
  • Registo interno de quem manipula os dados e com que finalidade.
  • Eliminação ou arquivo seguro dos ficheiros temporários após a migração.
  • Procedimento para responder aos direitos (acesso, retificação, apagamento) também durante a mudança.

A AEPD (a autoridade espanhola de proteção de dados) publica guias e critérios úteis para concretizar medidas e responsabilidades sem transformar isto num projeto interminável.

Ação aplicável: peça por escrito ao fornecedor que medidas usa para transferir ficheiros (canal, cifragem, acesso) e quem pode aceder durante o processo.

Agenda, pagamentos e pessoal: o que ninguém quer descobrir na segunda-feira

Agenda: recursos, durações e regras de vagas

Ao migrar a agenda, as falhas típicas não são «faltam marcações», mas sim:

  • Durações predefinidas diferentes (30 vs. 45 minutos).
  • Regras de sobreposição por profissional.
  • Recursos não migrados (sala, gabinete, equipamento) e marcações que ficam «sem lugar».
  • Tipos de consulta que mudam de nome e estragam as estatísticas internas.

Ação aplicável: antes da mudança, liste os seus tipos de consulta (primeira consulta, revisão, relatório, seguradora, teleconsulta, se existir) com duração e recursos; confirme que existem da mesma forma no novo sistema.

Pagamentos e faturação: o que deve estar fechado antes

Se mudar de software a meio de um período contabilístico, surgem dúvidas operacionais:

  • Onde emito uma fatura retificativa de uma fatura antiga?
  • Onde consulto o histórico de pagamentos de um paciente se houver uma reclamação?
  • Como controlo os valores em dívida se o estado não tiver migrado bem?

Sem dar aconselhamento fiscal, a prática de gestão é clara: feche o que puder fechar antes da mudança e defina que consultas se farão no sistema antigo, como «arquivo».

Ação aplicável: acorde uma data interna de «corte operacional» para a faturação e um procedimento: «as faturas anteriores consultam-se no sistema antigo; as novas emitem-se no novo».

Equipa: permissões, funções e entradas/saídas

Durante uma migração, o risco humano é elevado:

  • Alguém entra com permissões a mais «para ajudar».
  • Criam-se utilizadores genéricos partilhados.
  • As funções não são bem replicadas (a receção vê notas que não devia, ou o profissional não vê documentos de que precisa).

Ação aplicável: prepare uma lista de utilizadores com a sua função e o acesso mínimo necessário. Reveja no primeiro dia: receção, administração, direção e cada profissional.

O que pedir a um fornecedor antes de assinar a migração

Perguntas concretas que evitam surpresas

Leve estas perguntas para a demonstração ou para a reunião técnica:

  • Que formatos de exportação suportam a partir do meu sistema atual: CSV, Excel, JSON, ZIP de anexos?
  • Como importam os documentos: por ligação, por carregamento em massa, por pasta de cada paciente?
  • Que campos não são importados e porquê?
  • Como resolvem os duplicados: regra automática, revisão manual, relatório de conflitos?
  • O que entregam no fim: relatório de importação, lista de erros, registo do mapeamento?
  • Há ambiente de testes e quantas iterações de teste permite o processo?

Se estiver a avaliar o Clínica Digital Software, aplique estas mesmas perguntas; servem igualmente para comparar com qualquer alternativa sem depender do discurso comercial.

Ação aplicável: exija um documento de «âmbito da migração» com: o que entra, o que não entra, o que se valida, quem valida e o que se considera uma migração aceite.

Sinais de risco (para parar e redefinir)

  • «Passa-se tudo», sem detalhar o que significa tudo.
  • Não há plano de testes antes da data da mudança.
  • Não há relatório de erros de importação.
  • Pedem-lhe os ficheiros por canais informais, sem controlo de acesso.
  • Não se fala de funções/permissões nem de rastreabilidade.

Ação aplicável: se detetar um sinal, transforme esse ponto num requisito: «sem ambiente de testes não há data de mudança», por exemplo.

Como aplicar isto na sua clínica

  1. Segunda-feira (gerência + receção, 45 minutos): definam o «mínimo operacional» de continuidade do histórico (campos e documentos imprescindíveis) e registem-no numa folha partilhada.
    Verificação: todos os perfis (receção, profissional, administração) confirmam que com esse mínimo conseguem trabalhar um dia completo.

  2. Terça-feira (administração, 60 minutos): inventário das fontes de dados e das exportações disponíveis; peçam ao fornecedor atual a exportação em formato de exportação CSV e, à parte, os anexos/documentos.
    Verificação: existe uma pasta controlada com exportações datadas e um registo de quem tem acesso.

  3. Quarta-feira (responsável designado + fornecedor, 60–90 minutos): construir o mapa de campos origem→destino e acordar regras para duplicados e normalização (telefones, acentos, DNI/NIE, se aplicável).
    Verificação: o mapa tem responsável e versão; qualquer alteração fica registada.

  4. Quinta-feira (receção + 1 profissional + administração, 90 minutos): executar os testes antes de migrar com 10 casos-tipo (pacote de sessões, seguradora, devoluções, vários profissionais, documentos).
    Verificação: lista de incidências com captura de ecrã ou exemplo, e decisão: corrige-se na origem, no mapeamento ou no destino.

  5. Sexta-feira (gerência, 30 minutos): definir a janela de mudança e a «folha de alterações» para apontar marcações/pagamentos durante o corte; comunicá-lo à equipa.
    Verificação: toda a equipa sabe o que se aponta, onde e quem o passa para o novo sistema.

Perguntas frequentes

Que dados mínimos devo migrar para começar a trabalhar?

Deve migrar a identificação do paciente, o contacto, a agenda futura e um resumo utilizável do histórico recente. Acrescente a faturação em aberto (valores em dívida, pacotes de sessões ativos) para que a receção possa cobrar e fazer bater as contas. O resto pode ficar como arquivo consultável, se o definir assim desde o início.

O formato CSV serve para migrar documentos e consentimentos?

Não, o CSV serve para dados em tabela e relações básicas, se estiverem bem identificadas. Os documentos costumam migrar-se como ficheiros (por exemplo, pastas ou ZIP) e exigem uma regra para os associar a cada paciente. Peça um método de importação de anexos e teste-o com vários tipos de documento.

Como giro as novas marcações durante a janela de mudança?

Defina uma hora de corte e um registo temporário único para as alterações críticas: novas marcações, anulações e pagamentos. Uma pessoa responsável passa essas alterações para o novo sistema após o carregamento final. Se não houver um registo único, vão aparecer vagas duplicadas ou marcações perdidas.

O que devo pedir para cumprir o RGPD numa migração?

Deve pedir medidas de transferência e de armazenamento seguro de ficheiros, controlo de acessos e rastreabilidade de quem manipula os dados. Garanta que existe um contrato de subcontratação, se intervier um fornecedor, nos termos do RGPD e, em Espanha, da LOPDGDD. Guarde um registo interno do processo e elimine as cópias temporárias quando já não forem necessárias.

Ligações externas

Etiquetas migração dados histórico mudança de software