Tópico 4.4 — Dispositivos conectados, IoT e engenharia clínica

Na saúde e nos cuidados, o dispositivo conectado é onde o software encontra o corpo do paciente; por isso a forma como você gere a frota de bombas, monitores, escâneres e dispositivos vestíveis é uma decisão de segurança clínica, de cibersegurança e de confiança pública, e não uma linha de orçamento de instalações.

Por que isso importa na saúde e nos cuidados#

Um hospital moderno funciona sobre máquinas que tocam diretamente os pacientes e conversam com a rede o tempo todo. Bombas de infusão dosam medicamentos em microlitros, ventiladores mantêm as pessoas respirando, monitores vigiam sinais vitais, escâneres de imagem emitem radiação ionizante e sistemas de gestão predial mantêm a temperatura das geladeiras de vacinas. Uma parcela crescente deles está conectada: enviam dados aos prontuários, puxam configurações de servidores e expõem interfaces de gerenciamento. Quando um se comporta de modo inesperado, a falha não é uma indisponibilidade inconveniente — pode ser um erro de dose, um alarme perdido ou uma imagem corrompida que muda um diagnóstico.

É por isso que a gestão de dispositivos se situa na interseção de três deveres que você já carrega. É um dever de segurança clínica, porque uma falha de dispositivo ou uma correção ruim pode prejudicar um paciente (ver Tópico 1.6 — Segurança clínica e gestão de riscos). É um dever de cibersegurança, porque o equipamento clínico conectado é uma das maiores e menos governadas superfícies de ataque do parque (ver Tópico 1.7 — Governança da informação, proteção de dados e cibersegurança). E é um dever regulatório, porque os dispositivos médicos são produtos regulados com obrigações pós-comercialização que recaem em parte sobre você como operador.

O que está em jogo se alarga, e não se estreita. O cuidado está indo para a casa das pessoas por meio de dispositivos vestíveis e monitoramento remoto; assim, o "parque de dispositivos" agora inclui equipamentos que você não possui, em redes que você não controla. Os dispositivos duram muito mais do que o software dentro deles, de modo que um escâner comprado para uma vida clínica de quinze anos pode rodar um sistema operacional que perdeu o suporte de segurança depois de cinco. Os grupos de ransomware aprenderam que a tecnologia clínica é frágil, sem correções e crítica para a missão — uma combinação lucrativa. Tratar os dispositivos conectados como problema de outra pessoa é como as organizações descobrem, no meio de um incidente, que ninguém é dono deles.

Conceitos centrais#

Um dispositivo médico é qualquer instrumento, aparelho ou software destinado pelo fabricante a um fim médico — diagnóstico, monitoramento, tratamento ou prevenção — que não alcança seu efeito por meio de farmacologia. Um dispositivo médico conectado acrescenta uma interface de rede: envia ou recebe dados ou pode ser gerenciado remotamente. A Internet das Coisas Médicas (IoMT) é a aplicação em saúde da Internet das Coisas (IoT) mais ampla — a população de sensores e objetos cotidianos que se conectam a redes e trocam dados. Num ambiente de cuidados, a IoMT abrange monitores de beira de leito, bombas inteligentes, dispositivos vestíveis, sensores domiciliares e o middleware de nível clínico que os costura.

A engenharia clínica é a especialidade, situada dentro da engenharia biomédica, responsável pelo uso seguro e eficaz da tecnologia médica numa organização de saúde. No NHS essas equipes costumam ser chamadas de engenharia médica, física médica ou Engenharia Eletrônica e Biomédica (EBME). A gestão de dispositivos médicos é sua disciplina central: manter um inventário preciso, manutenção preventiva planejada, calibração, reparo, alertas de segurança, treinamento e desativação controlada no fim da vida.

A tecnologia operacional (OT) é o hardware e o software que monitoram ou controlam processos e equipamentos físicos, distinta da tecnologia da informação (TI) convencional, que processa dados de negócio. Os dispositivos clínicos e os sistemas prediais são OT: têm efeitos físicos no mundo real, ciclos de vida longos e restrições (disponibilidade, certificação, comportamento em tempo real) que tornam as práticas comuns de TI — reiniciar, corrigir, substituir — arriscadas ou proibidas sem a bênção do fabricante. A superfície de ataque (attack surface) é a soma dos pontos em que um atacante poderia entrar ou afetar um sistema; os dispositivos conectados a ampliam drasticamente, porque cada um é um pequeno computador, muitas vezes não endurecido, na sua rede.

