Tu App Acaba de Convertirse en un Producto Sanitario. ¿Y Ahora Qué?

Has añadido una función. Quizá una alerta de ritmo cardíaco irregular o una recomendación basada en los síntomas de un paciente. Tu código apenas ha cambiado. Pero, a ojos del Reglamento europeo de productos sanitarios (MDR), tu app puede ahora considerarse un producto sanitario.

El software puede seguir siendo el mismo, pero la forma en que lo desarrollas, lo lanzas y le das soporte ya no lo es. Te contamos qué cambia realmente y cómo prepararte sin frenar a tu equipo.

En este artículo

• Seis ámbitos de evidencia y control asociados al software de productos sanitarios
• Cómo mantener el desarrollo Agile y CI/CD compatibles con los requisitos del MDR
• Qué implican los cambios en software basado en IA para el control de las versiones
• Cuándo y cómo prepararte para un organismo notificado
• Por qué el marcado CE es el inicio de unas responsabilidades regulatorias continuas

Una Alegación Médica, Seis Ámbitos de Evidencia

Una app de bienestar necesita funcionar. Un producto sanitario necesita demostrar que funciona de forma segura para su finalidad prevista y seguir recopilando evidencia durante todo su ciclo de vida. Una alegación médica puede poner en juego seis ámbitos de responsabilidad interconectados.

1. Evaluación Clínica

La evidencia debe respaldar el beneficio clínico, la seguridad y el funcionamiento que se atribuyen al software. Un resultado técnicamente preciso no constituye necesariamente evidencia suficiente de que el producto aporta el beneficio clínico previsto.

2. Gestión de Riesgos

Los equipos necesitan una forma sistemática de identificar los riesgos para pacientes y usuarios, evaluar su gravedad y probabilidad, implementar controles y evaluar el riesgo residual. La gestión de riesgos debe acompañar al producto a medida que evoluciona.

3. Verificación y Validación

Las pruebas deben demostrar tanto que se han cumplido los requisitos del software como que el producto es adecuado para su uso previsto. La trazabilidad vincula los requisitos, las decisiones de diseño, los riesgos y la evidencia de las pruebas.

4. Seguimiento Poscomercialización y Vigilancia

Los fabricantes necesitan un proceso para recopilar y analizar información una vez que el producto está en el mercado, gestionar reclamaciones, identificar tendencias y notificar los incidentes graves y las acciones correctivas de seguridad en campo que deban notificarse.

5. Controles de Proveedores

Los proveedores de servicios en la nube, las bibliotecas de software, los desarrolladores externos y otros colaboradores críticos pueden afectar a la seguridad o al funcionamiento. Es necesario evaluar y controlar su papel y los riesgos asociados.

6. Control de Cambios

Los cambios en el software requieren una evaluación de su impacto en la seguridad, el funcionamiento, la documentación regulatoria y la configuración aprobada antes de su lanzamiento. El nivel de pruebas y aprobación debe reflejar el riesgo.

Agile Está Bien. Agile Sin Control, No.

La preocupación más habitual que escuchamos entre los equipos de software es: «¿Esto significa el fin de los sprints y de los lanzamientos semanales?»

No. El MDR no prohíbe el desarrollo Agile, la integración continua ni los lanzamientos frecuentes. Lo que exige es control y evidencia de que el producto sigue siendo seguro y funciona según lo previsto.

En la práctica, eso significa que:

• Los requisitos son trazables al diseño, las pruebas y los riesgos pertinentes.
• Antes del despliegue, se evalúa el impacto de los cambios en la seguridad, el funcionamiento y las obligaciones regulatorias.
• Las pruebas y la revisión se documentan con un nivel de detalle adecuado al cambio.
• Los lanzamientos se autorizan formalmente, en lugar de considerarse completados cuando se integra el código.
• Tu sistema de gestión de la calidad, con ISO 13485 y las prácticas pertinentes del ciclo de vida del software de IEC 62304, se adapta a la forma en que el equipo trabaja realmente.

Esto no significa crear un proceso documental paralelo para cada sprint. Significa integrar los controles de diseño, la gestión de riesgos, la trazabilidad y las aprobaciones de lanzamiento en el propio flujo de desarrollo.

