Como base fundamental del desarrollo del producto sanitario software se encuentra el proceso de mantenimiento. Se considera como un proceso metódico y planificado, que responde a las necesidades propias del producto sanitario.
Plan de mantenimiento software como parte del proceso de mantenimiento
El proceso de mantenimiento debe ser un proceso; por ello, recibe entradas y que genera salidas. Responde a una planificación prediseñada por el fabricante y que garantiza siempre el mantenimiento de la capacidad de cumplir los requisitos.
El plan de mantenimiento del software producto sanitario contendrá al menos:
- Un procedimiento de recepción de las solicitudes. Por ejemplo, una dirección de email dedicada o un portal web específico.
- Un sistema de documentación; regresando a los ejemplos anteriores el propio sistema de tickets o una gestión sistemática de los emails recibidos.
- Un método de evaluación de estas comunicaciones por personal adecuado, en relación con el propio proceso de diseño.
- Una resolución que, tras la evaluación, aprueba o deniega el cambio.
- Una responsabilidad de seguimiento que garantice el proceso.
Proceso de mantenimiento y el de diseño
Adicionalmente, como parte del plan de mantenimiento, y que bajo mi punto de vista, en muchas ocasiones se integrará en el propio proceso de diseño:
- Criterio para determinar si estas solicitudes de cambio constituyen problemas o eventos no deseados (típicamente, bajo mi punto de vista, integrándolo de una u otra manera con la gestión de la no conformidad y/o con el Seguimiento posmarket.
- El proceso metodológico que actualiza la gestión de riesgos.
- El proceso de resolución de problemas; que en un contexto de entrega continua y metodologías ágiles creo que pierde protagonismo.
- Una mención al proceso de gestión de la configuración, que en el contexto que termino de mencionar (además del tratamiento como rediseño), considero que respondería a la propia implantación o puesta en producción.
- Con una mención especial, dependiendo muchísimo del caso, una metodología para evaluar e implementar los cambios en el SOUP. Como adelantaba en publicaciones anteriores creo que el concepto SOUP, paulatinamente, está quedando obsoleto. No me refiero a las propias unidades SOUP, sino al concepto relacionado con el riesgo de que un elemento quede obsoleto o presente dificultades de integración. Considero que el proceso de desarrollo software, cada vez más, tienen hacia modelos basados en servicios, lo que garantiza la interoperabilidad. Como digo, depende mucho de cada caso, por ello, importante considerarlo; cuando no aplique deberá justificarse.
Problemas y modificaciones
En relación con el producto sanitario software que sea liberado, por su propia naturaleza como producto sanitario; el fabricante debe controlar, gestionar y liderar la información recibida. Esta información recibida debe ser analizada y, cuando sea necesario, se debe acompañar de las acciones en cada caso necesarias. En mi opinión, este no es un requisito nuevo en el producto sanitario y propongo que sea gestionado, independientemente de qué soporte use cada fabricante, de acuerdo con su propio proceso de no conformidad, de reclamaciones y/o retroalimentación junto con el de vigilancia.
Comunicación y vigilancia de mercado
En línea con lo anterior, cuando el problema o las modificaciones requeridas pudieran suponer cambios en el cumplimiento de la Regulación aplicable, sobre productos liberados, se deberá comunicar a usuarios y autoridades. En este aspecto, considero que lo más adecuado es implementar un sistema integrado de gestión de la calidad que garantiza que las comunicaciones o retroalimentación se analizan sistemáticamente; de forma que, cuando se descubre un potencial incidente, se aplica el proceso de vigilancia, común a cualquier producto sanitario.
CONCLUSIONES
En mi humilde opinión, bajo el enfoque actual de diseño y desarrollo software, los productos software se ven sometidos a un proceso continuo de mejora y rediseño. Es por ello, que el concepto de mantenimiento queda casi reducido, en la práctica, a una metodología eficaz del control de versiones.
Cada nueva versión será liberada, tras ser verificada y validada. Como corresponda en cada caso y, cuando sea necesario, de forma paralela, cuando una información haga sospechar la aparición de un incidente, se deberá actuar informando a las partes afectadas y Autoridades, siendo lo más ágiles posible en la posible retirada o información a usuarios. En el caso específico de los SaaS, inhabilitando el acceso.