Dois controles retornam ao longo deste tópico. A segmentação de rede é a prática de dividir uma rede em zonas isoladas para que um comprometimento numa não se espalhe livremente para as outras — a mitigação isolada mais eficaz para equipamento clínico que não pode ser corrigido. A visibilidade de ativos é simplesmente saber o que se tem: cada dispositivo, sua localização, firmware, propriedade, comportamento de rede e estado de suporte. Não se pode proteger, corrigir ou aposentar o que não se vê.

Por fim, o quadro regulatório. No Reino Unido, a Medicines and Healthcare products Regulatory Agency (MHRA) regula os dispositivos médicos, e a vigilância pós-comercialização — monitorar a segurança e o desempenho depois que um produto está no mercado — é uma obrigação compartilhada entre fabricantes e os operadores que usam e reportam sobre os dispositivos. A tecnologia vestível e o monitoramento remoto de pacientes estendem todos esses conceitos para além do edifício, até a casa e o bolso do paciente.

Boas práticas#

1. Construa e mantenha um inventário de dispositivos autoritativo. Você não consegue gerir, proteger nem aposentar o que não contou. Una o banco de dados de ativos da engenharia clínica com os dados de descoberta de rede, para que o inventário registre não apenas marca, modelo e localização, mas versão de firmware, sistema operacional, comportamento de rede, fluxos de dados, propriedade e estado de suporte. Trate o inventário como um sistema vivo de segurança, com um responsável nomeado, reconciliado continuamente com o que de fato está no fio, e não uma planilha atualizada uma vez por ano para a auditoria.

2. Reúna a TI, a engenharia clínica e a cibersegurança num único fórum de governança. Esses dispositivos caem entre três equipes, e as lacunas entre elas são exatamente onde moram os incidentes. Estabeleçam um grupo conjunto de segurança de dispositivos médicos, com direitos claros de decisão sobre integração, correções, segmentação e desativação, e deem-lhe uma ligação permanente com a função de segurança clínica. Os engenheiros clínicos entendem o dispositivo e o risco ao paciente; a equipe de segurança entende a ameaça de rede; nenhuma pode agir com segurança sem a outra.

3. Segmente a rede e adote por padrão a menor conectividade. A maioria dos dispositivos clínicos não pode ser endurecida nem corrigida no seu cronograma; contenha-os, portanto. Coloque os dispositivos em zonas segmentadas com fluxos rigidamente controlados, permitindo apenas as conexões de que o dispositivo genuinamente precisa e negando o restante, para que um comprometimento não atravesse o parque. A segmentação é o controle que permite continuar operando um dispositivo clinicamente seguro, mas digitalmente fraco — ganha tempo que as correções sozinhas jamais ganharão.

4. Trate a aplicação de correções como uma mudança de segurança clínica, de propriedade conjunta com o fabricante. Uma correção num dispositivo regulado é uma mudança num produto crítico para a segurança, e aplicar uma atualização não validada pode ser tão perigoso quanto deixar uma brecha aberta. Acompanhem os avisos de segurança dos fabricantes e as notificações de segurança de campo da MHRA, validem as atualizações frente à orientação do fabricante e agendem-nas por meio do controle clínico de mudanças, com planos de recuo. Onde um dispositivo não pode ser corrigido, registrem o risco residual aceito e os controles compensatórios, em vez de fingir que a lacuna não existe.

5. Planeje todo o ciclo de vida, inclusive o fim da vida, antes de comprar. A vida clínica de um dispositivo rotineiramente sobrevive ao suporte de software do fornecedor, criando anos de risco sem suporte e exposto à internet. Na aquisição, exijam uma lista de materiais de software, um compromisso declarado de suporte e correções, funcionalidades de segurança desde a concepção e uma data clara de fim de suporte, e orcem a substituição frente a essa data, e não à mecânica (ver Tópico 6.3 — Aquisições e contratações). A desativação também é uma etapa controlada: apaguem os dados dos pacientes, revoguem as credenciais e o acesso à rede e atualizem o inventário, porque um monitor esquecido num armário ainda é uma via de entrada ativa.

