¡Descubre GoogleTest, con certificación TÜV y la tecnología Agentic AI para pruebas de C/C++!
Obtenga los detalles »
White Paper
¿Quieres un resumen rápido antes de empezar? Empieza a continuación.
El desarrollo de software para dispositivos médicos se enfrenta a una creciente complejidad debido a las cargas regulatorias en torno a las pruebas de cobertura de código. La guía 510(k) de la FDA exige métricas de cobertura de código para dispositivos de Clase II y Clase III, aunque los requisitos varían según la clasificación.
Soluciones de pruebas automatizadas como Parasoft C / C ++test y Parasoft DTP medir la cobertura del código automáticamente e integrarse con los procesos modernos de SDLC, reduciendo el riesgo y aumentando la confianza en la seguridad de los dispositivos. Estas herramientas ayudan a los equipos a cumplir con las recomendaciones de la FDA y facilitan la preparación de la documentación regulatoria. Europa recurre cada vez más a los estándares de la FDA estadounidense a medida que el desarrollo de productos médicos se globaliza.
La mayoría de nosotros hemos sido beneficiarios de dispositivos médicos, desde tensiómetros comunes hasta oxímetros de pulso económicos disponibles en farmacias locales, desde escáneres de tomografía computarizada operados por médicos hasta máquinas de resonancia magnética. Todos están sujetos a la regulación del gobierno estadounidense a través de la FDA.
La clasificación de los dispositivos depende del uso previsto y de las indicaciones de uso. Además, la clasificación se basa en el riesgo; es decir, el riesgo que el dispositivo representa para el paciente o el usuario es un factor clave para su clasificación. La Clase I incluye los dispositivos con el menor riesgo, mientras que la Clase III incluye los de mayor riesgo. Como se indicó anteriormente, todas las clases de dispositivos están sujetas a Controles Generales. Los Controles Generales son los requisitos básicos de la Ley de Alimentos, Medicamentos y Cosméticos (FD&C) que se aplican a todos los dispositivos médicos de Clase I, II y III. Equivalencia en la Notificación Previa a la Comercialización 510(k).
La mayoría de los dispositivos médicos requieren una notificación previa a la comercialización 510(k) de la FDA o un registro simple si están exentos. Sin embargo, si un dispositivo se implanta o presenta un riesgo potencial irrazonable de enfermedad o lesión, es probable que sea un dispositivo de Clase III que requiere aprobación previa a la comercialización (PMA). Los dispositivos nuevos e innovadores sin ejemplos previos ("dispositivos predicados") son automáticamente de Clase III, pero podrían calificar para el proceso de novo en lugar de la PMA. Solo el 10% de los dispositivos regulados por la FDA son de Clase III, pero son los que más se asocian con un mayor riesgo.
La clasificación utilizada por la FDA se basa en gran medida en el riesgo. Todos los dispositivos eléctricos siguen el estándar IEC-60601 de seguridad eléctrica, pero cada vez más los dispositivos médicos contienen un software importante.
El estándar de software más asociado con el proceso de la FDA es IEC 62304. Describe el ciclo de vida del desarrollo de software para dispositivos médicos, detallando las actividades y tareas necesarias para un diseño y mantenimiento seguros. El software puede ser una parte integrada o integral del dispositivo, o bien, el software en sí mismo puede ser un dispositivo médico.
La norma IEC 62304 especifica los requisitos del software como un subconjunto de los requisitos para un sistema médico eléctrico programable (PEMS). El software es claramente una parte del proceso de verificación de la FDA, desde la especificación de los requisitos del software hasta la integración de elementos de software en un sistema de software.
Nadie estaría muy contento si los dispositivos o equipos médicos causaran dolor, sufrimiento o condiciones potencialmente mortales. A veces lo hacen, a pesar de los mejores esfuerzos de diseñadores, ingenieros, programadores, gerentes de producto, responsables de cumplimiento normativo y todos los involucrados en diseños complejos.
Las clasificaciones han cambiado con los años: la telesalud solía ser de Clase II, pero en muchos casos se ha relajado a Clase I. Por otro lado, las directrices de seguridad se han reforzado debido a las amenazas de adquisición por botnets del IoT.
Hay al menos dos razones para querer reducir el riesgo:
Cada vez más, el software ofrece más funcionalidades en los dispositivos médicos modernos, desde la conexión a internet hasta el almacenamiento y análisis de datos. El desarrollo de casos de uso de hardware ahora debe incluir casos de uso de software, y en muchos casos, el número de combinaciones y permutaciones es cada vez mayor.
¿Cómo podemos estar seguros de que tenemos casos de prueba para todas las condiciones? Medir qué porcentaje del código de software se prueba realmente es tarea de las herramientas de cobertura de código. Las herramientas de proceso manual de AMFE solo ofrecen resultados limitados. Si un software no se prueba, no se debe confiar en él. Esto podría resultar en dispositivos médicos inseguros.
El proceso 510(k) de la FDA requiere que se implemente la norma IEC 62304, que exige los siguientes procesos: desarrollo de software, mantenimiento de software, resolución de problemas, gestión de riesgos y gestión de configuración.
Frente a la creciente complejidad y a los nuevos lenguajes y tecnologías informáticas, la importancia de automatizar la mayor parte posible del proceso de desarrollo y prueba es clave para mejorar la calidad.
Un factor clave en esto son las pruebas. La dificultad en las pruebas reside en desarrollar casos de prueba que ejerzan no solo rutas comunes, sino también casos extremos. Como se mencionó anteriormente, la FDA considera crucial la verificación.
Las normas para la autorización de comercialización de la FDA Clase II y Clase III son difíciles de descifrar, ya que la FDA no ha actualizado sus directrices en varios años. No establecen el ciclo de vida del desarrollo de software, pero sí la gestión de riesgos. Y se basan en una norma IEC para ello.
Lo que a veces falta es comprender el papel que pueden desempeñar las herramientas de análisis de cobertura de código. El análisis de cobertura de código facilita la generación de datos de prueba, la automatización de análisis y la generación de informes sobre el estado del dispositivo bajo prueba (DUT). También permite garantizar a la FDA, y a ustedes mismos, que se han probado todas las rutas críticas y condiciones límite.
Se podría pensar que la FDA emitiría normas claras sobre los tipos de análisis y, en especial, la cobertura de código necesarios para los dispositivos de Clase II y Clase III, pero lamentablemente no lo hace. Ofrecen unos "Principios Generales de Validación de Software" bastante antiguos, que describen los principios para validar el software de dispositivos médicos, así como el software utilizado para diseñar, desarrollar o fabricar dispositivos médicos. Si usted fabrica un dispositivo o equipo médico, debe cumplir con los requisitos y directrices de este documento. Los productos clasificados como Clase II o Clase III también deben contar con rigurosos controles de diseño, desarrollo, pruebas, gestión de cambios y análisis de riesgos.
Si su software se utiliza (se incorpora) en un producto, debe validarse. Si el software constituye el producto completo, por supuesto, debe indicar en su solicitud 510(k) cómo se validó. Sorprendentemente, el software utilizado en su creación también debe validarse, por lo que es importante seleccionar cadenas de herramientas de compilación y herramientas adyacentes certificadas para su uso en el desarrollo de sistemas críticos para la seguridad. Los productos Parasoft C/C++test y C/C++test CT cuentan con la certificación TÜV SÜD.
Las mejores prácticas según lo explica la FDA incluyen:
No solo hay ventajas obvias al aumentar la confianza en los dispositivos médicos, sino que también hay otros beneficios. Por ejemplo, durante el desarrollo, la herramienta de cobertura de código puede supervisar qué fragmentos de código se introdujeron pero no se probaron. Monitorear los cambios en la base de código a lo largo del tiempo aumenta la visibilidad del producto.
No solo le dará confianza a la FDA en su producto, aumentando así la probabilidad de autorización de comercialización o aprobación, sino que también reduce la carga en desarrollo, calidad, cumplimiento y otras funciones. Esto es lo correcto: una decisión de "sí, deberíamos hacerlo para mejorar la eficiencia y reducir costos".
No hay sustituto para Adopción de soluciones de pruebas de software automatizadas que ya se han utilizado en el ámbito de la seguridad crítica. Aquí es donde entra Parasoft. El software integrado en una gran cantidad de dispositivos médicos, equipos médicos y otras aplicaciones que requieren seguridad ha sido probado por Parasoft C/C++test. Solución de pruebas totalmente integrada para el desarrollo de software C/C++ y Parasoft DTP cuentan con la certificación de TÜV SÜD, lo que garantiza que estos productos han sido probados según la norma IEC 62304 para aplicaciones de destino, tanto basadas en host como integradas. Por lo tanto, cumplen con los requisitos de las normativas nacionales, regionales e internacionales de seguridad funcional.
Al implementar una potente solución automatizada de pruebas e informes analíticos, los desarrolladores de software en pruebas (SDET) evitan recurrir a métodos manuales laboriosos y propensos a errores. En su lugar, pueden centrarse en sus actividades principales de desarrollo y aumentar la profundidad y el alcance de sus pruebas para ofrecer software de alta calidad. Una solución como C/C++test, que cumple con los requisitos de la FDA y es fácil de usar, emplea pruebas estáticas y dinámicas, mientras que DTP gestiona el progreso hacia el cumplimiento mediante un panel central de informes y análisis.
Automatizar la generación de casos de prueba unitarios Es ideal para pruebas de dispositivos médicos cuando se utiliza una metodología ágil como Scrum y DevOps, ya que uno de los requisitos es que los ingenieros de desarrollo escriban casos de prueba unitaria. Como parte del proceso de compilación y antes de que se registre el código, C/C++test ejecuta automáticamente casos de prueba unitaria para garantizar que el código esté libre de regresiones y otros errores. Además, con un conjunto desplegable de opciones configurables, Parasoft recopila las métricas de cobertura de código necesarias.
Los equipos también pueden ejecutar las soluciones de Parasoft tanto desde entornos de desarrollo integrados (IDE) como desde la línea de comandos o el shell. Encuentre la información completa. Lista de cadenas de herramientas compatibles aquí.
Cobertura de código resaltada en verde y opciones de cobertura de código en C/C++test.
Los equipos pueden ver análisis prácticos en cualquier navegador. DTP consolida los resultados de las pruebas en paneles inteligentes e informes detallados.
Panel de cobertura de código completo de Parasoft DTP.
Las herramientas de cobertura de código, como las de Parasoft, pueden integrarse en un flujo de trabajo de integración/entrega continua, de modo que la solución se encargue de la mayor parte del trabajo pesado. Dado que los dispositivos médicos son cada vez más blanco de ataques, la presión sobre los equipos de desarrollo e ingeniería, que intentan incorporarse a DevOps y ahora se les exige que también consideren DevSecOps, es enorme.
Afortunadamente, la capacidad de Parasoft de ejecutarse en cualquier cantidad de IDE y/o desde la línea de comandos significa que la integración ya está proporcionada y requiere poca o ninguna configuración.
Las soluciones de Parasoft pueden probar aplicaciones que se ejecutan en los siguientes sistemas:
Si su dispositivo médico es de Clase III según la FDA, aunque requiere mayor esfuerzo, se recomienda realizar pruebas en el hardware de destino, ya que los estándares son mucho más estrictos para la Clase III. Se puede argumentar que la Clase II es aceptable para ejecutarse en el host.
A continuación se presentan cinco pasos para abordar la implementación.
¿Listo para sumergirte más profundamente?
