El mantenimiento del estado validado de los sistemas, el gran reto de las empresas de Ciencias de la Vida
Descubra GO!FIVE™ y la validación sin papel
Las empresas de Ciencias de la Vida se enfrentan a una serie de retos a la hora de desarrollar y mantener sus sistemas. Uno de los mayores retos es mantener el estado validado, especialmente del “software” de gestión, lo que significa garantizar que funcionen de forma eficiente y fiable en todo momento. Esto es esencial para garantizar la calidad y seguridad de los productos farmacéuticos y médicos que producen estas empresas.
El objetivo de la validación es 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.
La pandemia aceleró la investigación y el desarrollo de nuevas terapias y vacunas, lo que exigió una mayor colaboración e intercambio de información en toda la cadena de valor de la industria farmacéutica y de dispositivos médicos, lo que solo fue posible gracias a las tecnologías digitales avanzadas.
Sin embargo, la transformación digital, basada en su mayor parte en la nube, ha traído consigo un aumento significativo del número de sistemas que se han implantado en los últimos años y que reciben constantes actualizaciones y mejoras en las soluciones y tecnologías implicadas. Por lo tanto, mantener el estado validado ha supuesto un verdadero reto.
Para hacer frente a estos retos, las empresas de Ciencias de la Vida deben contar con un riguroso proceso de gestión de cambios y, en función de su tamaño y escala, debe considerarse la posibilidad de crear un equipo dedicado al mantenimiento del estado validado de los sistemas. Es importante que estas empresas trabajen con proveedores de confianza y con experiencia en la industria farmacéutica para garantizar que las actualizaciones y mejoras se llevan a cabo de forma eficiente y segura, incluyendo las mejores prácticas.
Deployments de nuevas versiones en entornos de calidad y producción
Deployment es el término utilizado para indicar la acción de instalación o despliegue inicial o la actualización de un sistema. En los sistemas basados en la nube, las actualizaciones son generalmente competencia del proveedor que, si no está alineado con las mejores prácticas regulatorias farmacéuticas, puede hacer deployment sin previo aviso en los entornos de calidad y producción simultáneamente, sin dejar una ventana de tiempo para que los equipos de validación analicen los cambios y proporcionen documentación actualizada para autorizar la migración de esta actualización al entorno de producción.
Release notes
Release notes o notas de lanzamiento son documentos que distribuyen los vendedores de productos de software o hardware cuando van a ser lanzados o actualizados. Se espera que los proveedores incluyan el contenido de forma que pueda ser interpretado por usuarios de cualquier área de conocimiento que esté relacionada con el uso de la plataforma, evitando lenguajes demasiado técnicos.
En posesión de unas buenas notas de lanzamiento, el usuario puede analizar si el contenido del update impactará en el estado validado del sistema, es decir, si la documentación seguirá siendo válida (o no) en caso de actualización del sistema. Independientemente de la decisión, el análisis debe documentarse mediante un CC (control de cambios).
En caso de que se decida adoptar una nueva funcionalidad, debe realizarse una "mini validación" para estudiar el impacto del cambio que puede documentarse en el Análisis de Riesgos Funcionales y definir el objetivo de las pruebas.
¿Qué es FDA Audit Readiness?
Es el término utilizado para un sistema de calidad de alto nivel que está listo para la inspección de una agencia reguladora sin necesidad de grandes preparativos.
Ahora, ejemplifiquemos cómo aplicar este término a un estudio de validación de un sistema de gestión implantado en una empresa que aplica regularmente nuevas normas empresariales para adaptarse a un mercado cada vez más dinámico.
En este ejemplo, supongamos que esta empresa ha adoptado un ERP en la nube que lanza nuevas funcionalidades o actualizaciones cada dos o tres meses. Imaginemos los esfuerzos para mantener el estado validado de este sistema y de todos los demás de la empresa.
Para cada cambio BPx relevante (impacto en las mejores prácticas), se debe desarrollar un conjunto de requisitos, riesgos y pruebas para impulsar la validación del cambio en cuestión y su respectivo impacto. Esta documentación generada suele vincularse y adjuntarse al control del cambio (en lugar de la validación original).
El auditor puede cuestionar algo que ha cambiado y que ya no se encuentra en la documentación original. Es relativamente fácil y práctico "versionar" algunos documentos de validación originales para incluir los cambios, como por ejemplo: Plan de Validación, URS y Análisis de Riesgos.
Pero las empresas no suelen poder hacer lo mismo con los scripts de prueba, porque todo su contenido y sus respectivos pasos se encuentran en un único documento.
Cuando éste se actualiza (guardar como), las pruebas no modificadas quedarían sin aplicación en esta nueva versión.
Es por eso que la mayoría de los profesionales de validación acaban generando un nuevo script de prueba para cada modificación, alterando el estado del protocolo original, dejando en vigor una serie de anexos que pueden quedar desactualizados también con la apertura de nuevos CC’s.
En resumen, con el tiempo el estudio de validación se fragmenta y no existe una versión actualizada consolidada que contenga las pruebas que se realizaron en la validación original. Lo ideal sería poder disponer de un único script de pruebas de CO (calificación de operación), por ejemplo, referido a funciones que nunca han cambiado desde la implantación junto con los cambios en un único estudio que muestre la trazabilidad y el control de versiones de cada prueba, incluidas las respectivas revisiones y aprobaciones antes (pre) y después (post) de la ejecución de la prueba.
¿Alguna vez se ha parado a pensar que existe un sistema de gestión de validaciones en el que pueda generar conjuntos de documentos por CC o imprimir todo el estudio de validación actualizado en formato PDF con los elementos actualizados adjuntos al estudio original?
Pues bien, hemos diseñado esta función para que la disfrute en el software GO!FIVE®.
PINCHE AQUÍ para saber mais.
Control de Cambios
El primer paso para iniciar un cambio es abrir el documento de Control de Cambios según el procedimiento de la empresa. Normalmente, los cambios en el área de Sistemas Informatizados también se informan en el SOP (Procedimiento Operativo Estándar) de CC (Control de Cambios), es decir, puede que no se controle mediante un formulario específico de CC. En cualquier caso, el contenido deberá describir las acciones por realizar para ejecutar el cambio o corrección del sistema una vez finalizada la validación. La criticidad del cambio determinará la extensión y verificación de las actividades y documentaciones necesarias siempre en función del Análisis de Riesgos y de la complejidad del cambio por implantar.
El procedimiento de Control de Cambios de la empresa debe abordar la gestión y el control de todos los cambios relacionados con los sistemas informatizados validados con el objetivo de garantizar que permanezcan en ese estado.
Los cambios necesarios en un sistema informatizado validado deberán ser aprobados por un equipo multidisciplinar en el que participe el Control de Calidad. En el caso de cambios de emergencia, éstos deberán ser registrados y, aun así, analizados en cuanto a su impacto y aprobados por Garantía de Calidad. Los criterios para considerar los casos de emergencia se describirán en el procedimiento de control de cambios de la empresa.
Pruebas de regresión
Las Pruebas de Regresión consisten en una técnica de aplicación de pruebas a la versión más reciente del software para garantizar que no han aparecido nuevos defectos en componentes críticos ya probados. Si aparecen nuevos defectos en componentes no modificados, se considera que el sistema ha retrocedido. Cuando el cambio es aplicable a más de un sitio/país que no es necesario para todas las unidades, las pruebas de regresión también son importantes para verificar que no ha habido impacto en los otros sitios.
Para el reto de la nueva versión de la aplicación debido a un cambio, el Control de Cambios debe prever Pruebas de Regresión. El CC debe prever un Análisis de Riesgos Funcionales para definir el impacto de la actualización en las funciones críticas del sistema y, por tanto, pruebas de regresión directas cuando exista la posibilidad de un impacto indirecto de los cambios con funciones críticas "no modificadas".
Normalmente, hay muchas dudas sobre el contenido de estas pruebas, pero básicamente, es más fácil si definimos los riesgos clasificados como "alto" y "mediano" en el Análisis de Riesgos realizado durante la validación, como las pruebas que tienen que ser previstas como Pruebas de Regresión, porque son los puntos más débiles del sistema.
Así, mínimamente las pruebas relacionadas con el propio cambio, sumadas a las pruebas de regresión garantizarán la entrada del cambio en ambiente de producción, asegurando que los riesgos altos y medianos estén bajo control, demostrando robustez en el proceso, sin necesidad de repetir completamente la etapa de calificación de funcionamiento del sistema para cada vez que se realice un cambio, lo que sería inviable en el día a día.
CAB (Change Advisor Board)
Para la implantación y/o mejora del proceso de gestión de cambios, se recomienda formar un equipo que se encargue de aprobar y gestionar los cambios, apoyando el análisis de impacto y la priorización. El equipo suele estar formado por: el responsable del CAB, expertos técnicos de TI y/o OT (automatización), usuarios, ingeniería, mantenimiento, control de calidad y/o validación (BPx).
Los miembros del CAB son responsables de comprender las necesidades y el impacto del cambio desde las perspectivas técnica, empresarial y de calidad. Son importantes las reuniones semanales de toma rápida de decisiones. Los miembros del CAB también son responsables de supervisar el desarrollo, las pruebas y el proceso de aprobación para migrar el cambio de un entorno a otro.
Control de Cambios por sistema: ¡muchos cambios!
CAB debe implicar cambios de perfiles, funcionales, hardware, software, configuraciones, parches, actualizaciones, etc. Se trata de una práctica ITIL (Information Technology Infrastructure Library), conjunto de buenas prácticas para la gobernanza de TI.
Dependiendo del tamaño de la empresa, algunas medidas de control tienen que ser implementadas para la correcta gestión de los cambios que pueden ser muy numerosos, tales como: a.) determinar la regla de entrada del cambio en el comité sólo después de la aprobación del coste y b.) utilizar un sistema para la gestión de cambios desde la solicitud de cambio hasta la confirmación del correcto funcionamiento de la misma.
El sistema debe gestionar el workflow (flujo de aprobación) de cada cambio funcional y perfil que debe estar mínimamente controlado por la siguiente información ID (número para identificar el cambio), sector/área, equipo y/o sistema, system owner (propietario del sistema), contenido del cambio, clasificación de relevancia BPx, impacto documental, impacto productivo, plazo de implantación y campos para follow-up con fecha.
Revisão Periódica
Independientemente del tratamiento de los cambios, las validaciones del sistema deben revisarse periódicamente. En general, en este ámbito, evitamos el término "revalidación", y solemos utilizar la actividad de Revisión Periódica para verificar la actualización de la validación del sistema y, al final de esta tarea, comprobar si el sistema sigue teniendo el estado de validado.
La revisión periódica de los sistemas informatizados debe realizarse con el objetivo de asegurar que los posibles cambios en los procesos, los componentes del sistema o el mantenimiento, por ejemplo, no han afectado a su estado de validación. Debe determinarse un calendario de revisión para todos los sistemas.
La frecuencia de las revisiones de validación debe basarse en la criticidad del sistema. No es productivo establecer la misma frecuencia de revisión periódica para todos los sistemas de la empresa, ya que algunos de ellos son más dinámicos y más inestables que otros. Es interesante utilizar el enfoque de frecuencia variable para un mismo sistema y aún más interesante definir la primera revisión periódica relativamente cerca del final de la validación del sistema (aproximadamente 6 meses), precisamente para estudiar la estabilidad posterior a la implantación. Si esta primera revisión periódica se lleva a cabo sin problemas, y el sistema demuestra ser estable, los cambios y la administración de usuarios y backups actualizados, la revisión periódica se puede posponer durante 1 año y luego aumentar el tiempo de la frecuencia en el siguiente, dependiendo del resultado de este último proceso de revisión periódica.
La revisión debe tener en cuenta varios aspectos, como:
- La documentación de validación del sistema
- La documentación de la revisión anterior
- Los controles de cambios emitidos, las desviaciones ocurridas
- Los procedimientos operativos, el control de acceso al sistema
- La correcta ejecución de backup del sistema
- El status del sistema informático (por ejemplo, espacio en disco, uso de RAM)
- El status de los archivos históricos y las pistas de auditoría.
Si se detecta algún problema en el sistema, debe establecerse un plan de acción.
Durante la evaluación de la documentación de validación, es importante prestar especial atención al Análisis de Riesgos Funcionales y comprobar si los escenarios de riesgo, clasificaciones y mitigaciones que se exigían en el momento de la implantación siguen vigentes y son necesarios. Pueden surgir nuevos escenarios de riesgo si los cambios no se han controlado bien. En este caso, es necesario revisar el Análisis de Riesgos y proceder así como una "mini validación" en busca de nuevas mitigaciones (controles para disminuir los nuevos riesgos) y pruebas que demuestren que la validación se ajusta al proceso actual. El Informe de Revisión Periódica no debe finalizarse hasta que se hayan resuelto todas las cuestiones pendientes.
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 Sindusfarma. Ha impartido cursos de formación para inspectores de VISA y ANVISA. CEO y Co-fundadora de FIVE Validation.