6. Leve os dados dos dispositivos ao prontuário de forma segura e significativa. O valor dos dispositivos conectados se realiza quando as leituras fluem para o prontuário clínico com exatidão, com o paciente, as unidades e os carimbos de data e hora certos e com proveniência clara. Usem padrões reconhecidos de interoperabilidade e middleware de integração, em vez de ligações ponto a ponto sob medida, e validem que uma leitura de dispositivo corresponde ao paciente correto todas as vezes (ver Tópico 4.3 — Interoperabilidade e padrões de dados). Um sinal vital atribuído ao paciente errado, ou uma unidade ambígua, é um perigo de segurança clínica disfarçado de conveniência de integração.

7. Projete o monitoramento remoto e os dispositivos vestíveis para a casa, e não para a enfermaria. Quando o cuidado vai para o domicílio, você herda dispositivos em banda larga doméstica, compartilhados por famílias, carregados de forma intermitente e usados por pessoas doentes. Projetem para lacunas de conectividade, escalação clara quando as leituras ultrapassam limiares, inclusão digital e consentimento explícito sobre o que é coletado e quem age sobre isso (ver Tópico 1.9 — Inclusão digital e acessibilidade e Tópico 3.3 — Serviços digitais voltados a pacientes e cidadãos). Sejam honestos sobre a responsabilização clínica: um fluxo de leituras domiciliares que ninguém tem recursos para observar é falsa tranquilização, e não um serviço.

8. Ensaie a perda dos seus dispositivos e reporte as falhas para cima. Presumam que uma classe de dispositivos um dia estará indisponível — por ransomware, um recolhimento ou uma falha de rede — e ensaiem o recurso clínico para que a equipe não precise improvisar durante um incidente (ver Tópico 3.9 — Continuidade de negócios e recuperação de desastres). Em paralelo, levem falhas de dispositivos, quase-acidentes e eventos adversos à vigilância pós-comercialização da MHRA por meio do esquema Yellow Card, porque os seus relatos são como as falhas sistêmicas de dispositivos são pegas antes de prejudicar outra pessoa.

Perguntas para discutir com a sua equipe#

1. Quem de fato é dono da frota de dispositivos conectados ao longo de toda a sua vida — e onde estão hoje as lacunas entre a TI, a engenharia clínica e a cibersegurança? Isto importa porque os dispositivos sem dono são os que ficam sem correções, sem monitoramento e sem mapeamento até que um incidente force a pergunta. Na maioria das organizações, a engenharia clínica é dona do registro de ativos, a TI é dona da rede, a segurança é dona da ameaça e ninguém é dono do dispositivo como um todo conectado, regulado e voltado ao paciente. Debatam onde ficam as costuras: quem decide que um dispositivo pode entrar na rede, quem valida uma correção, quem aprova a desativação e quem responde quando um dispositivo é, ao mesmo tempo, um instrumento crítico para a segurança e um computador vulnerável. Considerem se o seu fórum de governança tem direitos de decisão e orçamento reais ou é uma conversa que escala tudo e não resolve nada. Uma boa resposta, honesta, nomeia o responsável por cada etapa do ciclo de vida, admite onde hoje a resposta é "ninguém" e se compromete a fechar costuras específicas, em vez de reiterar que a colaboração é importante.

2. Quanto do nosso parque conectado conseguimos de fato enxergar, e quão confiantes estamos nesse número? Não se pode segmentar, corrigir nem aposentar dispositivos que não foram contados, e, no entanto, a maioria das organizações descobre durante um incidente que seu inventário subestima a realidade por ampla margem — dispositivos paralelos, equipamento instalado por fornecedores, equipamento esquecido em depósitos e dispositivos domiciliares que ninguém catalogou. Discutam como o seu inventário é construído e reconciliado: é uma planilha estática ou é continuamente confrontado com o que a descoberta de rede vê no fio? Sondem a honestidade da confiança da equipe — uma contagem de aparência precisa, sem processo de reconciliação, é mais perigosa do que um "não sabemos por completo" admitido, porque gera falsa garantia. Considerem as categorias mais difíceis: sistemas de gestão predial, equipamentos gerenciados por terceiros e dispositivos nas casas dos pacientes. Uma boa resposta declara um número realista de cobertura, descreve como as discrepâncias são encontradas e fechadas e trata o inventário como um sistema crítico para a segurança, com responsável nomeado, e não um artefato de conformidade.

