¿Qué es el software de procedencia desconocida (SOUP)?

5 de marzo de 2024

La publicación ha sido traducida del inglés. Siempre recomendamos leer el original. Para ello, cambia el idioma a inglés en la parte superior derecha del menú.

En el mundo de los dispositivos médicos, el software desempeña un papel fundamental. Sin embargo, no todo el software utilizado en estos dispositivos se desarrolla partiendo de cero. Con frecuencia, se integra en el dispositivo software disponible en el mercado o software de procedencia desconocida (SOUP). Pero, ¿qué es SOUP exactamente?

Update: We also released a new license checker that you can use for the SOUPs in your software, completely free to use. Simply upload your package.json or requirements.txt to get all the licenses for SOUPs in your software. It saved our clients a ton of time so we decided to make it public. Check it out here after reading the article.

Software de procedencia desconocida, también conocido como SOUP

El software de procedencia desconocida, o SOUP, es un término que se utiliza en todos los sectores para describir el software cuya seguridad, rendimiento y riesgos potenciales no se conocen por completo porque no fue desarrollado por el propio fabricante del dispositivo. Esto incluye el software disponible en el mercado (OTS) que no se ha desarrollado con un proceso o metodología de desarrollo de software conocidos y que puede incluir cualquier cosa, desde un sistema operativo, un sistema de administración de bases de datos o incluso una biblioteca de software. A continuación, daremos algunos ejemplos más específicos al respecto.

El uso de SOUP en dispositivos médicos es particularmente importante debido a los posibles riesgos que puede representar para la seguridad y el rendimiento del dispositivo. Si se desconoce la procedencia del software, puede resultar difícil evaluar la fiabilidad, la seguridad y los posibles riesgos asociados con su uso. Esto es especialmente importante en el caso de los dispositivos médicos, donde las fallas del software pueden provocar daños graves o incluso la muerte.

La norma IEC 62304 proporciona un marco para los procesos del ciclo de vida del software de dispositivos médicos, incluido el uso de SOUP. Según la sección 8.1.2 de esta norma, debe identificar SOUP por el nombre, la versión y el fabricante de cada producto de SOUP. Hemos descubierto que la mejor manera de lograrlo es a través de una lista SOUP global.

Además, las secciones 7.1.2 y 7.1.3 requieren que los fabricantes analicen cada artículo de SOUP para detectar posibles riesgos para el paciente, el operador o terceros. Esto incluye la identificación de las anomalías conocidas del software que podrían contribuir a una situación peligrosa. Un buen lugar para comprobarlo son los problemas de GitHub u otros foros de problemas relacionados con el software.

Si bien el uso de SOUP puede proporcionar ciertos beneficios, como el ahorro de costos y tiempo, es crucial que los fabricantes documenten y evalúen minuciosamente los posibles riesgos asociados con su uso de acuerdo con la norma IEC 62304.

Es posible que se pregunte «¿cómo diablos voy a documentar todo esto para mi producto?» Bueno, no es necesario clasificar todos los componentes de software como SOP. Hablemos de cuáles son las SOP y por qué

Determinación de SOUP y manejo de los desafíos

Determinar si un componente de software es un SOUP puede ser difícil, especialmente cuando se trata de sistemas complejos o código heredado. ¿Cómo clasificamos estos componentes?

El primer paso para clasificar un componente de software como SOUP es identificar si el componente de software se desarrolló siguiendo un proceso de desarrollo de software conocido o una metodología relacionada con la tecnología médica. ¿El fabricante siguió la norma IEC 62304 y se fabricó según la norma ISO 13485? Si no lo fue, o si esta información no está disponible, el componente de software puede considerarse SOUP.

En términos prácticos, la clasificación de un componente de software como SOUP implica una evaluación exhaustiva del componente de software, su uso previsto en el dispositivo médico y los posibles riesgos que presenta. Este proceso requiere un conocimiento profundo tanto del componente de software como del dispositivo médico en el que se utilizará. Estas son algunas consideraciones generales para los diferentes tipos de componentes de software:

Dependencias de Node/Python/Java/Rust: Si provienen de bibliotecas de terceros y están incluidas en el software de su dispositivo médico, son SOP
Servicios hospedados, como la autenticación o las notificaciones: Esto depende de la función. Si están contenidas en su aplicación, son SOP. A menudo, pueden residir fuera de lo que consideramos el «dispositivo médico de software» y, en este caso, estos servicios no son SOUP.
Sistemas operativos o marcos: Hay cierto debate al respecto. Dado que los sistemas operativos y los marcos suelen considerarse como el entorno en el que funciona el software y no como parte del propio dispositivo médico de software, se podría justificar que no se incluyen en el SOUP.
Herramientas de desarrollo: Todas las herramientas utilizadas en el desarrollo, como los IDE y los compiladores, no se consideran SOUP, ya que no se utilizan para una función médica sino para crear el software.

‍

Veamos algunos ejemplos de productos de SOPA y productos que no son de SOPA. Para este ejemplo, consideremos que nuestro dispositivo médico es un software que analiza una fotografía de la piel para controlar las erupciones cutáneas causadas por la psoriasis y ayudarte a mantenerte al día con tus tratamientos. El software fue creado internamente por un equipo de ingeniería, pero contiene algunos componentes de software de terceros. En la siguiente tabla, proporcionamos algunos ejemplos de esos componentes y de si son SOUP o no.

