São 2h da manhã de uma segunda-feira. O pronto-socorro está cheio, e o sistema de prontuário eletrônico para de responder. Ninguém consegue acessar os prontuários e ver a alergia do paciente do leito 4, o laboratório não libera resultados e a farmácia não pode entregar os remédios. A equipe de TI descobre que o storage principal caiu, ou pior, que os arquivos foram criptografados por um ransomware.
A pergunta que todo gestor deveria conseguir responder antes desse dia chegar é simples: quanto tempo você pode suportar esta situação? E quantos dados você pode perder sem colocar o paciente em risco?
Essas duas respostas têm nomes técnicos: RTO e RPO. São elas que definem se a sua estratégia de continuidade de negócio.
RTO e RPO
RTO (Recovery Time Objective): É o tempo máximo que um sistema pode ficar fora do ar até voltar a funcionar. Se o RTO do prontuário é de 1 hora, o plano de DR precisa colocar o sistema em operação em até 1 hora depois da falha.
RPO (Recovery Point Objective): É o ponto no qual é aceitável a perda de dados para a continuidade do atendimento, medido em tempo. Um RPO de 15 minutos significa que, no pior caso, tudo o que foi registrado nos últimos 15 minutos antes da falha some e precisa ser refeito.
Um jeito fácil de lembrar: o RTO olha para frente (quanto tempo até voltar) e o RPO olha para trás (até onde eu consigo recuperar).
No hospital, isso se torna concreto. Um RPO de 24 horas, comum em quem só faz backup noturno, quer dizer perder um dia inteiro de evoluções médicas, prescrições, checagens de enfermagem e laudos. Alguém terá que reconstruir isso a partir de documentos impressos (prática cada vez mais rara) e/ou da memória; com isso, o risco clínico e jurídico torna-se consequência direta do evento inicial.
Nem todo sistema precisa do mesmo RTO
O erro mais caro em DR é tratar tudo igual. Proteger o ERP administrativo com o mesmo nível do prontuário clínico é realmente necessário? Por outro lado, proteger o prontuário clínico com o nível do ERP pode custar vidas. A tabela abaixo é um ponto de partida para definir o RTO e o RPO, embora os números finais devam vir da análise da criticidade de cada instituição:
Sistema | O que para quando ele cai | RTO de referência | RPO de referência |
Prontuário eletrônico (PEP) / HIS | Prescrição, evolução, alergias, histórico do paciente | Até 1 h | Até 15 min |
Laboratório (LIS) | Liberação de exames, interfaceamento com equipamentos | Até 2 h | Até 15 min |
PACS / RIS (imagem) | Visualização e laudo de raio-X, tomografia, ressonância | Até 4 h | Até 1 h |
Farmácia e dispensação | Controle de estoque e liberação de medicamentos | Até 2 h | Até 30 min |
Faturamento e TISS | Envio de guias e cobrança de convênios | Até 24 h | Até 4 h |
* ERP, RH e financeiro | Compras, folha, contas a pagar | Até 48 h | Até 24 h |
Note que o faturamento aguenta um dia parado sem afetar diretamente o paciente, mas cada hora de atraso impacta o fluxo de caixa. Outras áreas, mesmo não atendendo diretamente o paciente, podem influenciar o atendimento de forma indireta.
* Sempre existirão momentos críticos em função da sazonalidade. Por exemplo, o RH: se houver uma falha no fechamento da folha de pagamento no final do mês, os colaboradores da linha de frente podem ficar preocupados com as próprias contas a pagar, o que certamente afetará o foco e a eficiência no cuidado aos pacientes. Por isso, configurar um RTO e um RPO muito longos sem critério pode não ser a melhor prática de mitigação.
Como chegar aos seus números?
RTO e RPO não são decisões exclusivas da TI. Quem sabe quanto tempo o centro cirúrgico aguenta sem sistema é a diretoria clínica; quem sabe o impacto de um dia sem faturar é o financeiro; e quem sabe se a equipe virá trabalhar é o RH/DP. O caminho funcional exige quatro passos:
· Liste os sistemas e as dependências: O PEP pode estar de pé, mas se o Active Directory ou o banco de dados que ele usa cair, ninguém faz login. DR de aplicação sem DR de infraestrutura de apoio não funciona.
· Faça a análise de impacto no negócio (BIA – Business Impact Analysis): Para cada sistema, pergunte o que acontece após 15 minutos, 1 hora, 4 horas e 24 horas de paralisação. Envolva a coordenação de enfermagem, o corpo clínico, o setor administrativo e o jurídico.
· Coloque as exigências legais na mesa: A Lei 13.787/2018 e a Resolução CFM 1.821/2007 exigem a guarda do prontuário por no mínimo 20 anos, com integridade e autenticidade. A LGPD classifica dados de saúde como sensíveis e cobra medidas rígidas de segurança contra perdas e acessos indevidos (Art. 46). Perder dados de pacientes pode gerar incidentes comunicáveis à ANPD e processos jurídicos extremos.
· Compare o custo da parada com o custo de proteção: Quanto custa cada minuto, hora ou dia de inatividade? O objetivo é encontrar o ponto de equilíbrio entre o investimento em prevenção e o prejuízo de uma paralisação.
Backup não é Disaster Recovery
Muitas instituições descobrem isso no pior momento. O backup garante que o dado existe em algum lugar; o DR garante que o atendimento volta a rodar dentro do prazo combinado. Ter a cópia do banco de dados do PEP em uma fita ou storage externo não adianta se a restauração demorar 30 horas e não houver servidores disponíveis para subir o sistema.
Na prática, três pilares separam um plano funcional da teoria:
· Ambiente de recuperação pronto: Servidores, rede e armazenamento em um segundo site, distantes do primeiro, com replicação contínua dos sistemas críticos. É isso que viabiliza um RPO de minutos.
· Cópia isolada contra ransomware: Ataques modernos procuram e apagam os backups antes de criptografar o ambiente. Ter uma cópia imutável, que nem mesmo um administrador comprometido consiga alterar, faz toda a diferença.
· Testes efetivos e periódicos: Um plano de DR que nunca foi testado é apenas uma hipótese. Testes periódicos, com o RTO cronometrado, validam se os números da tabela são reais e ajudam a descobrir dependências esquecidas antes de uma crise real.
Como a PWS Cloud entrega DR para a saúde?
Montar e manter um segundo data center exclusivo para DR está fora da realidade da maioria dos hospitais e clínicas. É por isso que o modelo de Disaster Recovery como Serviço (DRaaS) cresceu: a instituição paga pelo ambiente de recuperação e operação sem imobilizar capital em hardware ocioso (conceito de CAPEX vs. OPEX).
No DRaaS da PWS Cloud, o ambiente de recuperação roda em nossa nuvem privada, alocada em data centers no Brasil. Os dados dos pacientes não saem do país, o que simplifica a conformidade com a LGPD perante o jurídico e o DPO.
O trabalho começa antes da tecnologia. Em conjunto com a equipe do cliente, fazemos o levantamento dos sistemas e definimos o RTO e o RPO de cada um com base na criticidade. A partir daí:
· Definimos os sistemas críticos (como PEP, LIS e farmácia) com replicação contínua para o ambiente PWS;
· Sistemas de menor criticidade recebem suporte via backup e restauração planejada;
· Uma cópia imutável protege o ambiente contra ransomware;
· Testes de failover agendados e acompanhados pelo nosso time geram relatórios detalhados com o tempo real de recuperação.
No dia em que algo falhar, o atendimento é retomado no ambiente PWS. A equipe de TI do hospital conta com suporte humanizado em português, operando no mesmo fuso horário.
Quer saber quanto tempo o seu atendimento aguenta parado hoje? Fale com o time de pré-vendas da PWS Cloud e agende um diagnóstico de RTO e RPO para os seus sistemas críticos.
Perguntas frequentes:
Qual a diferença entre RTO e RPO? RTO é o tempo máximo para o sistema voltar a funcionar após uma falha. RPO é a quantidade máxima de dados aceitável para perda, medida em tempo.
Clínica pequena precisa de Disaster Recovery? Sim, mas na proporção adequada. Uma clínica com agenda e prontuário em sistema próprio pode estabelecer um RTO de algumas horas ou resolver a questão com backup em nuvem e restauração testada. O erro é descobrir apenas na hora da falha que o backup não restaura ou não existe.
Se o meu prontuário é SaaS, ainda preciso pensar nisso? Sim. Vale a pena consultar o fornecedor para confirmar os RTOs e RPOs contratados e a localização das cópias. Sistemas locais — como PACS, LIS e integrações — continuam sob a responsabilidade da sua TI.
De quanto em quanto tempo devo testar o plano de DR? Para sistemas críticos, o ideal é testar ao menos duas vezes por ano, principalmente após grandes mudanças, como troca de versão do PEP ou migração de infraestrutura.
DR em nuvem atende à LGPD? Sim, desde que o provedor garanta controles rigorosos de segurança, contrato de tratamento de dados e armazenamento em território nacional. Com os dados no Brasil, evita-se a complexidade de análises de transferência internacional.
