El proceso de gestión de los riesgos en software como producto sanitario. Es aquel responsable de velar por la seguridad y funcionamiento del producto frente a peligros o situaciones peligrosas previsibles.
Contribución a situaciones peligrosas
El primer paso del proceso es la identificación de los elementos que podrían contribuir a una situación peligrosa, o peligro. Como parte de este análisis es necesario identificar las causas potenciales.
- Identificación errónea o incorrecta de las especificaciones y requisitos.
- Defectos en los elementos software.
- Fallo o resultados inesperados en los SOUP (Software of Unknown Provenance).
- Fallos hardware o imprevisibles del propio software.
- Cualquier mal uso razonablemente previsible.
Anomalías del SOUP
Como fuente típica, y externa, de situaciones peligrosas se encuentran los componentes SOUP. Como comentaba en anteriores publicaciones, considero que se trata de un concepto que tiende a desaparecer como origen de comportamientos inadecuados o desconocidos; desde un punto de vista actual, creo que el desarrollo tiende hacia un concepto de servicio y hacia un funcionamiento integrado de los diferentes SOUP.
En todo caso y como guía de buenas prácticas, el desarrollados del software se cerciorará de haber revisado cualquier lista o indicio de anomalía, como proceso de gestión de riesgos en Software como producto sanitario.
Documentará cualquier anomalía detectada, junto con la versión del SOUP con que se relaciona, así como la secuencia previsible de eventos; en el registro de gestión de riesgos, diseñando e implementando las acciones necesarias en cada caso. En este aspecto, es importante mantener la trazabilidad de los peligros – medidas de control – elementos; requisito que considero asequible asegurando políticas de gestión de riesgos y de control de versiones de software producto sanitario.
Gestión de riesgos de cambios en el software
Tan importante, o más que el propio proceso de gestión será el de análisis (y verificación) de ausencia de nuevos peligros emergentes de nuevas versiones software. En este aspecto, para evidenciar la ausencia de nuevos peligros y de un impacto negativo de los cambios sobre el código anterior; recomiendo que el control de versiones sea un proceso ágil y eficaz, donde quede relacionado con nuevas versiones del Archivo de gestión de riesgos por coincidencia temporal; idealmente, en el moderno entorno actual, con el uso de commits en programas Git, de control de código.
CONCLUSIÓN
Como parte esencial del proceso de gestión de riesgos en software producto sanitario, tras la identificación de peligros y la determinación de la secuencia previsible de eventos; se perfila la documentación de los riesgos, sus medidas y la verificación de las mismas. En el contexto de un proceso de gestión de cambios, resalta por encima del resto la documentación y análisis de los mismos, para lo que resulta esencial su trazabilidad, los peligros y las medidas implementadas en cada caso.
Los elementos SOUP, conocidos por su alta probabilidad de introducir riesgos, a priori no controlados. Deben ser gestionados junto con el propio estado de la tecnología actual.
