5 consejos para análisis estático y dinámico en software de dispositivos médicos

La ciberseguridad es un fuerte enfoque de la FDA con requisitos específicos en torno al análisis de código estático y dinámico. Como resultado, es importante que los ingenieros automaticen estas prácticas y las integren en los flujos de trabajo de desarrollo existentes.

Para empresas que desarrollan y entregan software crítico para la seguridad y la protección para dispositivos médicos, implementan prácticas de análisis de código estático y dinámico y las implementan en proyectos que van desde medidores de glucosa en sangre relativamente simples hasta sistemas más complejos como bombas de infusión, monitores de pacientes y pulmones. unidades de ventilación es parte integral del proceso. Esta publicación cubre análisis de código estático vs dinámico en software de dispositivos médicos y comparte consejos prácticos y mejores prácticas.

Introducción al análisis de riesgos de software de dispositivos médicos

Los dispositivos médicos son una parte esencial del sistema de salud moderno. La Organización Mundial de la Salud (OMS) estima que hay alrededor de 2 millones de dispositivos médicos en todo el mundo. Dada la evolución de la inteligencia artificial (IA), el aprendizaje automático (ML) y el Internet de las cosas (IoT), los dispositivos médicos modernos se han vuelto más conectados que nunca, aumentando su nivel de complejidad y casos de uso.

Con la creciente integración de la tecnología en la práctica médica, los dispositivos médicos dependen cada vez más del software para realizar algunas funciones clave. Por ejemplo, los dispositivos médicos pueden hacer cosas, como analizar imágenes médicas y brindar soporte de diagnóstico, implementar implantes inteligentes con sensores que se comunican con dispositivos de escritorio o móviles y realizar procedimientos quirúrgicos robóticos, entre otras cosas. Si bien el software de dispositivos médicos ha avanzado en el campo de la medicina, nos deja algunos riesgos que deben manejarse con cuidado.

Los riesgos del software de dispositivos médicos pueden provenir de varias fuentes, incluidos errores de codificación, mal funcionamiento del hardware, errores del usuario, etc. Estos riesgos pueden potencialmente causar daño a los pacientes, profesionales de la salud o cualquier persona que entre en contacto con el dispositivo.
Además de los riesgos anteriores, los riesgos de ciberseguridad rodean a estos dispositivos, ya que recopilan, almacenan, procesan y transmiten datos médicos. Por lo tanto, los organismos reguladores como la Administración de Alimentos y Medicamentos (FDA) están ahí para regular la fabricación y el despliegue de software de dispositivos médicos. Sin embargo, para saber si el software de su dispositivo médico cumple con estos estándares regulatorios, es vital realizar un análisis de riesgo exhaustivo del software de dispositivo médico antes de usarlo.

¿Qué es el análisis de riesgos de software de dispositivos médicos?

Antes de discutir software de dispositivos médicos análisis de riesgo, veamos el riesgo. En la definición más básica, el riesgo es la posibilidad de pérdida o lesión. El análisis de riesgos del software de dispositivos médicos es el proceso de probar el software de dispositivos médicos para identificar, evaluar y mitigar los riesgos asociados con ellos. También implica probar el uso previsto del software, la funcionalidad y los peligros potenciales para los pacientes o los operadores utilizando algunos puntos de referencia de gestión de riesgos.

Para los fabricantes de dispositivos médicos, el análisis de riesgos es un componente esencial del proceso de desarrollo de software de dispositivos médicos. Es un requisito esencial que ayuda a los fabricantes de dispositivos médicos a cumplir con los estándares normativos.

El objetivo principal del análisis de riesgos de software de dispositivos médicos es garantizar que el software sea seguro y efectivo, no solo para uso médico, sino también para garantizar que estos dispositivos no sean susceptibles a ataques cibernéticos y provoquen una violación de datos significativa.

¿Por qué es importante el análisis de riesgos de software de dispositivos médicos?

