Sistema de resposta a emergências: do chamado ao encerramento

Três da manhã. O telefone do plantão toca: vazamento de produto numa área industrial. O coordenador anota o que consegue num caderno, liga para o encarregado da base, que liga para os técnicos, que mandam mensagem num grupo para saber quem leva o caminhão. Duas horas depois, a central tem fotos soltas em três conversas diferentes, uma leitura de gás passada por telefone e nenhuma certeza sobre quem assinou a análise de segurança antes de entrar na área. O cliente liga pedindo um relatório de situação.

Este artigo mostra o que um sistema de resposta a emergências precisa registrar, do chamado ao encerramento, para que essa madrugada termine com um histórico completo em vez de um quebra-cabeça. Você vai encontrar o que a legislação pede em incidentes com óleo, a diferença entre coordenar por telefone e por um sistema, um checklist por fase e um roteiro de implantação. Se a sua operação também controla trabalho de risco fora das emergências, o artigo sobre permissão de trabalho digital cobre a rotina do dia a dia.

O que é um sistema de resposta a emergências?

Um sistema de resposta a emergências é o software em que a central de comando registra o incidente, despacha equipes e recursos, distribui tarefas e recebe do campo, em tempo real, o que está acontecendo, até o encerramento. Tudo fica preso ao incidente, com horário e autor, numa linha do tempo que qualquer pessoa autorizada consulta.

A ideia de organizar a resposta em torno de uma estrutura comum vem dos sistemas de comando de incidentes. O Decreto 10.950/2022, que trata do Plano Nacional de Contingência para incidentes de poluição por óleo, define o Sistema de Comando de Incidentes como uma ferramenta de gerenciamento padronizada, que permite adotar uma estrutura organizacional integrada para incidentes únicos ou múltiplos, independentemente de onde aconteçam.

O sistema de software não substitui essa metodologia nem o plano de emergência da empresa. Ele dá a ambos um lugar para acontecer: o plano define quem faz o quê, e o sistema registra se foi feito, quando e por quem.

Por que a primeira hora de uma emergência se perde em mensagens?

A primeira hora se perde porque o chamado, o despacho e as notícias do campo correm por canais diferentes, e ninguém junta tudo enquanto a operação acontece. Telefone, rádio e grupos de conversa são rápidos para avisar, mas não guardam a informação de um jeito que dê para consultar depois.

Isso pesa mais porque a lei cobra registro e comunicação rápidos. A Lei 9.966/2000, conhecida como Lei do Óleo, exige no artigo 7º que portos organizados, instalações portuárias e plataformas tenham planos de emergência individuais para combate à poluição por óleo e substâncias nocivas. O artigo 22 manda comunicar imediatamente ao órgão ambiental, à Capitania dos Portos e ao órgão regulador do petróleo qualquer incidente que possa poluir as águas, independentemente das medidas tomadas para controlá-lo.

Depois da comunicação inicial, o Decreto 10.950/2022 prevê, no artigo 15, que o poluidor envie relatórios de situação às autoridades. A lista de conteúdo é concreta: situação atual do incidente, volume descarregado e o que ainda pode vazar, características do produto, áreas afetadas, medidas adotadas e planejadas, data e hora da observação, localização da mancha, recursos mobilizados e necessidade de recursos adicionais. Quando essas informações estão espalhadas em conversas, cada relatório vira um trabalho de reconstrução feito sob pressão.

O mesmo vale para quem atende emergências fora da água, em plantas industriais e rodovias. O cliente, a seguradora e a fiscalização vão perguntar quem chegou, quando, o que mediu e o que fez. Na central de comando para resposta a emergências ambientais que construímos, o ponto de partida foi exatamente esse: o chamado entrava por telefone, o despacho era combinado por mensagem e o que acontecia no local chegava à central em fotos soltas.

O que muda entre coordenar por telefone e por um sistema?

Muda o lugar onde a informação fica. A tabela resume as diferenças que vimos ao digitalizar a coordenação de incidentes.

O rádio continua tendo lugar, principalmente em áreas sem sinal de celular. O que muda é que a decisão tomada pelo rádio passa a ser registrada no incidente por alguém da central, em vez de ficar só na memória de quem ouviu.

Fica de fora do primeiro escopo, em geral, o mapa com modelagem de dispersão, a integração com sistemas de órgãos públicos e o portal para o cliente acompanhar o incidente. São etapas úteis, que fazem mais sentido depois que a equipe já registra o básico no sistema durante uma ocorrência real.

O que o sistema precisa registrar em cada fase do incidente?

O sistema precisa registrar, no momento em que acontece, tudo o que alguém vai perguntar depois: quem comunicou, quem foi despachado, o que foi medido, o que foi feito, com que segurança e com que recursos. A lista abaixo segue as fases de um incidente, do chamado ao encerramento.

Para usar a lista, pegue a última ocorrência atendida e tente responder cada item com um registro, sem recorrer à memória de ninguém. Onde a resposta for "está no grupo" ou "o fulano sabe", há um campo que precisa entrar no sistema.

