SW de dispositivos médicos / producto sanitario: ciclo de vida y validación. Parte 1.

Este artículo, que se ha desglosado en 2 partes, proporciona una breve introducción a los estándares y regulaciones sobre SW de dispositivos médicos para el aseguramiento de su ciclo de vida y validación. Aborda diferencias entre las autoridades reguladoras de la FDA y la Unión Europea, así como revisa estándares relevantes para el desarrollo y validación de software de dispositivos médicos.
 

Introducción 

La rápida evolución en la tecnología existente está revolucionando la forma en la que nos comunicamos y gestionamos la información. La digitalización de los dispositivos médicos para dotarlos de tecnologías avanzadas clave de la industria 4.0. no es un asunto desconocido dentro del sector de dispositivos médicos, en donde el uso de dispositivos médicos inteligentes es ya una clara apuesta y tendencia del sector. Se estima que uno de cada cuatro dispositivos médicos incorpora software para dispositivos médicos o son dispositivos médicos por sí mismos. 

Por otro lado, la digitalización de la atención sanitaria está permitiendo a pacientes y médicos interactuar con la información de salud de una manera sin precedentes para su mejor optimización y sostenibilidad. Como ejemplos clave se encuentran la tecnología Cloud, Big Data, IoT o AI/ML.

A su vez, este proceso de digitalización está generando una enorme cantidad de datos que supera con creces las capacidades analíticas de los médicos a nivel individual, por lo que estamos viviendo un gran auge de herramientas de inteligencia artificial como catalizador del análisis de datos.  Además, no debemos olvidarnos de la gran eclosión del uso generalizado de teléfonos inteligentes y productos digitales portátiles. 

El software se ha convertido en consecuencia en una parte importante del panorama del campo de los dispositivos médicos, y debemos implementarlo de una forma segura y efectiva para asegurar el uso y seguridad del dispositivo médico en cuestión.

Definiciones de SW relacionado con dispositivos médicos

A nivel mundial, existen muchos mercados para la comercialización de dispositivos médicos, pero la Unión Europea y Estados Unidos son quizás los de mayor relevancia al ser los más grandes. 

Es importante introducir y remarcar que las regulaciones de la Unión Europea y de los Estados Unidos no utilizan los mismos términos en referencia al SW relacionado con dispositivos médicos. Por un lado, la Unión Europea habla de MDSW (Medical Device Software), y Estados Unidos de SaMD (Software as a Medical Device).

Aclarar que el término SaMD es un concepto internacional, según lo define el International Medical Device Regulators Forum (IMDRF), y que éste se incluye en la legislación de muchos países (a parte de la de Estados Unidos, como es por ejemplo la del Reino Unido, o la del Canadá), mientras que MDSW es exclusivamente un término utilizado por la Unión Europea.

A continuación, revisamos y resumimos cada enfoque, y los matices más relevantes a tener en cuenta:

Estados Unidos: SaMD, SiMD

Para la FDA el software relacionado con los dispositivos médicos puede ser catalogado dentro de las siguientes tipologías:

• Software como Dispositivo Médico (SaMD): Software que por sí solo es un dispositivo médico. Es decir, es aquel que "está destinado a ser utilizado para uno o más fines médicos sin ser parte de un dispositivo de hardware". La FDA define SaMD utilizando la descripción presentada por el International Medical Device Regulators Forum (IMDRF), de la que es miembro. Para ello, debemos conocer bien el uso previsto del producto y sus indicaciones de uso, y estar en conformidad con la definición de dispositivo de la 181 sección 201(h) de la FD&C Act.
• Software en un Dispositivo Médico (SiMD): Software que es parte integral de un dispositivo médico que es utilizado para operar o controlar un dispositivo de hardware pero que no cumple con los requisitos para ser categorizado como SaMD. Es decir, es aquel que ayuda a ejecutar un dispositivo médico de hardware (por ejemplo, alimentando su mecánica o produciendo una interfaz gráfica). Sin este software, el dispositivo no podría funcionar correctamente. Un “software embebido” o “firmware” que forma parte de un dispositivo médico de hardware, o un accesorio SW para el control remoto o pantalla del dispositivo médico hardware no cumpliría con la definición de SaMD. 
• Software utilizado en la fabricación o mantenimiento de un dispositivo médico.

