La clasificación de riesgo de un producto sanitario software se realiza mediante la evaluación de la aplicabilidad de las reglas de clasificación del Anexo VIII del Reglamento de Productos Sanitarios (MDR) 2017/745. La particularidad de un software es que su fabricante también debe determinar su clase de seguridad mediante la norma internacional ISO 62304 Software de dispositivos médicos. Procesos del ciclo de vida del software.
CLASIFICACIÓN DE RIESGO SEGÚN MDR
En publicaciones anteriores vimos como la Regla 11 nos ayuda a describir y a categorizar la importancia de la información proporcionada por el producto sanitario software para la decisión sanitaria junto con la situación sanitaria y condición del paciente. La tabla del Anexo III de la guía MDCG 2019-11, alineada con la IMDRF Risk Framework, muestra el resultado de combinar estos dos factores. De esta forma (a excepción de la Clase I):
- La Clase III se alinea con la Categoría IV.
- La Clase IIb se alinea con la Categoría III.
- La Clase IIa se alinea con la Categoría II y I.
CLASE DE SEGURIDAD SEGÚN ISO 62304
La norma internacional por excelencia del producto sanitario software es la ISO 62304. En ella se establecen las técnicas, herramientas y actividades relacionadas con el proceso de desarrollo del software a lo largo de su ciclo de vida. El primer paso será establecer la clasificación de riesgo. Ésta determinará el nivel de detalle en la documentación y evidencia para las diferentes etapas del ciclo de vida. Diferenciamos tres clases de seguridad:
- Clase A: el software no puede contribuir a una situación peligrosa o el software puede contribuir a una situación peligrosa que no resulte en un riesgo inaceptable después de considerar las medidas externas de control del riesgo aplicadas al software.
- Clase B: el software puede contribuir a una situación peligrosa que resulte en un riesgo inaceptable después de considerar las medidas externas de control del riesgo aplicadas al software y el posible daño resultante sea una lesión no-seria.
- Clase C: el software puede contribuir a una situación peligrosa que resulte en un riesgo inaceptable después de considerar las medidas externas de control del riesgo aplicadas al software y el posible daño resultante sea una lesión seria.
Vemos que en las clases de seguridad el riesgo residual (riesgo que permanece después de aplicar medidas de control) del producto sanitario software es clave. Cabe mencionar que estas medidas de control externas, según la normativa, pueden ser: un hardware, un software independiente, o los procedimientos de asistencia sanitaria, entre otros.
CONCLUSIÓN
Como conclusión, recordamos que la clasificación de un producto sanitario software se regirá por su finalidad prevista y su riesgo inherente. Una vez implementadas y verificadas las medidas de control (internas y externas), debemos reevaluar los riesgos resultantes y analizar si estos riesgos residuales podrán protagonizar o contribuir a situaciones peligrosas. De esta forma, determinaremos la clase de seguridad del software.
En futuras publicaciones, presentaremos en más detalle los aspectos requeridos para documentar el ciclo de vida del software según su clase de seguridad.