Validación de Software en Producto Sanitario por Oqotech

La validación de software en producto sanitario es un proceso determinante en la calidad y confiabilidad del producto final

La validación de software en Producto Sanitario es un proceso que se lleva a cabo para asegurar la calidad y la confiabilidad del producto de una organización.

Vamos a revisar de forma exhaustiva el ámbito de aplicación de la validación de software en Producto Sanitario, la regulación aplicable en la Unión Europea, los principios a seguir y las actividades y tareas a llevar a cabo.

Aplicabilidad

La validación de software en producto sanitario aplica a:

• Software utilizado como componente, pieza o accesorio de un dispositivo médico.
• Software que es en sí mismo un dispositivo médico (por ejemplo, software de gestión de hemocomponentes para los bancos de sangre).

Regulación aplicable en la UE

La regulación aplicable a la validación de software en producto sanitario es el Reglamento (UE) 2017/745 sobre los productos sanitarios, el cual reza en el guión 4to, literal b, apartado 6, Verificación y Validación de los Productos:

“b) información detallada sobre el diseño del ensayo, protocolos completos de ensayo o estudio, métodos de análisis de los datos, además de resúmenes de datos y conclusiones, en particular en relación con:

_ Verificación y validación del programa informático (descripción del diseño y el proceso de desarrollo del programa y pruebas de su validación tal como se usa en el producto final. Esta información contendrá normalmente un resumen de los resultados de verificaciones, validaciones y ensayos efectuados a nivel interno y en entorno de uso simulado o real antes de su aprobación final. Tendrá asimismo en cuenta las diversas configuraciones del soporte físico y, en su caso, los sistemas operativos mencionados en la información facilitada por el fabricante);”

Verificación VS Validación

La verificación del software permite validar de manera objetiva que los resultados del diseño de una fase particular del ciclo de vida del desarrollo del software cumplen con todos los requisitos especificados para esa fase.

La verificación del software persigue la consistencia, la integridad y la corrección del software y su documentación de respaldo, a medida que se desarrolla, y proporciona soporte para una conclusión posterior de que el software está validado.

Las pruebas de software representan una de las muchas actividades de verificación destinadas a confirmar que la salida de desarrollo de software cumple con sus requisitos de entrada. Otras actividades de verificación incluyen varios análisis estáticos y dinámicos, inspecciones de códigos y documentos, tutoriales y otras técnicas.

Por otra parte, la validación de software en producto sanitario es una parte de la validación del diseño para un dispositivo terminado, pero no está definida por separado en la regulación del Sistema de Calidad.

La FDA considera que la Validación de Software en Producto Sanitario es “confirmación mediante examen y provisión de evidencia objetiva de que las especificaciones del software se ajustan a las necesidades del usuario y los usos previstos, y que los requisitos particulares implementados a través del software se pueden cumplir consistentemente.”

En la práctica, las actividades de validación de software en producto sanitario pueden ocurrir durante y al final del ciclo de vida de desarrollo de software para garantizar que se cumplan todos los requisitos. Dado que el software es generalmente parte de un sistema de hardware más grande, la conclusión de que el software está validado depende en gran medida de pruebas integrales de software, inspecciones, análisis y otras tareas de verificación realizadas en cada etapa del ciclo de vida del desarrollo del software.

Las pruebas de la funcionalidad del software del dispositivo en un entorno de uso simulado y las pruebas en el sitio del usuario generalmente se incluyen como elementos de un programa de validación de diseño general para un dispositivo automatizado de software.

La verificación y validación del software son difíciles porque un desarrollador no puede probar para siempre, y es difícil saber cuánta evidencia es suficiente. En gran medida, la Validación de Software en Producto Sanitario es una cuestión de desarrollar un “nivel de confianza” de que el dispositivo cumple con todos los requisitos y expectativas del usuario para las funciones automatizadas del software y las características del dispositivo.

Medidas como evaluar los defectos encontrados en los documentos de especificaciones, las estimaciones de los defectos residuales, la cobertura de las pruebas y otras técnicas se utilizan para desarrollar un nivel de confianza aceptable antes de enviar el producto al mercado. El nivel de confianza, y por lo tanto el nivel de esfuerzo de validación, verificación y prueba del software necesario, variará dependiendo del riesgo de seguridad (peligro) que plantean las funciones automáticas del dispositivo.