¿Y Si Tu Software Utiliza IA?

La IA añade otra capa al control de cambios. Una actualización del modelo, una actividad de reentrenamiento o un cambio en los datos de entrada pueden afectar al funcionamiento clínico aunque la interfaz de usuario parezca idéntica.

Un modelo puede actualizarse después del lanzamiento, pero no bajo la premisa de que el aprendizaje continuo es automáticamente aceptable. Los cambios deben planificarse, evaluarse, verificarse y validarse según corresponda, documentarse y analizarse en cuanto a su impacto regulatorio antes del despliegue. Algunos cambios pueden requerir una nueva intervención en la evaluación de la conformidad.

El objetivo no es detener la iteración. Es que cada lanzamiento pueda justificarse.

¿Estás Preparado para un Organismo Notificado?

Para el software de productos sanitarios de clase IIa y superior, generalmente interviene un organismo notificado en la evaluación de la conformidad. Antes de esa evaluación, deberían ir tomando forma ocho bases:

1. Una finalidad prevista clara y coherente
2. Un proceso documentado de gestión de riesgos
3. Un proceso establecido para el ciclo de vida del software
4. Controles de diseño y desarrollo
5. Un proceso de gestión de cambios operativo
6. Procedimientos de gestión de reclamaciones
7. Un proceso de seguimiento poscomercialización y vigilancia
8. Una responsabilidad de la dirección definida dentro del sistema de calidad

No es necesario que todos estos elementos sean perfectos antes de una primera conversación con un organismo notificado. De hecho, el contacto temprano puede ayudar a los equipos a planificar teniendo en cuenta la capacidad limitada de evaluación y a comprender la vía prevista para la certificación.

Empieza por una finalidad prevista clara, una justificación inicial del riesgo y la clasificación, y un plan de desarrollo creíble. Confirma que el organismo notificado esté designado para el ámbito del producto correspondiente.

¿Y Si También Quieres Entrar en el Mercado Estadounidense?

No des por hecho que la evidencia preparada para un mercado satisface automáticamente los requisitos del otro. La FDA dispone de varias vías regulatorias, entre ellas 510(k), De Novo y la aprobación previa a la comercialización, según el producto. El MDR europeo sigue sus propias reglas de cualificación, clasificación y evaluación de la conformidad, incluida la regla 11 para el software.

Parte de la evidencia técnica, clínica y de calidad puede reutilizarse, pero es necesario evaluar la estrategia regulatoria y las carencias de evidencia resultantes para cada mercado.

El Marcado CE Es la Línea de Salida, No la Meta

El mayor error que vemos es tratar el marcado CE como la meta. En Europa, es el inicio de la siguiente fase de responsabilidad.

La evaluación clínica, el seguimiento poscomercialización, la vigilancia, la gestión de riesgos y el mantenimiento del software continúan durante todo el ciclo de vida del producto. Las actualizaciones significativas deben pasar por el control de cambios, evaluando su posible efecto en la certificación y las obligaciones regulatorias.

Los equipos que lo planifican desde el primer día están mejor preparados para avanzar con rapidez más adelante. Su documentación crece con el producto, los lanzamientos ya están controlados y la preparación para las inspecciones resulta menos disruptiva.

Integra el Cumplimiento del MDR en la Forma de Trabajar de Tu Equipo

Convertirte en fabricante de productos sanitarios no significa abandonar las prácticas de desarrollo que hicieron que tu producto tuviera éxito. Significa adaptarlas para que la seguridad, el funcionamiento y la evidencia regulatoria formen parte del mismo flujo de trabajo.

QbD Group ayuda a las empresas de salud digital a definir su estrategia MDR y a crear un sistema de gestión de la calidad alineado con ISO 13485 que encaje con su proceso de desarrollo de software, desde la cualificación inicial y los controles de diseño hasta la preparación para el organismo notificado y las obligaciones poscomercialización.

¿Estás pasando del bienestar al software de productos sanitarios? Contacta con nuestros expertos para construir una vía práctica y conforme hacia el mercado europeo.