3. O que acontece clinicamente quando uma classe desses dispositivos fica indisponível, insegura ou comprometida — e já ensaiamos isso alguma vez? Os dispositivos conectados falham como classe, e não um de cada vez: um evento de ransomware, um bug de firmware, um recolhimento ou uma indisponibilidade de rede pode derrubar todas as bombas ou monitores de um tipo ao mesmo tempo. Discutam quais classes de dispositivos causariam mais dano se perdidas, qual é o recurso clínico manual ou alternativo e se a equipe da linha de frente de fato o conhece ou estaria improvisando sob pressão. Tragam à tona a concessão entre disponibilidade e segurança: a pressão para manter funcionando clinicamente um dispositivo frágil versus o risco de deixar uma brecha conhecida aberta, e quem tem poder para tomar essa decisão. Considerem se vocês sequer detectariam um dispositivo comprometido se comportando de modo sutilmente errado — um monitor que reporta leituras plausíveis, mas falsas, é mais difícil de pegar do que um que apaga. Uma boa resposta identifica as classes de maior dano, confirma que existe um recurso ensaiado e dotado de recursos para cada uma e é franca sobre os pontos cegos de detecção que permanecem.

4. Estamos comprando e orçando a vida de software de um dispositivo, ou apenas a sua vida mecânica? Um escâner pode ter uma vida clínica de quinze anos enquanto o sistema operacional dentro dele perde o suporte de segurança depois de cinco; assim, uma decisão de aquisição tomada hoje compromete silenciosamente vocês com uma década de risco sem possibilidade de correção, a menos que alguém planeje para isso. Discutam se o seu processo de aquisição trata uma lista de materiais de software, um compromisso declarado de correções, funcionalidades de segurança desde a concepção e uma data explícita de fim de suporte como termos de contrato ou como desejáveis que caem sob pressão de preço. Sondem quem detém o orçamento de substituição e frente a que data ele é fixado — o ponto de falha mecânica ou o ponto de fim de suporte de software, que chega anos antes. Considerem os casos incômodos já no parque: dispositivos comprados antes de alguém fazer essas perguntas, agora anos além do suporte, sem financiamento de substituição à vista. Tragam à tona a tensão entre as equipes clínicas que querem a capacidade mais nova, as finanças que querem espremer os ativos por toda a sua vida física e a segurança que vê o passivo crescente. Uma resposta honesta liga a decisão de compra ao custo ao longo da vida, nomeia quem é dono do orçamento de substituição e admite onde o parque já carrega risco de obsolescência de software não financiado.

5. Para os dispositivos que estão indo para as casas dos pacientes, quem de fato está observando as leituras — e projetamos para as pessoas que os usam? O monitoramento remoto e os dispositivos vestíveis deslocam o parque de dispositivos para banda larga doméstica, compartilhada com famílias, carregada de forma intermitente e operada por pessoas doentes, de modo que as suposições da enfermaria sobre conectividade, controle e suporte já não valem. Discutam se uma equipe clínica nomeada e dotada de recursos responde por agir sobre as leituras domiciliares ou se os dados fluem para um painel que ninguém é financiado para observar — uma falsa tranquilização travestida de serviço. Tragam à tona a tensão da inclusão digital: um programa de monitoramento domiciliar pode excluir em silêncio quem não tem banda larga confiável, um dispositivo adequado ou a confiança para usá-lo, ampliando as próprias desigualdades que pretendia estreitar (ver Tópico 1.9 — Inclusão digital e acessibilidade). Considerem o consentimento e a clareza da responsabilização — pacientes e cuidadores precisam saber o que é coletado, quem vê e o que acontece quando uma leitura ultrapassa um limiar. Pesem a atração por escalar esses programas rapidamente frente ao dever de torná-los seguros e equitativos. Uma boa resposta confirma quem observa e escala, é franca sobre os riscos de inclusão e trata os dispositivos domiciliares como um serviço clínico governado, e não um conveniente fluxo de dados.

6. Quando uma leitura de dispositivo chega ao prontuário clínico, temos certeza de que é o valor certo, nas unidades certas, para o paciente certo? O valor clínico de um dispositivo conectado só se realiza quando seus dados chegam ao prontuário com exatidão e, no entanto, cada integração é também uma nova chance de atribuir um sinal vital ao paciente errado ou de perder as unidades e a proveniência por trás de um número. Discutam se os dados dos dispositivos fluem por padrões de interoperabilidade validados e middleware de integração com verificações explícitas de correspondência de pacientes, ou por ligações ponto a ponto sob medida que ninguém entende por completo (ver Tópico 4.3 — Interoperabilidade e padrões de dados). Sondem os modos de falha que parecem conveniência, mas são perigos de segurança: uma unidade ambígua, uma leitura com horário errado, um valor gravado no paciente anterior ainda conectado à beira do leito. Considerem como vocês sequer detectariam tal erro, dado que um número plausível, mas errado, é muito mais perigoso do que uma lacuna óbvia. Tragam à tona a concessão entre a velocidade de conectar um novo dispositivo e o trabalho de garantia que torna seus dados confiáveis. Uma resposta honesta descreve como a correspondência de pacientes e a integridade das unidades são validadas de ponta a ponta, nomeia quem é dono dessa garantia e trata uma leitura atribuída ao paciente errado como o incidente de segurança clínica que é, e não um incômodo de integração.

