Agile en software sanitario regulado: AAMI TIR45, Scrum bajo - Blog

Introducción

Existe un mito persistente en la industria del software sanitario: que las metodologías ágiles son incompatibles con los entornos regulados. Que Scrum y la IEC 62304 no pueden coexistir. Que el modelo en V es la única vía para certificar un producto sanitario software. Este mito es falso, y lo demuestra la guía AAMI TIR45:2023, un estándar de consenso en cuyo desarrollo ha participado la propia FDA como miembro del comité.

Las metodologías ágiles software sanitario regulado no solo son posibles: cuando se implementan correctamente, producen software más seguro, con mejor trazabilidad y con documentación regulatoria más consistente que los enfoques waterfall tradicionales. La clave está en entender que la IEC 62304 no prescribe secuencialidad entre actividades; prescribe qué actividades deben realizarse y qué evidencias deben generarse, pero no cuándo ni en qué orden. Esto abre la puerta a la integración completa de Scrum en el ciclo de vida del software sanitario.

En este artículo profundizaremos en la implementación práctica de metodologías ágiles en entornos regulados por IEC 62304, ISO 13485, ISO 14971 y FDA 21 CFR Part 820.30. Analizaremos las tres capas del TIR45, el Definition of Done regulatorio, la gestión de riesgos integrada en sprints, la cadena de trazabilidad completa y las herramientas que automatizan la generación de evidencia de compliance. Si lideras equipos de desarrollo de software sanitario en España o Europa, este artículo te proporcionará el marco para acelerar tus ciclos sin comprometer la conformidad regulatoria.

El mito del modelo en V: qué dice realmente la IEC 62304

La norma no exige waterfall

La IEC 62304:2006+Amd1:2015 (Medical device software — Software life cycle processes) es la norma armonizada de referencia para el desarrollo de software de dispositivos médicos en la Unión Europea. Su estructura define procesos del ciclo de vida del software: planificación, análisis de requisitos, diseño de arquitectura, diseño detallado, implementación, integración, verificación, liberación y mantenimiento.

Lo que la norma no hace es prescribir un orden secuencial obligatorio entre estas actividades. Las secciones 5 a 8 de la IEC 62304 definen qué debe hacerse (requisitos documentados, diseño trazable, verificación de cada unidad, tests de integración, gestión de configuración), pero no cuándo en relación con otras actividades. Esto es un punto crucial que muchos equipos malinterpretan: asumen que porque la norma se presenta de forma secuencial (sección 5.1 antes que 5.2, etc.), el proceso debe ser secuencial. Pero la propia norma permite la iteración y la concurrencia.

El modelo en V, tan arraigado en la cultura de dispositivos médicos, es una forma de cumplir la IEC 62304, pero no la única. Es un modelo de representación que muestra la correspondencia entre fases de diseño y fases de verificación. Nada impide que esas correspondencias se establezcan dentro de iteraciones de dos semanas en lugar de en fases de seis meses.

La clasificación de seguridad como habilitador

La enmienda 1 de 2015 a la IEC 62304 introdujo un cambio fundamental: la clasificación de seguridad del software a nivel de software item (elemento de software), no solo a nivel de producto completo. Esto significa que los componentes de un sistema pueden clasificarse de forma independiente:

Clase A: sin contribución posible a una situación peligrosa.
Clase B: contribución posible a una situación peligrosa, pero sin lesión grave.
Clase C: contribución posible a muerte o lesión grave.

Esta granularidad es un habilitador natural para las metodologías ágiles: permite aplicar niveles de rigor documental proporcionales al riesgo de cada componente, en lugar de tratar todo el sistema con el máximo rigor. Un módulo de interfaz de usuario para configuración administrativa (Clase A) no requiere la misma profundidad de documentación de diseño que un algoritmo de cálculo de dosis (Clase C).

AAMI TIR45:2023: las tres capas del desarrollo ágil regulado

La guía AAMI TIR45:2023 (Guidance on the use of agile practices in the development of medical device software) proporciona el marco de referencia para implementar metodologías ágiles software sanitario regulado de forma conforme. Su estructura se organiza en tres capas que mapean las actividades ágiles a los requisitos normativos.

Capa 1: Iteration/Sprint Level