Imagine poner un automóvil en la carretera sin revisar algunas de las partes críticas como el sistema de frenos, la bolsa de aire, las luces, la suspensión y los sistemas de dirección. Ignorar estos controles podría aumentar la probabilidad de tener un accidente automovilístico. Lo mismo ocurre con la implementación de software de dispositivos médicos sin someterlo a un análisis de riesgos.

El análisis de riesgos del software de dispositivos médicos es crucial para garantizar la seguridad del paciente y reducir la posible aparición de riesgos médicos y violaciones de seguridad en los registros médicos de los pacientes.

Además, las agencias reguladoras como la FDA requieren que los fabricantes de dispositivos médicos realicen un análisis de riesgo en el software de sus dispositivos médicos antes de que puedan ser aprobados para su uso por parte del consumidor. El incumplimiento de los requisitos reglamentarios puede causar retrasos en la aprobación del dispositivo o provocar retiros del mercado.

En otras palabras, el análisis de riesgos también puede ayudar a los fabricantes a identificar oportunidades para mejorar la seguridad y la facilidad de uso de los dispositivos, lo que podría conducir a un aumento de las ventas y la participación de mercado.

El marco regulatorio para el análisis de riesgos de software de dispositivos médicos

El desarrollo de software de dispositivos médicos está regulado por varios organismos reguladores, como la FDA y el Reglamento Europeo de Dispositivos Médicos (MDR).

Como agencia reguladora, la FDA garantiza la seguridad, la eficiencia y la seguridad de los medicamentos humanos y veterinarios, los productos biológicos, los dispositivos médicos, los suministros de alimentos, los cosméticos y otros productos. La misión de la FDA es proteger y promover la salud pública mediante la regulación y supervisión del desarrollo, la fabricación, la comercialización y la distribución de estos productos.

De manera similar, ISO 13485 es un estándar reconocido a nivel mundial que describe los requisitos de calidad en la industria de dispositivos médicos. Este estándar ofrece pautas prácticas para que los fabricantes implementen prácticas comerciales y técnicas para garantizar que todos los dispositivos médicos cumplan con las normas y las necesidades del cliente.

Al adoptar las mejores prácticas y procesos descritos en ISO 13485, los fabricantes pueden optimizar sus operaciones, reducir costos, administrar riesgos, aumentar la productividad y mejorar continuamente sus productos y servicios.

También existe IEC 62304, que es un conjunto de estándares internacionales que proporciona pautas para el desarrollo, mantenimiento y gestión de riesgos del software de dispositivos médicos. El marco describe los requisitos que se deben cumplir para garantizar que el software utilizado en los dispositivos médicos sea seguro, confiable y cumpla con los estándares aceptables. IEC 62304 especifica los procesos de desarrollo de software, procedimientos de verificación y validación de requisitos de documentación.

Estos marcos regulatorios están diseñados para servir como estándares para realizar análisis de riesgo en dispositivos médicos. Por lo tanto, su cumplimiento es esencial para obtener la aprobación reglamentaria para desarrollar software de dispositivos médicos y demostrar el compromiso de un fabricante con la excelencia y la capacidad para ofrecer productos de alta calidad.

Para que los fabricantes de software de dispositivos médicos cumplan con estas regulaciones, a menudo se requieren procesos de prueba de software para verificar errores de programación, violaciones de estándares de codificación, violaciones de sintaxis, configuraciones inseguras y similares. Aquí es donde análisis de código estático y análisis dinámico Adelante.

Análisis de código estático

El análisis estático es una práctica. de verificar automáticamente el cumplimiento de las pautas de codificación conocidas (MISRA, CERT, AUTOSAR, JSF) y detectar posibles errores, como la desreferenciación de puntero nulo, la división por cero y los desbordamientos de búfer. Las modernas herramientas de análisis estático también complementan la práctica tradicional de revisión de código al reducir el esfuerzo manual en al menos un 30 %.

En la mayoría de los casos, la primera ejecución de una herramienta de análisis estático contra su código actual mostrará miles de errores. Algunos equipos de desarrollo de dispositivos médicos han encontrado incluso más de 20,000 XNUMX en la primera ejecución. Esto puede ser increíblemente abrumador. Parece que llevaría años arreglarlos todos. Aquí hay algunos consejos de expertos para hacer frente al problema.