Na prática: um exemplo de saúde e cuidados#

O Meadowfield NHS Foundation Trust opera um hospital de agudos de porte médio e, cada vez mais, uma enfermaria virtual que monitora pacientes em casa. Depois que um hospital par sofreu um incidente de ransomware que se espalhou por dispositivos clínicos não gerenciados, o conselho do Meadowfield faz uma pergunta simples: quantos dispositivos conectados temos e quem é dono deles? A resposta honesta é que ninguém sabe dizer. O banco de dados da engenharia clínica lista cerca de 6.000 ativos; a ferramenta de descoberta passiva da equipe de rede vê mais perto de 9.000 coisas que se comportam como dispositivos. A diferença é o problema.

O hospital monta um grupo conjunto de segurança de dispositivos médicos, presidido em conjunto pelo Chefe de Engenharia Clínica e pelo Diretor de Segurança da Informação, com a presença do Responsável pela Segurança Clínica. Sua primeira entrega é um inventário reconciliado: unem as duas fontes de dados, caçam as discrepâncias e encontram bombas de infusão na rede geral, um escâner de TC rodando um sistema operacional três versões além do fim de suporte e um conjunto de controladores de gestão predial das geladeiras da farmácia que a TI jamais havia catalogado. Cada achado é registrado com uma classificação de risco clínico, e não apenas técnico.

Não podem substituir o escâner neste ano; então o contêm: ele passa para uma zona rigidamente segmentada que permite apenas os fluxos para o seu arquivo de imagens e para o gateway de suporte do fornecedor, e o risco residual aceito é registrado e aprovado pela governança clínica. As bombas são inscritas num ciclo gerido de correções, validado frente aos avisos do fabricante e agendado pelo controle de mudanças. Para a enfermaria virtual, o grupo insiste que os dispositivos de monitoramento domiciliar reportem ao prontuário por middleware de integração validado, com verificações de correspondência de pacientes, e que uma equipe clínica nomeada tenha recursos para observar e escalar as leituras — e não um painel sem dono.

Seis meses depois, um fornecedor emite uma notificação de segurança de campo sobre um defeito de firmware de um monitor. Como o inventário agora é preciso e reconciliado, o Meadowfield identifica todas as unidades afetadas em uma hora, aplica a correção validada pelo controle de mudanças e reporta o seu próprio quase-acidente relacionado à MHRA pelo esquema Yellow Card. O trabalho foi pouco glamoroso — um inventário, um fórum, um projeto de segmentação —, mas transformou um risco invisível e sem dono em um risco gerido.

Perspectivas setoriais#

Startup#

Uma startup de saúde digital que entrega um dispositivo vestível ou de monitoramento domiciliar está do lado do fabricante da linha regulatória, e seus modos de trabalho precisam refletir isso desde o primeiro dia. Construa com segurança desde a concepção: firmware assinado, um caminho de atualização pelo ar, uma lista de materiais de software e um plano de correção de dispositivos já em campo — retroajustar a segurança depois de uma rodada de financiamento é muito mais difícil. Entenda que você carrega deveres de vigilância pós-comercialização e obrigações da MHRA que não diminuem para uma equipe pequena e que um hospital cliente avaliará a sua postura de segurança antes de deixar o seu dispositivo se aproximar da rede. Sua vantagem competitiva não é só o dispositivo, mas a promessa crível e documentada de que você o apoiará e protegerá por toda a sua vida clínica.

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso ou uma clínica de unidade única — opera uma frota modesta, mas real, de equipamentos conectados: monitores de pressão, aparelhos de ECG, sensores de geladeira de vacinas, espirômetros e o filete crescente de dispositivos vestíveis de pacientes, tudo numa rede que nenhuma equipe de TI dedicada observa. Aplicam-se os mesmos deveres da MHRA, de cibersegurança e de segurança clínica de um grande hospital, mas não há departamento de engenharia clínica e, muitas vezes, nenhuma TI interna; assim, comece simplesmente sabendo o que tem: um inventário curto e honesto, com marca, firmware e estado de suporte, vale mais do que um sistema elaborado que você não consegue manter. Apoie-se fortemente em seus fornecedores e parceiros de serviços gerenciados — insista que contratos de manutenção, responsabilidades de correção e datas de fim de suporte estejam por escrito, porque você depende deles para uma capacidade que não consegue dotar de pessoal. Use o momento da compra como seu principal ponto de controle, já que substituir um dispositivo obsoleto costuma ser mais realista para você do que endurecê-lo no lugar. Mantenha os itens de maior dano — uma geladeira com vacinas da cadeia fria, um monitor em que um clínico confia — fora da rede de escritório plana, onde um comprometimento poderia alcançar tudo, mesmo que a segmentação completa esteja além do seu alcance.