A nivel de iteración (sprint en terminología Scrum), el TIR45 establece cómo las actividades de cada sprint producen los artefactos regulatorios exigidos por la IEC 62304. Cada sprint no solo genera código funcional, sino también:

Requisitos de software documentados y trazados a necesidades del usuario.
Diseño de software suficiente para el nivel de clasificación de seguridad.
Código implementado con estándares de codificación aplicados.
Tests unitarios y de integración ejecutados con resultados documentados.
Evaluación de riesgos actualizada según ISO 14971.

El concepto clave aquí es el Definition of Done regulatorio: una definición de "hecho" que incluye no solo los criterios funcionales habituales de Scrum (código revisado, tests pasados, funcionalidad desplegable), sino también los criterios regulatorios. Un elemento del backlog no está "hecho" hasta que:

Sus requisitos están documentados y trazados.
El diseño correspondiente está registrado (nivel de detalle proporcional a la clase de seguridad).
Los tests de verificación correspondientes están escritos, ejecutados y documentados.
Los riesgos asociados están evaluados y, si procede, se han implementado controles de riesgo.
El análisis de riesgos del producto está actualizado.

Capa 2: Release/Version Level

A nivel de release (versión), el TIR45 mapea las actividades de planificación de versiones a los requisitos de la IEC 62304 sobre planificación del desarrollo de software (sección 5.1) y liberación (sección 5.8). Cada release acumula los artefactos de múltiples sprints y genera:

Plan de desarrollo de software actualizado para la versión.
Verificación a nivel de sistema (tests end-to-end, tests de regresión).
Evaluación de riesgos completa a nivel de producto.
Registro de liberación con la evidencia acumulada.

Capa 3: Product Level

A nivel de producto, se gestionan las actividades que trascienden releases individuales: gestión de configuración, mantenimiento, gestión de problemas (bug tracking regulatorio), gestión de cambios y gestión del ciclo de vida completo. Aquí es donde se integran los requisitos de ISO 13485 sobre el sistema de gestión de calidad y los de FDA 21 CFR Part 820.30 sobre Design Controls.

Testing basado en riesgo: la integración de ISO 14971 en sprints

El modelo de riesgo del software según IEC 62304

Un aspecto fundamental de las metodologías ágiles software sanitario regulado es la gestión integrada de riesgos. La IEC 62304, en su relación con la ISO 14971:2019, adopta un enfoque particular para el software: asume que la probabilidad de fallo del software es 1 (es decir, el 100%). Esto no es una exageración pesimista, sino un reconocimiento práctico de que el software, a diferencia del hardware, no falla por desgaste sino por defectos de diseño, y que estimar probabilidades de fallo de software es metodológicamente cuestionable.

La consecuencia es que la evaluación de riesgos del software se centra en las consecuencias (severidad del daño) más que en la probabilidad de fallo. La clasificación de seguridad (A, B, C) refleja directamente esta severidad.

La cadena de trazabilidad completa

El testing basado en riesgo exige una cadena de trazabilidad que vincule cada elemento de la gestión de riesgos con los artefactos de verificación:

Hazard (peligro): situación o evento que puede causar daño (ej: sobredosis de medicación).
Software cause (causa software): comportamiento del software que contribuye al peligro (ej: cálculo incorrecto de dosis).
Software item: componente específico del sistema donde reside la causa (ej: módulo DoseCalculator).
Risk control (control de riesgo): medida implementada para mitigar el riesgo (ej: validación de rango de dosis, doble comprobación, alerta al usuario).
Verification: test que demuestra que el control de riesgo funciona correctamente.
Evidence: resultado documentado del test, trazado a todos los elementos anteriores.

En un entorno ágil, esta cadena se construye durante el sprint, no al final del proyecto. Cuando un desarrollador implementa un control de riesgo como parte de una user story, simultáneamente crea el test de verificación y documenta la trazabilidad. Esta es la diferencia fundamental con el enfoque waterfall: la documentación regulatoria se genera en el momento en que se implementa el código, cuando el conocimiento está fresco y la trazabilidad es natural.

Validación IQ/OQ/PQ adaptada a software

La validación de software sanitario tradicionalmente sigue el modelo IQ/OQ/PQ (Installation Qualification, Operational Qualification, Performance Qualification), heredado de la industria farmacéutica. En un entorno ágil:

IQ: se automatiza mediante pipelines de CI/CD que verifican la instalación correcta del software en cada despliegue (Infrastructure as Code, tests de smoke).
OQ: se mapea a los tests funcionales y de integración ejecutados en cada sprint, más los tests de regresión a nivel de release.
PQ: se valida en el entorno de producción o de preproducción con datos representativos, típicamente como parte del proceso de liberación de versiones.

Herramientas: automatización de la trazabilidad regulatoria

La viabilidad práctica de Scrum en entornos regulados depende en gran medida de las herramientas que automatizan la generación y mantenimiento de la trazabilidad. Documentar manualmente la conformidad regulatoria en cada sprint es insostenible; la automatización es imprescindible.

Jira + Ketryx: trazabilidad automatizada sobre Atlassian

Ketryx es una plataforma de ALM (Application Lifecycle Management) que se integra nativamente con Jira y automatiza la generación de documentación regulatoria. Su propuesta de valor es directa: los equipos trabajan en Jira como lo harían en cualquier proyecto ágil (backlog, sprints, boards), y Ketryx genera automáticamente:

Matrices de trazabilidad requisitos-diseño-tests-riesgos.
Documentos regulatorios formateados según las plantillas IEC 62304/ISO 14971.
Informes de verificación con evidencia de tests vinculada.
Detección de gaps de trazabilidad (requisitos sin tests, riesgos sin controles).

La integración con Azure DevOps Pipelines permite además vincular la evidencia de ejecución de tests automatizados (JUnit, pytest, Selenium) directamente a los elementos del backlog regulatorio.

Tuleap: alternativa open source con soporte SAFe

Tuleap es una plataforma open source que combina gestión de requisitos, tests, trazabilidad y DevOps en una única herramienta. Para equipos que operan bajo SAFe (Scaled Agile Framework) en entornos regulados, Tuleap ofrece soporte nativo para Agile Release Trains, Program Increments y la escalabilidad necesaria en organizaciones grandes.

La experiencia de Roche Diagnostics, documentada por el Dr. Jochen Jager, demuestra que SAFe puede implementarse con éxito en entornos de dispositivos médicos regulados. Roche utiliza SAFe para coordinar múltiples equipos de desarrollo de software de diagnóstico in vitro, manteniendo la conformidad con IEC 62304 e ISO 13485 mediante la integración de actividades regulatorias en los Program Increments.

Jama Connect y Perforce Helix ALM

Para organizaciones con requisitos más estrictos de gestión de trazabilidad, Jama Connect ofrece su tecnología Live Traceability, que mantiene las relaciones entre requisitos, diseño, tests y riesgos actualizadas en tiempo real, detectando automáticamente impactos de cambios en cascada. Perforce Helix ALM proporciona capacidades similares con un enfoque particular en la gestión de requisitos normativos.

Parasoft para testing de compliance

Parasoft (C/C++test, Jtest, dotTEST) complementa el stack con herramientas de análisis estático de código, testing unitario automatizado y verificación de estándares de codificación. En entornos de software sanitario, Parasoft permite:

Verificar conformidad con estándares de codificación como MISRA C (para software embebido de dispositivos médicos).
Generar informes de cobertura de código trazados a requisitos.
Ejecutar análisis estático que detecta defectos potenciales vinculados a riesgos de seguridad.

Para los tests de interfaz de usuario, Selenium (aplicaciones web) y Appium (aplicaciones móviles) proporcionan frameworks de automatización que generan evidencia de ejecución integrable en la cadena de trazabilidad regulatoria.

Contexto español: regulación y mercado

En España, las empresas de software sanitario que desarrollan productos clasificados como dispositivos médicos deben cumplir con el Reglamento (UE) 2017/745 (MDR), que a su vez referencia la IEC 62304 como norma armonizada para el ciclo de vida del software. La Agencia Española de Medicamentos y Productos Sanitarios (AEMPS) es el organismo notificado que supervisa la conformidad.

El mercado español de software sanitario regulado está en expansión, impulsado por las inversiones del Plan de Recuperación, Transformación y Resiliencia. Los más de 477 millones de euros destinados a la transformación digital del SNS (incluyendo los 230 millones para Atención Primaria y los 220 millones para Sostenibilidad) generan una demanda creciente de software sanitario conforme que debe desarrollarse con los ciclos de entrega ágiles que el mercado exige.