Consejo #1: El compilador es tu amigo

Los equipos de desarrollo disciplinados generalmente compilan con –Wall y –Werror (en GCC), o /Wall /WX (en Visual Studio) o usan opciones similares en otros compiladores. Reparar las advertencias del compilador es una forma fácil y económica de prepararse para la ejecución del análisis estático. Revisar la salida de su compilador en un modo "paranoico" puede reducir el volumen general de violaciones de análisis estático.

Si bien haber corregido todas las advertencias del compilador es algo bueno, hay muchos proyectos en los que usar solo un compilador no será suficiente y no es una opción aceptable por motivos de cumplimiento.

Después de agotar su compilador, use herramientas de análisis estático que están destinadas a profundizar mucho más en el código y brindarle muchas más sugerencias.

Sugerencia n.° 2: adopte el análisis estático al comienzo del proceso

Si actualmente está desarrollando software para dispositivos médicos, debe estar preparado para abordar la cuestión de un práctica de análisis de código estático automatizado. Es casi seguro que el análisis estático sea un tema de discusión durante una auditoría interna/externa o incluso una presentación previa a la comercialización.

La clave es implementar la herramienta de tal manera que el desarrollo no pierda velocidad mientras se enfoca en mejorar la calidad, y no tiene que lidiar con la idiosincrasia y el ruido de la herramienta. Este es un acto de equilibrio que requiere práctica y experiencia. Lo que puede encontrar es que mientras descubre la causa raíz de los errores informados, es probable que descubra que muchos de ellos son fáciles de solucionar.

Aquí hay algunos ejemplos de un informe de análisis estático que son fáciles de corregir con un script simple o pasantes bien capacitados.

1. Llamada de funciones claras en destructores.
   1. El destructor '~CTitle' no debe llamar a la función 'clear_' que no está en el contexto de prueba
   2. El destructor '~THelper' no debe llamar a la función 'removeModule' que no está en el contexto de prueba
2. Compruebe NULL.
   1. "pMP" puede ser nulo
   2. “((NPage*)this)->pSysCfg_” posiblemente sea nulo
3. Posiblemente declaración en la sección incorrecta.
   1. Los miembros de datos 'D_FILE_1' se declaran como 'públicos'
4. Argumentos no constantes.
   1. El literal de cadena "MCollection" se pasa a la función 'FixedBlockHeap' como puntero a un objeto no constante

Puede dejar de lado muchas infracciones en el código existente y tratarlas cuando tenga tiempo de inactividad. Sin embargo, es importante NO introducir nuevas infracciones, conocidas como deuda técnica, a medida que desarrolla el código. Por ejemplo, Parasoft C / C ++test tiene características que permiten a los ingenieros filtrar el ruido y concentrarse en corregir las violaciones recientes más críticas del análisis estático.

Análisis dinámico

Mientras que el análisis estático interpreta el código fuente como texto y saca todas las conclusiones basándose en la salida del analizador sin ejecutar una sola instrucción, pruebas de seguridad de aplicaciones dinámicas o DAST proporciona una perspectiva diferente sobre el código. Examina el código en ejecución y muestra la cobertura del código, la suficiencia y la calidad de las pruebas unitarias, las fugas de memoria y otros posibles problemas de debilidad.

Consejo n.º 3: sea flexible con su entorno de tiempo de ejecución

El término "incrustado" cubre una gran cantidad de dispositivos, desde MCU de 8 bits con kilobytes de RAM y flash hasta CPU multinúcleo de 64 bits con gigabytes de RAM y SSD de alta velocidad. En caso de que el funcionamiento diario del dispositivo requiera una memoria y una potencia de procesamiento mínimas, es probable que los fabricantes opten por hardware orientado solo a sus necesidades, teniendo en cuenta las limitaciones de tamaño, peso o coste.

