Migrar de sistemas legados sem downtime
Um guia operacional para levar a sua IPS a uma plataforma nova sem parar o atendimento clínico nem o faturamento.
Uma IPS (instituição prestadora de serviços de saúde, como se chamam os prestadores na Colômbia) não pode ser desligada. Não existe janela de manutenção num sábado à noite que funcione quando o pronto-socorro continua recebendo pacientes e a internação não para. Essa é a restrição que faz com que migrar um sistema hospitalar se pareça pouco com migrar qualquer outro software.
A boa notícia é que o problema já foi bem estudado. A má é que a maioria das migrações fracassa por motivos que não têm nada a ver com a tecnologia.
Por que as migrações fracassam
Quase nunca é um problema de dados. É um problema de sequência: tenta-se mover tudo ao mesmo tempo.
O padrão típico é a migração “big bang”: um fim de semana prolongado, todo mundo trabalhando, e na segunda-feira todos começam no sistema novo. Funciona em instituições pequenas com processos simples. Em uma IPS com várias unidades, o que acontece é que surgem quinze problemas simultâneos na segunda às 7 da manhã, ninguém sabe qual causou qual, e não há como isolar a falha porque tudo mudou de uma vez.
A alternativa é chata e funciona: migrar por fases, em uma ordem que respeite as dependências reais da operação.
A ordem que funciona de verdade
Fase 1. Os alicerces, sem usuários.
Antes que alguém toque no sistema novo, é parametrizado o que não muda no dia a dia: a tabela de preços, os contratos com as EPS (as operadoras de saúde da Colômbia), o plano de contas, os almoxarifados, os centros de custo, a estrutura de serviços e o cadastro de usuários com seus perfis.
Esta fase não tem glamour e é onde o projeto se ganha ou se perde. Uma tabela de preços mal carregada não aparece no primeiro dia; aparece no dia 45, quando o faturamento não fecha e já existem seis semanas de operação em cima dela.
Fase 2. Um serviço piloto, em paralelo.
Escolha um serviço delimitado e de baixo risco: o ambulatório de uma especialidade ou uma unidade pequena. Durante duas ou três semanas, esse serviço opera no sistema novo enquanto o resto continua no anterior.
Sim, há digitação dupla na fronteira. É um custo real e limitado, e é muito mais barato do que descobrir um problema de configuração com a instituição inteira dentro.
Fase 3. O ciclo assistencial.
Admissões, agenda, prontuário, internação. É aqui que o sistema chega aos médicos, e onde a resistência à mudança é mais alta e mais legítima: um médico que leva três minutos a mais por paciente atende vinte pacientes a menos por semana.
Fase 4. Faturamento e contas a receber.
São migrados por último por um motivo concreto: você precisa que o ciclo assistencial esteja gerando dados limpos antes de faturá-los. Se você fatura sobre um registro clínico que ainda está se estabilizando, as glosas do primeiro trimestre vão doer.
Fase 5. Administrativo.
Estoque, compras, contabilidade, escalas de plantão. Importante, mas pode conviver com o sistema anterior por mais tempo sem afetar o atendimento.
Quais dados mover, e quais não
A tentação é migrar tudo. Raramente é a decisão certa.
Migre a quente o que a operação precisa amanhã: pacientes ativos, internações em curso, agendas futuras, contas a receber em aberto, estoque atual, contratos vigentes.
Migre a frio o que é consultado, mas não operado: prontuários encerrados, faturamento protocolado de anos anteriores, movimentações históricas de estoque. Isso pode entrar depois da virada, sem pressão, e até ficar em um repositório de consulta.
Não migre o que você nunca mais vai olhar. Cada tabela que você arrasta é uma tabela que precisa ser mapeada, validada e mantida. Uma migração é a única oportunidade realista de deixar para trás quinze anos de lixo acumulado. Aproveite.
Uma ressalva importante: o prontuário tem requisitos legais de guarda e disponibilidade. “Não migrar” nunca significa “apagar”: significa decidir conscientemente se ele fica no sistema novo ou em um arquivo consultável, e deixar essa decisão documentada.
A reconciliação é inegociável
Depois de cada fase, antes de avançar para a próxima, é preciso provar que os dados chegaram completos. Não com uma revisão visual: com contagens.
Quantos pacientes havia na origem e quantos há no destino. Quanto somam as contas a receber de cada lado. Quantas unidades tem o estoque. Se os números não batem 100%, não se avança, e a diferença é explicada uma por uma, sem tirar média.
Esse passo é pulado com frequência porque é tedioso e porque o cronograma está apertado. É exatamente o passo que separa uma migração de um desastre silencioso descoberto três meses depois.
O fator que ninguém coloca no orçamento
O tempo da sua própria equipe.
Durante uma migração, o seu líder de faturamento, o seu coordenador de admissões e o seu gerente de TI vão dedicar entre 20% e 40% da jornada ao projeto, além do trabalho normal. Se isso não estiver planejado, vai sair de algum lugar: quase sempre da qualidade da parametrização ou das horas de descanso do seu pessoal.
Planeje isso explicitamente. Redistribua a carga, contrate reforço temporário ou estenda o cronograma. As três são opções razoáveis; fingir que o tempo aparece sozinho não é.
Um cronograma realista
Para uma IPS de porte médio com várias unidades, entre quatro e doze semanas é uma faixa razoável, dependendo de quantos módulos forem ativados e de quão limpos estiverem os dados de origem.
Desconfie de quem prometer duas semanas. Não porque seja tecnicamente impossível mover os dados em duas semanas, mas porque a migração não é o gargalo: o gargalo é a capacidade da sua equipe de absorver a mudança sem deixar de atender pacientes.
