Arquitetura de segurança dos dispositivos médicos

Sytance · Atualizado 6 de outubro de 2026

Uma arquitetura de segurança mostra como o dispositivo médico e os sistemas ligados estão protegidos. Identifica as interfaces a que um atacante poderá aceder e explica onde os controlos restringem o acesso, protegem os dados ou verificam as atualizações de software.

A arquitetura como evidência

A FDA recomenda vistas da arquitetura que ajudem os revisores a compreender a exposição do dispositivo a ataques e a proteção incorporada no sistema. Num ficheiro técnico da UE, as mesmas informações de conceção sustentam os requisitos aplicáveis do MDR ou do IVDR. A explicação regulamentar pode ser diferente, mas a arquitetura subjacente deve descrever o dispositivo efetivo e o respetivo ambiente previsto.

Por exemplo, uma ligação de assistência remota pode atravessar a rede de um prestador de serviços até um hospital. A arquitetura deve mostrar que endpoint autentica o técnico e que parte do dispositivo restringe as ações de manutenção.

Limite do sistema

Identifique o dispositivo e os sistemas externos de que depende. Indique que partes são controladas pelo fabricante e quais dependem da organização de saúde ou de outro prestador.

Limite de confiança

Assinale as alterações de confiança ou autoridade. Por exemplo, um comando recebido de uma aplicação móvel tem de ser verificado antes de o dispositivo permitir que altere uma definição clínica.

Vistas de arquitetura da FDA

A orientação final da FDA, de fevereiro de 2026, recomenda vistas de arquitetura proporcionais à arquitetura do dispositivo e ao risco de cibersegurança. Cada vista explica um aspeto diferente da forma como o sistema pode ser atacado e protegido.

Vista global do sistema (Global System View)

Vista de danos para vários doentes (Multi-Patient Harm View)

Vista da capacidade de atualização e aplicação de patches (Updateability and Patchability View)

Vistas dos casos de utilização de segurança (Security Use Case Views)

Vistas do ficheiro técnico da UE

O MDR e o IVDR não prescrevem os nomes das vistas da FDA. As informações da arquitetura sustentam a avaliação da segurança do software e da interação do dispositivo com o seu ambiente informático previsto. Devem explicar os pressupostos de conceção subjacentes à avaliação de riscos e as condições que o utilizador tem de manter.

Uma vista do fluxo de dados mostra onde os dados clínicos podem ser lidos ou alterados e que controlos os protegem ao longo desse percurso.
Uma vista de interfaces identifica as ligações permitidas e as verificações que restringem a sua utilização. Estes detalhes sustentam os requisitos gerais de segurança e desempenho (GSPR) pertinentes.
Uma vista do ambiente operacional explica a proteção esperada da organização de saúde, por exemplo, restringir o segmento de rede que pode aceder a um serviço de manutenção.
Uma vista da via de atualização explica como um patch testado chega aos dispositivos previstos e como recuperar de uma instalação sem êxito.

A MDCG 2019-16 Rev.1 explica como os fabricantes e as organizações de saúde partilham a responsabilidade pelo funcionamento seguro. A orientação ajuda a relacionar os pressupostos de conceção com os requisitos informáticos mínimos e as informações de segurança fornecidas com o dispositivo.

Dependências do sistema

A profundidade da arquitetura deve corresponder ao sistema efetivo do dispositivo. Um dispositivo local simples pode necessitar de menos vistas do que um sistema ligado à nuvem, móvel, em rede ou gerido como frota. As dependências que afetem a segurança ou a cibersegurança do dispositivo devem ser incluídas, mesmo quando o cliente opera o sistema ligado.

Serviços na nuvem e remotos

Inclua um serviço remoto quando o dispositivo depender dele para funcionar de forma segura. Por exemplo, a perda de um serviço de identidade pode afetar quem consegue aceder ao dispositivo e como é restabelecido o acesso local.

Vias de atualização

A arquitetura das atualizações deve explicar o percurso completo, desde a aprovação da versão até ao dispositivo instalado no terreno, incluindo autenticidade, integridade, falhas de implementação e recuperação.

Utilização móvel e doméstica

O telemóvel do doente e a rede doméstica introduzem controlos que o fabricante poderá não gerir. Explique que proteções são fornecidas pelo próprio dispositivo e que definições o utilizador tem de manter.

Infraestrutura clínica partilhada

Um sistema central de monitorização ou de informação hospitalar pode ligar muitos dispositivos. Mostre de que forma o acesso através desse sistema partilhado pode afetar outros dispositivos ou doentes.

Relacionar a arquitetura com os controlos de risco

Para cada interface importante, a arquitetura deve ajudar o revisor a localizar a ameaça abordada e o ensaio que verifica a proteção. Se a conceção depender de uma restrição da rede hospitalar, as informações para o utilizador têm de a descrever para que possa ser mantida durante a utilização.