GAMP5® 2ª edición y CSA FDA: porque pueden ser buenas para las empresas

Algunos puntos importantes que han traído la segunda edición de GAMP5® y CSA y que nos hacen reflexionar sobre cómo serán las validaciones de sistemas a partir de ahora.

El propósito de este artículo es consolidar los principales puntos de cambio entre la primera y la segunda edición de la guía GAMP5 y traer algunos temas de la guía CSA emitida por la FDA. Este articulo no sustituye la lectura de dichas guías.

Qué es GAMP5®, segunda edición

Las empresas de Ciencias de la Vida, especialmente las biofarmacéuticas y de productos sanitarios, son muy reguladas y necesitan demostrar que el producto y su proceso de fabricación y desarrollo son sólidos. Esta es la función de la validación: generar pruebas documentales que demuestren que los equipos, sistemas, hojas de cálculo, procesos y procedimientos funcionan de forma que protegen al paciente o consumidor, la calidad del producto y la integridad de los datos. ISPE® (International Society of Pharmaceutical Engineering) elaboró la guía GAMP (Good Automated Manufacturing Practice) para orientar a la comunidad de Ciencias de la Vida en el desarrollo de validaciones sólidas. La versión 5 de la guía se publicó en 2008 y recientemente, en 2022, se ha lanzado la segunda edición de la publicación, que aporta ideas que pueden ser muy útiles para la empresa.

Principales diferencias entre la primera y la segunda edición de GAMP5

 

La segunda edición de la Guía GAMP5 incluye los siguientes temas:

Apéndice D8 - Agile Software Development

Este punto resume los principios de las metodologías y software ágiles e ilustra cómo pueden implementarse para alinearse con los principios de GAMP5® y BPx (impacto en las buenas prácticas). En 2021, ISPE® publicó una guía apéndice titulada Enabling Innovation que básicamente se incluyó en la segunda versión de GAMP5®. El punto principal de esta literatura es el enfoque iterativo e incremental para el proceso de desarrollo de software y es una tendencia que ha estado dominando el mercado en su conjunto.

La amplia adopción se explica por la agilidad y flexibilidad que el marco aporta a los equipos empresariales. Aunque el modelo tradicional de cascada (Waterfall) ofrezca una serie de ventajas y responda a diversos escenarios (entre ellos, el reglamentario), este modelo presenta algunos inconvenientes por no estar alineado con las urgencias y los cambios constantes del mercado actual. Así, para hacer frente a estas exigencias y lograr mejores resultados a medio y largo plazo, es necesario buscar nuevas salidas. La adopción de este apéndice puede ayudar a su negocio a tener un mejor desempeño, cumpliendo de manera sólida, lo esperado por los organismos reguladores.

La adopción de un proceso de desarrollo iterativo e incremental en las aplicaciones BPx relevantes está en los fundamentos de las metodologías ágiles, como Scrum. La idea es que la creación de un software se guíe por varios ciclos más pequeños, en los que se introduzcan funcionalidades, se recojan comentarios y se revisen requisitos, y que cada etapa se valide y se entregue formalmente a la empresa (releases parciales). En este enfoque, la URS (User Requirement Specification) se elabora de forma incremental (para cada etapa de implementación), por parte o proceso que sigue para el desarrollo o configuración, pruebas y liberación en ciclos iterativos.

 

Haga clic para obtener más información: validación sin papel.

Apéndice D9 - Software Tools

Este punto describe el enfoque basado en el riesgo recomendado para las herramientas que soportan los procesos del ciclo de vida de los sistemas informáticos, los procesos de TI y la infraestructura de TI (herramientas de desarrollo, soporte y mantenimiento). Las herramientas que se utilicen deberán pasar por un proceso de selección, evaluación de los riesgos asociados a su uso, instalación y configuración, y estar disponibles en una forma que sea segura para el uso pretendido. Las herramientas que aceleran o asisten el proceso de validación deberán disponer de controles para mantener la integridad, la seguridad y la disponibilidad.

