Con la evolución de la tecnología, la industria de la salud se ha interesado en integrar software con Dispositivos Médicos para incorporar automatización y precisión en la predicción, diagnóstico, prevención, tratamiento y gestión de condiciones de salud. La FDA de EE. UU. había reconocido durante mucho tiempo el papel que el software puede desempeñar para beneficiar el funcionamiento de los Dispositivos Médicos, pero aún no había presentado ninguna guía o norma concreta que pudiera haber facilitado a los investigadores de la industria avanzar hacia la salud digital.
El 4 de noviembre de 2021, la FDA de US publicó un borrador de guía sobre ‘el contenido de las presentaciones previas a la comercialización para funciones de software de Dispositivos’, dando una idea clara a los patrocinadores responsables de preparar el documento y 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 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 de software de Dispositivos Médicos que la FDA se ha comprometido a publicar como reemplazo del documento de guía de 15 años de antigüedad ‘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 mantenido abierto el plazo para recibir comentarios, y cualquier discusión al respecto está abierta 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ó aún más en SaMD - Software como Dispositivo Médico y SiMD - Software en un Dispositivo Médico, como subdivisiones de las funciones de software de los dispositivos. El Software como Dispositivo Médico o SaMD es un software que por sí mismo realiza 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 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 con respecto a la preparación de documentos requeridos para las presentaciones previas a la comercialización de funciones de software de dispositivos. Llegaron a una comprensión clara de lo que esperan ver en los documentos que establecen de manera robusta la Especificación de Requisitos de Software (SRS) y las Especificaciones de Diseño de Software o del Sistema (SDS). La FDA enfatiza un enfoque basado en el riesgo al documentar las presentaciones previas a la comercialización de funciones de software de dispositivos. Basado en este nivel de preocupación o el riesgo asociado con el uso previsto del dispositivo, el nivel de documentación también debe variar entre 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:
- La descripción general del software que presenta las entradas y las 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 de Software o Sistema (SDS) que cubren la información del software desde la etapa de diseño se requieren 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 un detalle de diseño técnico completo con información adecuada sobre la utilidad y el funcionamiento que se remonta al SRS, ya sea que se requiera asistencia para operar el software o si es un sistema CAD entrenado basado en modelos de IA/ML.
- La adhesión a los estándares de consenso voluntarios reconocidos por la industria para las presentaciones reglamentarias sería fácil y estaría más en sintonía con las tendencias, prácticas e innovaciones actuales del mercado de la salud digital, 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 ANSI/AAMI IEC 62304 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 mayores sobre el plan de desarrollo de diseño y mantenimiento en el ciclo de vida del software para una mayor claridad durante la revisión.
- Según el análisis de riesgos y los requisitos de las Regulaciones del Sistema 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 consistencia, los límites y el rango de operación, y cualquier valor base o umbral que el software requiera para funcionar. Debe mencionarse la provisión de cualquier sistema de vigilancia para rastrear los datos registrados utilizando la memoria o el sistema de almacenamiento del dispositivo.
- Como parte del ciclo de vida del software, la verificación y validación del software son esenciales, logradas mediante la prueba de los componentes del software a nivel de sistema o integración. Esto es obligatorio para una documentación mejorada. Además, también debe discutirse la descripción de los protocolos de prueba junto con los resultados esperados u observados para establecer el estado de aprobado/reprobado del sistema.
- Cualquier implicació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 según la taxonomía de defectos de la Clasificación de defectos en software de salud de ANSI/AAMI SW91.
Se requiere la presentación de documentación mejorada para dispositivos que son un producto combinado, o clasificados como un dispositivo de Clase III de alto riesgo, o 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 del donante y el receptor. Los dispositivos que requieren documentación especial deben seguir los requisitos de documentación mejorada. La documentación básica debe incluir informes resumidos de análisis de peligros, mitigación de peligros y justificación de riesgos.
Según los compromisos de MDUFA IV, la Agencia debe publicar la guía final en un plazo de 12 meses a partir del final del período de comentarios del borrador. La FDA ha anunciado que organizará 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, con el fin de discutir este borrador de guía.
Para saber más sobre la presentación previa a la comercialización de funciones de software de dispositivos, contacte a un experto reglamentario regional como Freyr. Manténgase informado. Manténgase en cumplimiento.