← Volver a especializaciones

Ciclo de vida del software y verificación según IEC 62304

IEC 62304 define cómo debe desarrollarse, documentarse y verificarse el software de dispositivos médicos, y el rigor exigido escala directamente con el daño que podría causar una falla. Construimos nuestro enfoque de verificación en torno a esa escala, no en torno a una suite de pruebas única para todos los casos.

IEC 62304Software Clase A / B / CISO 14971ISO 13485Trazabilidad

Qué exige realmente IEC 62304

IEC 62304 es la norma internacional para los procesos del ciclo de vida del software de dispositivos médicos. No dice qué debe hacer su software: define el proceso que se sigue para construirlo: planificación, análisis de requisitos, diseño de arquitectura, diseño detallado, implementación, integración y pruebas de integración, pruebas de sistema y liberación, seguidos del mantenimiento y la resolución de problemas una vez que el producto sale al mercado.

Lo que la convierte en una norma de cumplimiento, y no solo en una buena práctica, es que cada una de esas etapas debe producir evidencia documentada y trazable: un revisor debe poder seguir un único requisito desde el documento de requisitos, a través del diseño, hasta el código y hasta el caso de prueba que lo verifica.

Clasificación de seguridad del software: Clase A, B y C

No todo el software de un dispositivo médico conlleva el mismo riesgo, y IEC 62304 no finge que así sea. Antes de comenzar el desarrollo, al software se le asigna una clase de seguridad según la severidad del daño que podría resultar si el software falla o contribuye a un peligro:

  • Clase A — no es posible ninguna lesión ni daño a la salud.
  • Clase B — es posible una lesión no grave.
  • Clase C — es posible la muerte o una lesión grave.

La clasificación se determina por la severidad, no por la probabilidad, una distinción que importa porque implica que se decide mediante el mismo proceso de gestión de riesgos (ISO 14971) que se usa para los peligros del dispositivo en general, y no mediante un juicio aparte. Además, a un elemento de software se le puede asignar una clase menor que la del sistema del que forma parte si se demuestra, a través de la arquitectura, que no puede contribuir a un peligro de mayor severidad; es parte de por qué el diseño de arquitectura se trata como una actividad de cumplimiento y no solo de ingeniería.

Cómo escala el rigor de la verificación con la clasificación

La clasificación no es solo una etiqueta: determina cuánto rigor de proceso requiere el resto del ciclo de vida. En la práctica, eso significa:

  • El software de Clase A puede resolverse con documentación y verificación comparativamente livianas, ya que una falla no tiene consecuencias para la seguridad del paciente.
  • El software de Clase B necesita casos de prueba documentados y basados en requisitos, y evidencia de que la verificación efectivamente se realizó, ya que una falla podría causar un daño no grave.
  • Se espera que el software de Clase C cargue con todo el peso de la norma: trazabilidad completa de requisitos a pruebas, documentación rigurosa de arquitectura y de diseño detallado, verificación exhaustiva y un control de cambios más formal y más revisado, porque una falla aquí podría ser fatal.

Escalamos las pruebas unitarias, las pruebas de integración y la profundidad de la documentación según la clase asignada, en lugar de aplicar la misma lista de control sin importar el riesgo; así el trabajo de Clase A se mantiene ágil y el de Clase C, tan riguroso como debe ser.

Dónde encajan ISO 14971 e ISO 13485

IEC 62304 no opera de forma aislada. ISO 14971 (gestión de riesgos) es lo que realmente determina la clasificación de seguridad y la identificación de las medidas de control de riesgos que se convierten en requisitos de software. ISO 13485 (sistemas de gestión de la calidad) es el marco más amplio dentro del cual se ubican las actividades de IEC 62304: control de documentos, archivos de historial de diseño y procesos de gestión de cambios que se aplican al software igual que al hardware. Los equipos que ya operan bajo ISO 13485 tienen dónde alojar los registros de IEC 62304; los que aún no tienen un sistema de gestión de la calidad necesitan construir esa estructura junto con el proceso de software, no después.

Control de cambios y mantenimiento

IEC 62304 no termina con la liberación. Una vez que el software sale al mercado, la norma exige un proceso definido de resolución de problemas —una forma de recibir, evaluar y atender defectos e incidencias en campo— y un proceso definido para evaluar si un cambio (una corrección de errores, una nueva funcionalidad, la actualización de un componente de terceros) debe volver a pasar por la clasificación y la verificación, en proporción a lo que cambió.

¿Tiene un proyecto en esta área?

Cuéntenos sobre su dispositivo y sus plazos: le diremos qué se necesita realmente.

Contáctenos