Guía GAMP 5 2ª edición: ¿qué hay de nuevo?

Para facilitar una implementación más eficiente de los cambios con menor riesgo, las directrices sugieren que el control de calidad debe tener menos participación en dichos cambios, evitando los procedimientos formales de control de cambios. Se realiza un acuerdo formal entre QA e IT en el que se enumeran los cambios menores. 

Por ejemplo, el 2 de febrero de este año, Microsoft Edge (versión 109.0.1518.78) publicó actualizaciones de seguridad.

Este enfoque basado en el sentido común insiste en evitar el cumplimiento excesivo de procedimientos innecesarios. Ser racional en el diseño y mapeo de procesos es suficiente para satisfacer las necesidades proporcionales.

El mejor ejemplo de esta nueva forma de pensar es la transición de la Validación de Software Informático a la Aseguramiento del Software Informático (CSA) que ha estado en marcha durante varios años.

Después de que el ISPE publicara su guía de la 2ª edición de GAMP5 en julio, la FDA publicó oficialmente el borrador del documento de orientación "Computer Software Assurance for Production and Quality System Software" en septiembre de 2022. La forma de validación con este enfoque de CSA se basa en el riesgo y la eficiencia.

El objetivo es minimizar el tiempo perdido en los procedimientos estándar de CSV, como la búsqueda de errores en la implementación de protocolos u otras redacciones de documentación por parte de los testers, y ahora centrarse en las tareas de valor añadido, es decir, comprobar realmente las funcionalidades: ¿funciona el sistema como se espera?

En la edición de 2008 de GAMP, las Especificaciones de Requisitos de Usuario (URS) y las Especificaciones de Requisitos Funcionales (FRS) se separaron y trataron en diferentes apéndices. En la nueva edición, ambas especificaciones se gestionan de forma Agile.

Con la metodología rígida y "anticuada" del modelo V, los requisitos y los pasos posteriores del proceso (incluidos los entregables) se definen de antemano en el primer proyecto y plan de validación, sin dejar lugar a ocurrencias inesperadas desde el principio hasta el final. Para obtener más detalles, consulte nuestra publicación de blog sobre la validación CSV de acuerdo al modelo V.

Por el contrario, el enfoque Agile está orientado al descubrimiento, lo que permite una mayor flexibilidad e independencia en cada paso del proceso (cada paso tiene sus propios ciclos de diseño/construcción/prueba).

Sin embargo, el proyecto todavía está diseñado de acuerdo con la categoría de requisitos, la prioridad y la criticidad para la seguridad del paciente. Para obtener más información, consulte el párrafo D8 – DESARROLLO DE SOFTWARE ÁGIL.

La nueva edición hace hincapié en evitar el exceso de documentación, como las capturas de pantalla excesivas de cada función. Además, GAMP 5 2ª edición tiene como objetivo aumentar la confianza en los paquetes de proveedores que ya han sido validados por ellos de acuerdo con sus propios requisitos de GxP.

En resumen, el mensaje principal es: pruebe y documente lo que se necesita para agregar valor. Usa el pensamiento crítico. como explicamos anteriormente en M12 – PENSAMIENTO CRÍTICO (NUEVO) y D1 – REQUISITOS ESPECÍFICOS (ACTUALIZACIÓN AGREGADA) en relación con el Aseguramiento del Software Informático y el modelo Agile.

Algunos riesgos se consideran menores porque no afectan directamente al producto ni a la seguridad del paciente. Pero debido a que afectan al sistema de calidad en general, aún deben ser probados. 

En este caso, la segunda edición de GAMP5 recomienda realizar pruebas sin script. A diferencia de las pruebas tradicionales con scripts, no es necesario documentar un procedimiento detallado paso a paso: el enfoque permanece en el objetivo de aprobación/reprobación.

Supongamos que deseas utilizar un software en particular para actividades de desarrollo/validación. Dado que este software está diseñado de acuerdo con un modelo Agile, recibirás actualizaciones periódicas del proveedor.  

Bueno, es exactamente con la misma mentalidad que GAMP5 2ª edición te dice que abordes tu proyecto de validación. Sin embargo, los entregables del ciclo de vida del software resultantes del modelo Agile no se pueden aprobar de acuerdo con 21 CFR Parte 11: se utilizan otras formas para la trazabilidad, como el correo electrónico y los registros de auditoría. Consulta nuestra publicación de blog de QbD 21 CFR Part 11 compliance checklist.

Las herramientas que no forman parte directa de un proceso regulado por GXP no necesitan ser validadas por CSV (por ejemplo, Microsoft Word). Aunque puedan utilizarse en los ciclos de vida de validación de sistemas o en los procedimientos informáticos, bastarán con las buenas prácticas IT y la evaluación de riesgos.

La tecnología Blockchain aún está en pañales, pero tiene un gran potencial para la integridad y el seguimiento de datos en entornos GxP a lo largo del ciclo de vida del producto. Esta innovación será, sin duda, una parte importante de los nuevos modelos Agile. Para obtener más información sobre este potencial de las nuevas tecnologías, consulte nuestra publicación de blog de QbD "What is digital health?".

La novedad de la inteligencia artificial (IA) y el aprendizaje automático (ML) no impide que los sistemas sean validados. La validación del modelo aquí se basa en la descripción del algoritmo de IA y ML, así como en el caso de uso y los indicadores clave de rendimiento como especificaciones técnicas. El equipo central de salud digital de QbD ha creado una publicación de blog sobre esto: The Advent of Artificial Intelligence and Machine Learning in Medical Devices.

Las nuevas tecnologías descritas anteriormente producen una cantidad significativa de datos que deben ser monitoreados con audit trails. La segunda edición de GAMP5 recomienda establecer objetivos de punto de recuperación (RPO: frecuencia de copias de seguridad) y objetivos de tiempo de recuperación (RTO: intervalo entre el fallo del sistema y la recuperación) basados en evaluaciones de riesgos de los sistemas.

• D2 – Especificaciones funcionales se retira. Su contenido se incorpora a la D1 Especificación de Requisitos.
• O7 – Se retira la actividad de reparación. Los requisitos para las actividades de reparación se encuentran en O6 – Gestión de cambios operativos y configuración.
• S5 – Gestión de la calidad dentro de un entorno de IS/IT externalizado se retira. Su contenido está en M11 – Infraestructura de IT.