A referência internacional ajuda a calibrar o que registrar. O Instituto de Gestão de Emergências da FEMA, agência federal de emergências dos Estados Unidos, publica os formulários padrão do Incident Command System. Entre eles estão o ICS 201, de briefing do incidente, o ICS 209, de resumo da situação, e o ICS 214, um registro de atividades com horário. Eles não são obrigatórios no Brasil, mas mostram que o diário do incidente, com horário de cada ação, faz parte do método.

Dois itens fazem diferença logo na primeira ocorrência. As tarefas-modelo por tipo de incidente evitam que a equipe comece de uma tela em branco às três da manhã. Na central de comando que construímos, cada tipo de incidente já traz suas etapas e tarefas, e a central pode acrescentar tarefas específicas durante a operação. O segundo item é a análise de segurança assinada antes de começar. No mesmo sistema, o técnico preenche a análise no celular, passo a passo, e a equipe assina na tela antes de entrar na área.

Como implantar um sistema de resposta a emergências?

A implantação funciona melhor quando começa pelo plano de emergência que a empresa já tem e é testada em simulado antes de valer numa ocorrência real.

1. Reúna o plano de emergência, os procedimentos por tipo de incidente e os registros das últimas ocorrências. Eles mostram as etapas reais e onde a informação se perdeu.
2. Defina os tipos de incidente e as tarefas-modelo de cada um com quem coordena a resposta. A configuração precisa refletir o plano, e não o contrário.
3. Cadastre bases, equipes, respondedores, veículos e equipamentos. Sem esse cadastro, o despacho não sai do papel.
4. Configure a análise de segurança do trabalho e as leituras de monitoramento que cada tipo de incidente exige.
5. Instale o sistema nos celulares das equipes e teste as notificações. Confira também o que acontece quando o aparelho está no modo silencioso.
6. Rode um simulado completo, do chamado ao encerramento, e gere o relatório de situação com o que foi registrado.
7. Ajuste o que travou no simulado e passe a usar o sistema nas ocorrências reais, com o telefone ainda como apoio no começo.

O lado do campo precisa funcionar no celular, com luva, pressa e pouca atenção sobrando. Por isso construímos a visão do técnico como aplicativo para equipes de campo, e a da central como tela de monitor, com a linha do tempo e o progresso das tarefas. Na central de comando, o sistema é instalado pelo navegador e recebe notificações push como um aplicativo comum. A escolha entre esse formato e um aplicativo de loja está no artigo sobre PWA ou aplicativo nativo.

E se a equipe fica sem sinal ou fala outro idioma?

Quando falta sinal, o registro precisa de um caminho alternativo combinado antes. Em áreas remotas e em parte das operações no mar, a equipe passa as informações por rádio e alguém da central lança no incidente, identificando a origem. Se o projeto previr registro sem conexão, as fotos e os registros feitos no aparelho sobem quando o sinal volta e entram na linha do tempo com o horário em que foram feitos. O que precisa funcionar sem conexão é uma decisão de cada projeto, tomada com base nos locais onde a empresa atua.

Equipes de outros países e empresas parceiras são comuns em grandes incidentes. Na central de comando que construímos, toda a interface e a biblioteca técnica existem em português, inglês e espanhol, e cada usuário escolhe o idioma. O conteúdo do incidente fica no idioma em que foi registrado.

Também há o caso em que o cliente já tem um sistema de gestão de projetos de campo. Em vez de pedir que a equipe registre duas vezes, o sistema de resposta pode se integrar a ele. No nosso projeto, a jornada das equipes, com entrada e saída, é controlada na central e conversa com a plataforma de gestão de projetos de campo do cliente.

E há as ocorrências que começam pequenas e crescem. O sistema precisa permitir mudar a classificação do incidente, chamar mais recursos e acrescentar tarefas sem abrir um registro novo, para que a linha do tempo continue uma só.

Quando o sistema de resposta não basta?

O sistema organiza e registra a resposta, mas a estratégia de combate e o treinamento da equipe continuam fora dele, assim como o plano de emergência aprovado. Se o plano tem lacunas, o sistema vai mostrar essas lacunas mais rápido, o que já ajuda, mas a correção é do responsável técnico pelo plano.

As obrigações legais também continuam com a empresa. Quais órgãos avisar, em que prazo e em que formato dependem do tipo de incidente, do local e do licenciamento. O sistema pode lembrar e registrar cada comunicação, mas a definição vem do jurídico e do setor de QSMS.

O registro da emergência conversa com outras rotinas de segurança. A liberação de trabalho em área de risco no dia a dia é tema da permissão de trabalho digital, e o documento de entrega ao cliente depois do serviço é tema do relatório de serviço automático. Numa base de apoio portuário, por exemplo, permissão de trabalho, portaria e não conformidades ficam na mesma plataforma.

Se a sua central ainda coordena incidentes por telefone e grupos de conversa, a boosting.tech é uma empresa de software customizado que constrói esse tipo de sistema a partir do plano e da rotina que a sua equipe já tem. Podemos olhar o seu caso numa conversa de diagnóstico, sem custo. Os detalhes estão em sistemas web sob medida.