La adopción de AAMI TIR45 en España es aún incipiente, pero empresas como las que participan en el ecosistema de HL7 Spain y los programas de interoperabilidad del Ministerio de Sanidad están liderando la transición hacia modelos de desarrollo ágil regulado. El reto particular en España es la fragmentación del mercado sanitario entre 17 servicios de salud autonómicos, lo que multiplica los requisitos de integración y hace aún más necesaria la eficiencia de las metodologías ágiles.

El backlog regulatorio: vinculando user stories, requisitos, riesgos y tests

Un aspecto práctico que merece atención específica es la estructura del backlog en un proyecto ágil regulado. El backlog no es una simple lista de funcionalidades: es un grafo de relaciones que vincula:

User stories (necesidades del usuario/stakeholder).
Requisitos de software (especificaciones formales derivadas de las user stories).
Elementos de riesgo (peligros, causas software, controles de riesgo vinculados a requisitos específicos).
Tests de verificación (casos de prueba que verifican tanto la funcionalidad como la eficacia de los controles de riesgo).

Cada user story del backlog debe poder trazar hacia arriba (a qué necesidad responde y qué riesgos involucra) y hacia abajo (qué tests la verifican y qué evidencia se genera). Esta trazabilidad bidireccional es el corazón de la conformidad regulatoria en Scrum y lo que las herramientas como Ketryx, Jama Connect y Tuleap automatizan.

La documentación regulatoria no se genera al final del proyecto como un ejercicio retrospectivo: se genera durante cada sprint como subproducto natural del trabajo de desarrollo. Esto es más eficiente (la información está fresca), más preciso (se documenta lo que realmente se ha hecho) y más auditable (la trazabilidad es contemporánea al desarrollo).

Conclusión

Las metodologías ágiles software sanitario regulado no son una concesión al mercado ni un compromiso con la seguridad: son la forma más eficaz de producir software médico seguro, trazable y conforme. El AAMI TIR45:2023 lo demuestra con el respaldo de la FDA, y la experiencia de empresas como Roche Diagnostics lo confirma en la práctica.

La clave está en tres principios: integrar la documentación regulatoria en el Definition of Done de cada sprint (no dejarla para el final), automatizar la trazabilidad con herramientas como Ketryx, Tuleap o Jama Connect, y entender que la IEC 62304 prescribe qué hacer, no cómo organizarse para hacerlo.

En Informática Médica ayudamos a equipos de desarrollo de software sanitario a implementar Scrum conforme con IEC 62304, ISO 14971 e ISO 13485: desde la definición del Definition of Done regulatorio hasta la configuración de pipelines de trazabilidad automatizada. Porque desarrollar más rápido y cumplir con la regulación no son objetivos contradictorios; son dos caras de la misma disciplina de ingeniería.

Referencias

AAMI TIR45:2023 — Guidance on the use of agile practices in the development of medical device software. Association for the Advancement of Medical Instrumentation, 2023.
IEC 62304:2006+Amendment 1:2015 — Medical device software — Software life cycle processes. International Electrotechnical Commission. Secciones 5-8.
ISO 14971:2019 — Medical devices — Application of risk management to medical devices. International Organization for Standardization.
IEC/TR 80002-1 — Medical device software — Part 1: Guidance on the application of ISO 14971 to medical device software.
ISO 13485:2016 — Medical devices — Quality management systems — Requirements for regulatory purposes.
FDA Design Controls Guidance Document — Design Control Guidance for Medical Device Manufacturers. U.S. Food and Drug Administration. fda.gov
Johner Institute: TIR45 Agile Software Development — blog.johner-institute.com. Análisis técnico detallado del TIR45.
Greenlight.guru: AAMI TIR45 Guide — greenlight.guru. Guía práctica de implementación.
Roche Diagnostics: experiencia SAFe en entornos regulados. Presentación del Dr. Jochen Jager sobre la adopción de Scaled Agile Framework en software de diagnóstico in vitro.
FDA 21 CFR Part 820.30 — Design Controls. Code of Federal Regulations, Title 21, Chapter I, Subchapter H, Part 820.