4 min leer
Con la evolución de la tecnología, el sector sanitario se ha aficionado a integrar software con dispositivos médicos para incorporar automatización y precisión en la predicción, el diagnóstico, la prevención, el tratamiento y la gestión de los problemas de salud. La FDA estadounidense reconoció hace tiempo el papel que el software puede desempeñar en beneficio del funcionamiento de los dispositivos médicos, pero aún no había presentado ninguna directriz o norma concreta que pudiera haber facilitado a los investigadores del sector los avances hacia la salud digital.
El 4 de noviembre de 2021, la FDA de EE.UU. publicó un borrador de directrices sobre el "contenido de las presentaciones previas a la comercialización para funciones de software de dispositivos", dando una idea firme a los patrocinadores responsables de preparar el documento y qué información deben incluir. Esta información facilitada por los patrocinadores es importante para que la FDA evalúe el software del dispositivo que ejecuta una o varias funciones y garantice la seguridad y eficacia a lo largo de su ciclo de vida. La nueva guía es una recomendación y una versión preliminar sobre las funciones del software de dispositivos médicos que la FDA se ha comprometido a publicar en sustitución del documento de orientación de 15 años de antigüedad "Guidance for the content of pre-market submission for the software contained in Medical device", publicado en mayo de 2005. Han mantenido abierta la ventana para comentarios y cualquier discusión al respecto hasta el 2 de febrero de 2022.
En esta nueva versión, la FDA reconoció el modo de asociación del software con un dispositivo médico y los diferenció además en SaMD - Software as a medical device (software como dispositivo médico) y SiMD - Software in a Medical Device (software en un dispositivo médico), como subdivisiones de las funciones de software de los dispositivos. El software como producto sanitario o SaMD es un software que realiza por sí mismo la tarea de un producto sanitario según la definición de producto sanitario mencionada en la Sección 201 (h) de la Ley FD&C, pero no forma parte de un componente del producto. Por otro lado, el software en SiMD, como su nombre indica, forma parte del componente o hardware del dispositivo médico utilizado para registrar, controlar o mostrar información médica o no médica.
El borrador se centra más en las expectativas de la FDA respecto a la preparación de los documentos necesarios para la presentación previa a la comercialización de las funciones de software de los dispositivos. Han llegado a una clara comprensión de lo que esperan ver en los documentos que establecen sólidamente la Especificación de Requisitos de Software (SRS) y el software o las Especificaciones de Diseño del Sistema (SDS). La FDA hace hincapié en un enfoque basado en el riesgo a la hora de documentar las presentaciones previas a la comercialización de las funciones de software de los dispositivos. Basándose en este nivel de preocupación o en el riesgo asociado con el uso previsto del dispositivo, el nivel de documentación también se supone que varía como documentación básica y mejorada. Los puntos clave que cada nivel de documentación requiere destacar para identificar el nivel de preocupación del software asociado con el dispositivo médico son:
- Visión general del programa informático que da una idea de las entradas y salidas
- Especificaciones de requisitos de software (SRS), que incluyen detalles de la arquitectura del software con un diagrama esquemático de todos los módulos, periféricos, lenguajes de programación, sistema operativo, versión del compilador, uso de cualquier software de shell y cualquier detalle de UI/UX.
- Las especificaciones de diseño del software o del sistema (SDS), que incluyen información sobre el software desde la fase de diseño, son necesarias para que los patrocinadores presenten documentación mejorada. Mientras que las SRS describen la función prevista del software, las SDS son información detallada sobre la metodología de implementación de los requisitos mencionados en las SRS. La SDS debe incluir un diseño técnico exhaustivo con información adecuada sobre la utilidad, el funcionamiento que se remonta al SRS, si se requiere asistencia para manejar el software o si se trata de un sistema CAD capacitado basado en modelos AI/ML.
- La adhesión a las normas de consenso voluntario reconocidas por la industria para las presentaciones reglamentarias sería más fácil y más en sintonía con las tendencias actuales del mercado de la salud digital, las prácticas y las innovaciones de acuerdo con este nuevo proyecto de directriz. Los dispositivos que requieren documentación básica y mejorada deben cumplir con la versión reconocida por la FDA de ANSI/AAMI IEC 62304 Medical device software- Software lifecycle process. Los documentos mejorados requieren una descripción adicional de la configuración completa con detalles aún mayores sobre el desarrollo del diseño y el plan de mantenimiento en el ciclo de vida del software para una mayor claridad durante la revisión.
- Sobre la base del análisis de riesgos conforme a los requisitos de la normativa sobre sistemas de calidad (21 CFR 820), también debe incluirse información relacionada con la seguridad, como el entorno operativo, la eficacia, la precisión, el tiempo de respuesta, el tiempo de retardo, la coherencia, los límites operativos y el rango, y cualquier valor base o umbral que el software requiera para funcionar. Debe mencionarse cualquier sistema de vigilancia para el seguimiento de los datos registrados mediante la memoria del dispositivo o el sistema de almacenamiento.
- Como parte del ciclo de vida del software, la verificación y validación del software son esenciales, y se consiguen probando los componentes del software a nivel de sistema o de integración. Esto es obligatorio para mejorar la documentación. Además, hay que describir los protocolos de prueba junto con los resultados esperados u observados para establecer el estado correcto/incorrecto del sistema.
- Cualquier anomalía no resuelta, como errores o defectos que puedan afectar al rendimiento de la función de software, debe identificarse y clasificarse según la taxonomía de defectos de ANSI/AAMI SW91's Classification of defects in health software.
Se requiere la presentación de documentación mejorada para los productos que sean un producto combinado o estén clasificados como productos de alto riesgo de clase III o una función de software destinada a ser utilizada en aplicaciones de donación y transfusión de sangre que realice la evaluación de compatibilidad del donante y el receptor. Los productos que requieren documentación especial deben seguir los requisitos de documentación mejorada. La documentación básica debe resumir los informes de análisis de peligros, mitigación de peligros y justificación de riesgos.
De acuerdo con los compromisos de MDUFA IV, la Agencia debe publicar la guía final en un plazo de 12 meses tras la finalización del periodo de comentarios del borrador. La FDA ha declarado que organizará un seminario web el 16 de diciembre de 2021 para los fabricantes de dispositivos médicos, los investigadores de la industria de la salud digital y los profesionales para discutir este proyecto de guía.
Para obtener más información sobre la presentación previa a la comercialización de funciones de software de dispositivos, póngase en contacto con un experto regional en regulación como Freyr. Manténgase informado. Cumpla la normativa.