Aunque suelen dejar cierta capacidad para las actualizaciones y el mantenimiento del software, aún puede ser insuficiente cuando se trata de la herramienta de análisis dinámico que instrumenta el software, ya que el proceso requerirá una gran cantidad de RAM en comparación con el modo de funcionamiento normal y espacio de almacenamiento para recopilar pruebas. y resultados de cobertura de código.

Por lo tanto, cuando la cantidad de memoria en el dispositivo es demasiado baja para ejecutar pruebas y recopilar cobertura de código, es posible que la plataforma de destino no sea adecuada para recopilar cobertura de código para pruebas unitarias y de integración.

Si su plataforma de destino principal no es compatible desde el primer momento, busque alternativas válidas. Podría haber una plataforma hermana con más interfaces y memoria respaldada por una herramienta de análisis dinámico para que pueda usarla para la unidad y algunas pruebas de integración. Otra alternativa es utilizar simuladores de hardware, que ejecutan ARM Fast Models y QEMU.

Si bien la ejecución de pruebas en la plataforma de destino es lo más deseable, muchas veces los equipos optan por realizar pruebas de integración de unidades y algunas aplicaciones en la estación de trabajo del desarrollador, como Linux, Mac, Windows, para beneficiarse de un ciclo de desarrollo más rápido y una mayor cantidad de herramientas. disponible para plataformas de desarrollo general. En ese caso, deberá portar su código incrustado para compilar con un compilador host, lo que podría presentar algunos desafíos.

Hay muchos compiladores, herramientas de compilación, marcos y métodos para ejecutarlos. Las herramientas de análisis dinámico admiten algunas técnicas de compilación comunes con presunciones internas sobre cómo los desarrolladores podrían aplicarlas. Por lo tanto, incluso si el código es portátil, lo más probable es que el equipo del proyecto necesite tiempo adicional para alinear la configuración de una herramienta de análisis dinámico según cómo funcione el sistema de compilación del proyecto.

Se recomienda encarecidamente que todos los esfuerzos se estimen con anticipación para elegir el mejor enfoque para el desarrollo futuro y el apoyo en una perspectiva a largo plazo.

Consejo n. ° 4: no confíe demasiado en los casos de prueba generados automáticamente

Las modernas herramientas de análisis dinámico generan automáticamente conjuntos de pruebas unitarias para aumentar la cobertura del código. Pero las herramientas son solo herramientas. Son independientes de varios escenarios de cómo se pretende usar el código de producción, especialmente cuando intenta aumentar la cobertura del código y cruzar un límite entre las pruebas unitarias puras y las pruebas de integración. Todavía tendrá que actualizar manualmente las pruebas unitarias generadas e incluso escribir otras nuevas porque solo usted sabe qué pretende hacer el código cuando se trata de resultados de prueba positivos y negativos.

Un conjunto de archivos seleccionados en un área crítica puede tener pruebas unitarias generadas automáticamente cubiertas en un rango de 40% hasta 100% para cada archivo. Pero en promedio, para todo el proyecto, los números pueden variar del 25% al ​​60%.

Además, las pruebas unitarias generadas automáticamente que utilizan solo el código fuente como entrada a menudo pueden ejecutarse perfectamente en código con errores. La generación automática debe utilizarse como una buena manera de iniciar el proceso de prueba unitaria. El proceso de creación de casos de prueba manualmente mejora la calidad del código porque obliga a una revisión adicional del código y proporciona un punto de vista diferente sobre el diseño.

Sugerencia n.° 5: no subestime el esfuerzo de calificación y validación de herramientas

La FDA requiere que cualquier herramienta utilizada durante el desarrollo formal sea validada para el uso previsto para garantizar que realice las acciones esperadas y produzca los resultados correctos. Por lo general, este es un protocolo de prueba especial llamado IUV (validación de uso previsto).

Los proveedores líderes en la industria de herramientas de análisis estático y dinámico ayudan a producir los procedimientos y la documentación necesarios, lo que es extremadamente útil para minimizar sus esfuerzos. Las soluciones de Parasoft son especialmente valiosas porque automatiza gran parte del proceso. Al igual que con cualquier otro paquete genérico, es posible que desee reservar algunos de sus esfuerzos para revisar y ajustar documentos para sincronizarlos con sus propios procedimientos de SGC. Por ejemplo, Tool Qualification Kit de Parasoft proporciona un conjunto de casos de prueba que se ejecutarán en su entorno para validar las capacidades de análisis estático y dinámico.