En el caso de la herramienta GO!FIVE® desarrollada por FIVE Validation, todos los controles de integridad de los datos de los registros BPx fueron proporcionados, puestos a disposición y validados por el equipo de control de calidad. Cualquier aprobación o aceptación de documentos o resultados de pruebas tiene un robusto control de acceso, trazabilidad y firma electrónica.

Haga clic para obtener más información: validación sin papel.

La segunda edición de la Guía GAMP5 incluye los siguientes temas:

Apéndice D10 - Distributed Ledger Systems (Blockchain)
Este apéndice de la guía describe cómo manejar infraestructuras o sistemas descentralizados con computación distribuida.

El término "Ledger" se utiliza mucho en contabilidad. Es como un libro de contabilidad final y oficial o un archivo de entrada digital donde se registran las transacciones comerciales.

“Ledgers Systems” distribuidos son el consenso de datos digitales replicados, compartidos y sincronizados que se extienden geográficamente (distribuidos) por muchos lugares, países o instituciones.

A diferencia de una base de datos centralizada, un sistema de “Ledger” distribuido no requiere un administrador central y, en consecuencia, no tiene un único punto central de fallo.

A medida que más miembros del entorno tecnológico de healthcare decidan participar en la red, ésta podrá abarcar cadenas de suministro enteras, desde fabricantes de materias primas hasta farmacias, clínicas u hospitales.

Los efectos de red de esta tecnología pueden presionar a los fabricantes biofarmacéuticos para que participen tanto con fines normativos como comerciales. Incluso si la empresa regulada decide no participar, es muy probable que lo haga alguno de sus proveedores o clientes.

Blockchain puede utilizarse para rastrear el origen de los productos farmacéuticos, el transporte de medicamentos y la adquisición de materias primas.

La tecnología Blockchain también puede reducir el número de intermediarios que intervienen en el proceso farmacéutico, reduciendo así los costes y mejorando la seguridad.
Apéndice D11 – Artificial Intelligence and Machine Learning (AI/ML)
Este apéndice describe cómo la Inteligencia Artificial y Machine Learning pueden integrarse en el sector de las Ciencias de la Vida.

Su adopción es importante para la innovación en el sector.
Describe la importancia de la integridad de los datos para la calidad de la IA/ML y la comprensión de los riesgos inherentes.

El uso de la IA, junto con la subdisciplina del ML, plantea a la industria de las Ciencias de la Vida el reto de mantener la calidad general y el cumplimiento normativo de dichos sistemas, aplicaciones y/o soluciones informáticas.

Este apéndice proporciona una comprensión básica de estas soluciones digitales y orientación sobre cómo garantizar la integración y la idoneidad para su uso en un entorno BPx relevante.
Apéndice M11 - IT Infrastructure
La primera edición de GAMP5 tenía un importante capítulo en el apéndice S5 sobre la gestión de la calidad en el entorno de TI externalizado.

Ahora, en la segunda edición, el apéndice M11 deja clara la recomendación de estrategia basada en el riesgo para las buenas prácticas en la gestión de la infraestructura interna o de proveedores externos, especialmente la infraestructura en la nube.

Una infraestructura de TI controlada es un requisito previo para garantizar que las aplicaciones BPx relevantes se gestionen en este entorno.

La infraestructura desempeña un papel importante a la hora de garantizar que las aplicaciones se encuentren en una plataforma estable con las comunicaciones e interfaces necesarias y fiables.

La infraestructura informática favorece el rendimiento y la disponibilidad de las aplicaciones, así como la integridad, seguridad y confidencialidad de los datos. Muchos de los procesos necesarios para garantizarlos dependen de algunos aspectos de la gestión de la infraestructura, como la seguridad de la información, el load balance (equilibrio de carga), el backup y la restauración, la recuperación de desastres, etc.
Apéndice M12 – Critical Thinking
En este apéndice se analiza el concepto de pensamiento crítico para optimizar de forma proactiva el enfoque que debe seguirse para garantizar la calidad y la conformidad de los sistemas informatizados.

Perder tiempo y esfuerzo en actividades que no aportan valor añadido puede dar lugar a un trabajo insuficiente o excesivo, con posibles costes adicionales y retrasos, y puede reducir la atención prestada a actividades de calidad más valiosas y esenciales.