En líneas generales, la verificación del software puede responder a la pregunta ¿Se está desarrollando el software de forma correcta? Mientras que la validación del software se refiere a la pregunta: ¿Estamos desarrollando el producto correcto?

Principios de la validación de software en producto sanitario

A continuación, enumeramos los principios generales a considerar para la validación de software en producto sanitario:

• Requisitos: el proceso de validación del software no puede completarse sin una especificación de requisitos de software establecida.
• Prevención de defectos: la garantía de calidad del software debe enfocarse en prevenir la introducción de defectos en el proceso de desarrollo del software y no en tratar de “probar la calidad” en el código del software una vez que está escrito. Y, para ello, los desarrolladores de software deben usar una combinación de métodos y técnicas para evitar errores de software y detectar errores de software que sí ocurren.
• Tiempo y Esfuerzo: la preparación para la validación del software debe comenzar temprano, es decir, durante la planificación del diseño y el desarrollo y la entrada del diseño.
• Ciclo de vida del software: el ciclo de vida del software contiene tareas de ingeniería de software y la documentación necesaria para respaldar el esfuerzo de validación del software. Además, el ciclo de vida del software contiene tareas específicas de verificación y validación que son apropiadas para el uso previsto del software
• Planes: el plan de validación del software define “qué” debe lograrse a través del esfuerzo de validación del software. Los planes de validación de software en producto sanitario especifican áreas como el alcance, el enfoque, los recursos, los programas y los tipos y el alcance de las actividades, tareas y elementos de trabajo.
• Procedimientos: los procedimientos establecen “cómo” realizar el esfuerzo de validación del software y además deben identificar las acciones específicas o la secuencia de acciones que se deben tomar para completar actividades de validación, tareas y elementos de trabajo individuales.
• Validación del software después de un cambio: dependiendo de la complejidad del software, un cambio local aparentemente pequeño puede tener un impacto significativo en el sistema global. Cada vez que se cambia el software, se debe realizar un análisis de validación no solo para la validación del cambio individual, sino también para determinar el alcance y el impacto de ese cambio en todo el sistema de software.
• Cobertura de validación: la cobertura de validación debe basarse en la complejidad del software y el riesgo de seguridad, no en el tamaño de la empresa o las limitaciones de recursos. La selección de actividades de validación, tareas y elementos de trabajo debe ser acorde con la complejidad del diseño del software y el riesgo asociado con el uso del software para el uso previsto especificado. Para dispositivos de menor riesgo, solo se pueden llevar acabo actividades de validación inicial. A medida que aumenta el riesgo, se deben agregar actividades de validación adicionales para cubrir el riesgo adicional.
• Independencia de revisión: la autovalidación es extremadamente difícil. Cuando es posible, una evaluación independiente siempre es mejor, especialmente para aplicaciones de mayor riesgo. Algunas empresas contratan para una verificación y validación independiente de un tercero, pero esta solución no siempre es factible. Otro enfoque es asignar personal interno que no esté involucrado en un diseño particular o su implementación, pero que tenga el conocimiento suficiente para evaluar el proyecto y llevar a cabo las actividades de verificación y validación.
• Flexibilidad y responsabilidad: el fabricante del dispositivo tiene flexibilidad para elegir cómo aplicar los principios de validación, pero conserva la responsabilidad final de demostrar que el software ha sido validado.En cada entorno, los componentes de software de muchas fuentes se pueden usar para crear la aplicación (por ejemplo, software desarrollado internamente, software comercial, software de contrato, shareware). Además, los componentes de software vienen en muchas formas diferentes (por ejemplo, software de aplicación, sistemas operativos, compiladores, depuradores, herramientas de administración de configuración, y muchos más). La validación del software en estos entornos puede ser una tarea compleja; por lo tanto, es apropiado considerar todos estos principios de validación de software en producto sanitario al diseñar el proceso de validación del software.

Actividades y Tareas

Actividades del ciclo de vida del software