A continuación, revisamos unos ejemplos de cuándo un software es SaMD y no lo es:

Software como Dispositivo Médico (SaMD)

• Software que proporciona información (input) a otro dispositivo médico con hardware o software médico diferente. Por ejemplo, el software de planificación de tratamientos que suministra información utilizada en un acelerador lineal.
• El software con uso previsto médico que opera en una plataforma hardware convencional (ej.: ordenador, tableta, móvil). Por ejemplo, el software destinado al diagnóstico de una enfermedad.
• El software que está conectado a un dispositivo médico que contiene hardware pero que no es necesario para que ese producto alcance su uso previsto.

Software que no es un Dispositivo Médico (SaMD)

• Software utilizado para "accionar o controlar" los motores y la bomba de infusión de medicamentos, o software que controla un marcapasos (SiMD). 
• Software requerido por un dispositivo médico de hardware para realizar el uso previsto del dispositivo médico de hardware, incluso si se vende por separado del dispositivo médico de hardware (SiMD).
• Software que se basa en datos de un dispositivo médico, pero que no tiene un propósito médico, por ejemplo, software que cifra datos para su transmisión desde un dispositivo médico.
• Software que permite la comunicación clínica y el flujo de trabajo, incluido el registro de pacientes, la programación de visitas, las llamadas de voz y las videollamadas.
• Software que monitoriza el rendimiento o el funcionamiento adecuado de un dispositivo con el fin de darle servicio (por ejemplo, software que monitoriza el rendimiento del tubo de rayos X para anticipar la necesidad de reemplazo), o software que integra y analiza datos de control de calidad de laboratorio para identificar errores aleatorios o tendencias en la calibración de los IVDs.
• Software que proporciona parámetros que se convierten en entradas (inputs) para el software como dispositivo médico pero que no tiene un propósito médico. Por ejemplo, una base de datos que incluye funciones de búsqueda y consulta por sí misma.

Para ofrecer mayor orientación de ejemplos de cuando se trata de SaMD, la FDA ha publicado en su web varios ejemplos.

Unión Europea: MDSW

Software de dispositivo médico (MDSW) 

En el ámbito de la Unión Europea el software de dispositivo médico (MDSW) es el software destinado a ser utilizado, solo o en combinación, para un propósito especificado en la definición de "dispositivo médico" conforme a la MDR o IVDR, independientemente que el software sea independiente o impulse o influya en el uso de un dispositivo.

En resumen, se deben cumplir las siguientes tres condiciones para que el software sea clasificado como MDSW:

• Tener un propósito médico por sí solo,
• Realizar una acción sobre datos más allá del almacenamiento, archivo, comunicación, búsqueda simple o compresión sin pérdidas, y
• Estar destinado al beneficio de pacientes individuales.

Cabe mencionar que los siguientes tipos de software que no tienen un propósito de dispositivo médico en sí mismos y, por lo tanto, no se consideran MDSW, aún están sujetos a los requisitos del EU MDR o IVDR, según corresponda:

• Software que corresponde a la definición legal de "accesorio" de un dispositivo médico o de un dispositivo de diagnóstico in vitro (IVD),
• Software que corresponde a productos sin fines médicos, según lo enumerado en el Anexo XVI del MDR de la EU,
• Software que impulsa o influye en el uso de un dispositivo médico (hardware) o IVD, siempre que no tenga un propósito médico separado y no cree información por sí solo (en cuyo caso, el módulo de software con un propósito médico separado o que genere información cualificaría como MDSW). Este software puede, entre otros ejemplos:

(a) operar, modificar el estado o controlar el dispositivo ya sea a través de una interfaz (por ejemplo, software, hardware) o a través del operador de este dispositivo

(b) o suministrar salida relacionada con el funcionamiento (hardware) de ese dispositivo

Para dar orientación y guía a los fabricantes, la Comisión Europea (EC) ha publicado en su web los siguientes documentos y guías (avalados en su mayoría por la MDCG):

• MDCG 2023-4: Medical Device Software (MDSW)