El uso de tablas rígidas, o templates demasiado prescriptivos derivados de procedimientos que no permiten la apertura para la adaptación a cada caso, impide el pensamiento crítico y puede inhibir la innovación y la adopción de nuevas tecnologías.GAMP5 promueve un enfoque basado en el riesgo para garantizar la idoneidad para el uso previsto.

Algunos profesionales no reflexionan lo suficiente para asegurarse de que el enfoque que van a adoptar podría adaptarse y ser proporcionado a las necesidades de cada sistema.

Un ejemplo práctico de pensamiento crítico, o racional (término que también utilizamos a menudo) es clasificar el CDS (Chromatography Data System) como categoría 4 - configuración, tal como sugiere la edición actual de GAMP en la tabla del punto 12.1 como ejemplo típico de cómo puede optimizarse su ciclo documental.

Clasificarlo como categoría 4 de GAMP tiene sentido cuando hay cálculos personalizados o interfaz con LIMS (Laboratory Information Management System), por ejemplo. Pero este mismo sistema se instala a menudo utilizando sus funciones estándares.

En este caso, el enfoque del ciclo de vida podría ser diferente.Cuando clasificamos un sistema como categoría 4 de la GAMP, es habitual que los procedimientos requieran una Especificación Funcional. Cuando el CDS se utiliza en su función estándar, esto es, sin interfaces y sin cálculos personalizados, ¿por qué habríamos de elaborar una Especificación Funcional? ¿Para replicar o repetir menciones que ya figuran en el manual del fabricante? Una pérdida de tiempo, no aporta valor añadido.

Es este tipo de pensamiento crítico lo que pretende fomentar la versión actual de GAMP5.
Debe haber una razón para producir documentos y pruebas que añadan valor, que se centren en la calidad del producto, la salud del paciente o consumidor y la integridad de los datos, es decir, lo que realmente importa.

Por otro lado, el pensamiento crítico no debe utilizarse como herramienta para desestimar algún entregable del ciclo de validación, por falta de tiempo de diseño o coste no previsto.

El pensamiento crítico también debe utilizarse para planificar los esfuerzos aplicados a las pruebas.

Finalmente, la nueva versión de la Guía GAMP5 incentiva la libertad de uso de los racionales, sin embargo, debemos utilizar estas directrices de forma responsable y comprometida con la calidad.

Las decisiones deben ser tomadas en equipos multidisciplinares y registradas en documentos que expliquen dicha estrategia, como, por ejemplo, el Plan de Validación.
Apéndice D1 - Specifying Requirements
La extensión y el detalle de los requisitos deben basarse en el riesgo, la complejidad y la innovación, y deben ser suficientes para respaldar el Análisis de Riesgos.
Apéndice S2 - Electronic Production
Records Describe el concepto y el enfoque high level para determinar los requisitos de los registros electrónicos de producción (fabricación).

Se mencionan la revisión por excepción (RBE: Review by exception), la adopción de tecnología en la nube, blockchain, la disponibilidad de datos en tiempo real y una mayor claridad de los datos en el registro de auditoría y su revisión.

Herramientas en lugar de documentos

Este es un punto crítico que puede impactar positivamente en el negocio. La nueva edición de la Guía GAMP5® fomenta y recomienda el uso de herramientas de software para apoyar las prácticas Agile que pueden aportar oportunidades para mejorar el enfoque tradicional de documentación que presenta barreras y potencialmente introduce riesgos de incumplimiento (en papel, cualquier cosa puede ser aprobada y es difícil de rastrear).

Las herramientas de software de apoyo a la validación permiten al equipo redactar requisitos funcionales y de calidad de forma eficiente para iniciar el proceso ágil, gestionando el ciclo de vida de cada requisito de forma independiente. Un conjunto de requisitos puede formar un release.

Las pruebas son un excelente ejemplo de dónde las herramientas de software pueden ofrecer oportunidades para mejorar el rendimiento de la entrega.

Así, un gran volumen de pruebas se ejecuta de forma más eficiente, con menos recursos humanos.