‍

Componente de Software	Fuente	SOUP	Por Qué
Servicio de notificación y SDK utilizado para enviar alertas a los usuarios en la aplicación.	Github	Sí	Esta alerta de notificación es parte del software del dispositivo médico y el software fue desarrollado en otro lugar.
Librería de Python utilizada para comparar datos de imagen de usuario con datos de referencia para diagnóstico.	Github	Sí	Esta librería se utilizó como parte de su dispositivo médico y fue desarrollada en otro lugar por un tercero no específicamente para su dispositivo médico.
Librería utilizada para renderizar gráficos y mostrar datos al usuario en la aplicación.	Github	Sí	Esta librería se utilizó como parte de su dispositivo médico y fue desarrollada en otro lugar por un tercero no específicamente para su dispositivo médico.
Autenticación utilizada para iniciar sesión de usuarios en la aplicación de software	Auth0 (o algo similar)	Probablemente sí	La mayoría de la autenticación de usuarios es fundamental para recuperar la información correcta del usuario y, por lo tanto, es parte del dispositivo médico. Sin embargo, puede haber casos en los que la autenticación no sea parte del dispositivo médico y, por lo tanto, no sea SOUP.
Sistema operativo de teléfono para la aplicación de software	Apple, Android	Probablemente no	Un SO puede considerarse externo a su dispositivo médico y parte de su "entorno operativo". Si el SO está controlado como parte de su software y es fundamental para su funcionamiento, entonces puede considerarse SOUP
Función de recomendación de tratamiento basada en datos de imagen	Ingeniero de software independiente	Probablemente no	Si el ingeniero de software independiente trabaja en su equipo, bajo sus estándares de desarrollo para ISO 13485 e IEC 62304, entonces este software es interno y no se considera SOUP.
Función de recomendación de tratamiento basada en datos de imagen	Proveedor contratado de desarrollo de software médico	No	Si contrata a un desarrollador de software certificado para producir software de dispositivo médico para crear un componente de software para usted, entonces lo que producen no es SOUP. Esto depende de sus calificaciones (ISO 13485, IEC 62304) y su acceso a sus métodos de desarrollo.

‍

Recuerde que el uso de SOUP no lo exime de garantizar la seguridad y la eficacia del dispositivo médico. Sigues siendo responsable del rendimiento del dispositivo, incluidos los componentes de software clasificados como SOUP. Por lo tanto, un proceso riguroso de gestión de riesgos es esencial cuando se trata de SOUP.

Gestión de los requisitos de documentación de IEC 62304 para SOUP

Para gestionar eficazmente los requisitos de documentación de la norma IEC 62304 para SOUP, puede adoptar algunas estrategias prácticas. Estas incluyen el mantenimiento de un inventario de SOUP, la realización de evaluaciones de riesgos periódicas y el establecimiento de un proceso sólido de gestión de cambios.

A continuación se describe con más detalle cómo llevar a cabo esos procesos:

Identifique el SOUP: El primer paso es identificar todos los SOUP utilizados en el software de su dispositivo médico por nombre, fabricante y versión del software que está utilizando. También debe identificar en qué parte de su arquitectura de software reside el SOUP. Lo primero que debe buscar en SOUP es en la lista de dependencias de cada elemento de software del software de su dispositivo médico. Si sus dependencias tienen dependencias, se cubrirán mediante la evaluación de la dependencia original.
Gestione los riesgos: La norma exige que gestione los riesgos relacionados con el uso de todos los SOP. Esto se puede capturar de forma individual en SOUP o, de manera más amplia, en su archivo de gestión de riesgos. Si el fracaso de un SOUP puede provocar daños al paciente, documéntelo en su análisis de riesgos.
Documente los requisitos de SOUP: para el software de clase de riesgo B y C, los elementos de SOUP deben tener documentados sus requisitos funcionales y de rendimiento, así como los requisitos de hardware y software del sistema. En su lista de SOP, puede especificar qué deben hacer sus SOP y qué se requiere para ejecutarlas, respectivamente.
Anomalías de SOUP: Se requiere que todas las SOP se revisen para detectar cualquier anomalía conocida. Como mínimo, cualquier lista de anomalías que exista para las SOP debe revisarse para asegurarse de que se conocen las anomalías conocidas asociadas con la SOUP.

Obviamente, esta puede ser una cantidad onerosa de documentación si tiene listas largas de bibliotecas de terceros que está incorporando a su software. Hemos descubierto que lo mejor sería utilizar una tabla para documentar la mayor cantidad posible de información sobre SOUP. Además, es una buena práctica anotar los requisitos del SOUP en la documentación de la arquitectura del software.

FormlyAI: su socio en la certificación de dispositivos médicos

En FormlyAI, entendemos las complejidades de la certificación de dispositivos médicos MDR. Nuestro servicio proporciona una ruta ágil y eficiente hacia el marcado CE y todas las herramientas para garantizar que su dispositivo médico cumpla con todas las regulaciones de la UE necesarias. Todo ello por una fracción del coste de utilizar consultores tradicionales. De esta forma, puede crear su documentación de cumplimiento y solicitar el marcado CE en cuestión de semanas, no de años.

Obtén más información sobre nuestro software y acelera tu camino hacia el marcado CE con Formly.