Los desarrolladores de software deben establecer un modelo de ciclo de vida del software que sea apropiado para su producto y organización. El modelo de ciclo de vida del software que se seleccione debe abarcar el software desde su nacimiento hasta su retirada del mercado. Un modelo de ciclo de vida de software suele incluir las siguientes actividades:

• Planificación de Calidad.
• Definición de los requisitos del sistema.
• Especificación detallada de requisitos de software.
• Especificación de diseño de software.
• Construcción o Codificación.
• Pruebas.
• Instalación.
• Operación y soporte.
• Mantenimiento.
• Retirada.

La verificación, las pruebas y otras tareas que respaldan la validación de software en producto sanitario ocurren durante cada una de estas actividades.

Tareas típicas de apoyo a la validación

Para cada una de las actividades del ciclo de vida del software, hay ciertas tareas “típicas” que respaldan la conclusión de que el software está validado. Sin embargo, las tareas específicas que se realizarán, su orden de rendimiento, y la iteración y el tiempo de su desempeño serán dictados por el modelo de ciclo de vida específico del software que se seleccione y el riesgo de seguridad asociado con la aplicación de software. Para aplicaciones de muy bajo riesgo, ciertas tareas pueden no ser necesarias. Sin embargo, el desarrollador de software debe al menos considerar cada una de estas tareas y debe definir y documentar qué tareas son o no apropiadas para su aplicación específica.

Planificación de Calidad

La planificación del diseño y el desarrollo debe culminar en un plan que identifique las tareas necesarias, los procedimientos para la notificación y resolución de anomalías, los recursos necesarios y los requisitos de revisión de la administración, incluidas las revisiones formales del diseño. El plan debe incluir:

• Las tareas específicas para cada actividad del ciclo de vida.
• Enumeración de factores de calidad importantes (p. Ej., fiabilidad, facilidad de mantenimiento y facilidad de uso).
• Métodos y procedimientos para cada tarea.
• Criterios de aceptación de tareas.
• Criterios para definir y documentar productos en términos que permitan evaluar su conformidad con los requisitos de entrada.
• Entradas para cada tarea.
• Salidas de cada tarea.
• Roles, recursos y responsabilidades para cada tarea.
• Riesgos y suposiciones.
• Documentación de las necesidades del usuario.

La gerencia debe identificar y proporcionar el entorno y los recursos de desarrollo de software apropiados.

Se deben crear procedimientos para informar y resolver anomalías de software encontradas a través de validación u otras actividades.

Tareas típicas – Planificación de calidad

• Plan de gestión de riesgos.
• Plan de gestión de la configuración.
• Plan de aseguramiento de la calidad del software.
• Plan de validación y verificación de software.
• Tareas de verificación y validación, y criterios de aceptación.
• Programación y asignación de recursos (para actividades de validación y verificación de software).
• Los requisitos de información.
• Requisitos de revisión de diseño formal.
• Otros requisitos de revisión técnica.
• Informe de problemas y procedimientos de resolución.
• Otras actividades de apoyo.

Requisitos

El desarrollo de requisitos incluye la identificación, el análisis y la documentación de la información sobre el dispositivo y su uso previsto.

El documento de especificación de requisitos de software debe contener una definición escrita de las funciones del software. No es posible validar el software sin requisitos de software predeterminados y documentados. Los requisitos típicos de software especifican lo siguiente:

• Todas las entradas del sistema de software.
• Todas las salidas del sistema de software.
• Todas las funciones que realizará el sistema de software.
• Todos los requisitos de rendimiento que el software satisfará (por ejemplo, rendimiento de datos, confiabilidad y tiempo).
• La definición de todas las interfaces externas y de usuario, así como cualquier interfaz interna de software a sistema.
• Cómo los usuarios interactuarán con el sistema.
• Qué constituye un error y cómo deben manejarse los errores.
• Tiempos de respuesta requeridos.
• El entorno operativo previsto para el software, si se trata de una restricción de diseño (por ejemplo, plataforma de hardware, sistema operativo).
• Todos los rangos, límites, valores predeterminados y valores específicos que el software aceptará.
• Todos los requisitos, especificaciones, características o funciones relacionadas con la seguridad que se implementarán en el software.