Grande organização#

Um grande hospital do NHS ou um grupo hospitalar gerencia milhares de dispositivos de dezenas de fornecedores num parque extenso e de longa duração, e seu desafio é a coordenação e a escala. O objetivo realista é um inventário reconciliado, uma segmentação disciplinada e um fórum conjunto de governança que atravesse a engenharia clínica, a TI e a segurança, com autoridade real — e não a aplicação perfeita de correções em toda parte, que as restrições dos fornecedores tornam impossível. Incorpore a segurança de dispositivos à aquisição, para que compromissos de suporte, funcionalidades de segurança desde a concepção e datas de fim de suporte sejam termos de contrato, e alinhe o orçamento de substituição à vida de software, e não à mecânica (ver Tópico 4.0 — Arquitetura técnica, nuvem e sistemas legados). Nessa escala, os maiores ganhos vêm de um pequeno número de controles em todo o parque feitos de modo consistente, e não de heroísmo em dispositivos individuais.

Governo#

Um órgão nacional ou regional — NHS England, um departamento de saúde descentralizado, a MHRA — molda o ambiente em que todo operador trabalha. Define padrões de segurança de dispositivos e marcos de aquisição, conduz inteligência de ameaças e alertas nacionais para que uma vulnerabilidade encontrada num hospital proteja todos, e regula os dispositivos e sua vigilância pós-comercialização. Sua alavancagem é tornar a segurança desde a concepção e o suporte ao ciclo de vida o padrão do mercado por meio de normas e poder de compra, para que os hospitais individuais não negociem cada um a segurança a partir de uma posição fraca. O governo também carrega o dever de equidade: garantir que os programas de monitoramento domiciliar e de dispositivos vestíveis não ampliem a divisão digital e que o relato de segurança suba, de modo que falhas sistêmicas de dispositivos sejam pegas nacionalmente, e não redescobertas hospital a hospital (ver Tópico 9.1 — Trabalho com governos locais e nacionais).

Modos de falha comuns#

• O inventário que mente. Uma planilha arrumada, reconciliada pela última vez há um ano, dá falsa confiança; os dispositivos que prejudicam você são os que ela nunca listou. Reconcilie continuamente com a descoberta de rede.
• Dispositivos na terra de ninguém entre equipes. Quando a TI diz que o equipamento é da engenharia clínica e a engenharia clínica diz que a rede é da TI, ninguém corrige, segmenta nem monitora. Atribua propriedade de ponta a ponta.
• Paralisia ou imprudência na aplicação de correções. Ambos os extremos prejudicam pacientes — nunca atualizar deixa brechas conhecidas abertas; aplicar atualizações não validadas pode quebrar um dispositivo crítico para a segurança. Encaminhe as correções pelo controle clínico conjunto de mudanças.
• Comprar pela vida mecânica, esquecendo a vida de software. Um escâner de quinze anos com um sistema operacional com cinco anos de suporte vira um passivo sem possibilidade de correção. Oriente a substituição pelo fim do suporte de software.
• Redes planas. Dispositivos conectados na rede geral deixam um único comprometimento alcançar tudo. Segmente por padrão.
• Monitoramento domiciliar sem ninguém observando. Um fluxo de leituras de dispositivos vestíveis sobre o qual nenhum clínico tem recursos para agir é falsa tranquilização e um risco de governança, e não um serviço.
• Desativação que não desativa. Um dispositivo aposentado ainda na rede, com credenciais antigas e dados de pacientes, é uma via de ataque ativa. Apague, revogue, desconecte e atualize o inventário.

