El término "software como producto sanitario" es definido por International Medical Device Regulators Forum (IMDRF) como "software destinado a ser utilizado para uno o más fines médicos que realiza estos fines sin formar parte de un producto sanitario de hardware".
Pero no todos el software utilizado en la atención sanitaria puede calificarse como producto sanitario. El software destinado a procesar, analizar, crear o modificar información médica sólo puede calificarse como software de producto sanitario si tiene una finalidad médica bien definida.
En particular, para ser calificado como producto sanitario, el producto debe cumplir tanto la definición de software como la definición de "producto sanitario" (MD, Medical Device) de conformidad con el artículo 2, apartado 1, del Reglamento (UE) 2017/745 (MDR) o, alternativamente, la definición de "producto sanitario para diagnóstico in vitro" (IVD, In vitro Diagnostic Medical Device) del artículo 2, apartado 2, del Reglamento (UE) 2017/746 (IVDR).
Producto sanitario significa todo instrumento, aparato, dispositivo, software, implante, reactivo, material u otro artículo destinado por el fabricante a ser utilizado, solo o en combinación, en seres humanos para uno o varios de los siguientes fines médicos específicos:
-
Diagnóstico, prevención, monitorización, predicción, pronóstico, tratamiento o alivio de enfermedades;
-
Diagnóstico, seguimiento, tratamiento, alivio o compensación de una lesión o discapacidad;
-
Investigación, sustitución o modificación de la anatomía o de un proceso o estado fisiológico o patológico;
-
Suministro de información mediante el examen in vitro de especímenes derivados del cuerpo humano, incluidas las donaciones de órganos, sangre y tejidos, y que no logran su acción principal prevista por medios farmacológicos, inmunológicos o metabólicos, en o sobre el cuerpo humano, pero que pueden ser asistidos en su función por dichos medios.
Producto sanitario para diagnóstico in vitro: cualquier producto sanitario que sea un reactivo, producto de reactivo, calibrador, material de control, kit, instrumento, aparato, pieza de equipo, programa informático o sistema, utilizado solo o en combinación, destinado por el fabricante a ser utilizado in vitro para el examen de muestras, incluidas las donaciones de sangre y tejidos, derivadas del cuerpo humano, con el fin exclusivo o principal de proporcionar información sobre uno o varios de los siguientes aspectos:
-
Relativos a un proceso o estado fisiológico o patológico;
-
Relativos a deficiencias físicas o mentales congénitas;
-
Relativos a la predisposición a una afección médica o a una enfermedad;
-
Para determinar la seguridad y compatibilidad con posibles receptores;
-
Para predecir la respuesta o las reacciones al tratamiento;
-
Para definir o supervisar medidas terapéuticas.
Por tanto, el primer paso es calificar el software de "médico". ¿Y después? En este punto, es importante entender a qué regulación puede referirse el software.
En este caso particular, la Guía MDCG 2019-11 sobre Calificación y Clasificación de Software en el Reglamento (UE) 2017/745 - MDR y el Reglamento (UE) 2017/746 - IVDR pueden brindar apoyo ya que la guía indica las etapas de decisión para la cualificación de un software como un producto sanitario o como un producto sanitario de diagnóstico in vitro.
En la guía, queda claro que si la información proporcionada por el software se basa en datos obtenidos de un producto sanitario para diagnóstico in vitro, entonces el software es un producto sanitario para diagnóstico in vitro. En caso contrario, si los datos analizados se obtienen de productos sanitarios y de productos sanitarios de diagnóstico in vitro, el fabricante deberá sopesar las fuentes de datos y la información necesaria para alcanzar el fin previsto para determinar si el software entra dentro de la regulación de productos sanitarios o dentro de la de producto sanitario de diagnóstico in vitro.
Ahora, llegamos a la parte interesante, que son las reglas de clasificación.
Según el Reglamento (UE) 2017/745, si el software se define como un producto activo, para la clasificación de producto activos (hardware), se deben considerar las siguientes reglas del Anexo VIII:
-
La regla 9 se aplica a los productos terapéuticos activos destinados a administrar o intercambiar energía, así como a los productos activos destinados a controlar, supervisar o influir directamente en determinados productos;
-
La regla 10 se aplica a los productos activos para el diagnóstico y la vigilancia o destinados a la radiología diagnóstica o terapéutica;
-
La regla 11 se aplica al software para la toma de decisiones con fines diagnósticos o terapéuticos o al software destinado a supervisar procesos fisiológicos;
-
La regla 12 se aplica a los productos activos destinados a la administración y/o extracción de sustancias;
-
La regla 13 se aplica cuando no se aplican las demás reglas;
-
La regla 15 se aplica a los productos utilizados con fines anticonceptivos; y
- La regla 22 se aplica a los sistemas de circuito cerrado.
Por el contrario, en el caso del software que entra en la calificación de productos sanitarios para diagnóstico in vitro, deben tenerse en cuenta todas las normas de clasificación del anexo VIII del Reglamento (UE) 2017/746.
Cabe señalar que, en ambos casos, las reglas de clasificación se regirán por la finalidad prevista del producto. Recuerda que el software cualificado con una finalidad prevista médica bien definida puede comercializarse de dos formas diferentes: como producto sanitario o producto sanitario para diagnóstico in vitro por derecho propio, o como componente integral o parte de un dispositivo de hardware.
A continuación se presentan algunos ejemplos de software que pueden clasificarse según el IVDR:
- Software autónomo capaz de combinar una serie de resultados de IVD para calcular e informar de un resultado adicional que se utilizará con fines clínicos;
- Software que impulsa o influye en el uso de un instrumento IVD;
- Software integrado en un producto sanitario de IVD (por ejemplo, instrumento o analizador);
- Software independiente destinado a la estadificación o predicción de la gravedad de una enfermedad mediante un algoritmo basado en una combinación de medidas antropométricas y biomarcadores no invasivos.
Además, a continuación se ofrecen algunos ejemplos de software que puede clasificarse según MDR:
- Software que muestra imágenes de resonancia magnética y otros tipos de imágenes médicas en dispositivos móviles;
- Software que interpreta los datos de entrada del paciente para desarrollar un plan de tratamiento para el paciente;
- Software que analiza y supervisa el rendimiento o el funcionamiento de un producto sanitario.
En este escenario, es importante disponer de las normas (SOTA, state-of-the-art) que deben seguirse al desarrollar software como Productos Sanitarios.
Por ejemplo, tanto para el software MDR como para el IVDR, se debe seguir la norma IEC 62304:2006+A1:2015 Procesos de ciclo de vida de software para productos sanitarios: Esta norma cubre el desarrollo de software, el mantenimiento de software, la gestión de riesgos y la gestión de la configuración para un SaMD.
Además, tanto para el software MDR como para el IVDR, se debe seguir la norma IEC 62366-1:2015+A1:2020 Productos Sanitarios Parte 1: Aplicación de la ingeniería de usabilidad a productos sanitarios. Esta norma se utiliza para verificar el grado en que un producto puede ser utilizado por usuarios específicos para lograr ciertos objetivos con eficacia, eficiencia y satisfacción en un contexto de uso específico.
Si el software también es un "Software de Salud", se debe seguir una norma adicional de SOTA, la IEC 82304-1:2017 Software de Salud Parte 1: Requisitos generales de seguridad del producto, porque esta norma cubre las actividades de validación del producto necesarias para el SaMD.
Hay que tener en cuenta que pueden aplicarse otras normas para un software concreto ( IVD o MD) en función de su finalidad prevista o en función de sus características/funcionalidades.
En conclusión, para entender si un software está regulado como producto sanitario o como producto sanitario para diagnóstico in vitro, es importante y fundamental definir su finalidad prevista. Este concepto es el que define su ámbito de aplicación y, por tanto, qué reglamentos y normas deben seguir.
Por supuesto, es importante que la finalidad prevista coincida con la funcionalidad del software.