Cibersegurança dos equipamentos hospitalares: do caderno de encargos à operação segura

A cibersegurança dos equipamentos hospitalares não começa no dia em que um sistema é ligado à rede. Também não termina quando acaba a colocação em serviço. Na realidade, começa muito antes: quando o hospital decide de que necessita, que comunicações serão indispensáveis, quem poderá administrar a solução, durante quanto tempo receberá suporte e como será substituída quando chegar ao fim da sua vida útil.

Num bloco operatório conectado, um incidente digital vai muito além da confidencialidade dos dados. Uma conta partilhada, uma atualização sem possibilidade de reversão, uma dependência não documentada ou um acesso remoto sem controlo podem colocar uma função fora de serviço, dificultar a manutenção ou prolongar uma interrupção. O impacto dos ciberataques no setor da saúde obriga, por isso, a deixar de pensar apenas em como reagir e a começar a decidir como prevenir os riscos desde a conceção e a contratação.

A questão verdadeiramente útil não é saber se um produto «é seguro» em termos absolutos. O importante é compreender como será integrado no ambiente hospitalar, que testes permitirão verificá-lo e quem será responsável por manter as suas condições de segurança ao longo do tempo.

A cibersegurança não é acrescentada aos equipamentos quando o projeto já está concluído. É definida no caderno de encargos, verificada durante a receção e mantida ao longo de toda a sua vida útil.

Esta abordagem tornou-se ainda mais relevante com as orientações da ENISA para a contratação cibersegura nos hospitais, publicadas em julho de 2026. O guia organiza a aquisição em três grandes etapas —planeamento, seleção e gestão— e propõe requisitos, informações a fornecer pelo fornecedor e evidências que devem ser conservadas durante todo o ciclo contratual.

Porque é que a cibersegurança começa no caderno de encargos

Uma formulação como «o sistema deverá ser seguro» pode parecer tranquilizadora, mas é quase impossível de verificar. Também não permite atribuir responsabilidades com clareza se algo falhar. Um requisito bem formulado, pelo contrário, descreve um comportamento concreto, estabelece que evidência deve ser apresentada e indica quem deve validá-la.

Não se trata de uma diferença meramente semântica. Se a política de atualizações, os registos de atividade ou as condições do suporte remoto não constarem do caderno de encargos, o hospital poderá descobrir as suas limitações quando o sistema já estiver instalado. Corrigir a arquitetura nessa fase costuma ser mais dispendioso, exige maior coordenação e deixa menos margem para escolher uma alternativa.

O Plano de Ação Europeu para a Cibersegurança dos Hospitais e Prestadores de Cuidados de Saúde estrutura a resposta europeia em torno de quatro eixos: prevenção, deteção, resposta e dissuasão. Integrar estas capacidades no processo de aquisição permite transformar princípios gerais em decisões concretas para o projeto.

Seis decisões para gerir todo o ciclo de vida

A segurança não funciona como uma fase isolada que se possa considerar concluída. Acompanha os equipamentos desde a definição das necessidades até ao fim do suporte e à sua retirada definitiva. Qualquer projeto de área crítica conectada deve contemplar, no mínimo, estas seis decisões:

Comprar um sistema conectado sem definir como será mantido e retirado equivale a assumir uma dívida técnica antes mesmo da sua entrada em funcionamento.

Sete requisitos de cibersegurança para equipamentos hospitalares

1. Inventário técnico e mapa de dependências

O hospital precisa de saber que componentes recebe, que versões utilizam, com que sistemas comunicam e de que serviços necessitam para funcionar. Este inventário não é uma simples lista administrativa. É a referência que permitirá avaliar a criticidade de cada elemento, preparar uma atualização e antecipar que outras funções poderão ser afetadas por uma alteração ou um incidente.

Além do inventário inicial, é necessário definir quem o manterá atualizado. Uma documentação exata no dia da receção perde grande parte do seu valor se não refletir as alterações posteriores.

2. Identidades, privilégios e acesso remoto

