En la era actual de desarrollo ágil, DevOps y ciclos de iteración rápidos, muchos desarrolladores ven la norma IEC 62304 como un vestigio de una época anterior. Su ciclo de vida de software clásico y la dependencia del modelo V a menudo se sienten en desacuerdo con las prácticas de desarrollo flexibles y de ritmo rápido.

Pero la CEI 62304 nunca pretendió ser una prescripción rígida de cómo debe construirse el software. En su lugar, ofrece un marco sólido para demostrar el control, la seguridad y la trazabilidad, elementos fundamentales independientemente de si su equipo trabaja en sprints de dos semanas o en ciclos de cascada más largos.

Trazabilidad: El principio no negociable

En el núcleo de la norma IEC 62304 se encuentra el concepto de trazabilidad. Esto incluye:
- Requisitos de software definidos y comprobables,
- Decisiones de arquitectura y diseño documentadas,
- Actividades de verificación alineadas y registradas,
- Medidas de control de riesgos integradas según ISO 14971,
- Gestión de anomalías de software y cambios de configuración.
Estos principios se aplican universalmente, tanto si su equipo utiliza Scrum, Kanban o cualquier marco ágil híbrido.

IEC 62304 y Agile: compatibles por diseño

Aunque la IEC 62304 promueve un ciclo de vida estructurado, es fundamentalmente agnóstica en cuanto a metodología. El desarrollo ágil puede alinearse con sus expectativas cuando se interpreta a través de la lente de los resultados y artefactos en lugar de una secuencia rígida.

Los sprints pueden entregar componentes probados de forma incremental; los backlogs pueden asignarse a especificaciones de requisitos. La clave es que todas las actividades del ciclo de vida -desde los requisitos hasta la verificación- se documenten, revisen y controlen.

Lo que importa no es cómo se construye el software, sino lo bien que se puede demostrar que es seguro, eficaz y cumple las expectativas normativas.

Replanteamiento del modelo en V como andamiaje de documentación

El modelo V, que a menudo se considera sinónimo de la norma IEC 62304, no debe tomarse como un manual de instrucciones para los procesos de desarrollo. La mejor forma de entenderlo es como un andamiaje de documentación: una visualización de la alineación entre las actividades de desarrollo y su correspondiente verificación.
El desarrollo ágil se ajusta a este modelo cuando:

- Los requisitos se trazan hasta los casos de prueba,

- Las decisiones de diseño se validan,

- Los cambios de código se controlan y revisan,

- Las versiones se documentan con las correspondientes evaluaciones de riesgos.

Alineación con las expectativas normativas

Los organismos reguladores siguen reconociendo y confiando en la norma IEC 62304, no por su estructura de ciclo de vida, sino por sus expectativas coherentes y auditables:

Los requisitos de alto nivel, como se indica en el Anexo II - Reglamento de Dispositivos Médicos (MDR 2017/745) se pueden rastrear a requisitos más específicos de software indicados por IEC 62304, tales como requisitos, gestión de riesgos y control de configuración, historial de versiones de software y verificación basada en riesgos que son naturalmente apoyados por el marco de IEC 62304. Incluso la Guía 2023 de la FDA sobre documentación de software se remite directamente a los conceptos de la IEC 62304.

Lo que los reguladores quieren es la garantía de que los fabricantes comprenden su software, pueden verificar su comportamiento y pueden mitigar sus riesgos. La norma IEC 62304 sigue siendo la forma más armonizada a escala mundial de ofrecer esa garantía.

Como Organismo Notificado bajo MDR, DQS-MED sigue reconociendo la IEC 62304 como la norma más adecuada para la documentación estructurada de los procesos del ciclo de vida del software de dispositivos médicos.

Conclusión: La IEC 62304 es una norma que vale la pena reinterpretar

La norma IEC 62304 no es una reliquia del pasado, sino un ancla normativa para el desarrollo de software moderno.

Sí, la CEI 62304 necesita ser reinterpretada, o incluso adaptada a las realidades de los entornos de desarrollo actuales. Su modelo de ciclo de vida puede parecer tradicional, pero sus principios -trazabilidad, verificación y control- son intemporales.

De hecho, a medida que adoptamos estrategias de desarrollo más ágiles y flexibles, esos principios se vuelven aún más críticos para los desarrolladores de software de dispositivos médicos que desean garantizar no sólo el cumplimiento, sino también la seguridad del paciente.

¡El software de conformidad empieza aquí - MDR, ISO 13485, MDSAP y más por DQS!

¡El software de conformidad empieza aquí - MDR, ISO 13485, MDSAP y más por DQS!

Contact us!
Autor

Dr. Andrei Ninu

El Dr. Andrei Ninu es un experto en reglamentación con gran experiencia especializado en productos sanitarios activos, con especial atención a la seguridad funcional y del software, así como a las aplicaciones de inteligencia artificial (IA) en la atención sanitaria. Tiene una amplia experiencia en el cumplimiento normativo de la UE, en particular en los procesos de certificación y evaluación de la conformidad para los fabricantes de productos sanitarios.

Más allá de su experiencia reguladora, el Dr. Ninu aporta más de una década de experiencia práctica en el desarrollo de software, habiendo sido testigo directo de la evolución de los sistemas de IA en la atención sanitaria y su impacto transformador en la tecnología médica.

Su formación académica incluye un máster en Sistemas de Control y Robótica y un doctorado en Informática/Ingeniería Biomédica por la Universidad Tecnológica de Viena, donde se centró en la interacción hombre-máquina en rehabilitación. Avanzó en este campo durante su investigación posdoctoral en el Centro Médico Universitario de Gotinga, especializándose en la rehabilitación asistida por robots.

Loading...

Artículos y eventos relevantes

También podría interesarle esto
Blog
Loading...

Ley de IA y dispositivos médicos habilitados por IA: situación regulatoria actual

Blog
Loading...

Actualización MDR de la UE: Nuevas normas publicadas en virtud de la Decisión de Ejecución (UE) 2026/193

Blog
Loading...

EUDAMED ya está en marcha: qué deben hacer los fabricantes dispositivos médicos