Modelo de maturidade#

Lista de verificação#

• Existe um inventário de dispositivos autoritativo, reconciliado continuamente com a descoberta de rede, com responsável nomeado.
• Um fórum conjunto de TI, engenharia clínica e cibersegurança tem direitos reais de decisão sobre integração, correções, segmentação e desativação.
• Os dispositivos conectados ficam em zonas de rede segmentadas que permitem apenas os fluxos de que genuinamente precisam.
• As correções e atualizações de firmware de dispositivos regulados são validadas e encaminhadas pelo controle clínico de mudanças, com planos de recuo.
• Os contratos de aquisição exigem uma lista de materiais de software, funcionalidades de segurança desde a concepção e uma data declarada de fim de suporte.
• Os orçamentos de substituição são alinhados à vida de suporte de software, e não apenas à vida mecânica.
• A desativação apaga os dados de pacientes, revoga credenciais e acesso à rede e atualiza o inventário.
• Os dados dos dispositivos chegam ao prontuário clínico por integração validada, com verificações de correspondência de pacientes e de unidades.
• Os programas de monitoramento domiciliar e de dispositivos vestíveis têm escalação clínica dotada de recursos, consentimento explícito e inclusão desde a concepção.
• O recurso clínico para a perda de cada classe de dispositivos de alto dano está documentado e ensaiado.
• As falhas, quase-acidentes e eventos adversos de dispositivos são reportados à MHRA pelo esquema Yellow Card.

Fontes-chave#

• MHRA — Medical devices: guidance for manufacturers, operators and users e o esquema de relato Yellow Card para incidentes adversos e notificações de segurança de campo.
• NHS England / NHS Digital — Data Security and Protection Toolkit e orientações de segurança de rede e de dispositivos para organizações de saúde e cuidados.
• NCSC (National Cyber Security Centre) — orientações sobre tecnologia operacional, segmentação de rede e proteção de dispositivos conectados.
• NHS England / normas IEC — boas práticas de engenharia clínica e de gestão de dispositivos médicos (incluindo a IEC 80001 para a gestão de riscos de redes de TI que incorporam dispositivos médicos).
• NICE — Evidence Standards Framework for Digital Health Technologies e orientações sobre monitoramento remoto e dispositivos vestíveis.
• Institute of Physics and Engineering in Medicine (IPEM) — orientações profissionais para a engenharia clínica e biomédica.

Referências#

1. Medical device — Wikipedia — https://en.wikipedia.org/wiki/Medical_device
2. Internet of things — Wikipedia — https://en.wikipedia.org/wiki/Internet_of_things
3. Clinical engineering — Wikipedia — https://en.wikipedia.org/wiki/Clinical_engineering
4. Biomedical engineering — Wikipedia — https://en.wikipedia.org/wiki/Biomedical_engineering
5. Operational technology — Wikipedia — https://en.wikipedia.org/wiki/Operational_technology
6. Network segmentation — Wikipedia — https://en.wikipedia.org/wiki/Network_segmentation
7. Attack surface — Wikipedia — https://en.wikipedia.org/wiki/Attack_surface
8. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
9. Postmarketing surveillance — Wikipedia — https://en.wikipedia.org/wiki/Postmarketing_surveillance
10. Wearable technology — Wikipedia — https://en.wikipedia.org/wiki/Wearable_technology
11. Remote patient monitoring — Wikipedia — https://en.wikipedia.org/wiki/Remote_patient_monitoring
12. Infusion pump — Wikipedia — https://en.wikipedia.org/wiki/Infusion_pump
13. Medicines and Healthcare products Regulatory Agency — Medical devices: guidance and Yellow Card reporting — GOV.UK — https://www.gov.uk/government/organisations/medicines-and-healthcare-products-regulatory-agency
14. National Cyber Security Centre — Guidance on operational technology and device security — NCSC — https://www.ncsc.gov.uk/
15. NHS England — Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/
16. National Institute for Health and Care Excellence — Evidence Standards Framework for Digital Health Technologies — NICE — https://www.nice.org.uk/about/what-we-do/our-programmes/evidence-standards-framework-for-digital-health-technologies
17. Institute of Physics and Engineering in Medicine — Clinical and biomedical engineering guidance — IPEM — https://www.ipem.ac.uk/