– Hardware combinations Guidance on MDSW intended to work in combination with hardware or hardware components 

• Manual: Manual on borderline and classification under Regulations (EU) 2017/745 and 2017/746
• Infografía: Is your software a Medical Device?
• MDCG 2021-24: Guidance on classification of medical devices
• MDCG 2020-1: Guidance on clinical evaluation (MDR) / Performance evaluation (IVDR) of medical device software.
• MDCG 2019-16: Guidance on cybersecurity for medical devices
• MDCG 2019-11: Qualification and classification of software - Regulation (EU) 2017/745 and Regulation (EU) 2017/746.

Diferencias entre MDSW y SaMD

Mientras que SaMD se refiere únicamente al software que es independiente y excluye completamente a cualquier software “embebido” en un dispositivo médico físico, MDSW puede ser independiente o parte de un dispositivo médico de hardware, en el caso de que tenga su propio propósito de dispositivo médico además del propósito de impulsar/influir en el dispositivo médico de hardware. En MDCG 2019-11 se proporcionan un par de ejemplos de software “embebido” con fines médicos propios:

• Software de análisis de imágenes de melanoma destinado a controlar un escáner de luz láser de infrarrojo cercano.
• MDSW pretende medir y transmitir los niveles de glucosa en sangre, calcular la dosis de insulina necesaria.

Por otro lado, el término de software “standalone” (o independiente) utilizado ampliamente en la industria de la tecnología médica no es sinónimo de MDSW "standalone" ya que un MDSW "standalone" aún puede controlar o influir en un dispositivo médico de hardware.

Ciclo de vida del SW de dispositivos médicos: IEC 62304

La IEC 62304 es una norma internacional que establece requisitos y directrices para el ciclo de vida del software de dispositivos médicos. Esta norma es un estándar de consenso reconocido por las agencias de salud que establece la seguridad y eficacia de un dispositivo médico que contiene software. 

El objetivo principal de la IEC 62304 es proporcionar un marco de trabajo para el desarrollo y mantenimiento de software en dispositivos médicos, asegurando la seguridad y eficacia de estos productos. La norma se enfoca en la gestión de riesgos, la documentación, la validación y verificación del software, y garantiza que se cumplan los requisitos reglamentarios y de calidad propios de la industria de dispositivos médicos. 

Su ámbito de aplicación es el siguiente:

• El software es en sí mismo un dispositivo médico.
• El software es una parte integrante o embebida del dispositivo médico.

Por otro lado, la IEC 62304 no cubre la parte de validación clínica del sistema SW como dispositivo médico, sino la parte técnica, no clínica, desde la liberación hasta el mantenimiento y discontinuación.

Según este estándar los procesos del ciclo de vida del software de dispositivo médico son los siguientes:

• Desarrollo del software.
• Mantenimiento del software.
• Gestión de riesgos del software.
• Gestión de la configuración del software.
• Resolución de problemas del software.

Desarrollo del software

El proceso de desarrollo del software está comprendido por las siguientes etapas: 

• Plan de desarrollo del software.
• Análisis de requisitos del software.
• Diseño arquitectónico del software.
• Diseño detallado del software.
• Implementación y verificación de la unidad software.
• Integración y pruebas del sistema de software.
• Liberación de software.

Pero antes de iniciar el proceso de desarrollo del SW, los fabricantes de dispositivos médicos deben realizar una clasificación de la seguridad del software para la asignación de una clase (A, B o C) a cada sistema de software que se implemente en el dispositivo médico según su severidad conforme a los posibles efectos adversos que puedan causar sobre el paciente. Esta severidad puede ser la siguiente: 

• Clase A: no es posible que se produzcan lesiones ni daños a la salud.
• Clase B: es posible que se produzcan lesiones o daños no graves a la salud.
• Clase C: es posible la muerte o lesiones graves.

El propósito de realizar esta clasificación de seguridad del software sirve de base para determinar qué tan riguroso debe ser el proceso de desarrollo de software posterior (ver figura 1):

Figura 1: Actividades recogidas en 62304 en función del riesgo del dispositivo médico