Se debe llevar a cabo un análisis de rastreabilidad de los requisitos del software para rastrear los requisitos del software para (y desde) los requisitos del sistema y los resultados del análisis de riesgos.

Tareas típicas – Requisitos

• Análisis Preliminar de Riesgos.
• Análisis de Trazabilidad.
• Requisitos de software para los requisitos del sistema (y viceversa).
• Requisitos de software para el análisis de riesgos.
• Descripción de las características del usuario.
• Listado de características y limitaciones de la memoria primaria y secundaria.
• Evaluación de requisitos de software.
• Análisis de requisitos de interfaz de usuario de software.
• Generación del plan de prueba del sistema.
• Generación de plan de prueba de aceptación.
• Revisión o análisis de ambigüedad.

Diseño

En el proceso de diseño, la especificación de requisitos de software se traduce en una representación lógica y física del software que se implementará. La especificación de diseño de software es una descripción de lo que el software debería hacer y cómo debería hacerlo.

La especificación de diseño de software debe incluir:

• Especificación de requisitos de software, incluidos los criterios predeterminados para aceptación del software.
• Análisis de riesgo de software.
• Procedimientos de desarrollo y pautas de codificación (u otros procedimientos de programación).
• Documentación de sistemas (p. Ej., Un diagrama narrativo o de contexto) que describe el contexto del sistema en el que se pretende que el programa funcione, incluida la relación del hardware, el software y el entorno físico).
• Hardware para ser utilizado.
• Parámetros a medir o grabar.
• Estructura lógica (incluida la lógica de control) y pasos de procesamiento lógico (por ejemplo, algoritmos).
• Estructuras de datos y diagramas de flujo de datos.
• Definiciones de variables (control y datos) y descripción de dónde se usan.
• Mensajes de error, alarma y advertencia.
• Software de soporte (por ejemplo, sistemas operativos, controladores, otro software de aplicación).
• Enlaces de comunicación (enlaces entre módulos internos del software, enlaces con el software de soporte, enlaces con el hardware y enlaces con el usuario).
• Medidas de seguridad (seguridad física y lógica).
• Cualquier restricción adicional no identificada en los elementos anteriores.

La mayoría de los modelos de desarrollo de software serán iterativos. Es probable que esto resulte en varias versiones de la especificación de requisitos de software y la especificación de diseño de software. Todas las versiones aprobadas deben archivarse y controlarse de acuerdo con los procedimientos de gestión de configuración establecidos.

Tareas típicas – Diseño

• Análisis de riesgo de software actualizado.
• Análisis de rastreabilidad.
• Especificación de diseño para requisitos de software (y viceversa).
• Evaluación de diseño de software.
• Diseño de análisis de enlace de comunicación.
• Generación del plan de prueba del módulo.
• Generación del plan de prueba de integración.
• Generación de diseño de prueba (módulo, integración, sistema y aceptación).

Construcción o Codificación

El software se puede construir ya sea mediante codificación (es decir, programación) o ensamblando componentes de software codificados previamente (por ejemplo, desde librerías de códigos, software estándar, etc.) para su uso en una nueva aplicación. La codificación es la actividad de software donde la especificación de diseño detallado se implementa como código fuente. La codificación es el nivel más bajo de abstracción para el proceso de desarrollo de software. Es la última etapa en la descomposición de los requisitos del software donde las especificaciones del módulo se traducen a un lenguaje de programación.

Las decisiones sobre la selección de lenguajes de programación y herramientas de compilación de software (ensambladores, enlazadores y compiladores) deben incluir la consideración del impacto en tareas posteriores de evaluación de calidad (por ejemplo, disponibilidad de herramientas de depuración y prueba para el idioma elegido).

Un análisis de trazabilidad del código fuente es una herramienta importante para verificar que todo el código esté vinculado a las especificaciones establecidas y los procedimientos de prueba establecidos. Se debe realizar y documentar un análisis de trazabilidad del código fuente para verificar que:

• Cada elemento de la especificación de diseño de software se ha implementado en código.
• Los módulos y funciones implementados en el código se pueden remontar a un elemento en la especificación de diseño de software y al análisis de riesgos.
• Las pruebas de los módulos y funciones se remontan a un elemento en la especificación de diseño de software y al análisis de riesgos.
• Las pruebas para módulos y funciones se pueden remontar al código fuente para los mismos módulos y funciones.

