Arquitectura de seguridad de productos sanitarios
Sytance · Actualizado
Una arquitectura de seguridad muestra cómo se protegen el producto sanitario y los sistemas conectados. Identifica las interfaces a las que podría llegar un atacante y explica dónde los controles restringen el acceso, protegen los datos o verifican las actualizaciones de software.
La arquitectura como evidencia
La FDA recomienda vistas de arquitectura que ayuden a los revisores a comprender la exposición del producto a ataques y la protección incorporada al sistema. En un expediente técnico de la UE, la misma información de diseño respalda los requisitos aplicables del MDR o del IVDR. La explicación reglamentaria puede variar, pero la arquitectura subyacente debe describir el producto sanitario real y su entorno previsto.
Por ejemplo, una conexión de asistencia remota puede cruzar desde la red de un proveedor de servicios hasta un hospital. La arquitectura debe mostrar qué endpoint autentica al técnico y qué parte del producto restringe las acciones de mantenimiento.
Límite del sistema
Identifique el producto sanitario y los sistemas externos de los que depende. Indique qué partes controla el fabricante y cuáles dependen de la organización sanitaria o de otro proveedor.
Límite de confianza
Marque los cambios de confianza o autoridad. Por ejemplo, un comando recibido desde una aplicación móvil debe comprobarse antes de que el producto permita modificar un ajuste clínico.
Vistas de arquitectura de la FDA
La guía final de la FDA de febrero de 2026 recomienda vistas de arquitectura cuya complejidad sea proporcional a la arquitectura del producto y al riesgo de ciberseguridad. Cada vista explica un aspecto distinto de cómo puede atacarse el sistema y cómo se protege.
Muestre el producto sanitario dentro del sistema completo que se utiliza para prestar su función prevista. Incluya los servicios conectados y la red del hospital o del domicilio cuando afecten a la seguridad. En sistemas complejos, utilice diagramas complementarios para explicar los protocolos y flujos de datos que no podrían leerse en la vista general.
Explique cómo un único compromiso podría afectar a varios productos o pacientes. Por ejemplo, un servicio central de monitorización comprometido podría interrumpir las alarmas de muchos monitores de cabecera. Muestre cómo limita el sistema esa propagación y mantiene o restablece las funciones afectadas.
Siga una actualización de software desde su origen aprobado hasta su instalación en el producto sanitario. Muestre cómo comprueba el producto su autenticidad e integridad, qué debe hacer el usuario y qué ocurre si falla la instalación. Identifique cualquier etapa que dependa de tecnología fuera del control del fabricante.
Describa una operación concreta que pueda afectar a la seguridad o la eficacia. En el caso de la configuración remota, muestre al usuario que realiza la solicitud, la ruta del comando y las comprobaciones de permisos previas al cambio del ajuste. Utilice vistas adicionales para las operaciones con actores o controles diferentes.
Vistas para el expediente técnico de la UE
El MDR y el IVDR no prescriben los nombres de vistas de la FDA. La información de arquitectura respalda la evaluación de la seguridad del software y la interacción del producto con su entorno informático previsto. Debe explicar las hipótesis de diseño que fundamentan la evaluación de riesgos y las condiciones que el usuario debe mantener.
- Una vista de flujo de datos muestra dónde pueden leerse o modificarse los datos clínicos y qué controles los protegen a lo largo de esa ruta.
- Una vista de interfaces identifica las conexiones permitidas y las comprobaciones que restringen su uso. Estos detalles respaldan los requisitos generales de seguridad y funcionamiento (GSPR) pertinentes.
- Una vista del entorno operativo explica la protección que se espera de la organización sanitaria, por ejemplo, restringir el segmento de red desde el que se puede acceder a un servicio de mantenimiento.
- Una vista de la vía de actualización explica cómo llega un parche probado a los productos previstos y cómo recuperarse de una instalación fallida.
MDCG 2019-16 Rev.1 explica cómo comparten fabricantes y organizaciones sanitarias la responsabilidad de una operación segura. La guía ayuda a relacionar las hipótesis de diseño con los requisitos informáticos mínimos y la información de seguridad suministrada con el producto sanitario.
Dependencias del sistema
El nivel de detalle de la arquitectura debe corresponderse con el sistema real del producto sanitario. Un producto local sencillo puede necesitar menos vistas que un sistema conectado a la nube, móvil, en red o gestionado como flota. Deben incluirse las dependencias que afecten a la seguridad del producto, aunque el sistema conectado lo gestione el cliente.
Servicios en la nube y remotos
Incluya un servicio remoto cuando el producto dependa de él para funcionar de forma segura. Por ejemplo, la pérdida de un servicio de identidad puede afectar a quién puede acceder al producto y a cómo se restablece el acceso local.
Vías de actualización
La arquitectura de actualización debe explicar toda la vía, desde la aprobación de la versión hasta el producto desplegado en campo, incluidas la autenticidad, la integridad, los fallos de implementación y la recuperación.
Uso móvil y doméstico
El teléfono del paciente y la red doméstica introducen controles que quizá no gestione el fabricante. Explique qué protecciones proporciona el propio producto y qué ajustes debe mantener el usuario.
Infraestructura clínica compartida
Un sistema central de monitorización o de información hospitalaria puede conectar numerosos productos. Muestre cómo el acceso a través de ese sistema compartido podría afectar a otros productos o pacientes.
Vincular la arquitectura con los controles del riesgo
Para cada interfaz importante, la arquitectura debe ayudar al revisor a localizar la amenaza que se aborda y la prueba que verifica la protección. Si el diseño depende de una restricción de la red hospitalaria, la información para el usuario debe describirla para que pueda mantenerse durante el uso.