Resumen de 5 consejos

Trate las advertencias del compilador como errores. Las advertencias pueden convertirse en errores más adelante para la versión más reciente del mismo compilador. Las advertencias a menudo significan que el compilador hace algo implícitamente.

1. Ejecute herramientas de análisis estático al principio del proyecto y solucione los problemas a medida que aparezcan.
2. Mantenga el código portátil. Incluso si no planea portar su producto a otra plataforma, esta podría ser una opción en el futuro. Por otro lado, esto también ayudará a mantener su código limpio, fácil de mantener y legible, lo que siempre es bueno para su revisión y soporte adicional.
3. No confíe demasiado en los casos de prueba generados automáticamente para mejorar la calidad del código.
4. No subestime la necesidad y el esfuerzo de validar la herramienta para su uso previsto.

Gestión de riesgos en el desarrollo de software de dispositivos médicos

Al desarrollar software para dispositivos médicos, la gestión de riesgos es un componente crítico del proceso. El software de dispositivos médicos a menudo es complejo y debe funcionar dentro de estrictos puntos de referencia para garantizar la seguridad y la eficiencia de los dispositivos médicos. Como resultado, es esencial identificar, analizar y mitigar los riesgos potenciales que podrían surgir durante el proceso de desarrollo.

• La gestión eficaz de riesgos en el desarrollo de software de dispositivos médicos implica una serie de actividades diferentes. Estos pueden incluir:
• Identificar peligros y riesgos potenciales asociados con el dispositivo y su software.
• Evaluar la probabilidad y severidad de los riesgos.
• Implementar controles de riesgo para mitigar o eliminar los riesgos.
• Supervisar la eficacia de esos controles a lo largo del tiempo.

Además, la gestión de riesgos en el desarrollo de software de dispositivos médicos también requiere una comprensión profunda del nivel de daño que puede causar un defecto en el software médico. Esto se puede hacer a través de la indexación de riesgos, que clasifica los riesgos según su nivel de gravedad.
En el contexto del software de dispositivos médicos, establecer un índice de riesgo ayuda a determinar los indicadores de gestión de riesgos, como el nivel requerido de prueba, verificación y validación que se debe realizar en el software antes de que se lance para su uso. También puede ayudar a establecer el tono para las pruebas, el monitoreo y el mantenimiento continuos que pueden ser necesarios para garantizar la seguridad y eficacia continuas del software.

La importancia de la gestión de riesgos en el desarrollo de software de dispositivos médicos

La gestión eficaz de riesgos es fundamental en el desarrollo de software para dispositivos médicos. Incluso los errores o descuidos menores pueden tener graves consecuencias para los pacientes del sector sanitario. En consecuencia, es esencial identificar y mitigar los riesgos potenciales lo antes posible en el proceso de desarrollo.

A continuación se presentan algunas de las razones por las que la gestión de riesgos es importante en el desarrollo de software de dispositivos médicos:

• Garantiza la seguridad del paciente. Las fallas en el software de los dispositivos médicos pueden generar riesgos para la salud. La gestión de riesgos eficaz ayuda a identificar riesgos potenciales y mitigarlos antes de que causen daño a los pacientes.
• Garantiza el cumplimiento normativo. El desarrollo de software de dispositivos médicos está sujeto a requisitos reglamentarios establecidos por organismos reguladores como FDA y EU MDR. El cumplimiento de estas normas es fundamental para evitar sanciones y reducir la probabilidad de retirada de productos. También puede salvar a los fabricantes de dispositivos médicos de ser considerados responsables de cualquier daño causado por sus productos, salvándolos de consecuencias legales y financieras.
• Ahorra tiempo y dinero. La gestión de riesgos efectiva puede ayudar a reducir el tiempo y el costo de tratar problemas de productos y acciones legales. Identificar los riesgos al principio del ciclo de vida del desarrollo de software puede evitar que surjan problemas más adelante y evitar retrasos en el tiempo de comercialización del producto.
• Aumenta la reputación. Ningún fabricante de dispositivos médicos querría arriesgarse a tener una mala reputación, ya que una mala reputación puede afectar las posibilidades de éxito. La gestión de riesgos eficaz ayuda a demostrar que el fabricante está comprometido con la seguridad del paciente y la calidad del producto, lo que puede mejorar la reputación de una empresa.