As contas partilhadas, as palavras-passe predefinidas e as permissões permanentes impedem saber com certeza quem fez o quê e quando. O projeto deve especificar como serão autenticados os utilizadores e os técnicos, de que privilégios necessita cada perfil, quem poderá autorizar uma intervenção remota e como serão revogadas as credenciais quando esta terminar.

O acesso remoto merece uma atenção especial. Não deve permanecer aberto por conveniência nem depender de uma palavra-passe conhecida por várias pessoas. Uma abordagem razoável consiste em ativá-lo apenas quando necessário, durante um período limitado e mantendo um registo da atividade realizada.

3. Segmentação e interoperabilidade controlada

Um bloco operatório conectado precisa de partilhar informação, mas isso não significa que todos os seus componentes devam comunicar livremente entre si. A rede deve permitir os fluxos necessários à atividade clínica e bloquear aqueles que não são necessários.

A interoperabilidade e a segmentação não são conceitos opostos. A primeira permite a troca de informação; a segunda estabelece os seus limites. O objetivo é permitir que os equipamentos colaborem sem aumentar desnecessariamente a superfície de exposição. Esta questão complementa a análise sobre a interoperabilidade dos dispositivos médicos em unidades de cuidados críticos.

4. Atualizações, vulnerabilidades e duração do suporte

Antes de adjudicar um sistema, o hospital deve saber como e com que frequência é atualizado, através de que canal são comunicadas as vulnerabilidades, durante quanto tempo se prevê mantê-lo e que procedimento será seguido se uma correção não puder ser instalada de imediato.

Numa área crítica, atualizar sem validação pode criar tanto risco como adiar indefinidamente uma correção necessária. Por isso, devem ser acordados uma cópia de segurança prévia, um teste de compatibilidade, uma janela de intervenção, os responsáveis pela autorização e um mecanismo de reversão caso o resultado não seja o esperado.

Também deve ficar claro o que acontecerá quando o suporte terminar. Conhecer essa data antecipadamente permite orçamentar uma migração e evita manter sistemas vulneráveis por falta de alternativas preparadas.

5. Disponibilidade, modo degradado e recuperação

Num ambiente crítico, a disponibilidade também é uma propriedade de segurança. A conceção deve antecipar o que acontecerá se falhar a rede, uma estação de trabalho, uma integração ou um serviço central. A resposta não pode ser improvisada durante o incidente.

Os modos degradados, as cópias de configuração, as peças de substituição previstas e os procedimentos manuais ajudam a reduzir o impacto clínico. Tão importante como dispor de uma cópia é verificar se pode ser restaurada dentro do prazo acordado. Esta dimensão complementa o artigo sobre a continuidade operacional em blocos operatórios e unidades de cuidados intensivos.

6. Registos, monitorização e notificação

Quando ocorre um incidente, as equipas técnicas precisam de reconstruir o sucedido sem comprometer a privacidade. Para isso, é necessário saber que eventos o sistema regista, como sincroniza a hora, durante quanto tempo conserva a informação e de que forma pode ser integrado nas ferramentas de monitorização do hospital.

O contrato também deve estabelecer um canal de notificação claro. Se o fornecedor detetar uma vulnerabilidade, a instituição precisa de saber quem receberá o aviso, que informação conterá, como será classificada a sua gravidade e em que prazo será proposta uma atuação.

7. Cadeia de abastecimento, fim do suporte e retirada segura

Uma solução pode depender de componentes de terceiros, subcontratantes, bibliotecas de software ou serviços externos. O hospital precisa de identificar os elementos críticos, saber quem os mantém e que alternativas existem se um desses fornecedores deixar de prestar suporte. O guia do NIST para a gestão do risco de cibersegurança na cadeia de abastecimento recomenda integrar estas relações na governação e comunicar os requisitos de segurança aos fornecedores envolvidos.

