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 o productos sanitarios, 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 o productos sanitarios

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.

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):

CapítuloClase AClase BClase C
Planificación del desarrollo (5.1.)xxx
Análisis de los requisitos (5.2)xxx
Diseño arquitectura (5.3) xx
Diseño detallado (5.4) xx
Implementación (5.5)xxx
Ensayos test unitarios (5.5) xx
Integración (5.6) xx
Ensayos de integración (5.6) xx
Ensayos del sistema (5.7)xxx
Liberación (5.8)xxx

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.

Normativas de referencia

Las empresas fabricantes de software de dispositivos médicos deben disponer de un sistema de gestión de calidad adecuado que asegure el correcto ciclo de vida del dispositivo médico. A continuación, se dan como referencia y orientación las siguientes guías y estándares:

Estándares

  • ISO 13485 Medical Devices – Quality Management Systems – Requirements for Regulatory Purposes
  • ISO 14971 Medical Devices – Application of Risk Management to Medical Devices
  • ISO 14155 Clinical Investigation of Medical Devices for Human Subjects: Good Clinical Practice
  • IEC 62366-1 Medical devices – Part 1: Application of usability engineering to medical devices
  • IEC 62304:2006 Medical device software. Software life cycle processes.
  • IEC 82304-1:2016 Health software – Part 1: General requirements for product safety
  • ISO/TS 82304-2:2021 Health software – Part 2: Health and wellness apps. Quality and reliability
  • IEC 81001-5-1 IEC 81001-5-1 Health software and health IT systems safety, effectiveness and security.
  • ISO/IEC TR 24028:2020 Information technology — Artificial intelligence — Overview of trustworthiness in artificial intelligence
  • ISO/IEC DIS 5259-1 Artificial intelligence — Data quality for analytics and machine learning (ML) Under development (draft 2023)

Documentos guías publicados por Autoridades Regulatorias

  • CDRH. Draft Guidance – Computer Software Assurance for Production and Quality System Software. Sep 2022.
  • Europe MDCG 2021-3, Questions and Answers on Custom-Made Devices (& considerations on Adaptable medical devices and Patient-matched medical devices). Mar 2021.
  • US FDA 21 CFR 820.30, Design Control Guidance for Medical Device Manufacturers. Mar 1997.
  • US FDA CDRH, Technical Considerations for Additive Manufactured Devices – Guidance for Industry and Food and Drug Administration Staff. Dec 2017.
  • US FDA CDRH, Applying Human Factors and Usability Engineering to Medical Devices – Guidance for Industry and Food and Drug Administration Staff. Feb 2016.
  • US FDA CDER, CBER – Q7 Good Manufacturing Practice Guidance for Active Pharmaceutical Ingredients – Guidance for Industry (Revision 1). Sept 2016.
  • MITRE_MDIC (FDA) – Playbook for Threat Modeling Medical Devices.
  • Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software.
  • MDCG 2019-16—Guidance on Cybersecurity for Medical Devices.
  • Australia TGA, Guidance on Personalized Medical Devices (including 3D-printed Devices) regulatory reforms. 2022.
  • Health Canada, Supporting Evidence for Implantable Medical Devices Manufactured by 3D Printing. Apr 2019.
  • China NMPA, Technical Review Guidance for the Registration of Personalized Additive Manufacturing Medical Devices of Passive Implantable Bone, Joint and Oral Hard Tissues.
  • Japan MHLW, Guidance on Evaluation of Customized Orthopedic Devices for Osteosynthesis. Dec 2010.
  • Japan MHLW, Guidance on Evaluation of Orthopedic Customized Artificial Hip Joint Prosthesis. Dec 2011.
  • Singapore HSA, Regulatory Guideline for 3D-Printed Medical Devices, July 2021
  • South Korea MFDS, Guidance for Patient-matched Medical Devices manufactured using 3D printers. Dec 2015.
  • Discussion Papers. AI in Drug Manufacturing, (March 2023);
  • Using Artificial Intelligence and ML in the Development of Drug and Biological Products. FDA, CDER. May 2023.
  • Reflection paper on the use of Artificial Intelligence (AI) in the medicinal product lifecycle. EMA, CVMP & CHMP. Jul 2023.
  • GMLP for Medical Device Development: Guiding Principles. MHRA, Health Canada, FDA. Oct 2021.