Elementos clave de la gestión de riesgos en el desarrollo de software de dispositivos médicos

Llevar a cabo la gestión de riesgos en el desarrollo de software de dispositivos médicos puede ser complicado. Sin embargo, existen elementos clave que pueden servir como guía para los desarrolladores de software de dispositivos médicos y los probadores de control de calidad. Aquí hay cinco de ellos.

1. Comience con la identificación de riesgos. El primer paso en la gestión de riesgos es identificar los riesgos potenciales asociados con el proceso de desarrollo de software de dispositivos médicos. Esto se puede hacer a través de un análisis exhaustivo del proceso de diseño, desarrollo y prueba del software. Los riesgos potenciales pueden incluir fallas de software, violaciones de seguridad de datos y fallas de hardware.
2. Realice una evaluación de riesgos. Una vez que se han identificado los riesgos, el siguiente paso es evaluar la gravedad y la probabilidad de cada riesgo. Esto implica considerar factores como la gravedad del riesgo, la probabilidad de que ocurra y sus posibles consecuencias.
3. Desarrollar medidas de mitigación y control de riesgos. En este punto, el objetivo es desarrollar estrategias de mitigación de riesgos para reducir o eliminar los riesgos identificados. Esto puede incluir el rediseño del software, la implementación de funciones de seguridad o la capacitación de los usuarios. Los desarrolladores también podrían desarrollar medidas de control de riesgos para minimizar o eliminar los riesgos identificados tomando medidas como rediseñar el software, implementar funciones de seguridad adicionales o desarrollar manuales de usuario y programas de capacitación para el dispositivo.
4. Vigilar los riesgos. El monitoreo de los riesgos potenciales en el software de dispositivos médicos debe ser continuo. Esto significa que incluso después de implementar estrategias de control y mitigación de riesgos, es crucial continuar monitoreando los riesgos a lo largo del ciclo de vida del desarrollo del software. Esto puede implicar pruebas y evaluaciones continuas del software para garantizar que continúe funcionando según lo previsto y que no presente nuevos riesgos.
5. Documentar los riesgos. Es importante documentar todas las actividades de gestión de riesgos, incluidas las evaluaciones de riesgos, las estrategias de mitigación de riesgos y la supervisión continua. Esta documentación es fundamental para demostrar el cumplimiento de los requisitos reglamentarios y garantizar que los riesgos se gestionen de manera eficaz durante todo el proceso de desarrollo de software.

Resumen

La gestión de riesgos es un aspecto crucial del desarrollo de software de dispositivos médicos. Someter los dispositivos médicos a análisis estáticos y dinámicos son dos de las mejores formas de evaluar los riesgos en el software de dispositivos médicos.

Con el análisis estático y dinámico, los desarrolladores de software de dispositivos médicos pueden identificar los riesgos potenciales de forma temprana, evitar daños a los pacientes, garantizar el cumplimiento normativo, ahorrar tiempo y crear software que sea menos vulnerable a los ataques cibernéticos.

Afortunadamente, Parasoft ofrece un conjunto integral de soluciones de automatización de pruebas de software que admiten varias prácticas recomendadas para las pruebas de dispositivos médicos en C / C ++, Javay .NET aplicaciones Se ha demostrado que estas herramientas mejoran la seguridad, la confiabilidad y la experiencia del usuario del software de dispositivos médicos.

“MISRA”, “MISRA C” y el logotipo del triángulo son marcas comerciales registradas de The MISRA Consortium Limited. © The MISRA Consortium Limited, 2021. Todos los derechos reservados.