Tras el análisis de requisitos del software, el desarrollador (o fabricante del producto sanitario) define la arquitectura o diseño arquitectónico más adecuado.
Desarrollo del diseño arquitectónico
Como base del diseño, el fabricante determina los elementos que componen su software. Tras ello, determinará cuales son los interfaces y comunicaciones entre ellos, sean software o hardware. En este punto me parece importante, por no decir esencial, planificar y documentar correctamente el desarrollo, porque como ya vimos, podríamos encontrarnos en un embudo que debe relacionar las entradas de esta fase (requisitos) con una batería de datos que debemos organizar, justificar y coordinar.
Principalmente me refiero al trinomio lenguaje – herramientas – tecnología, junto con el resto de elementos propios del modelo del ciclo de vida (donde destaco principalmente la verificación y validación del diseño).
- ¿En qué y cuántas fases dividimos el diseño?
- ¿Cuándo y cómo comprobamos que es diseño progresa y está siendo adecuado?
- ¿Cómo vamos a desarrollar el software?
- ¿Cómo probaremos que es adecuado para desempeñar su funcionamiento? ¿Qué impacto tiene en estas pruebas las tecnologías que intervienen en el diseño? ¿Y en el funcionamiento? ¿Cómo garantizamos la integración con otros elementos (por ejemplo hosting o datos de entrada)?
- ¿Cómo y cuándo será necesario mantener el Software?
Elementos SOUP
Del inglés Software Of Unknown Provenance o software de origen desconocido, son elementos del programa informático con origen desconocido.
En este punto, se ha abierto una discusión en torno a si se trata de una falta de origen propio, como pudiera ser un componente que no hubiera sido directamente desarrollado por el fabricante. En otro extremo están los que dicen que se corresponde con los elementos o componentes software que no han sido desarrollados con una metodología o proceso conocido. Parece que pudiera limitarse, en este último caso, a por ejemplo, software de distribución libre.
En todo caso, mi recomendación es que se tenga en cuenta la posibilidad de hacer un análisis específico de riesgos, o un «GAP analisis» para estar preparado ante diferencias de criterio.
Será necesario, en todo caso, proporcionar los elementos y cumplir las especificaciones requeridas por estos elementos en caso de que finalmente sean incorporados.
Verificación de la arquitectura
El fabricante de producto sanitario diseña, documenta y justifica que:
- La arquitectura seleccionada es adecuada para cumplir los requisitos; todos los requisitos que mencionamos con anterioridad e incluso los derivados del control del riesgo.
- La arquitectura es capaz de soportar los interfaces necesarios que conectan (de forma eficaz) los diferentes elementos.
- Finalmente, que la arquitectura soporta (y permite un desarrollo eficaz) de los elementos SOUP.
CONCLUSIÓN
Parece, por tanto, que toma casi la misma importancia que tiene la elección y diseño de la arquitectura; la justificación y verificación de la misma.
En este ámbito recomiendo como elementos complementarios a los requeridos por esta norma armonizada, usar el concepto de proceso de diseño; desarrollado por ISO 13485.
Bajo mi punto de vista la implementación de un archivo histórico de diseño nos proporciona la evidencia de los procesos de revisión, verificación y validación del producto; junto con la trazabilidad de los documentos y de los cambios en el diseño.
Adicional a esto último, como metodología de trazabilidad de los requisitos y de su cumplimiento y evidencia, empleo el concepto de la salida de diseño.