Tareas típicas – Construcción o codificación

• Análisis de Trazabilidad.
• Código fuente para diseñar la especificación (y viceversa).
• Casos de prueba para el código fuente y para diseñar la especificación.
• Evaluación del código fuente y la documentación del código fuente.
• Análisis de interfaz de código fuente.
• Procedimiento de prueba y generación de casos de prueba (módulo, integración, sistema y aceptación).

Pruebas realizadas por el desarrollador de software

Las pruebas de software implican ejecutar productos de software en condiciones conocidas con entradas definidas y resultados documentados que se pueden comparar con sus expectativas predefinidas. Es una actividad que consume mucho tiempo, es difícil e imperfecta. Como tal, requiere una planificación temprana para ser eficaz y eficiente.

Los planes de prueba de software deben identificar las tareas particulares que se llevarán a cabo en cada etapa del desarrollo e incluir la justificación del nivel de esfuerzo que representan sus correspondientes criterios de finalización.

Un elemento esencial de un caso de prueba de software es el resultado esperado. Es el detalle clave que permite una evaluación objetiva del resultado real de la prueba. Esta información de prueba necesaria se obtiene a partir de la definición o especificación predefinida correspondiente.

El verdadero esfuerzo de las pruebas de software efectivas radica en la definición de lo que se va a probar en lugar de en la realización de la prueba.

Un proceso de prueba de software debe basarse en principios que fomenten exámenes efectivos de un producto de software. Los principios de prueba en la validación de software en producto sanitario aplicables incluyen:

• El resultado esperado de la prueba está predefinido.
• Un buen caso de prueba tiene una alta probabilidad de exponer un error.
• Una prueba exitosa es aquella que encuentra un error.
• Hay independencia de la codificación.
• Se emplean tanto la experiencia de la aplicación (usuario) como la del software (programación).
• Los probadores usan diferentes herramientas de los codificadores.
• Examinar solo el caso habitual es insuficiente.
• La documentación de la prueba permite su reutilización y una confirmación independiente del estado de aprobado / reprobado de un resultado de la prueba durante la revisión posterior.

Tareas típicas – Pruebas realizadas por el desarrollador de software

• Planificación de prueba.
• Validación del software del dispositivo médico o la validación del software utilizado para diseñar, desarrollar o fabricar dispositivos médicos.
• Identificación de caso de prueba funcional.
• Análisis de Trazabilidad – Pruebas.
• Pruebas de unidad (módulo) para el diseño detallado.
• Pruebas de integración para el diseño de alto nivel.
• Pruebas del sistema a los requisitos del software.
• Ejecución de prueba de unidad (módulo).
• Ejecución de prueba de integración.
• Ejecución de prueba funcional.
• Ejecución de prueba del sistema.
• Ejecución de prueba de aceptación.
• Evaluación de resultados de prueba.
• Evaluación / resolución de errores.
• Informe de prueba final.

Prueba en el sitio del usuario

Las pruebas en el sitio del usuario son una parte esencial de la validación del software. La regulación del sistema de calidad requiere procedimientos de instalación e inspección (incluidas pruebas cuando corresponda), así como documentación de inspección y prueba para demostrar la instalación adecuada.

Las pruebas en el sitio del usuario deben seguir un plan escrito predefinido con un resumen formal de las pruebas y un registro de aceptación formal. Debe conservarse la evidencia documentada de todos los procedimientos de prueba, datos de entrada de prueba y resultados de prueba.

El plan de prueba debe especificar pruebas en toda la gama de condiciones operativas y debe especificar la continuación por un tiempo suficiente para permitir que el sistema encuentre un amplio espectro de condiciones y eventos en un esfuerzo por detectar cualquier falla latente que no sea aparente durante actividades normales.

Durante las pruebas en el sitio del usuario, se deben mantener registros del rendimiento adecuado del sistema y de cualquier fallo del sistema que se encuentre. La revisión del sistema para compensar las fallos detectados durante esta prueba del sitio del usuario debe seguir los mismos procedimientos y controles que para cualquier otro cambio de software.

