4 min de lectura
Con la evolución de la tecnología, el sector sanitario se ha interesado en integrar software en los 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 las condiciones de salud. La US FDA reconoció desde hace tiempo el papel que el software puede desempeñar para beneficiar el funcionamiento de los dispositivos médicos, pero aún debía presentar directrices o normas concretas que facilitaran a los investigadores del sector avanzar hacia la salud digital.
El 4 de noviembre de 2021, la US FDA publicó un proyecto de guía sobre el 'contenido de las presentaciones previas a la comercialización para funciones de software de dispositivos', ofreciendo una idea clara a los patrocinadores responsables de preparar el documento y sobre qué información incluir. Esta información proporcionada por los patrocinadores es importante para que la FDA evalúe el software del dispositivo que ejecuta una o más funciones y para garantizar la seguridad y la eficacia durante todo su ciclo de vida. La nueva guía es una recomendación y una versión preliminar sobre las funciones de software de dispositivos médicos que la FDA se ha comprometido a publicar en sustitución del documento de guía de hace 15 años titulado 'Guía para el contenido de la presentación previa a la comercialización del software contenido en dispositivos médicos', publicado en mayo de 2005. Han dejado abierto el plazo para recibir comentarios y debates sobre el mismo 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ó en SaMD (Software as a Medical Device) y SiMD (Software in a Medical Device), como subdivisiones de las funciones de software de dispositivos. El software como producto sanitario o SaMD es un software que realiza por sí mismo la tarea de un dispositivo médico según la definición de dispositivo médico mencionada en la Sección 201 (h) de la Ley FD&C, pero no forma parte de un componente del dispositivo. Por otro lado, el software en SiMD, como su nombre indica, viene como parte del componente del dispositivo médico o del hardware utilizado para registrar, controlar o mostrar información médica o no médica.
El proyecto se centra más en las expectativas de la FDA respecto a la preparación de documentos necesarios para las presentaciones previas a la comercialización de funciones de software de dispositivos. Presentaron una comprensión clara de lo que esperan ver en los documentos que establezcan de forma sólida las Especificaciones de Requisitos de Software (SRS) y las Especificaciones de Diseño de Software o de Sistema (SDS). La FDA enfatiza un enfoque basado en riesgos al documentar para las presentaciones previas a la comercialización de funciones de software de dispositivos. Según este nivel de preocupación o el riesgo asociado con el uso previsto del dispositivo, el nivel de documentación también debe variar en documentación básica y mejorada. Los puntos clave que cada nivel de documentación debe destacar para identificar el nivel de preocupación del software asociado con el dispositivo médico son:
- La visión general del software 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 interfaz de usuario/experiencia de usuario (UI/UX)
- Las Especificaciones de Diseño de Software o de Sistema (SDS) que cubren información del software desde la etapa de diseño son requeridas para los patrocinadores que presentan documentación mejorada. Mientras que el SRS describe la función prevista del software, el SDS es información detallada sobre la metodología de implementación de los requisitos mencionados en el SRS. El SDS debe incluir detalles de diseño técnico exhaustivos con información adecuada sobre la utilidad y el funcionamiento que se vinculen con el SRS, ya sea que se requiera asistencia para operar el software o que sea un sistema CAD entrenado construido sobre modelos de IA/ML
- La adhesión a las normas de consenso voluntarias reconocidas por la industria para presentaciones reglamentarias será más sencilla y estará más en sintonía con las tendencias actuales del mercado de la salud digital, las prácticas y las innovaciones, según este nuevo proyecto de guía. Los dispositivos que requieren documentación básica y mejorada deben cumplir con la versión reconocida por la FDA de la norma ANSI/AAMI IEC 62304 de software para dispositivos médicos - Proceso del ciclo de vida del software. Los documentos mejorados requieren una descripción adicional de la configuración completa con detalles aún mayor sobre el plan de desarrollo de diseño y mantenimiento en el ciclo de vida del software para una mejor claridad durante la revisión
- Basándose en el análisis de riesgos según los requisitos de las Regulaciones del Sistema de Calidad (21 CFR 820), también se debe incluir información relacionada con la seguridad, como el entorno operativo, la eficacia, la precisión, el tiempo de respuesta, el tiempo de retraso, la consistencia, los límites y el rango operativo, y cualquier valor base o umbral sobre el cual el software deba operar. Debe mencionarse la provisión de cualquier sistema de vigilancia para rastrear los datos registrados utilizando 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, las cuales se logran probando los componentes del software a nivel de sistema o integración. Esto es obligatorio para la documentación mejorada. Además, también se debe analizar la descripción de los protocolos de prueba junto con los resultados esperados u observados para establecer el estado de aprobación/fallo del sistema
- Cualquier participación de anomalías no resueltas como errores o defectos que puedan afectar el rendimiento de la función del software debe identificarse y clasificarse en función de la taxonomía de defectos según la clasificación de defectos en software de salud de ANSI/AAMI SW91
La documentación mejorada debe presentarse para los dispositivos que son un producto combinado, están clasificados como dispositivos de alto riesgo de Clase III, o son una función de software destinada a ser utilizada en aplicaciones de donación y transfusión de sangre que realiza la evaluación de compatibilidad entre donante y receptor. Los dispositivos que requieren documentación especial deben seguir los requisitos de documentación mejorada. La documentación básica debe resumir el análisis de peligros, la mitigación de riesgos y los informes de justificación de riesgos.
Según los compromisos de MDUFA IV, la Agencia debe publicar la guía definitiva dentro de los 12 meses posteriores al final del periodo de comentarios del proyecto. La FDA ha anunciado la organización de un seminario web el 16 de diciembre de 2021 para fabricantes de dispositivos médicos, investigadores de la industria de la salud digital y profesionales para debatir sobre este proyecto de guía.
Para saber más sobre la presentación previa a la comercialización de funciones de software de dispositivos, póngase en contacto con un experto regional en asuntos regulatorios como Freyr. Manténgase informado. Manténgase en cumplimiento.
