Qué exige la IEC 62304 al software médico

El monitor de signos vitales había pasado las pruebas eléctricas, las de compatibilidad electromagnética y la validación clínica. En la auditoría, el auditor pidió el plan de desarrollo del firmware, la clase de seguridad asignada al software, la lista de componentes de terceros y la trazabilidad de cada requisito a su prueba. El equipo de ingeniería tenía el código en un repositorio, un historial de commits y muchas pruebas hechas a mano, pero ninguna evidencia de que el software se hubiera desarrollado con un proceso controlado.

Qué es la IEC 62304

La IEC 62304 es la norma internacional sobre los procesos del ciclo de vida del software de dispositivos médicos. Aplica tanto al software que forma parte de un equipo, como el firmware de una bomba de infusión, como al software que es un dispositivo médico por sí mismo. No dice qué lenguaje usar ni cómo programar: define qué actividades debe tener el proceso de desarrollo y mantenimiento, y qué evidencia debe quedar de cada una. Presupone que la organización ya tiene un sistema de gestión de calidad, como la ISO 13485, y un proceso de gestión de riesgos conforme a la ISO 14971. La FDA la reconoce como norma de consenso y en Europa se usa como norma armonizada para demostrar conformidad.

Las clases de seguridad del software

El rigor que exige la norma depende de la clase de seguridad, que se asigna a partir del análisis de riesgos:

• —Clase A: el software no puede contribuir a una situación peligrosa, o no puede provocar un daño inaceptable después de considerar los controles de riesgo externos al software.
• —Clase B: el software puede contribuir a una situación peligrosa que resulte en una lesión no grave.
• —Clase C: el software puede contribuir a una situación peligrosa que resulte en una lesión grave o la muerte.

Un control de riesgo externo, como un circuito de protección en el hardware que corta la energía, puede bajar la clase del software. La clasificación también puede hacerse por partes: un sistema clase C puede tener elementos de menor clase si se demuestra que están separados.

Qué procesos exige

• —Plan de desarrollo del software, con las actividades, entregables, herramientas y criterios de verificación.
• —Análisis de requisitos del software, incluidos los que salen de las medidas de control de riesgo.
• —Diseño de la arquitectura, con la identificación de los componentes de terceros y la separación entre elementos.
• —Diseño detallado, implementación y verificación de unidades, con más exigencia en clase C.
• —Integración, pruebas de integración y pruebas del sistema de software contra sus requisitos.
• —Liberación del software, con las anomalías conocidas evaluadas y documentadas.

A esos se suman cuatro procesos de soporte que acompañan todo el ciclo: mantenimiento del software después de la liberación, gestión de riesgos del software, gestión de la configuración y resolución de problemas. Un cambio en un producto que ya está en el mercado pasa por los mismos controles que el desarrollo original.

Qué es el SOUP

La norma llama SOUP al software de origen desconocido: bibliotecas de código abierto, sistemas operativos, controladores o componentes comerciales que no se desarrollaron bajo un proceso conforme. No está prohibido usarlo, pero hay que identificarlo con su versión, definir los requisitos de funcionamiento y de hardware que necesita, evaluar sus anomalías conocidas y analizar cómo una falla del componente puede contribuir a una situación peligrosa.

Errores frecuentes

• —Asignar clase A por conveniencia, sin un análisis de riesgos que lo justifique.
• —Escribir la documentación al final del proyecto, reconstruyendo decisiones que nadie registró.
• —No listar las bibliotecas de terceros ni seguir sus actualizaciones y vulnerabilidades.
• —Corregir errores en campo sin pasar por la gestión de la configuración ni evaluar el impacto en el riesgo.

Dónde se rompe en la operación

En Tijuana, donde las plantas de dispositivos médicos conviven con manufactura electrónica que carga firmware en tarjetas para equipo médico, el software suele desarrollarse en otro país y la planta recibe versiones para programar en línea. Lo que falla es el control de qué versión se carga en cada lote, cómo se autoriza un cambio y cómo se registra una anomalía reportada en campo. Conectar la liberación del software con el control de cambios, la trazabilidad del producto y el tratamiento de quejas es parte de lo que se trabaja en la Consultoría ISO 9001 en Tijuana, como base para los requisitos específicos del sector médico.

En resumen

La IEC 62304 define el ciclo de vida del software de dispositivos médicos. Clasifica el software en clases A, B y C según el daño que puede contribuir a causar, y con base en esa clase exige planeación, requisitos, arquitectura, verificación, liberación, mantenimiento, gestión de riesgos, configuración y resolución de problemas, con control explícito del software de terceros.