GAMP 5
Cada vez mas la industria ha hecho énfasis en la seguridad del paciente, la calidad del producto y la integridad de los datos. Estas son las directrices que han tenido en cuenta las GAMP 5. En paralelo, otras consideraciones en la nueva versión han sido:
Evitar que las actividades se duplicaran (integración de las actividades de ingeniería y las relacionadas con los sistemas informatizados para hacerlas solo una vez). Incremento en lo posible de las actividades realizadas por los proveedores sin olvidar asegurar que las aplicaciones sean adecuadas para el uso previsto. Escalado de todas las actividades del ciclo de vida y la documentación asociada en base a riesgo, complejidad y novedad de las mismas. Reconocimiento del hecho que la mayoría de sistemas computarizados están hoy basados en paquetes configurables, muchos de ellos en red. Considerar que los modelos de desarrollo lineal o en cascada no siempre son los más apropiados.
En concepto clave que acentúa GAMP, consiste en considerar el sistema informatizado como uno de los componentes integrantes de un sistema mas amplio o incluso del proceso productivo, especialmente en un entorno integrado de QbD (Quality by Desgin); pero tanto una validación de los sistemas informatizados especifica y separada puede o no ser necesaria en adelante. El enfoque integrado de la validación, por lo tanto ha llevado a la definición de otros aspectos heredados, tales aspectos son:
Gestión del riesgo de la calidad (QRM).
Maximización de la implicación del proveedor.
Aproximación de ciclo de vida en el ámbito del sistema de gestión de la calidad (QMS).
Actividad en el ciclo de vida escalable.
Conocimiento del producto y del proceso.
GESTION DEL RIESGO DE LA CALIDAD
El objetivo es determinar el impacto del sistema informatizado sobre la seguridad del paciente, la calidad del producto y la integridad de los datos en el proceso del negocio. La GAMP 5 sugiere evaluar la complejidad del proceso de utilización y la complejidad del sistema informatizado asociado. Un sistema típico de alto impacto, posee las siguientes características:
Genera, manipula o controla datos para la seguridad y la eficacia del producto. Controla los parámetros o los datos críticos, incluidos datos preclínicos, clínicos, de desarrollo y producción.
Controla datos para la liberación del producto.
Controla los datos que se requieren en caso c aso de una “retirada del mercado”
Controla los datos relacionados con acontecimientos adversos en el ámbito de la farmacovigilancia.
La gestión del riesgo de la calidad de sistemas de alto impacto, puede por lo tanto explicarse mediante la emisión de un documento de evaluación del riesgo que considera como puede influir en la calidad del producto en cada una de las diferentes fases del proyecto, desde el desarrollo del software a la del arranque de la producción. La “evaluación de riesgo inicial”, por ejemplo, debe contribuir al desarrollo del proceso de planificación; se caracteriza por una serie de decisiones clave, basadas en la limitación del riesgo, que se deben tomar en la fase de la planificación, y que abarcan:
Evaluación y auditoria del proveedor. Determinación de todas las actividades, los objetivos y las responsabilidades a fin de poder obtener la conformidad GMP del sistema para su uso especifico. Evaluación a continuación de la ejecución de un análisis de riesgos funcional.
Todas estas decisiones se deben documentar ya que implican decisiones basadas en la evaluación el riesgo para la generación y el mantenimiento de la conformidad GMP de los sistemas, y permiten obtener ventajas a dos niveles:
ESCALABILIDAD: a nivel del sistema, lo que implica que los sistemas de bajo impacto pueden ser documentados y verificados con menor grado de rigurosidad. ENFOQUE: a nivel funcional, mayor rigor en las pruebas de funcionalidad de riesgo elevado, mientras que para las funcionalidades de bajo riesgo las pruebas serán menos rigurosas.
Tras la concepción y desarrollo del sistema, la automatización permite controlar los riesgos del proceso detectados inicialmente, pero al mismo tiempo puede introducir nuevos riesgos (p.e. integridad de los registros electrónicos, disponibilidad del sistema, seguridad, infraestructura) no asociados a un proceso “manual”; por lo tanto también en esta fase se hace necesario hacer una evaluación que debe centrarse en la potenciales riesgos de cada una de las funciones del sistema dependiendo el grado de criticidad cada función será verificada con grado diferente de rigurosidad. Tras la fase de pruebas, el SGC debe prever la planificación de aquellos aspectos y decisiones de funcionamiento que se deben considerar para mantener el estado valido del sistema. Decisiones a considerar para el mantenimiento operativo del sistema son:
Disponibilidad del sistema
Frecuencia y nivel de la copia de seguridad (backup) y de la recuperación
Plan de desastre
Seguridad del sistema
Control de cambios
Revisiones periódicas
El sistema a de gestión del riesgo de la calidad descrito en las GAMP 5 considera también la fase final del ciclo de vida del sistema, cuando un sistema entra en un plan de substitución o va a dejar de usarse, se deben tener en cuenta los aspectos siguientes:
Retención y migración de los datos críticos
Verificación de la compatibilidad de los datos migrados en el sistema que los remplazara
CATEGORIAS DE SOFTWARE DE LA GAMP
GAMP 5 utiliza cuatro categorías de software diferente, las cuales son: 1. Software de infraestructura
Esta categoría se divide en dos tipologías de software:
Software estándar o disponible en el comercio: son plataformas estándares, en esta categoría entran los sistemas operativos, gestores de bases de datos, lenguajes de programación, herramientas estadísticas de programación, etc. Herramientas de software de infraestructura: sistemas de software de monitorización de la red, herramientas del tratamiento por lotes, software de seguridad, antivirus y herramientas de la gestión de la configuración.
Esta categoría no exige validación específica pero sin embargo tendría que hacerse un análisis de riesgo para valorar el potencial sobre la seguridad de otras aplicaciones criticas asociadas (gestión de contraseñas o gestión de la seguridad). 2. Software no configurable
Son aplicaciones que se fabrican en tamaños estándar, se trata o de sistemas no configurables adaptados para un proceso del negocio o de sistemas configurables pero que ya tienen parámetros por defecto, en ambos casos la configuraciones del tipo “entorno de usuario” (p.e. la configuración de una impresora) Las especificaciones funcionales y de diseño no se exigen, pero sin embargo una descripción de sistema es recomendable; la verificación se puede hacer en una única fase de pruebas. Todos los cambios deben ser trazables, incluidas eventuales actualizaciones realizadas por el proveedor.
Todos los PNT necesarios para el uso y la gestión del sistema deben emitirse. La gestión de la configuración podría aplicarse a aquellos sistemas en los cuales la selección de los parámetros por defecto se realiza de manera precisa. 3. Software configurable
Son aplicaciones con interfaces estándar pero con funcionalidades que se pueden configurar y adaptar a los diferentes requisitos del negocio. Esto implica generalmente módulos de software de configuración predefinida. Muchos de los riesgos asociados a estos software dependen por completo de la tipología de la configuración asociada al proceso del negocio. En este caso se necesita un documento de requerimiento de usuario (URS) extremadamente detallado; las especificaciones funcionales se deben hacer exclusivamente por el proveedor con un grado de detalle elevado de manera que se garantice, posteriormente, que se hayan previsto todas las pruebas necesarias. La verificación de las pruebas debe satisfacer todos los requisitos de los URS, con particular atención a las funciones configuradas específicamente para el negocio La aproximación de la validación se caracteriza por un ciclo de vida completo con una evaluación del proveedor que permita determinar el estado de su propio SGC y un posterior análisis de riesgo funcional para evaluar e indexar la prioridad de las funciones mas criticas para el proceso. 4. Software desarrollado a medida
Los sistemas a sub-sistemas hechos a medida han sido desarrollados específicamente para satisfacer los requisitos específicos de una compañía; el riesgo asociado es alto. La aproximación aproximac ión a la validación es difícil puesto que no existen “experiencias anteriores” contrastables. Sin embargo, el ciclo de vida de la validación es muy similar al producto configurado se le añadimos el diseño de software, generalmente proporcionado por el proveedor, en el que se describe de forma minuciosa la arquitectura del hardware y del software del sistema. En ese caso, la evaluación del proveedor debe basarse en un análisis de riesgos y documentarse. Se exige generalmente una auditoria del proveedor para verificar que tenga un SGC adecuado.
