Los fabricantes de Software como Producto Sanitario o SaMD (Software as Medical Device) tienen que documentar el ciclo de vida completo del desarrollo del SW de acuerdo con la norma IEC62304. La metodología no está definida y se puede usar la que mas convenga. Es de aplicación para todo software médico y al ciclo de vida completo y además requiere de la aplicación de la ISO14971
El SaMD se clasifica de acuerdo con la norma IEC62304 por clases de seguridad:
- si el SW no puede contribuir a una situación peligrosa o contribuye a una situación peligrosa que no resulta en un riesgo inaceptable después de tomar las medidas de control de riesgo entonces decimos que es un SW con clase A de Seguridad.
- si el SW puede contribuir a una situación peligrosa que resulta en un riesgo inaceptable después de tomar las medidas de control de riesgo y el resultado del posible daño no es serio, entonces decimos que es un SW con clase B de Seguridad.
- si el SW puede contribuir a una situación peligrosa que resulta en un riesgo inaceptable después de tomar las medidas de control de riesgo y el resultado del posible daño es serio o la muerte, entonces decimos que es un SW con clase C de Seguridad.
Cuando no exista una clasificación clara siempre lo clasificaremos como Clase C.
Apartados de la norma
La norma IEC62304 se desglosa en apartados y se requiere que el ciclo de vida del SW sea implementado con los procesos de los apartados 5, 6, 7, 8 y 9 y será responsabilidad del fabricante documentarlos convenientemente. Estos procesos son:
- Desarrollo del SW
- Mantenimiento del SW
- Gestión del riesgo del SW
- Gestión de la configuración
- Resolución de problemas
Así tenemos que dependiendo de la clase de seguridad que tenga el SW (A, B o C) le aplicaremos unos apartados de la norma u otros como se muestra a continuación:
Ciclo de vida de desarrollo del software
El ciclo de vida del desarrollo del SW, según la norma EN 62304 la podemos dividir en estas partes:
Proceso de Desarrollo del Software
Los fabricantes pondrán los medios necesarios para que el proceso de desarrollo del SW esté totalmente planificado por uno varios planes que detallaran los subprocesos que lo componen, los entregables o documentos de cada actividad y tarea, la trazabilidad entre los requisitos del sistema, los requisitos del SW, los requerimientos de sistema de ensayo o test y las medidas de control de riesgo implementadas. El Plan o planes se deben tener actualizados de forma continua.
Proceso de mantenimiento
Como mantenimiento de SW entendemos los procedimientos para realizar actualizaciones, resolución de errores, parches de seguridad y qué hacer cuando se produzca la obsolescencia del SW. Este proceso estará totalmente planificado y se detallaran: los procedimientos para recabar, documentar, evaluar, resolver y realizar la trazabilidad del feedback sobre el software después de su entrega. No solo esto sino que también será necesario establecer los criterios para determinar el grado del feedback para considerarlo un problema u otra cosa.
Proceso de gestión del riesgo del Software
Por cada modulo de software que pueda contribuir a una situación de riesgo, se definirán las medidas de gestión y control del mismo. Cualquier cambio en el SW o cualquier evento no identificado anteriormente estará sujeto a una verificación de las medidas de control de riesgo para ver en qué manera podría afectar a la seguridad del SW.
Proceso de gestión de la configuración
Será necesario establecer un esquema para la identificación de las configuraciones y sus versiones. El fabricante solo realizará un cambio en la configuración o aplicará una configuración nueva después de una aprobación de petición de cambio. Deberá existir una trazabilidad desde la petición de cambio hasta la aprobación del cambio. Todas las configuraciones y sus cambios quedarán reflejadas en un documento para que se pueda realizar una trazabilidad del proceso.
Proceso de resolución de problemas
Ante cualquier problema detectado deberemos generar un informe del problema. Es importante reflejar el tipo de problema/resolución, como correctiva, preventiva, adaptativa a un nuevo entorno. Reflejaremos el alcance del problema así como nº de unidades, modelos o accesorios afectados, al igual que el tiempo invertido en la acción. Ser requiere una investigación que determine las causas, que evalúe las posibles consecuencias usando el proceso de gestión del riesgo en caso de que este nuevo problema resulte ser un riesgo que hay que gestionar y que no conocíamos hasta el momento. Es importante informar sobre el problema a los partes involucradas. Las partes involucradas en un problema pueden depender de si el SW se ha liberado ya o no, si se encontró dentro de la organización o fuera de ella, etc…El fabricante decidirá en cada caso las partes a ser informadas. El informe puede reflejar también una tendencia que se esté produciendo.
