Healthtech: la trazabilidad del software no se reconstruye la víspera de la auditoría

Un auditor pregunta cómo se implementó un requisito concreto, cómo se verificó después y cómo se validó antes de salir a producción. El equipo sabe que está hecho: el producto funciona, los tests pasan, nadie duda del resultado. Pero demostrar el camino completo, requisito por requisito, exige tres días de reconstrucción manual entre Jira, una hoja de cálculo Excel y actas de validación dispersas en Word. En el sector salud, esta escena se repite en cada auditoría, cada ronda de financiación, cada revisión de calidad.

Un software que funciona no basta

Fuera del sector salud, un software que funciona es un software que ha tenido éxito. En healthtech y medtech, eso nunca basta: hay que demostrar además cómo se especificó, se desarrolló, se verificó y se validó. La diferencia parece sutil. No lo es. Un auditor no pregunta si la funcionalidad funciona, pide ver la cadena de pruebas: qué requisito, qué issues lo implementaron, qué tests lo verificaron, qué revisión validó el resultado antes del release. Sin esa cadena reconstruible, el software mejor diseñado sigue siendo, desde el punto de vista regulatorio, no conforme.

Tres herramientas, cero vínculos entre ellas

La mayoría de los equipos healthtech jóvenes heredan un conjunto de herramientas pensado para la velocidad, no para la prueba: Jira o Linear para seguir el desarrollo, una hoja Excel para la matriz de trazabilidad, documentos Word para las actas de validación. Cada una hace su trabajo de forma aislada. Ninguna de las tres sabe qué hacen las otras dos. El vínculo entre un requisito y la issue que lo implementa, entre esa issue y el test que la verifica, entre ese test y la decisión que validó el release, no existe en ningún sistema: existe solo en la memoria del equipo, y en las horas dedicadas a reconstruirlo antes de cada auditoría.

Esta deuda de trazabilidad no se ve en el día a día. Se paga de golpe, en el peor momento: durante una auditoría ISO 13485, una revisión de dossier técnico MDR, o una due diligence de un inversor que pide pruebas de rigor antes de firmar.

Los retos regulatorios a los que se enfrentan las healthtech

Las startups healthtech y medtech no eligen añadir rigor: lo reciben desde fuera, en varias capas que se acumulan:

• IEC 62304 regula el ciclo de vida del software médico: clasificación de riesgo, planificación, requisitos, arquitectura, implementación, tests de integración, tests de sistema. Cada etapa debe documentarse y vincularse a la anterior.
• ISO 13485 exige un sistema de gestión de calidad que cubra todo el ciclo de vida del producto, no solo el desarrollo: diseño, producción, vigilancia postcomercialización, gestión de incidentes.
• MDR (Medical Device Regulation) en Europa, y los requisitos equivalentes de la FDA en Estados Unidos, exigen un dossier técnico que demuestre el cumplimiento, con trazabilidad completa entre requisitos de usuario, especificaciones, verificación y validación.
• RGPD y alojamiento de datos se suman en cuanto el producto toca, aunque sea indirectamente, datos de salud, con expectativas de localización y cifrado que van más allá del software en sí.

Ninguna de estas normas impone una herramienta concreta. Todas exigen, en el fondo, lo mismo: poder reconstruir, sin depender de la memoria colectiva, el camino completo entre un requisito y su puesta en producción verificada.

Qué aporta Sinra a esta ecuación

Sinra no certifica nada ni sustituye ningún proceso de calidad: Sinra es una herramienta de organización del desarrollo, no una certificación, y no garantiza por sí sola el cumplimiento de una norma como IEC 62304 o ISO 13485. Lo que hace: construir la trazabilidad mientras el equipo desarrolla, para que no haya que reconstruirla nunca después.

• Requisitos vinculados al código y a los tests. Cada especificación está vinculada a las issues que la implementan y a los tests que la verifican. El vínculo que Jira, Excel y Word no podían mantener existe de forma nativa, en un solo sistema.
• Validaciones formales e historizadas. Revisiones de fase con criterios de evaluación explícitos, veredicto go / no-go / condicional, e historial completo de cada decisión: justo lo que un auditor pide ver, ya disponible en lugar de tener que reconstruirlo.
• Incidentes documentados. Postmortems estructurados: cronología, factores sistémicos, acciones correctivas, tiempo de resolución. La gestión de incidentes se convierte en una prueba de madurez de calidad en sí misma, no en un punto ciego.
• Un vocabulario controlado. Un glosario de negocio compartido y reutilizado en las especificaciones, para que un requisito signifique lo mismo para el desarrollador que lo implementa y para el auditor que lo revisa un año después.
• El rigor del ciclo en V, el ritmo del agile. Las specs siguen su propio flujo de redacción y validación mientras los desarrolladores avanzan en cycles cortos. Los tests y las revisiones de fase garantizan que nada pasa a producción sin haberse verificado, sin sacrificar la velocidad de iteración que una startup no puede permitirse perder.
• Alojamiento en Francia, RGPD, datos cifrados. Sinra está diseñado para datos de desarrollo, no para datos de pacientes: como en un entorno de test, solo los datos ficticios o anonimizados tienen su lugar en las issues y archivos adjuntos.

Qué hay que recordar

La trazabilidad regulatoria en healthtech no es un documento que se escribe una vez, antes de la auditoría: es una disciplina que se construye issue tras issue, test tras test, revisión tras revisión. Los equipos que la reconstruyen a mano entre tres herramientas desconectadas lo pagan en días perdidos y estrés en cada plazo. Al vincular requisitos, desarrollo, tests y validaciones en un solo sistema desde el primer día, Sinra convierte esa reconstrucción de urgencia en un historial ya listo para mostrarse.