Regulación del software como medical device: clase de riesgo y fases del proceso

¡Disponible en VÍDEO! Roadmap regulatorio necesario para configurar, validar y lanzar al mercado un software como medical device (MD) en el 10º Breakfast&Learn de la Red TECSAM. De la mano de Dominique Monferrer, Medical Device Director de Asphalion, conocerás la clasificación del software en función de la clase de riesgo y las fases del proceso regulatorio. ¡No te lo pierdas!

La clasificación del software en función de su clase de riesgo (I, IIA, IIB o III) es uno de los puntos centrales a definir en la fase inicial de la creación de este tipo de productos sanitarios

El software como medical device se clasifica, por defecto, en riesgo IIA, lo que incide en el proceso regulatorio de estos productos sanitarios y precisa la implicación de un organismo notificado para llevar a cabo su validación y salida al mercado. Ésta ha sido una de las ideas centrales del 10º Breakfast&Learn de la Red TECSAM.

Esta nueva cita del B&L, bajo el nombre «Regulación del software como medical device», ha corrido a cargo de Dominique Monferrer, Medical Device Director de Asphalion, quien ha trazado los pasos que todo investigador o investigadora debe llevar a cabo por para acreditar su software, desde su conceptualización y diseño hasta su validación clínica y su posterior comercialización.

 

 

Uno de los criterios imprescindibles a tener en cuenta tanto en la fase inicial de configuración del software como en su desarrollo es la clase de riesgo (I, IIA, IIB o III) del software en función de su usabilidad y grado de error potencial que podemos identificar en su funcionamiento, según ha explicado Monferrer.

Según se estipula en los nuevos reglamentos, concretamente la norma 11 de la Medical Device Regulation, de entrada, el software como MD está sujeto a la clase IIA, algo que hace que tenga que pasar por un proceso de regulación de conformidad con un organismo notificado. Los softwares que se clasifican en IIB y III son aquellos que tienen mayor riesgo de impacto en la gestión del paciente. Por otra parte, los que se clasifican en clase I (se dan en casos muy puntuales) tienen un control regulatorio muy laxo y no deben pasar por la auditoría del organismo.

Pese a esta clasificación, la experta en regulación de Asphalion ha indicado que deben tenerse en cuenta muchas reglas y subreglas aplicables en función de la tipología y finalidad de cada software y que debe mirarse caso por caso. Sin embargo, afirmó que, en caso de duda, siempre debe aplicarse la regla y subregla más estricta que dé lugar a la clasificación de riesgo más elevada.

Roadmap regulatorio del software como medical device, por fases

Todo software como medical device tiene la potencialidad de resolver una necesidad médica, pero antes de convertirse en un medical device debe pasar por un camino regulatorio complejo y con muchas fases intermedias. En esta sesión, todos los asistentes han podido conocer de primera mano la hoja de ruta a seguir para dar cumplimiento a la regulación y el marco europeo que rige estas tecnologías.

De acuerdo con Dominique, el proceso regulatorio del software como producto sanitario viene definido por 5 momentos clave: diseño del software, definición de la clase de riesgo, desarrollo del producto (validación clínica), documentación técnica y el procedimiento de evaluación de la conformidad.

Conceptualización y diseño del producto

Tal y como ha explicado Monferrer, ya desde la configuración del producto, y aparte de los requisitos de diseño (funcionalidad) y usabilidad (user-friendly), los fabricantes de software deben adoptar una mirada regulatoria para mostrar conformidad con los requisitos regulatorios y normas técnicas (ISO).

Asimismo, es la fase en la que se determina la clase de riesgo de la tecnología, que, tal y como se ha mencionado anteriormente, viene marcada por las consecuencias de un posible error del software en el usuario. El producto también debe cumplir con especificaciones en cuanto a ciberseguridad e interoperabilidad, algo que obliga a los desarrolladores a implementar planes de ciberseguridad.

En la sesión celebrada también se ha puesto la lupa sobre las principales diferencias para discernir cuándo un software se clasifica como medical device y, por tanto, debe atenerse a la Medical Device Regulation, y cuando se trata de un producto de diagnóstico in vitro, gobernado por la In Vitro Diagnostic Regulation.

A pesar de que ambos tienen una finalidad médica y realizan acciones complejas de datos, el software como IVDR analiza una muestra biológica obtenida del cuerpo humano, incluidas las donaciones de sangre y tejidos, y su análisis debe ser exvivo.

Desarrollo: verificación y validación clínica

A medio camino, los investigadores llegan al proceso de desarrollo del producto, donde aparte de la verificación de su tecnología, todo software debe pasar por una evaluación clínica, para demostrar su validez con datos clínicos, según ha subrayado la experta en medical devices de Asphalion.

Documentación técnica y comercialización

Una vez se llevan a cabo estas últimas fases del desarrollo, tiene lugar la «compilación de documentación técnica» (pack documental que describe el producto: qué es, uso previsto, mecanismo de acción o principio operativo a través del cual se alcanza la finalidad, proceso de diseño y desarrollo, verificación en todos sus niveles y validación clínica final) a fin de enviarse al organismo notificado.

Una vez en el mercado, el software será objeto de planes de monitorización y seguimiento de postcomercialización para garantizar su seguridad y eficiencia. La regulación es un proceso vivo que obliga a los y las investigadoras a poner la atención en toda la normativa vigente.

Tanto si te encuentras en fase de desarrollo y evaluación clínica de tu software como medical device como si estás a un paso de lanzarlo al mercado, necesitas conocer toda la regulación que rodea esta tecnología. Esta sesión es una oportunidad para adentrarse en el complejo campo regulatorio. ¿Te has perdido el B&L o quieres volver a ver la jornada? Ya puedes acceder a la sesión grabada en vídeo.

Puedes consultar el programa del día y más información sobre la sesión en el siguiente enlace.