Este es el segundo de una serie de tres artículos que presentan las lecciones que nuestro equipo de validación aprendió al completar un par de proyectos de validación que utilizaban el borrador de la FDA de la Guía de Aseguramiento del Software Informático para Sistemas de Producción y Calidad (CSA). El número de recursos, la cantidad de trabajo que se realiza y el número de entregables completados son siempre máximos durante la fase de ejecución. Por ello, en la fase de ejecución es donde se producen más problemas durante el esfuerzo de validación, lo que repercute significativamente en el coste y el calendario del proyecto. Este artículo presenta acciones que pueden llevarse a cabo para prevenir o al menos reducir el impacto de los problemas que se producen durante la aplicación de las metodologías CSA en la fase de ejecución del proyecto.
Lección 1: Crear planes y protocolos de pruebas exhaustivos para todas las pruebas de verificación
El plan de validación identifica los entregables necesarios para completar la validación de los sistemas. Aun así, el contenido de los planes y protocolos de pruebas debe contener información y pruebas que cumplan los requisitos de verificación definidos en el plan. Un área problemática que se introduce al utilizar las directrices de la CSA es el uso de documentos generados por el proveedor para verificar requisitos de bajo riesgo. Los documentos de prueba del proveedor suelen crearse fuera del ámbito del esfuerzo de validación, y muchas veces no incluyen las expectativas y los resultados documentados de las pruebas, la identificación y resolución de problemas, o la identificación del ejecutor de la prueba y la fecha de ejecución de la prueba. Las directrices de la CSA exigen esta información en la documentación de las pruebas cuando se utilizan los resultados de éstas para verificar el funcionamiento del sistema. No registrar estos elementos durante las pruebas puede retrasar la finalización del proyecto debido a la repetición de las pruebas documentadas inadecuadamente. Evalúa el programa y los procedimientos de calidad de un proveedor para confirmar que sus entregas satisfacen los requisitos de la guía en cuanto a registros adecuados. Si se revisan las pruebas del proveedor y no satisfacen estos requisitos, es posible modificar las pruebas para que cumplan la orientación antes de que se ejecuten. Podría consistir en añadir un espacio adicional para iniciales/fechas, hacer referencia a una resolución para un problema encontrado o explicar el objetivo de la prueba con mayor claridad. Un enfoque proactivo para actualizar los documentos de las pruebas de los proveedores puede eliminar la reejecución de las pruebas de los proveedores que originalmente no cumplen los requisitos de documentación de la CSA para verificar los registros GxP.
Los requisitos de riesgo medio o alto suelen verificarse mediante protocolos más robustos que se crean utilizando procesos y procedimientos que cumplen las GxP y que son revisados y aprobados por el fabricante del medicamento en lugar del proveedor. Estos resultados de las pruebas suelen contener todos los elementos enumerados en la CSA para un registro de pruebas aceptable. Al crear estos documentos, una buena práctica es incluir una sección en los protocolos que identifique los requisitos verificados con pruebas que ya se han completado y no requieren más verificación. Por ejemplo, las Pruebas de Aceptación en el Emplazamiento (SAT) pueden hacer referencia a las Pruebas de Aceptación en Fábrica (FAT) o a las pruebas de desarrollo que verifican requisitos de bajo riesgo. Las Cualificaciones de Instalación y Funcionamiento pueden hacer referencia a las SAT o FAT del mismo modo. La aprobación de protocolos que contengan estas secciones proporciona pruebas de que los grupos de Validación y Garantía de Calidad aceptaron estos resultados antes de pasar a la siguiente fase de pruebas. Seguir estas prácticas evita que se ejecuten pruebas excesivas e innecesarias, y evita sorpresas a las partes interesadas del proyecto cuando revisen los requisitos y los resultados de las pruebas más adelante en el proyecto.
Lección 2: Supervisa de cerca todas las pruebas
Recuerda que muchos proveedores están acostumbrados a realizar sus pruebas de desarrollo y de fábrica con poca supervisión, registro informal de los resultados de las pruebas y documentación nominal de los problemas y sus resoluciones. Documentar formalmente los resultados de sus pruebas, registrar los problemas que encuentran (y su resolución), y firmar y fechar todas las entradas de datos suelen ser prácticas nuevas. Incluso después de asistir a una sesión de formación para explicarles el nuevo proceso de pruebas/documentación, es posible que vuelvan a caer en los viejos hábitos, sobre todo al tratar los problemas y las desviaciones. Esto puede hacer que los resultados de las pruebas y la documentación entregados no cumplan los requisitos de buena documentación (GDP) para su uso en el esfuerzo de validación. Implantar mecanismos de supervisión continua para detectar y resolver los problemas rápidamente durante la ejecución puede minimizar el número de resultados inaceptables de las pruebas realizadas por el proveedor. Es especialmente importante supervisar los resultados del proveedor durante las pruebas finales de desarrollo y las FAT, cuando el proveedor se centra en conseguir la aprobación del sistema para su envío y no en generar una documentación de validación aceptable.
Un método utilizado para proporcionar esta supervisión adicional consiste en celebrar breves reuniones de estado durante las pruebas del proveedor para responder preguntas y reforzar los requisitos de las pruebas. Revisar una muestra de los resultados de las pruebas durante estas reuniones y presentar ejemplos de resultados de pruebas correctamente documentados, especialmente al principio de las pruebas, puede verificar su cumplimiento de los protocolos, proporcionar un ejemplo visual de resultados de pruebas correctamente registrados y evitar tener que cambiar muchos resultados de pruebas documentados más adelante en el proyecto. Estos cambios añaden un número sorprendente de recursos y tiempo a las fases posteriores del proyecto, por lo que es una buena práctica revisar los resultados de las pruebas al principio para evitar que causen problemas más adelante. Este tipo de supervisión también agiliza la resolución de problemas en las primeras fases del proyecto, ya que desaconseja la práctica anterior de los proveedores de señalar muchos problemas detectados durante las pruebas de desarrollo e incluso las FAT, pero no completar la reparación hasta las pruebas SAT o de cualificación. Esto era aceptable antes de la CSA porque la mayoría de las empresas sólo aceptaban los resultados de las pruebas de cualificación durante su esfuerzo de validación. Aun así, es un problema cuando los resultados de las pruebas de desarrollo y FAT se utilizan como registros apropiados en la validación del sistema.
Lección 3: Comunicación/Colaboración
Los planes de validación que siguen las metodologías de validación existentes requieren una comunicación eficaz y mucha flexibilidad durante su ejecución. El empleo de nuevas prácticas con la guía CSA magnifica la importancia de utilizar estas dos herramientas a lo largo de la vida del proyecto. Deben celebrarse reuniones que se centren en los problemas, especialmente los relacionados con la adhesión a la guía CSA. Fomenta la franqueza en el equipo, ya que algunos miembros pueden sentirse incómodos con los cambios y necesitar refuerzos para actuar como es debido. Fomenta un enfoque colaborativo de la desviación y la resolución de problemas también durante estas reuniones. Establece canales de comunicación claros para informar y abordar los problemas, proporcionar actualizaciones al proyecto e identificar los recursos adecuados para completar las tareas. Estas acciones ayudan a mantener el calendario del proyecto acelerando la resolución de problemas, manteniendo informados a los miembros del equipo y aumentando la eficacia de la ejecución. Una buena práctica es crear una matriz de trazabilidad de requisitos al principio del proyecto y actualizarla durante cada paso de validación. Esto identifica cada riesgo de requisito, su rigor de prueba asociado y el documento que verifica los resultados de la prueba para el requisito, pero también documenta visualmente el progreso del proyecto, identifica cualquier cambio en los entregables y minimiza las lagunas identificadas cuando el proyecto está a punto de terminar. Esta capacidad de cambiar rápidamente la validación minimizará su impacto en los planes de pruebas y el calendario.
La fase de ejecución siempre será la más impredecible de un proyecto de validación, y la aplicación de las directrices de la CSA expone a muchos recursos a una filosofía de validación del software diferente a la que estaban acostumbrados, lo que puede hacer que las pruebas sean aún más impredecibles. Poner en práctica las acciones sugeridas en este artículo puede eliminar parte de esta imprevisibilidad de la fase de ejecución, corrigiendo los problemas en una fase temprana del proyecto para reducir la reelaboración posterior. Los entregables de la fase de ejecución son extremadamente importantes porque proporcionan a cualquier revisión reglamentaria o futura pruebas documentadas de cómo se validó el sistema. Los resultados de la validación deben ser claros, concisos y completos, y verificar que se cumplen los requisitos del sistema, por muchas pruebas y repeticiones que haya que hacer, así que tiene sentido prepararse para hacerlo bien a la primera.