Por otro lado, tener en cuenta que, aunque la IEC 62304 tiene una estructura bastante lineal es posible a su vez cumplir con sus requisitos utilizando un desarrollo de SW ágil. De hecho, existe otro estándar AAMI TIR 45 que ofrece orientación sobre el uso de prácticas ágiles en el desarrollo de software de dispositivos médicos. 

Es por ello importante la definición de un modelo de ciclo de desarrollo del software acorde a los estándares actuales que pueda tener cabida a enfoques agiles de desarrollo de SW más flexibles, dinámicos e incrementales, especialmente ante sistemas de software complejos en donde se necesita un mayor ajuste y redefinición de requisitos.

Mantenimiento del software

Debe establecerse un plan de mantenimiento que describe cómo se gestionará el mantenimiento del software a lo largo de su ciclo de vida. Esto incluye la identificación de las actividades de mantenimiento necesarias, la frecuencia de las actualizaciones, la gestión de riesgos asociados con el mantenimiento, y la asignación de recursos y responsabilidades.

El proceso de mantenimiento del software descrito en IEC 62304 consta de los siguientes puntos:

• Establecimiento del plan de mantenimiento del software
• Análisis de problemas y modificaciones.
• Implementación de las modificaciones.

Gestión de riesgos del software

Los requisitos de gestión de riesgos de la IEC 62304 se correlacionan con los de ISO 14971, norma internacional sobre la aplicación de la gestión de riesgos en dispositivos médicos, por lo que resulta fácil notar su interconexión. Este proceso implica la identificación, análisis, evaluación y gestión de los riesgos asociados con el software médico a lo largo de todo su ciclo de vida. Esto incluye, por ejemplo:

• Análisis del software en términos de contribución a situaciones peligrosas.
• Medidas de control de riesgo.
• Verificación de las medidas de control de riesgo.
• Gestión de riesgos de cambios en el software.

Gestión de la configuración del software

Este proceso se encarga de mantener un control estricto de las configuraciones y versiones del software a lo largo de su ciclo de vida permitiendo su trazabilidad. De esta forma se identifican y definen los elementos de software (incluyendo la documentación), así como se controlan los cambios y liberaciones, documentando e informando del estado de los elementos de configuración y solicitudes de cambio. Se incluye:

• Identificación de la configuración: Identificación de cada elemento de configuración del software y sus versiones.
• Control de Cambios: Incluyendo el proceso de solicitud de cambios.
• Histórico del control de los elementos de configuración.

Resolución de problemas del software

Finalmente, el proceso de resolución de problemas del software implica la identificación y gestión de problemas, errores o no conformidades en el software, así como la implementación de acciones correctivas para su resolución. Este proceso proporciona un medio oportuno, responsable y documentado para garantizar que el problema es analizado y resuelto. 

IEC 62304 establece un esquema general para un proceso de resolución de problemas:

• Elaboración de los informes de problemas
• Estudio del problema
• Aviso a las partes interesadas
• Uso del proceso de control de cambios
• Mantenimiento de los registros
• Análisis para la detección de tendencias en los informes de problemas
• Verificación de la resolución de problemas de software
• Contenido de la documentación de prueba/ensayo

Como regla general, es probable que encuentre menos problemas con el tiempo a medida que su producto madure. Sin embargo, es probable que la gravedad de los problemas que encuentre más adelante sea aún mayor y requiera un proceso más riguroso para resolución.

Acrónimos

AI: Artificial Intelligence
EC: European Comission
EU: European Union
FDA: Food and Drug Administration
IEC: International Electrotechnical Commission
IMDRF: international Medical Device Regulators Forum
IoT: Internet of Things
ISO: International Organization for Standardization
IVD: in vitro diagnostic medical device
IVDR: In Vitro Medical Device Regulation (EU) 2017/746
MDCG: Medical Device Coordination Group
MDR: Medical Device Regulation (EU) 2017/745
MDSW: Medical Device Software
ML: Machine Learning
SaMD: Software as a Medical Device
SiMD: Software in Medical Device
SW: Software

Datos del autor

Nombre	Mar Díaz
Empresa	Trescal Life Sciences
Cargo	Resposable Tecnica Validaciones