Una herramienta puede proporcionar trazabilidad automática sin necesidad de crear manualmente un documento matriz.

La trazabilidad puede ser obtenida de forma dinámica y demostrada por la herramienta, que, si es necesario, puede generar informes en etapas clave (releases parciales).

Nota: FIVE Validation ha desarrollado un sistema de generación y gestión de validaciones que sigue un software ágil, con validaciones 5 veces más rápidas y que cumple los requisitos de la FDA y la EMA. 

Haga clic para obtener más información: validación sin papel.

¿Qué es la CSA FDA?

CSA significa Computer Software Assurance y es una guía de la FDA para asegurar la calidad del software utilizado en todo el proceso de fabricación, y la garantía de calidad de los productos médicos.

En resumen, algunos puntos importantes sobre CSA, versión draft publicada en Sept/2022:

  • No tiene en cuenta el riesgo para el paciente o el consumidor, ni la integridad de los datos; sólo el riesgo de proceso;
  • No tiene en cuenta la probabilidad de ocurrencia ni la detectabilidad en la composición del riesgo;
  • No fomenta acciones mitigadoras que no estén relacionadas con el alcance de las pruebas (como directrices sobre procedimientos o nuevos desarrollos) para reducir los riesgos;
  • La determinación del riesgo se informa directamente en el requisito.

Pruebas CSA y GAMP5®

Aunque las directrices de las guías GAMP5 y CSA son diferentes, existe una interesante sinergia entre ambas literaturas en lo que respecta al alcance de las pruebas. Los tipos de pruebas guiadas y no guiadas sugeridas o recomendadas en ambas guías son similares.

Las pruebas no deben limitarse a un protocolo detallado y prescriptivo que incluya el paso a paso. Se fomenta el uso de pruebas exploratorias y otras técnicas no guiadas para ampliar la cobertura de las pruebas y mejorar la detección de defectos.

Las pruebas no guiadas deben documentarse y luego pueden aprovecharse como parte de la fase de verificación general.

El uso de pruebas automatizadas tiene ventajas para la cobertura de la verificación, la repetibilidad y la velocidad de ejecución.

Algunos enfoques de pruebas que pueden utilizarse:

 Unscripted Testing (pruebas no guiadas): normalmente elaboradas por equipos de proyecto

No significa sin documentación de las pruebas.

Las pruebas no guiadas deben documentarse y luego pueden aprovecharse como parte de la fase de verificación general.

La segunda edición de GAMP5 recomienda que las pruebas no se limiten a un protocolo detallado, prescriptivo y paso a paso. Por lo tanto, resulta factible explicar la estrategia de pruebas que está aplicando el equipo del proyecto. Este enfoque puede justificarse en el Plan de Validación o en el Protocolo de Pruebas.

Las pruebas previstas por el equipo del proyecto ya no necesitan ser ignoradas por falta de solidez en sus evidencias. Sin embargo, sigue siendo necesario capturar algunos datos que demuestren que la prueba fue/va a ser realmente ejecutada, tales como: quién la ejecutó, fecha, problemas enfrentados en la ejecución de la prueba, si pasó o falló. Sin embargo, no es necesario que el script de la prueba sea detallado, especialmente las pruebas relacionadas con transacciones o funcionalidades que no son críticas y tienen riesgos clasificados como bajos.

No se trata de llegar a aceptar cualquier falta de solidez en la documentación por parte del equipo del proyecto, pero si el trabajo en equipo es posible, ¿puede bastar con orientar en el uso de las mejores prácticas de documentación para aprovechar esas pruebas?

¿Por qué entonces no repetir o dejar las pruebas críticas para las fases formales de cualificación de la instalación, el funcionamiento y el rendimiento, de modo que se garantice la calidad?

Unscripted testing puede ser: ad-hoc, error-guessing y exploratorias.

Ad-hoc significa prueba o escenario que no se ha planificado ni se planificará de antemano.

Error-guessing es una técnica de concepción de pruebas en la que los casos de prueba se derivan a partir de los conocimientos del ejecutor, que tiene en cuenta los fallos anteriores o el conocimiento general de los modos de fallo.

