4 min leer
Con la evolución de la tecnología, el sector sanitario se ha interesado por integrar el software en los dispositivos médicos para incorporar la automatización y la precisión en la predicción, el diagnóstico, la prevención, el tratamiento y la gestión de las afecciones de salud. LaFDA US FDA el papel que puede desempeñar el software en el funcionamiento de los dispositivos médicos, pero aún no había elaborado ninguna orientación o norma concreta que pudiera facilitar a los investigadores del sector el avance hacia la salud digital.
El 4 de noviembre de 2021, laFDA US FDA un borrador de guía sobre«el contenido de las solicitudes previas a la comercialización para las funciones del software de los dispositivos», en el que se ofrece una idea clara a los patrocinadores responsables de preparar el documento y la información que deben incluir. Esta información proporcionada por los patrocinadores es importante para FDA evalúe el software del dispositivo que ejecuta una o más funciones y garantice la seguridad y la 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 los dispositivos médicos que la FDA comprometido a publicar en sustitución del documento de orientación de hace 15 años «Guía sobre el contenido de las solicitudes previas a la comercialización para el software incluido en los dispositivos médicos», publicado en mayo de 2005. Se ha mantenido el plazo para enviar comentarios, y cualquier debate al respecto estará abierto hasta el 2 de febrero de 2022.
En esta nueva versión, la FDA el modo de asociación del software con un dispositivo médico y los diferenció aún más en SaMD Software as a medical device SaMD Software as a medical device SiMD (software en un dispositivo médico), como subdivisiones de las funciones del software del dispositivo. Software as a medical device SaMD 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 que no forma parte de los componentes del dispositivo. 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 la preparación de documentos necesarios para las presentaciones previas a la comercialización de las funciones del software de los dispositivos. Han llegado a un claro entendimiento de lo que esperan encontrar en los documentos que establecen de forma sólida las especificaciones de requisitos de software (SRS) y las especificaciones de diseño de software o sistemas (SDS). La FDA un enfoque basado en el riesgo a la hora de documentar las solicitudes previas a la comercialización de las funciones del software de los dispositivos. En función de este nivel de preocupación o del riesgo asociado al uso previsto del dispositivo, el nivel de documentación también debe variar, ya sea documentación básica o ampliada. Los puntos clave que debe destacar cada nivel de documentación para identificar el nivel de preocupación del software asociado al 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.
- Los patrocinadores que presenten documentación mejorada deben incluir especificaciones de diseño de software o sistemas (SDS) que abarquen la información del software desde la fase de diseño. Mientras que las SRS describen la función prevista del software, las SDS proporcionan información detallada sobre la metodología de implementación de los requisitos mencionados en las SRS. Las SDS deben incluir un diseño técnico completo con información adecuada sobre la utilidad y el funcionamiento que se remonta a las SRS, si se requiere asistencia para operar el software o si se trata de un sistema CAD entrenado basado enML
- El cumplimiento de las normas consensuadas voluntarias reconocidas por la industria para las presentaciones reglamentarias sería más 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 directriz. Los dispositivos que requieren documentación básica y mejorada deben cumplir con la versión FDA de la norma 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 más precisos 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.
- Según el análisis de riesgos establecido en los requisitos del Reglamento 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 consistencia, los límites y el rango de funcionamiento, 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 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 del MDUFA IV, la Agencia debe publicar la guía definitiva en un plazo de 12 meses a partir del final del periodo de comentarios sobre el borrador. La FDA anunciado que el 16 de diciembre de 2021 celebrará un seminario web dirigido a fabricantes de productos sanitarios, investigadores del sector de la salud digital y profesionales para debatir este borrador de guía.
Para obtener más información sobre la presentación previa a la comercialización de las funciones del software de los dispositivos, reach con un experto en normativa regional como Freyr. Manténgase informado. Cumpla con la normativa.
