CAPÍTULO 3. PROPUESTA PARA VALIDACIÓN DE SISTEMAS AUTOMÁTICOS Y
3.2 Plan de Validación 37
Planeación para la validación. 14.2 3.2 Plan de Validación.
Documentación. 14.3 3.2 Plan de Validación.
3.4 Plan del Proyecto y Calidad
3.9 Reporte de Validación
Calificación. 14.4 3.7 Pruebas al Equipo o Sistema.
Sistemas computacionales. 14.8 1.2 Marco Normativo. Mantenimiento del estado validado. 14.11 3.10 Mantenimiento del Estado Validado
PROPUESTA PARA VALIDACIÓN DE SISTEMAS AUTOMÁTICOS Y DE CÓMPUTO PARA LA INDUSTRIA FARMACÉUTICA
Página 33 de 125
Tabla 3.2. Correspondencia entre mi Propuesta y la GAMP4.
PROPUESTA DE VALIDACIÓN GAMP4
Antecedentes y Marco Normativo 1.0 1.0 Introducción a la GAMP (Introduction to GAMP)
Antecedentes 1.1 1.1 ¿Cómo surgió la iniciativa GAMP? (How did the GAMP Initiative start?)
Validación, Ciclo de Vida y GAMP 2.0 6.0 Generalidades de la Validación (Validation Overview)
Validación 2.1
Propuesta para Validación de Sistemas Automáticos y de Cómputo para la
Industria Farmacéutica. 3.0 7.0 Ciclo de Vida de Validación (Validation Life Cycle)
Análisis 3.1 8.0
Sistema de Administración para Proveedores de Sistemas de TI (Management System for Suppliers of IT Systems)
9.0
Validación de Sistemas de Control de Proceso (Process Control System Validation)
Plan de Validación 3.2 7.5 Validación, Plan del Proyecto y Calidad (Validation, Quality and Project Plan)
8.1.2 Planeación (Planning)
9.1 Planeación (Planning)
Especificación de Requerimientos de usuario (URS) y Especificación Funcional
(FS). 3.3 7.3
Especificación de Requirimientos de Usuario (User Requirements Specification)
8.1.3
Especificación, Diseño y Construccción (Specification, Design and
Construction)
9.2 Especificación y Diseño (Specification and Design)
Plan del Proyecto y Calidad 3.4 7.5 Validación, Plan del Proyecto y Calidad (Validation, Quality and Project Plan)
8.1.2 Planeación (Planning)
9.1 Planeación (Planning)
PROPUESTA PARA VALIDACIÓN DE SISTEMAS AUTOMÁTICOS Y DE CÓMPUTO PARA LA INDUSTRIA FARMACÉUTICA
Página 34 de 125 Matriz de Rastreabilidad de
Requerimientos 3.5 8.2.1 Revisiones (Reviews)
9.7 Revisión de Diseño (Design Review)
Especificación de Diseño 3.6 8.1.3
Especificación, Diseño y Construccción (Specification, Design and
Construction)
9.2 Especificación y Diseño (Specification and Design)
Pruebas al Equipo o Sistema 3.7 7.9 Pruebas (Testing)
8.4 Especificaciones de Prueba (Test Specifications)
9.7 Revisión del Diseño (Design Review)
9.12 Desarrollo de Pruebas (Development Testing)
9.13 Pruebas de Aceptación (Aceptance Testing)
9.15 Calificación (Qualification)
Registro de Capacitación 3.8 7.11.2 Capacitación (Training)
8.2.4
Capacitación del Usuario por el Proveedor (Training of Supplier Staff)
Reporte de Validación 3.9 7.10 Reporte de Validación (Validation Reporting)
9.16 Reporte de Validación (Validation Report)
Mantenimiento del Estado Validado 3.10 7.11 Mantenimiento del Estado Validado (Maintaining the Validated State) 9.17 Mantenimiento del Estado Validado (Maintaining the Validated State)
Retiro 3.11 9.18 Retiro (Retirement)
7.11.14 Retiro del Sistema (System Retirement)
PROPUESTA PARA VALIDACIÓN DE SISTEMAS AUTOMÁTICOS Y DE CÓMPUTO PARA LA INDUSTRIA FARMACÉUTICA
Página 35 de 125
Tabla 3.3. Correspondencia entre mi Propuesta y la Norma NMX-CC-9001-IMNC- 2000.
PROPUESTA DE VALIDACIÓN NMX-CC-9001-IMNC-2000
Propuesta para Validación de Sistemas Automáticos y de Cómputo para la
Industria Farmacéutica. 3.0
Plan de Validación 3.2 5.4 Planificación
Especificación de Requerimientos de usuario (URS) y Especificación Funcional
(FS). 3.3 5.2 Enfoque al Cliente
7.2.1 Determinación de los requisitos relacionados con el Producto
7.3.2 Elementos de Entrada para el Diseño y Desarrollo
Plan del Proyecto y Calidad 3.4 5.4 Planificación
7.1 Planificación de la realización del Producto
7.3.1 Planificación del Diseño y Desarrollo
7.3.4 Revisión del Diseño y Desarrollo
Matriz de Rastreabilidad de
Requerimientos 3.5 5.2 Enfoque al Cliente
7.2.2 Revisión de los requisitos relacionados con el Producto
7.5.3 Identificación y Trazabilidad
Especificación de Diseño 3.6 7.3 Diseño y Desarrollo
7.3.1 Planificación del Diseño y Desarrollo
7.3.3 Resultados del Diseño y Desarrollo
Pruebas al Equipo o Sistema 3.7 7.2.2 Revisión de los requisitos relacionados con el Producto
7.3 Diseño y Desarrollo
7.3.1 Planificación del Diseño y Desarrollo
7.3.4 Revisión del Diseño y Desarrollo
7.3.5 Verificación del Diseño y Desarrollo
7.3.6 Validación del Diseño y Desarrollo
7.4.3 Verificación de los Productos comprados
Registro de Capacitación 3.8 6.2.2 Competencia, toma de conciencia y formación
Reporte de Validación 3.9 7.3.6 Validación del Diseño y Desarrollo
PROPUESTA PARA VALIDACIÓN DE SISTEMAS AUTOMÁTICOS Y DE CÓMPUTO PARA LA INDUSTRIA FARMACÉUTICA
Página 36 de 125 Mantenimiento del Estado Validado 3.10 4.2.3 Control de los documentos
8.2.2 Auditoría interna
8.2.3 Seguimiento y medición de los procesos
8.2.4 Seguimiento y medición del producto
8.4 Análisis de datos
8.5.1 Mejora continua
8.5.2 Acciones correctivas
PROPUESTA PARA VALIDACIÓN DE SISTEMAS AUTOMÁTICOS Y DE CÓMPUTO PARA LA INDUSTRIA FARMACÉUTICA
Página 37 de 125
3.2 PLAN DE VALIDACIÓN
El primer paso que nos marca la GAMP4 (para los 3 tipos de sistemas), dentro de la etapa de Planeación y Especificación, para iniciar con el ciclo de vida de un sistema es elaborar un Plan de Validación. De hecho nos habla del desarrollo de un Plan Maestro de Validación y de los Planes de validación para proyectos o sistemas.
Un Plan de Validación es el documento donde se definen las actividades de validación, las responsabilidades y los procedimientos a seguir para llevarla a cabo. En cada Empresa dependerá el nombre que se le quiera dar y el alcance que tenga, los más comunes son Plan Maestro de Validación, Plan de Validación y Guías de Validación.
Las siglas en inglés para los términos que utilizaremos para la descripción de estos documentos de validación son: VMP para el Plan Maestro de Validación (Validation Master Plan) y VP para un Plan de Validación (Validation Plan).
Usualmente en el VMP se definen todas las áreas y elementos que requieren validación dentro de una Compañía y se define el plan general para el cumplimiento de esas validaciones específicas. Este Plan no lo comentaremos a fondo ya que el alcance de ese Plan es toda la Planta (limpieza de áreas de producción y equipos, procesos de producción, edificios, instalaciones, equipos y sistemas automáticos y críticos, etc) y nosotros hablaremos del VP que nos definirá como validar en específico uno de los elementos que comprende el VMP.
La importancia del VP radica en que este Plan junto con la Especificación de Requerimientos son la base para definir el Plan del Proyecto y Calidad, entre Usuario y Proveedor.
La GAMP4 nos dice que para cada sistema GMP (Good Manufacturing Practice, Buenas Prácticas de Manufactura) se debe elaborar un Plan de Validación, pero también aclara que cada Compañía establece la estructura en que desarrollara sus Planes.
En esta parte me parece importante mencionar que para un sistema nuevo es conveniente hacer su Plan de Validación individual, pero en el caso de sistemas pequeños que se puedan agrupar o en el caso de aplicar un Plan general de validación para varios equipos iguales en la Planta lo que conviene es hacer un solo Plan que aplique a esos determinados sistemas o equipos.
El Plan de validación es la clave para todo el proceso de validación, en él se puede describir la estrategia de validación que se seguirá o hacer referencia al documento donde está descrito.
Un aspecto importante dentro de la documentación son las firmas y hablando del VP debe ser firmado por el área de Aseguramiento de Calidad y por los usuarios finales
PROPUESTA PARA VALIDACIÓN DE SISTEMAS AUTOMÁTICOS Y DE CÓMPUTO PARA LA INDUSTRIA FARMACÉUTICA
Página 38 de 125 del sistema o equipo. El significado de las firmas debe ser definido. La responsabilidad de elaborar el VP recae en el propietario del sistema o en el líder del proyecto.
El contenido de un Plan de Validación debe definir:
Las actividades requeridas.
Cómo esas actividades se llevarán a cabo y quiénes son los responsables de
ello.
Cuáles deben ser los resultados.
Cuáles serán los requisitos para la aceptación.
Cómo se mantendrá la validación del sistema durante su ciclo de vida.
La GAMP4 menciona que puede haber la necesidad de generar una serie de reportes para indicar el avance en el proyecto o la aprobación de etapas parciales del proyecto. Si este fuera el caso, deberá indicarse en el VP que se emitirán dichos reportes.
La GAMP4 contempla los siguientes puntos como contenido de un Plan de Validación: 1. Introducción y alcance. 2. Estructura organizacional. 3. Evaluación de la criticidad. 4. Estrategia de validación. 5. Entregables de la validación. 6. Criterios de aceptación. 7. Control de cambios. 8. Procedimientos. 9. Capacitación. 10.Administración de documentos. 11.Mantenimiento del estado validado. 12.Glosario.
A continuación les presento la Plantilla que propongo para desarrollar un Plan de validación para un proyecto. Estoy tomando como base el contenido y la estructura que propone la GAMP4, pero adiciono algunas secciones que me parece importante
incluir. Los datos propios de la empresa como derechos reservados, logos de
confidencialidad, deben ser seguidos conforme a las políticas de la empresa.
En mi experiencia, el primer documento que realizo para la validación de sistemas GMP es un Plan de aseguramiento de Calidad, más no un Plan de Validación, como sugiere la GAMP4. Esto es porque los planes para validar los sistemas están contemplados en VMP’s generales. Por mi parte sugiero que se realice el VP y posteriormente en otra etapa el Plan de Calidad, ya que ambos tienen características especificas e importantes. De esta manera el VP se puede realizar desde el punto de vista de usuario y el QPP (Plan del Proyecto y Calidad, Quality and Project Plan) desde el punto de vista del acuerdo de Usuario y Proveedor.
PROPUESTA PARA VALIDACIÓN DE SISTEMAS AUTOMÁTICOS Y DE CÓMPUTO PARA LA INDUSTRIA FARMACÉUTICA
Página 39 de 125
PLANTILLA 1. PROPUESTA DE CONTENIDO DE UN PLAN DE
VALIDACIÓN
1. Carátula del documento.
La carátula debe proporcionar información como:
Nombre del Laboratorio Farmacéutico y/o logo.
Nombre del documento.
Numero de identificación del documento. (Usualmente cada empresa tieneestablecido un procedimiento para asignar números o claves a sus documentos de ciclo de vida para su manejo y control).
Fecha de emisión del documento.
Versión del documento emitido.2. Índice.
3. Registro de cambios al documento.
Este registro de cambios debe proporcionar información de los cambios hechos al documento, por ejemplo: fecha de modificación, persona que realizó el cambio y en que consistió el cambio. En este registro de cambios cuando un documento es elaborado se puede incluir la fecha de emisión del documento, quién lo elaboró y que es su primera emisión.
Esta sección es importante porque nos muestra todo el historial de cambios que ha tenido el documento desde su emisión, lo cuál apoya al control de cambios que se debe llevar a lo largo de la validación.
4. Sección de firmas.
En toda la documentación es importante esta sección ya que en ella deben ser incluidas las firmas de la persona que elabora el documento, de los revisores y de los aprobadores. Las firmas deben definir bajo qué autoridad se está firmando y con qué objetivo. Esta sección de firmas tiene relación con la sección de descripción de roles y responsabilidades, ya que el número de firmas debe asegurar el cumplimiento de los requerimientos de todos los Departamentos.
Se pueden incluir tantas áreas firmantes como sean necesarias para el cumplimiento del objetivo del proyecto.
PROPUESTA PARA VALIDACIÓN DE SISTEMAS AUTOMÁTICOS Y DE CÓMPUTO PARA LA INDUSTRIA FARMACÉUTICA
Página 40 de 125
5. Introducción.
Esta sección debe dar un bosquejo general del contenido del documento, recomiendo describir los antecedentes del proyecto y de una manera breve en que consistirá el proyecto.
6. Objetivo.
En esta sección se definen el o los objetivos del documento. Es importante que estos sean precisos para no caer en ambigüedades.
7. Alcance.
La importancia de esta sección es que en ella se define el alcance del documento, señalando los límites del objetivo del mismo. En esta sección se puede mencionar el periodo en el cual se realizará la siguiente revisión al documento (en el caso de que aplique).
8. Referencias.
Es importante mencionar documentos con los que tenga relación este Plan que se está desarrollando o los documentos que sirvieron como base para su elaboración, por ejemplo políticas, procedimientos, guías, VMP’s, etcétera.
9. Descripción de los roles y responsabilidades.
La GAMP4 señala que en esta sección se deben describir los roles y responsabilidades como mínimo del Líder o administrador del Proyecto, del departamento de Aseguramiento de Calidad y de los Dueños del sistema.
10.Evaluación de la criticidad del sistema.
Aquí se debe describir la evaluación de la criticidad del sistema, ésta debe incluir un alto nivel de valoración de la información o recurrir a alguna fuente de información relacionada a este tema. Cada empresa debe tener establecidos los criterios de clasificación de sus sistemas. Recomiendo en base a mi experiencia y la GAMP4 cubrir lo siguiente:
1. Clasificación de Software / Sistema
Clasificación de
Software / Sistema Descripción
Categoría 1:
Sistemas Operativos / Infraestructura
Están disponibles en el mercado como Sistemas Operativos. Aplicaciones que están desarrolladas para ejecutarse bajo la plataforma de estos sistemas operativos. También incluye la infraestructura para Sistemas Operativos y Redes, aplicaciones
PROPUESTA PARA VALIDACIÓN DE SISTEMAS AUTOMÁTICOS Y DE CÓMPUTO PARA LA INDUSTRIA FARMACÉUTICA
Página 41 de 125 web, y software de servidor. Ejemplos: Windows XP, Unix, Windows NT, DOS, etc.
Los sistemas de esta categoría no están sujetos a una validación específica, ya que su funcionalidad es probada indirectamente durante las pruebas involucradas en la validación de la aplicación. El nombre del sistema operativo y su versión deben ser documentados en la Especificación de Diseño y verificados en la Calificación de Instalación.
Categoría 2: Sistema Firmware
Sistemas que no están personalizados ni en hardware ni software. Es una combinación de hardware con instrucciones que dan como resultado un software de solo lectura en ese dispositivo. Dentro de esta clasificación caen instrumentos y controladores. Ejemplos: Sistemas que trabajan a partir de un PLC u otro controlador, básculas, lectores de código de barras, cronómetros, etc.
Para los sistemas firmware, su nombre, versión y configuración deben ser documentados en la Especificación de Diseño y verificados en la Calificación de Instalación. Su operación también debe ser probada en un protocolo.
Clasificación 3: Sistema Estándar
Estos sistemas están disponibles en el mercado como software estándar, (llamados en inglés “off-the-shelf”) y proveen una solución de negocio o de proceso de manufactura. No son configurados para definir procesos de manufactura o de negocio. El sistema puede ser adaptado con cambio de datos para operar dentro de un ambiente operativo específico pero no son adaptados para conformar un usuario específico. Ejemplos: Paquetes de análisis estadístico, software de instrumentos de laboratorio como un HPLC, etc.
Su nombre y versión deben ser documentados en la Especificación de Diseño y verificados en la Calificación de Instalación. Su operación también debe ser probada en un protocolo.
Clasificación 4: Sistema
Configurable
Software configurable que provee interfases y funciones estándar que habilitan la configuración de un usuario específico de procesos de negocio o manufactura. Envuelve módulos de software configurados de manera predefinida y la posibilidad de personalizar dichos módulos. Ejemplos: ERP, SCADA, etc.
Clasificación 5: Sistema
Personalizado
Estos sistemas son desarrollados para cubrir necesidades específicas de una Empresa. Incluyen la construcción y personalización del sistema completo o subsistemas. No es un software o sistema comercial. Ejemplo: Desarrollos en Oracle.
PROPUESTA PARA VALIDACIÓN DE SISTEMAS AUTOMÁTICOS Y DE CÓMPUTO PARA LA INDUSTRIA FARMACÉUTICA
Página 42 de 125
11.Estrategia de Validación.
Esta sección debe describir la estrategia de validación a ser aplicada, haciendo referencia a los procedimientos de sistemas automáticos a ser seguidos y el modelo de ciclo de vida a ser aplicado. Esta sección se basa en la determinación de la criticidad del sistema. Conforme la GAMP4 también se pueden definir los requerimientos de calificación de hardware y software y si hay algún impacto en el sistema de infraestructura.
Si la validación se realizara en etapas, es en este documento donde se pueden definir esas etapas, sus entregables y como se pondrá el sistema o una determinada parte del sistema en funcionamiento.
Si la estrategia de validación no incluye la auditoría al proveedor esta sección debe justificar el porque no se contempla.
En concreto la GAMP4 recomienda que se describa:
El modelo del ciclo de vida.
La evaluación del riesgo del proceso.
Las categorías de hardware y software.
Las salidas y entradas requeridas para cada nivel o etapa del proyecto.
Los criterios de aceptación para cada nivel o etapa.12.Documentos a realizar en la validación (entregables).
Esta sección debe describir los documentos a elaborar, incluyendo las responsabilidades de elaboración, revisión y aprobación de cada uno de ellos. Conviene hacer una tabla donde se indiquen las etapas del proyecto, que documentos se elaborarán y los responsables.
13.Criterios de aceptación.
Aquí se debe definir de manera general los criterios de aceptación para el sistema.
14.Control de Cambios.
Esta sección debe mencionar cómo se llevarán a cabo los controles de cambio para la implementación del nuevo equipo o sistema y como se llevará el control de cambios en el desarrollo de los mismos. Se puede hacer referencia a los procedimientos existentes para estos fines.
PROPUESTA PARA VALIDACIÓN DE SISTEMAS AUTOMÁTICOS Y DE CÓMPUTO PARA LA INDUSTRIA FARMACÉUTICA
Página 43 de 125
15.Capacitación.
Se deben establecer los requerimientos de capacitación tanto del equipo de proyecto como a los usuarios del sistema.
16.Calendario de actividades y recursos.
Esta sección da un esbozo de las actividades de validación, tiempos de finalización y los recursos asignados para cada tarea.
17.Mantenimiento del estado validado.
En esta sección se deben definir las acciones y procedimientos a seguir para mantener el estado del sistema validado.
18.Glosario, Acrónimos y Términos
Esta sección contiene la definición de los términos que pueden no ser familiares para el lector.
19.Anexos
En esta sección se puede incluir información necesaria para la completa comprensión del documento.
3.3 ESPECIFICACIÓN DE REQUERIMIENTOS DE USUARIO (URS) Y