Las pruebas exploratorias se basan en la experiencia del ejecutor, que define los escenarios y los ejecuta espontáneamente en función de sus conocimientos pertinentes.

La realización de pruebas no guiadas reduce el tiempo de redacción de secuencias de comandos, disminuye los errores de redacción y acelera la elaboración de informes, con la ventaja de proporcionar formación a los usuarios sobre la operación del sistema.

Integrar con éxito las pruebas no guiadas en su estrategia de validación significa más pensamiento crítico, pero menos documentación, lo que en última instancia ahorra tiempo, esfuerzo y costes.

Scripted Testing (pruebas guiadas)

Pruebas en las que las acciones del ejecutor están prescritas por instrucciones escritas en un caso de prueba. Pruebas guiadas sólidas: esfuerzos de pruebas con script en que el sistema de gestión o el riesgo de automatización incluyen pruebas de repetibilidad, trazabilidad a los requisitos y comprobación sólida de la ejecución de las pruebas. Pruebas guiadas limitadas: enfoque híbrido de pruebas guiadas y no guiadas que se escala adecuadamente en función del riesgo que aporta la implantación del sistema. Este enfoque puede aplicar pruebas con script para funciones u operaciones de alto riesgo y pruebas sin script para elementos de riesgo bajo y medio, como parte del mismo esfuerzo de garantía.

Herramienta de Software que sirve a ambas áreas: Proyectos y Calidad

Imagine que existe un proveedor capaz de proporcionar un software de producción de documentos de validación robusto, pero con la agilidad que necesitan las áreas de TI, Ingeniería o proveedores. Imagine también que esta misma herramienta es capaz de gestionar requisitos, riesgos y pruebas de forma integrada, para funcionalidades BPx (impacto en la calidad) relevantes y no relevantes.

Haga clic para obtener más información: validación sin papel.

Conclusión - Cambio de paradigma

La primera edición de GAMP5 abrió nuevos caminos en 2008 al aportar la lógica de centrar las actividades de validación en lo que realmente importa, utilizando la gestión de riesgos de calidad como forma de decidir dónde concentrar los esfuerzos. En aquel momento, la comunidad farmacéutica y de dispositivos médicos tardó algún tiempo en asimilar qué beneficios aportaba realmente esta guía.

Todo hace pensar que la segunda edición vino a continuar el enfoque de basar las decisiones en el riesgo, pero buscando la apertura a la innovación y la agilidad, quitando algunos preceptos de templates o procedimientos muy robustos. Se trata, sin duda, de una ruptura de paradigma que probablemente llevará algún tiempo al mercado "para digerir" los nuevos beneficios.

Quien salga adelante en esta adopción tendrá más economía de tiempo y agilidad en el cumplimiento de sus procesos.

El objetivo es evitar que la validación sea el 'ancla pesada' del negocio que obstaculice la innovación. Ya es una realidad para el equipo de FIVE Validation dedicar más tiempo al alineamiento entre los equipos, comprometiéndolos a adoptar las mejores prácticas, que exactamente a la producción de documentos de validación.

PINCHE AQUÍ para citar una reunión y descubra cómo el equipo de FIVE Validation puede producir documentos 6 veces más rápido que en 2018 (el proceso basado en papel).

 

GAMP5® es una guía cuyos derechos intelectuales están reservados a ISPE. Puede adquirirse en https://ispe.org/.

 

Sobre la autora

SILVIA MARTINS es ingeniera eléctrica con 20 años de experiencia en Validación de Sistemas. Formada en Inglaterra en GAMP5 y FDA 21 CFR Part11, en Alemania en validación SAP y en Dinamarca en Data Integrity y Data Governance. Coordinó el grupo que desarrolló la 1ª Guía de Validación de Sistemas Informatizados en conjunto con ANVISA, Manual de Integridad de Datos y Manual de Calificación de Proveedores en la Nube, ambos en Sindufarma. Ha impartido cursos de formación para inspectores de VISA y ANVISA. CEO y co-fundadora de FIVE Validation.