Documentos guías publicados por IMDRF / GHTF

  • GHTF/SG3/N99-10:2004 (Edition 2) Quality Management Systems – Process Validation Guidance.
  • GHTF/SG1/N71:2012 Definitions of the Terms ‘Medical Device’ and ‘In Vitro Diagnostic (IVD) Medical Device’.
  • GHTF/SC/N4:2012 (Edition 2) Glossary and definition of terms used in GHTF documents.
  • IMDRF/ UDI WG/N48 FINAL: 2019 Unique Device Identification system (UDI) Application Guide.
  • IMDRF/PMD WG/N49 Final: 2018 Definitions for Personalized Medical Devices.
  • IMDRF/GRRP WG/N47 FINAL: 2018 Essential Principles of Safety and Performance of Medical Devices and IVD Medical Devices.
  • IMDRF/MDCE WG/N55 FINAL: 2019 Clinical Evidence – Key Definitions and Concepts.
  • IMDRF/MDCE WG/N56 FINAL: 2019 Clinical Evaluation.
  • IMDRF/MDCE WG/N57 FINAL: 2019 Clinical Investigation.
  • IMDRF/GRRP WG/N52 FINAL: 2019 Principles of Labelling for Medical Devices and IVD Medical Devices.
  • IMDRF/PMD WG/N58 FINAL: 2023 Personalized Medical Devices – Regulatory Pathways.
  • IMDRF/ MDCE WG/N65 FINAL: 2021 Post-Market Clinical Follow-Up Studies.
  • IMDRF Principles and Practices for Medical Device Cybersecurity.

Documentos guías publicados por la industria

  • ISPE. GAMP 5 Guide 2nd Edition. A Risk-Based Approach to Compliant GxP Computerized Systems. July 2022.
  • ISPE. GAMP Good Practice Guide: Enabling Innovation. Sep 2021.
  • ISPE. RDI GAMP Guides: Records and data integrity.
  • AAMI TIR45:2023; Guidance on the use of agile practices in the development of medical device software.

¿Qué ofrece Trescal? 

Desde TRESCAL ofrecemos servicios de soporte relativos al software de dispositivo médico según las normativas de aplicación, ofreciendo consultoría de calidad específica en las siguientes materias:

  • Auditoría de software.
  • Establecimiento de los requerimientos técnicos y reguladores.
  • Revisión del diseño.
  • Proceso de desarrollo y mantenimiento del software de dispositivo médico (IEC 62304).
  • Desarrollo del VMP / VP.
  • Establecimiento de estrategias.
  • Desarrollo de los expedientes de validación.
  • Actividades de verificación y validación.
  • Transición a enfoque CSA (Computer Software Assurance).
  • Cualificacion de Infraestructura IT
  • Evaluación de proveedores de SW / tecnológicos.
  • Acompañamiento a proveedores en pruebas de aceptación.
  • Procedimientos del sistema de gestión de calidad. 
  • Actividades de formación dirigida.

TRESCAL es un proveedor global de servicios para la industria LIfe Sciences que ofrece servicios de implantación/consultoría en sistemas de calidad de productos sanitarios, gestión de riesgos, Data Integrity, validación de sistemas, cualificación de equipos, calibraciones (incluyendo calibraciones dentro del sector médico/sanitario). Nuestro conocimiento específico y transversal nos permite ofrecer un servicio global de calidad como especialistas en la materia en los puntos que necesiten.

Si está evaluando la necesidad de contar con un proveedor experto para asegurar y agilizar la correcta consecución del proyecto de validación, ahorrando imprevistos y recursos, no pierda más tiempo y contacte con nosotros, nos encantará tener noticias suyas y sumarnos a su proyecto.

Acrónimos

AI: Artificial Intelligence

EC: European Comission

EU: European Union

FDA: Food and Drug Administration

GHTF: Global Harmonization Task Force

IMDRF: international Medical Device Regulators Forum

IoT: Internet of Things

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