Tareas típicas – Prueba en el sitio del usuario

• Ejecución de prueba de aceptación.
• Evaluación de resultados de prueba.
• Evaluación / resolución de errores.
• Informe de prueba final.

Mantenimiento y cambios de software

El mantenimiento del software incluye mantenimiento correctivo, de mejora y adaptativo, pero no incluye acciones de mantenimiento preventivo o reemplazo de componentes de software.

Los cambios realizados para corregir errores y fallos en el software son mantenimiento correctivo. Los cambios realizados en el software para mejorar el rendimiento, la capacidad de mantenimiento u otros atributos del sistema de software son un mantenimiento de mejora. Los cambios de software para hacer que el sistema de software se pueda utilizar en un entorno modificado son el mantenimiento adaptativo.

El esfuerzo de validación específico necesario para cada cambio de software está determinado por el tipo de cambio, los productos de desarrollo afectados y el impacto de esos productos en el funcionamiento del software.

La documentación detallada y completa de la estructura de diseño y las interrelaciones de varios módulos, interfaces,etc., pueden limitar el esfuerzo de validación necesario cuando se realiza un cambio. El nivel de esfuerzo necesario para validar por completo un cambio también depende del grado en que se documentó y archivó la validación del software original.

Además de las tareas de validación y verificación de software que forman parte del proceso de desarrollo de software estándar, se deben abordar las siguientes tareas de mantenimiento adicionales:

• Revisión del plan de validación del software: para el software que se validó previamente, el plan de validación del software existente se debe revisar para respaldar la validación del software revisado. Si no existe un plan de validación de software en producto sanitario anterior, dicho plan debe establecerse para respaldar la validación del software revisado.
• Evaluación de anomalías: las organizaciones que desarrollan software frecuentemente mantienen documentación, como informes de problemas de software que describen anomalías de software descubiertas y la acción correctiva específica tomada para corregir cada anomalía. Las anomalías del software deben evaluarse en términos de su gravedad y sus efectos sobre el funcionamiento y la seguridad del sistema, pero también deben tratarse como síntomas de deficiencias del proceso en el sistema de calidad. Un análisis de causa raíz de anomalías puede identificar deficiencias específicas del sistema de calidad.
• Identificación de problemas y seguimiento de resolución: todos los problemas descubiertos durante el mantenimiento del software deben documentarse.
• Evaluación de cambios propuesta: todas las modificaciones, mejoras o adiciones propuestas deben evaluarse para determinar el efecto que tendrá cada cambio en el sistema. Esta información debe determinar en qué medida las tareas de verificación y /o validación deben repetirse.
• Iteración de tareas: para cambios de software aprobados, se deben realizar todas las tareas de validación y verificación necesarias para garantizar que los cambios planificados se implementen correctamente, toda la documentación esté completa yactualizada, y no se hayan producido cambios inaceptables en el rendimiento del software.
• Actualización de documentación : la documentación debe revisarse cuidadosamente para determinar qué documentos se han visto afectados por un cambio.

Beneficios de la Validación del software

La validación de software en producto sanitario es una herramienta fundamental utilizada para asegurar la calidad del software del dispositivo y las operaciones automatizadas del software.

Validación de software en producto sanitario puede aumentar la usabilidad y la confiabilidad del dispositivo, lo que resulta en una disminución de las tasas de errores, menos retiradas y acciones correctivas, menos riesgos para los pacientes y usuarios, y una menor responsabilidad para los fabricantes de dispositivos. La validación de software en producto sanitario también puede reducir los costes a largo plazo al hacer que sea más fácil y menos costoso modificar el software de manera confiable y revalidar los cambios de software. El mantenimiento del software puede representar un porcentaje muy grande del coste total del software a lo largo de todo su ciclo de vida. Un proceso de validación de Software en Producto Sanitario integral establecido ayuda a reducir el coste a largo plazo del software al reducir el coste de validación para cada versión posterior del software.

En Oqotech contamos con más de 10 de experiencia en la validación de sistemas informatizados en entornos regulados. Contacta con nuestro equipo y te ayudaremos a informatizar y validar tus sistemas siguiendo una metodología probada y enfocada a conseguir resultados reales.