Trocar de sistema laboratorial sem perder dados nem o sono

Todo dono de laboratório que já pensou em trocar de sistema chegou à mesma trava mental: "e se a gente perder o histórico dos pacientes no meio do caminho?". É um medo legítimo — dados de exame são permanentes por obrigação legal, e um cutover malfeito pode travar a operação por dias. Mas a migração de sistema laboratorial não precisa ser um salto no escuro. Com plano de exportação, mapeamento de campos e uma janela de corte bem desenhada, dá para trocar de LIS num fim de semana e abrir na segunda-feira com tudo no lugar.

Por que laboratórios trocam de sistema — e por que adiam

Raramente a troca de sistema é sobre "gostar mais" de uma tela. Os motivos reais costumam ser dolorosos: o sistema atual não interfaceia com o equipamento novo, não tem faturamento TISS decente, trava toda semana, ou o fornecedor simplesmente parou de evoluir o produto. O problema é que a dor de ficar é silenciosa, e o medo de trocar é ruidoso — por isso tantos laboratórios convivem anos com um sistema que já sabem que precisa ir embora.

A migração de dados é, de longe, o maior bloqueio percebido. Faz sentido: um laboratório de médio porte carrega centenas de milhares de resultados, laudos assinados e cadastros de pacientes que precisam sobreviver à troca — por obrigação regulatória e por respeito ao paciente que confia no seu histórico clínico.

O plano: as 4 fases de uma migração segura

Toda migração de sistema laboratorial bem-sucedida segue a mesma lógica, independente do porte do laboratório: primeiro você entende o que tem, depois exporta, depois mapeia para o novo formato, e só então executa o cutover — a virada real de um sistema para o outro. Pular etapa é a receita mais comum de dor de cabeça.

1. Inventário: você não migra o que não conhece

Antes de pedir qualquer exportação ao fornecedor atual, faça um raio-x do que precisa sobreviver. Nem todo dado tem o mesmo peso: um cadastro de paciente incompleto de 2019 pode ser corrigido depois; um laudo assinado não pode simplesmente desaparecer.

• Cadastro de pacientes — nome, CPF, data de nascimento, contatos, convênios vinculados.
• Histórico de exames e resultados — valores, unidades, valores de referência usados na época.
• Laudos liberados e assinados — PDF ou estrutura original, com data de liberação e responsável técnico.
• Convênios e tabelas de preço — contratos ativos, códigos TUSS praticados.
• Cadastro de médicos solicitantes — CRM, especialidade, vínculos com convênios.
• Financeiro em aberto — contas a receber de convênio e particular ainda não conciliadas.

2. Exportação: exija formato aberto, não um PDF de tela

Aqui mora a primeira armadilha contratual. Alguns fornecedores tratam a exportação de dados como moeda de negociação — cobram caro, demoram semanas ou entregam relatórios em PDF impossíveis de reimportar. Isso é dado seu, do laboratório, não do fornecedor. Peça, por escrito, exportação em formato estruturado (CSV, JSON ou banco relacional) desde o primeiro contato de rescisão.

3. Mapeamento: o de-para que decide o sucesso da migração

Todo sistema organiza os mesmos conceitos de um jeito ligeiramente diferente. O que um sistema chama de "status da amostra", outro chama de "situação da coleta". Um guarda o CPF sem máscara, outro com pontuação. Esse trabalho de tradução — o mapeamento de campos — é onde a maioria dos erros de migração nasce, porque parece trivial e não é.

Cutover: a virada sem parar o laboratório

O cutover é o momento em que o sistema antigo para de receber lançamentos novos e o novo assume. É a etapa mais tensa porque acontece com o laboratório de portas abertas — pacientes continuam chegando, coletas continuam acontecendo. O segredo é escolher uma janela de baixo movimento (normalmente um fim de semana) e ter um plano de rollback caso algo dê errado.

1. Sexta à noite — última exportação completa do sistema antigo, já com o volume real do dia.
2. Sábado de manhã — importação para o sistema novo em ambiente de homologação, com conferência por amostragem.
3. Sábado à tarde — sistema antigo entra em modo somente-leitura (ninguém lança nada novo nele).
4. Sábado à noite — importação final para produção, validação cruzada de totais (nº de pacientes, exames, laudos).
5. Domingo — testes ponta a ponta: abrir um paciente real, emitir um laudo de teste, simular um atendimento completo.
6. Segunda-feira — equipe opera 100% no sistema novo, com o antigo disponível apenas para consulta histórica.

Os riscos que mais custam caro

A maioria dos problemas de migração não é técnica — é de planejamento e comunicação. O código para importar dados costuma ser a parte fácil; o difícil é garantir que ninguém opere no sistema errado durante a transição, e que a equipe saiba exatamente onde procurar cada informação no dia seguinte.

• Lançamento duplo. Um técnico esquece que o sistema antigo está em modo leitura e lança um resultado nele — e ele nunca chega ao sistema novo. Comunique a data de corte em todos os postos de trabalho, com aviso visual.
• LGPD durante o trânsito. Dados de saúde são dados sensíveis; a exportação e o armazenamento temporário dos arquivos precisam seguir o mesmo cuidado de segurança do sistema em produção — nada de planilha solta em e-mail pessoal.
• Assinatura digital perdida no meio do caminho. Um laudo que já foi assinado eletronicamente precisa manter a validade jurídica após a migração; migre o arquivo original assinado, não apenas o texto do resultado.
• Equipe despreparada no dia 1. Treinar depois do cutover é tarde demais. Treine na semana anterior, em ambiente de homologação, com dados reais (anonimizados se necessário).

Checklist prático antes de marcar a data do cutover

Use esta lista como gate de decisão: se qualquer item estiver pendente, adie a data. Um cutover adiado uma semana custa muito menos do que um cutover malsucedido que precisa ser revertido.

• Exportação completa do sistema antigo testada e validada em ambiente de homologação.
• Mapeamento de campos revisado por alguém que conhece o processo clínico, não só a estrutura técnica.
• Amostra de 50 a 100 registros conferida manualmente, campo a campo, incluindo anexos e laudos assinados.
• Contagem de totais batendo entre origem e destino (pacientes, exames, laudos, contas a receber).
• Plano de rollback definido: o que fazer se a importação falhar na madrugada do cutover.
• Equipe treinada no sistema novo, com manual rápido disponível no posto de trabalho.
• Comunicação enviada a médicos parceiros e convênios sobre a data de troca, se houver impacto de integração.
• Sistema antigo mantido acessível em modo leitura por pelo menos 60 dias após o corte.

Depois do cutover: os primeiros 30 dias

A migração não termina na segunda-feira em que o sistema novo entra no ar. Os primeiros 30 dias são o período em que problemas escondidos aparecem — geralmente quando alguém busca um exame antigo de um paciente específico e não encontra, ou encontra com um dado divergente.

Reserve tempo da equipe para auditar ativamente nesse período: comparar amostras aleatórias entre os dois sistemas, monitorar reclamações de pacientes sobre histórico e manter um canal direto com o suporte do novo fornecedor. Trate esse mês como parte do projeto, não como "já terminou, agora é operação normal".

Trocar de sistema laboratorial dói mais na antecipação do que na execução — quando existe plano de exportação, mapeamento revisado e uma janela de cutover bem desenhada, a virada vira um evento controlado, não uma aposta. O histórico do paciente é o ativo mais importante do seu laboratório; trate a migração com o rigor que ele merece, e o sistema novo vira alavanca no dia seguinte, não um risco que você carregou até a última hora.