A obsolescência também não deve surgir de surpresa. O contrato pode estabelecer com que antecedência deve ser comunicado o fim do suporte e que opções de migração serão disponibilizadas. Ao retirar o equipamento, as contas, credenciais, configurações e dados devem ser eliminados de forma verificável; os acessos remotos devem ser revogados e o inventário deve registar a retirada.

Como se aplica num bloco operatório conectado

A arquitetura digital do bloco operatório conectado pode reunir controlos ambientais, vídeo, comunicações, alarmes, informação e serviços técnicos. Esta integração facilita o acesso à informação e pode reduzir etapas operacionais, mas também cria dependências que devem ser documentadas desde a fase de projeto.

No ecossistema da Tedisel Medical, o software de controlo HERMES centraliza funções do ambiente. O painel técnico Q Panel pode integrar ecrãs, PC, vídeo, dados, alarmes e outros componentes, enquanto o painel de controlo e visualização Glass Panel reúne elementos visuais e admite configurações compatíveis com PACS, postos de enfermagem e HERMES. O âmbito concreto depende sempre da configuração acordada para cada hospital.

Testes de aceitação: transformar promessas em evidências

A receção técnica é o momento em que o hospital verifica se a solução contratada funciona no ambiente real. Não se trata de realizar testes invasivos sem coordenação, mas de verificar a documentação, as configurações e as capacidades acordadas antes de colocar a solução em serviço.

Cada requisito deve produzir uma evidência. Se uma verificação não puder ser concluída ou exigir uma exceção, esta deve ser documentada juntamente com o risco, a medida compensatória e a pessoa responsável pela sua resolução.

Um teste de aceitação útil não se limita a confirmar que «tudo funciona». Demonstra o que funciona, em que condições e quem deve atuar quando deixa de funcionar.

Governação: uma responsabilidade partilhada, mas nunca difusa

As compras transformam os requisitos em obrigações contratuais. As TI definem a rede, as identidades e a monitorização. A engenharia biomédica gere o parque instalado. A engenharia coordena as instalações e a sua disponibilidade. Os profissionais clínicos explicam as consequências de uma interrupção. O fornecedor, por sua vez, documenta, mantém e comunica.

Todos participam, mas isso não significa que a responsabilidade possa ser distribuída até desaparecer. Cada decisão necessita de um responsável claramente identificado e de um procedimento de escalonamento conhecido.

Infografia: exigir, testar e manter a segurança

A infografia resume o ciclo de vida em três compromissos fáceis de aplicar a qualquer projeto hospitalar. Exigir transforma os riscos em requisitos concretos. Testar transforma as promessas do caderno de encargos em evidências. Manter evita que uma configuração inicialmente aceite se torne obsoleta ou perca controlo ao longo do tempo.

Não são três ações independentes. O que não é exigido dificilmente poderá ser testado, e o que não é mantido deixará de oferecer garantias, mesmo que funcionasse corretamente no dia da receção.

Conclusão: comprar tecnologia é assumir o seu ciclo de vida

A cibersegurança dos equipamentos hospitalares não depende de uma única função nem pode ser totalmente delegada no fornecedor. Começa quando o hospital define as suas necessidades, continua durante a conceção da arquitetura e é sustentada através da manutenção, monitorização, testes e responsabilidades claras.

Nos blocos operatórios e nas áreas críticas, a questão relevante não é saber se um sistema «é seguro», mas como contribui para uma operação segura e verificável. As dependências que introduz, a forma como é atualizado, os registos que gera, como é recuperado e o que acontece quando o suporte termina são tão importantes como as suas funcionalidades.

Para a Tedisel Medical, esta abordagem amplia o grupo de conteúdos dedicado aos painéis técnicos, à arquitetura digital e à continuidade operacional. A integração do HERMES, Q Panel, Glass Panel e dos restantes equipamentos deve ser planeada como parte de um ambiente clínico coordenado, de fácil manutenção e preparado para evoluir.

Principais fontes técnicas: ENISA, 2026; Comissão Europeia; e NIST SP 1305.

Perguntas frequentes sobre cibersegurança hospitalar