Validación de computadora

GMP

1 Contenidos

1 Contenido..................................................................................................1
2 Agradecimiento...................................................................................2
3 Introducción..............................................................................................3
4 Glosario..................................................................................................4
5 Alcance
6 Requisitos legales................................................................................4
7 Orientación
7.1Estrategia...................................................................................................5
7.1.1Enfoque. 5
7.1.2Análisis. 5
7.1.3Inventario. 5
7.1.4Análisis de Riesgos. 6
7.1.5Economía. 6
7.2Cumplimiento
7.3Plan de Proyecto.............................................................................................7
7.3.1Descripción. 7
7.3.2Organización. 7
7.3.3Gerente de Proyecto...........................................................................................7
7.3.4Propietario del sistema y patrocinador.........................................................................7
7.3.5Usuarios. 8
7.3.6Desarrollador/ Proveedor......................................................................................8
7.3.7Soporte Técnico de Computadora.................................................................8
7.3.8Unidad de Calidad. 8
7.3.9Matriz de Responsabilidad.....................................................................................8
7.4Ciclo de Vida del Sistema...................................................................................9
7.4.1Introducción. 9
7.4.2Categorías GAMP. 9
7.4.3Proceso del Ciclo de Vida del Sistema.........................................................................12
7.4.4Planificación. 12
7.4.5Especificación............................................................................................... 12
7.4.6Selección de proveedores / vendedores.........................................................................13
7.4.7Diseño y construcción.............................................................................14
7.4.8Pruebas de Aceptación.14
7.4.9Implementación y aceptación.................................................................16
7.4.10Operación en curso;...................................................................................16
7.4.11Uso del sistema........................................................................................... 17
7.4.12Seguridad. 17
7.4.13Copia de seguridad y restauración..............................................................................17
7.4.14Recuperación de desastres.17
7.4.15Planificación de contingencias...............................................................................17
7.4.16Continuidad del negocio.18
7.4.17Mantenimiento preventivo...........................................................................18
7.4.18Mantenimiento correctivo (Informe de problemas)............................................18
7.4.19Control de cambios.........................................................................................18
7.4.20Registro de auditoría. 18

página1/ 39
 7.4.21Entrenamiento..................................................................................................... 18
7.4.22Evaluación periódica.18
7.4.23Archivando................................................................................................... 19
7.4.24Fase de jubilación.19
7.4.25Infraestructura. 19
7.4.26Entregables y actividades de validación..............................19
8 Apéndices............................................................................................22
8.1Glosario. 22
8.2Listas de verificación prácticas para la validación de computadoras......................................................22
8.3Matriz de Trazabilidad de Especificaciones de Requisitos de Usuario..........................................25
8.4 Definición...........................................................................................................26
8.5Control de Cambios.27
8.5.1Alcance. 27
8.5.2Sistema de control de cambios...............................................................................27
8.6Matriz. 27
8.7Beneficios. 27
8.8Referencias........................................................................................................ 28
8.8.1Sitio web de la FDA / Directrices de la FDA..........................................................................28
8.8.2ICH................................................................................................................... 29
8.8.3 G.A.M.P.. 29
8.8.4 IEEE 730, 828, 829, 830, 1012.......................................................................29
8.8.5 ISO Normas. 29

8.9 Apéndice/Glosario..........................................................................................30
2 Reconocimiento

Este documento fue preparado por un Grupo de Trabajo compuesto por representantes de
varias empresas que participan en los Ingredientes Farmacéuticos Activos
Comité de CEFIC.
Agradecemos a todos los miembros mencionados a continuación por sus esfuerzos, cooperación,
creatividad, comentarios constructivos y resistencia. Sin estos
elementos este documento no habría alcanzado su estado actual.
Los miembros de este Grupo de Trabajo son:

Lisa Näsman* (Astra Zeneca)

Claude Becker (Seloc/PCAS)
Gert Beets* (OmniChem)
Jean-Pierre Bovee (Aventis)
Gerben Canninga* (Diosynth)
Nigel Cryer (MSD/Merck)
William Cuijpers* (Diosynth)
Kees Piket (Solvay Pharmaceuticals)
Willy Verhaegen (OmniChem)
Allert Wiersema (DSM Antiinfecciosos)
* estos miembros se fueron antes de terminar el documento o se unieron más tarde

3 Introducción

En la última década, los sistemas informatizados se han convertido en una parte vital en la fabricación de
Ingredientes Farmacéuticos Activos.
Las aplicaciones típicas son Sistemas de Control de Procesos (DCS, PLC, SCADA), Laboratorio
Sistemas de Gestión de Información de Laboratorio (LIMS), Sistemas de Control de Instrumentos de Laboratorio y
Sistemas Empresariales (ERP, MRP II).

Las regulaciones cGMP implican que la funcionalidad de esos sistemas computerizados, que tienen
la influencia en la calidad de la API debe ser validada.

La validación deberá demostrar que los parámetros definidos como críticos para su operación y
el mantenimiento se controla/gestiona adecuadamente.

Es esencial que la validación sea práctica y alcanzable, y que añada valor al proyecto.
y se concentra en los elementos críticos del sistema.

Esta directriz describe el alcance y los requisitos legales para la validación de sistemas informatizados.
los sistemas, los capítulos 7 a 9 ofrecen una metodología integral adecuada para la mayoría de las situaciones
dentro de situaciones de control de producción de API y manejo de datos.

En algunos casos específicos, la cobertura puede ser menos extensa y/o puede haber subsecciones.
fusionado dependiendo de la criticidad y la importancia de los sistemas a validar.
Donde se deben manejar los casos de validación especializada, el párrafo 10 proporciona la orientación oficial.
referencias y directrices de la industria.
 GMF

4 Glosario
Consulte el Apéndice (capítulo 8)

5 Alcance
Esta guía está destinada a ser utilizada por fabricantes de Ingredientes Farmacéuticos Activos (API)
y intermediarios que utilizan sistemas computarizados para varias partes del proceso que conducen a
la fabricación de un API o intermedio. Proporciona interpretación de cGMP existentes
directrices relacionadas con la validación de computadoras críticas para la calidad. Estas interpretaciones tienen como objetivo
ser práctico por un lado y aceptable tanto para la industria como para las autoridades por otro.
El énfasis está en explicar "qué hacer" y en menor medida en "cómo hacerlo".
Donde sea práctico y factible, se prestará atención a vincular la validación de los sistemas informatizados.
sistemas con otros tipos de validación, como la validación de procesos y la validación de equipos.

Dentro de esta guía se prestará atención a dos partes esenciales de los sistemas informatizados:
1. Infraestructura
2. Aplicaciones

Al aplicar el contenido de esta guía, se debe tener en cuenta que no todas las computadoras
los sistemas contendrán todos los elementos (a a e) mencionados a continuación.
Los siguientes aspectos se cubrirán:
a. hardware
b. sistema operativo
c. sistema de red
sistema de gestión de bases de datos
e. software del sistema

f. estrategia
cumplimiento
h. plan de proyecto
ciclo de vida del sistema
j. control de cambios

Aparte de los temas mencionados anteriormente, actividades de apoyo como la capacitación de personal,
se cubrirá la documentación y el uso de listas de verificación. Se prestará atención al aspecto de
análisis de riesgos en relación con la validación de sistemas computadorizados.
Nota
Aunque no se incluirá orientación en este documento relacionada con los registros electrónicos y
firmas (consulte la parte 11 del 21 CFR), esta área temática debe ser considerada en el URS.

6 Requisitos legales
Los sistemas informatizados utilizados en la fabricación de API deben ser debidamente desarrollados.
validado y mantenido para asegurar la integridad de los datos y del producto.
ICH Q7a cubrirá esto además de las regulaciones GMP enumeradas en la parte 211 del Código de
Regulaciones Federales de los EE. UU.
 GMP

7 Orientación

7.1 Estrategia
En el entorno empresarial de hoy en día, los sistemas informatizados se utilizan cada vez más. Es crítico
diseñarlos y validarlos para que sean adecuados para su propósito y satisfagan al usuario así como
requisitos de cumplimiento
Hay una necesidad de aclarar esta área muy compleja y a menudo malentendida de
cumplimiento. Esta área es cada vez más el dominio de unos pocos consultores y expertos.
Este documento proporcionará una guía clara y transparente para los fabricantes de API.
Ayudará a la industria a restablecer el equilibrio entre demasiado, a menudo ineficaz,
documentación con muy poco impacto en la garantía de calidad. Esto traerá un costo
efectivo, valor añadido, forma eficiente y efectiva de realizar la validación de computadoras
sistemas que se mantienen en cumplimiento.
Una estrategia para lograr esto se establecerá en un enfoque pragmático utilizando un Plan de Validación.
incluyendo los elementos a continuación.

7.1.1 Enfoque
1. El enfoque para la validación de sistemas informáticos debe basarse en el sentido común y
utilizar técnicas que son familiares en otras áreas de validación y también en los negocios.
2. Es importante establecer el objetivo final de la validación y elegir un enfoque.
donde se da una respuesta positiva, cada vez que se hacen las siguientes preguntas:
¿Tendrá esto un valor añadido?
¿Es esta la forma más eficiente?
¿Es esta la forma más efectiva?
¿Podemos alcanzar el 80 % del objetivo con el 20 % del esfuerzo?
Una forma de ayudar con estas decisiones es usar diagramas de flujo simples.

7.1.2 Análisis
Se puede establecer una prioridad para las actividades de validación analizando un inventario del sistema para el
criticidad, estado de validación, categoría de software y tipo de sistema. Este análisis ayuda a la validación
planificación y priorización.

7.1.3 Inventario
Para un enfoque efectivo, primero haga un inventario de los sistemas existentes y de cualquier sistema propuesto.
Al compilar el inventario, se debe hacer una evaluación sobre la criticidad de cada sistema.
usando un enfoque metódico. Esta lista debe mantenerse completamente actualizada y las prioridades deben
ser asignado una vez que se complete el inventario actual.
Este inventario podría incluir clasificaciones basadas en el impacto potencial en la calidad del producto (por ejemplo.
crítico
La lista de inventario (que puede tomar la forma de una hoja de cálculo o base de datos) normalmente
incluir encabezados como:
nombre del sistema y número de versión
tipo de sistema, por ejemplo, sistema legado o sistema nuevo y módulos
propietario del sistema
uso del sistema, p. ej. gestión de materiales, control de procesos, control analítico, etc.
criticidad, por ejemplo, calidad del producto, cumplimiento, negocio
estado de validación
 BMP

fecha de implementación (real o planificada)

categoría de desarrollo (por ejemplo, listo para usar, desarrollado por el usuario, etc.)
categoría de software, por ejemplo, hojas de cálculo, PLC, controles de proceso
Categoría GAMP
CFR 21 parte 11, por ejemplo, registros electrónicos y firmas compatibles
Última verificación del rendimiento de validación.
Prioridad (un resultado del análisis de riesgo).

7.1.4 Análisis de Riesgos

(Ref. guía básica de ISPE para calificación y puesta en marcha)
Un análisis de riesgos debe incluir todos los factores, incluyendo seguridad, medio ambiente, calidad del producto y financiero.
ser tomado en consideración. Sin embargo, el más importante es definir la criticidad del
sistema. Observando el impacto del sistema en la calidad del producto, el estado de validación y el
el impacto potencial en el negocio puede hacer esto.
La calidad del producto puede verse afectada directa, indirecta o no en absoluto. Algunos ejemplos son los siguientes:
impacto directo: control del proceso del paso final de purificación, análisis del producto terminado
impacto indirecto: lista de distribución de productos terminados, programa de mantenimiento de equipos

Una vez validados, todos los sistemas informatizados deben ser mantenidos de acuerdo con el Ciclo de Vida del Sistema
Enfoque cíclico.
El enfoque cGMP para la validación se puede utilizar en un enfoque de calidad total para la computación.
sistemas involucrados en seguridad, medio ambiente, finanzas, sin embargo, no hay requisito legal para
haga eso y estos sistemas no deben estar sujetos a la inspección cGMP.

7.1.5 Economía
Dado que la producción de API generalmente ocurre en un entorno altamente competitivo, es de suma importancia
importancia de realizar la validación de manera eficiente y rentable. Con ese fin, cada
la empresa tiene que decidir cómo ejecutar la validación.
Se utilizan dos principales:
utilizar personal propio, bien educado y capacitado
contratar consultores para guiar y organizar la tarea de validación
La última opción debe ser considerada especialmente para empresas más pequeñas. Sin embargo, uno debe
darse cuenta de que se necesita cierta experiencia interna para mantener el control del sistema informático
actividades y de los costos. Es un requisito fundamental que la empresa misma permanezca
responsable de los resultados finales.
Para ayudar en el control de costos, es útil reconocer que no todos los sistemas computarizados están en
necesidad del mismo nivel de validación. Los sistemas menos críticos deben tener un nivel apropiado de
documentación.

Cumplimiento
Las regulaciones de cGMP implican que los sistemas informatizados que influyen en la calidad del API deben
ser validado.

La profundidad y el alcance de la validación dependen de la criticidad de la funcionalidad informatizada.

Esto debe establecerse mediante un análisis de riesgos en una etapa temprana de la validación
proceso.
Los puntos clave críticos de cumplimiento a tener en cuenta incluyen:
Ajuste comprobado para el propósito
Control de acceso / gestión de usuarios.
 GMP

La integridad de los datos incluye: prevención de eliminación, malas transcripciones y omisiones.

Cambios autorizados / no autorizados a los datos y documentos
Manejo de Alarmas Críticas (Proceso)
Rutas de auditoría
Recuperación de desastres / Copia de seguridad y recuperación
Mantenimiento del sistema y control de cambios
Entrenamiento

Se debe demostrar evidencia de un control suficiente de estos problemas en la validación.

documentación.
Esta conformidad debe integrarse utilizando el enfoque del ciclo de vida del sistema (SLC), y claramente
identificados en la fase de requisitos del usuario para cualquier nuevo sistema informatizado como se detalla en
capítulo0.
Para los sistemas existentes, para los cuales no se aplicó un modelo de ciclo de vida, debe realizarse un análisis de brechas.
emprendidos contra problemas de cumplimiento de cGMP. Los problemas identificados deben ser probados y
documentado siguiendo un plan/informe de calificación formal.
Para cualquier no conformidad identificada, se deben considerar las siguientes alternativas:
actualizando
asegurando el nivel de control solicitado a través de procedimientos adicionales si el
la actualización no es factible
reemplazando/mejorando el sistema donde las brechas son sustanciales y no pueden ser
cubierto por las medidas anteriores.

7.3 Plan de Proyecto

7.3.1 Descripción
El plan del proyecto es la columna vertebral de cualquier actividad de validación de TI para cualquier sistema. Describe el
objetivos, la organización, cronograma, actividades paso a paso y su cronología incluyendo
hitos. Entre estos hitos se encuentran los entregables.
Debería abordar medidas para controlar el proyecto, como la revisión y la comunicación.
Se supone que los principales aspectos que cubren el sistema de gestión de calidad GMP están en su lugar.
Se debería disponer de un documento que describa la situación actual de la validación de computadoras.
Para las actividades realizadas como parte del plan del proyecto, consulte la sección 7.4.4.

7.3.2 Organización
Se debe prestar especial atención a la organización del proyecto.

7.3.3 Gerente de Proyecto

El Gerente de Proyecto es responsable de cumplir con los objetivos en términos de cumplimiento con los URS,
mientras se observan los requisitos de calidad, tiempo y costos.

7.3.4 Propietario y Patrocinador del Sistema

El Propietario del Sistema es el propietario formal del sistema y es responsable de la validación.

estado del sistema informatizado
El Patrocinador proporciona la inversión y los recursos necesarios para apoyar el proyecto.
 GMP

7.3.5 Usuarios
Los usuarios clave deben ser identificados antes de redactar el URS. Por ejemplo, cuando un proyecto abarca
en diferentes áreas específicas, es recomendable designar un usuario clave para cada área específica.
Deben aprobar los siguientes documentos:
. URS
. Especificaciones Funcionales/Diseño
Están involucrados en pruebas. Es clave que el usuario tenga suficiente conocimiento del tipo de
sistema para que puedan involucrarse en el diseño del sistema. Si hay una falta de
es crítico que se proporcione capacitación para que el usuario pueda brindar una respuesta informada
opinión.

7.3.6 Desarrollador/ Proveedor

El papel del Desarrollador/Proveedor debe ser claro en relación a los entregables, documentos
autorización, cronometraje, control de cambios. Deben cumplir con toda la calidad referenciada
estándares.
El Desarrollador/Proveedor debe proporcionar las especificaciones de diseño que deben cumplir con el URS.
Cada vez más, los proveedores están involucrados en la ejecución de parte de las actividades de validación (pruebas tempranas
en el sitio del proveedor).
Estos aspectos estarían cubiertos por el contrato establecido entre el cliente y el
proveedor.

7.3.7 Soporte Informático en el Sitio

El sitio Computer Support define o al menos autoriza el diseño de hardware, tomando en cuenta
tenga en cuenta la compatibilidad de los sistemas existentes, la carga, la infraestructura.
Su papel en lo que respecta a la instalación y el mantenimiento, incluida la documentación, debe ser definido.

7.3.8 Unidad de Calidad

La unidad de calidad debería estar involucrada desde el principio del proyecto. Deben revisar
y aprobar todos los documentos que impactan la calidad.

7.3.9 Matriz de Responsabilidad

Las actividades y responsabilidades se asignan, por ejemplo, utilizando una matriz que enumera todo el
entregables versus contribuyentes para cada tarea. Responsabilidades para escribir, aprobar y
se debe asignar la autorización.

[Link].
Sistema de Colaboradores Proyecto QA Proveedor Usuario Clave de TI

Entregables propietario Gerente Apoyo

URS A R A W W
IQ/OQ R A W A A
protocolo
Scripts de prueba R A W A A
Etc.

Responsabilidades:
. Escritura: W
. Revisando: R
. Aprobando: A
 GMP

7.4 Ciclo de Vida del Sistema

7.4.1 Introducción
Este capítulo detalla las actividades de validación reales que se realizarán para proporcionar un
sistema informatizado validado según los estándares actuales.
Las actividades de validación para sistemas informatizados se dividen en la calificación de la infraestructura
(ordenadores, software de sistema y red) y validación de aplicaciones (incluyendo el
software de aplicación, interfaces a otras aplicaciones, equipos y procedimientos operativos
debido a las diferencias en el enfoque requerido para cada uno de los grupos. El término
se utiliza un sistema informatizado en el texto para designar la combinación de ambas infraestructuras
y aplicaciones.

Un Plan de Validación (Maestro) debe ser desarrollado de acuerdo con las políticas de la empresa y las internas
procedimientos, incluidos tanto la infraestructura como las aplicaciones.
Los Procedimientos Operativos Estandarizados (POEs) deben estar establecidos junto con un Sistema formal.
Concepto de Ciclo de Vida que describe todas las actividades relevantes para crear y mantener
infraestructura y aplicación cualificada.

7.4.2 Categorías de Software (GAMP)

Para las aplicaciones, el método de desarrollo de software o el estado pueden determinar la validación.
esfuerzo. Una referencia muy útil en esta área es la guía GAMP.
La guía GAMP es un estándar industrial (Ref0)que define cinco categorías de niveles de validación
para software como se muestra en la matriz a continuación.
Las categorías 4 y 5 son las categorías para las cuales se requieren importantes esfuerzos de validación.
 Validación de ordenador del grupo de trabajo

GMP

Categorías de software según la Guía GAMP

GAMP Aplicación Infraestructura

categoría Tipo ejemplo ejemplo Comentarios
1 Operando VMS, MVS, UNIX Sistemas operativos establecidos y comerciales que se utilizan en
Sistemas, Windows NT la fabricación farmacéutica se considera validada como parte de cualquier proyecto en
red qué software de aplicación que opera en tales plataformas forma parte de
software proceso de validación (es decir, los sistemas operativos en sí no están actualmente
sujeto a una validación específica aparte de como parte de aplicaciones particulares
que se ejecutan en ellos).

2 Estándar saldos lógica en un Estos son impulsados por firmware no programable por el usuario. Son configurables.
Instrumentos, medidores de pH la interfaz del controlador y la configuración deben ser registradas en el IQ del equipo.
Micro código de barras

Controladores escáneres,
Inteligente controladores PID.
Instrumentos
3 Estándar Oficina Productos en capas Estos se llaman configurables de tipo Canned o COTS (Comercial Off-The-Shelf)
software aplicaciones, como DBMS, ACL paquetes en los EE. UU. Ejemplos incluyen Lotus 1-2-3, software Microsoft Excel
paquetes hoja de cálculo y (pero no la hoja de cálculo en sí, ya que incluye generalmente cálculos y
base de datos comunicación eventualmente macros). No hay requisito de validar el paquete de software,
sistemas paquetes sin embargo, las nuevas versiones deben ser tratadas con precaución.
4 Configurable LIMS, ERP (por ej.)
Usuarios específicos .
software basado en MRPII aplicaciones que Estos se llaman paquetes configurables personalizados en los EE. UU. Ejemplos incluyen
paquetes DCS, SCADA están basados en PLC. Sistemas de Control Distribuido (DCS), Control Supervisorio y Adquisición de Datos
MES, paquetes (SCADA), sistemas de ejecución de manufactura y algunos LIMS y
Cromatografía Paquetes MRP. En estos ejemplos, el sistema y la plataforma deben estar bien
sistemas de datos. conocido y maduro antes de ser considerado en la categoría 4, de lo contrario categoría 5
deberían aplicarse. Una característica típica de estos sistemas es que permiten a los usuarios
desarrollar sus propias aplicaciones configurando/modificando software predefinido
módulos y también desarrollando nuevos módulos de software de aplicación. Cada
la aplicación (del producto estándar) es, por lo tanto, específica del proceso del usuario

pagina10/ 39
 GAMP Solicitud Infraestructura
categoría Escriba ejemplo ejemplo Comentarios
y el mantenimiento se convierte en un tema clave, particularmente cuando aparecen nuevas versiones de la
se producen productos estándar.
5 Construido a medida exclusivamente construido PLC
con single Estas son aplicaciones personalizadas e incluyen también la personalización.
o a medida soluciones para un interfaces dedicadas con propósito implementadas al instalar un paquete configurable. Para estos
sistemas uno o pocos programa los sistemas el Ciclo de Vida completo debe ser seguido para todas las partes del sistema.
clientes Cabe señalar que los sistemas complejos a menudo tienen capas de software, y uno
el sistema podría exhibir varias o incluso todas las categorías anteriores.
 Validación de computadora del Grupo de Trabajo

GMP

7.4.3 Proceso del Ciclo de Vida del Sistema

Esta sección proporciona orientación detallada sobre el esfuerzo de validación necesario para establecer documentado
evidencia de que un proceso funcionará consistentemente de acuerdo con su predeterminado
especificaciones y atributos de calidad. Dependiendo de la complejidad del computadorizado
sistema, o en la categoría GAMP, no todas las fases y/o actividades deben ser seguidas, por ejemplo.
la documentación puede ser combinada (por ejemplo, en el plan de validación).
Las actividades y los resultados relacionados, que se describen en las siguientes secciones, no son
obligatorio, pero debe ser visto como un ejemplo a ajustar para cada situación específica.

El concepto del Ciclo de Vida del Sistema describe todos los aspectos del ciclo de vida de un sistema computerizado.
sistema que podría consistir en:
planificación
especificación
diseño
construcción
pruebas
implementación y aceptación
operación en curso;
archivado del sistema cuando se reemplace.

En los próximos capítulos se discuten las actividades de validación paso a paso siguiendo la vida-
concepto de ciclo.

7.4.4 Planificación
Las actividades y resultados típicos en esta fase son:

Actividad Salida
Definir la necesidad/problema empresarial Justificación del negocio / Descripción del problema *
Asignar gerente de proyecto
Definir equipo de proyecto/validación
Describa los requisitos principales del sistema (Principal) requisitos del sistema *
Realizar un estudio de viabilidad Resultados del estudio de viabilidad
Asignar recursos del proyecto
Escribe un plan de proyecto Plan de Proyecto
* Puede ser incorporado en el plan del proyecto

7.4.5 Especificación
La validación de un sistema informatizado debe demostrar que el sistema cumple
predetermined specifications. Testing is needed in several stages of the Life Cycle.
Por lo tanto, se necesitan especificaciones detalladas documentadas para cada etapa de
prueba.
En la Fase de Especificación, la especificación de requisitos del usuario detallada (URS) y el
se especifican los criterios de aceptación, basados en los requisitos críticos identificados.

página 12/39
Sobre la base de esta especificación, se puede realizar una encuesta de mercado de proveedores para filtrar el
posibles proveedores candidatos. Por lo general, un proveedor tiene información detallada sobre un existente
producto en documentos como la especificación funcional y/o el diseño del sistema.
Después de la aprobación del DQ, se debe aplicar un control de cambios formal a todas las especificaciones.
documentos.

Considere actividades de validación paralelas (ver tabla a continuación)

Las actividades y resultados típicos en esta fase, no necesariamente en este orden cronológico, son:
Actividad Salida
Desarrollar un plan de validación Plan de validación
Definir la Especificación de Requisitos del Usuario (URS) Especificación de Requisitos del Usuario
(URS)
Desarrollar criterios de aceptación Criterios de aceptación
Realizar análisis de riesgos Informe de análisis de riesgos
Desarrollar plan de prueba de aceptación (protocolos IQ/OQ) Plan de prueba de aceptación (IQ/OQ/(PQ)
protocolo PQ si es aplicable protocolos) *
Solicitud de propuesta (es decir, cotización) Solicitud de propuesta
Revisión/auditoría del proveedor Informe de revisión/auditoría
Selección de proveedores Calificación de proveedores
Elaboración del contrato Contrato con proveedor; con
requisitos contractuales
Hacer pedido Orden de adquisición

*Si se desarrolla el software, estos elementos son parte del Diseño y Programación del Sistema
Fase.
Generalmente, antes de la selección del proveedor, la Especificación de Requisitos del Usuario (URS) y el
se deben especificar los criterios de aceptación. El URS debe contener tres tipos de
requisitos
requisitos relacionados con el proceso/usuario (detallando las funcionalidades requeridas)
requisitos técnicos/relacionados con TI (que incluyen no solo, por ejemplo, hardware y software
requisitos e interfaces requeridas con otros sistemas informatizados, pero también
abordar la capacidad del sistema para migrar datos de versiones anteriores así como a
versiones o sistemas futuros),
requisitos relacionados con calidad/QA (incluyendo cumplimiento de GMP y todos los requisitos de
21 CFR Parte 11.
Todos los requisitos deben ser claros, completos, verificables/testeables y consistentes con
el uno al otro. Preferiblemente, los URS se configuran de tal manera que se pueda construir la matriz de trazabilidad.
desde allí (ver apéndice 8.6).

7.4.6 Selección de proveedores / vendedores

Ya sea que el proveedor sea una empresa externa o un departamento interno, la capacidad del proveedor
proporcionar un sistema que pueda ser validado debería ser una consideración principal. El conocimiento de
los requisitos de validación y la experiencia en la provisión de sistemas para sistemas GMP son importantes
criterios de selección.

Al menos para los sistemas de Categoría 4 y 5 utilizados para actividades de GMP, se requiere una revisión de calidad del proveedor, y
si se considera relevante, se debe realizar una auditoría en el lugar para evaluar la validez de las potenciales
proveedores. La revisión y/o auditoría del proveedor debe cubrir la información de la empresa, Calidad
 Validación de computadora del grupo de trabajo

GMP

Información del sistema de gestión, desarrollo de software e información del paquete.

el proceso de selección de proveedores debe ser documentado y cualquier desviación de los requisitos
lo observado durante una auditoría debe ser abordado.
Para sistemas críticos, esta revisión y/o auditoría debe llevarse a cabo antes del proveedor final.
selección.
Cuando se haya seleccionado un proveedor, se deben definir los requisitos contractuales. Estos
los requisitos contractuales suelen ser una "mezcla" de requisitos del usuario y técnicos
especificaciones.

7.4.7 Diseño y construcción

Esta fase solo es aplicable a sistemas informatizados que pertenecen a la categoría 4 o 5 de GAMP.
y será en gran medida responsabilidad del proveedor.
En la fase de diseño se desarrollará una especificación funcional cuando se realicen personalizaciones en un
se necesitan productos existentes, o un sistema construido a medida. Esta es una actividad combinada por ambas
el(los) proveedor(es) y el cliente. El diseño total del sistema se puede verificar contra el
Especificación de Requisitos del Usuario para verificar que se cumplan todos los requisitos. Este chequeo a menudo
facilitado por una Calificación de Diseño, DQ.

Las actividades y resultados típicos en esta fase son:

Actividad Salida
Definir especificación funcional Especificación funcional
Diseña el sistema Especificación de diseño
Calificación de Diseño Informe DQ (puede incluirse en la trazabilidad del URS)
matriz)
Programación y pruebas de módulos Informe de prueba del módulo de software
Auditar proveedor Informe de auditoría
Proporcione la descripción final del sistema Descripción del sistema (incluidos diagramas de hardware/software)
Procedimiento de instalación del sistema de suministro Procedimiento de instalación del sistema
Documentación del sistema de suministro Manuales y guías de usuario

Se requiere que el proveedor siga una metodología de desarrollo, estándares de programación, y

Procedimientos de control de cambios durante el desarrollo del producto. Para sistemas adquiridos (GAMP 4)
(categoría), (partes del) diseño y programación pueden ya haber sido realizadas. En este caso
el proveedor debe proporcionar pruebas documentadas de que una metodología de desarrollo,
normas de programación y procedimientos de control de cambios durante la fase de desarrollo
se siguieron y se realizaron pruebas adecuadas.

En caso de que el proveedor esté realizando una programación sustancial, en esta fase posiblemente se requiera un adicional
auditoría de proveedores con un enfoque especial en el SLC, cumplimiento de procedimientos y correcto
la documentación puede ser útil.

7.4.8 Pruebas de Aceptación

El objetivo de esta fase es tomar una decisión sobre la aceptación formal del sistema como
entregado por el proveedor. Para los sistemas desarrollados, esto se puede dividir en dos partes:
 Aceptación en el sitio del proveedor, Prueba de Aceptación de Fábrica (FAT);
 Aceptación en el sitio del cliente, Prueba de Aceptación en el Sitio (SAT).
También se puede combinar en una Prueba de Aceptación general.

página 14/39
 GMP

Tenga en cuenta que, cuando sea necesario, se deben verificar los requisitos según 21 CFR parte 11.
durante las pruebas de aceptación

Durante esta fase, la instalación y operación del sistema informatizado deben ser
calificado de acuerdo con los protocolos de Calificación de Instalación y Operacional (IQ/OQ) para el
sistema. Aunque una calificación puede ser, al menos en parte, realizada por el proveedor de la
el sistema, el equipo del proyecto es responsable de los resultados.

El nivel de detalle de las pruebas internas depende de la categoría GAMP y de la

pruebas realizadas por el proveedor.

Las actividades y resultados típicos en esta fase son:

Actividad Salida
Calificación de Instalación Informe de IQ (FAT, SAT pueden ser incluidos)
Calificación Operacional Informe OQ (FAT, SAT se pueden incluir)
Capacitación de usuarios Personal calificado
Auditoría/revisión de IQ/OQ y, si corresponde Informe de auditoría/revisión interna
(partes de) PQ
Informe de IQ/OQ actualizado para QA por Informes IQ/OQ aprobados finales
aprobación

Si se utilizan protocolos de IQ/OQ desarrollados por el proveedor, estos protocolos deben ser revisados.
y aprobado por el equipo del proyecto antes de comenzar el IQ/OQ. El IQ/OQ se puede ejecutar en
el sitio del usuario, por el proveedor o por un representante del usuario o miembro(s) del equipo del proyecto.
Cada prueba debe ser documentada de manera que pueda ser reconstruida. Esto se puede lograr
creando archivos de registro, haciendo impresiones, utilizando libros de registro, etc. Si estas opciones no son viables o
practicable, se permite la prueba de testigos. Los evaluadores deben firmar por cada prueba realizada.
Los revisores deben firmar por conjuntos lógicos de pruebas. En el caso de las pruebas de testigos, el testigo
debería firmar los mismos pasos que el probador. Se requiere testimonio de prueba cuando un proveedor o
el contratista se compromete a realizar pruebas del sistema.

La cronología de IQ, OQ y PQ es un problema de cumplimiento crítico. Las partes críticas del IQ

debería estar terminado antes de ejecutar el OQ de esa parte en particular, pero actividades paralelas para otros
las piezas son posibles.
Si alguna prueba o desafío no cumple con la especificación o se encuentran otras desviaciones, esto
debería ser documentado y, si es necesario, cubierto por acciones correctivas (por ejemplo, identificación de
la causa de la desviación, las acciones correctivas y pruebas adicionales.

Después de la instalación, la Calificación Operacional (OQ) verifica las especificaciones funcionales de

cualquier sistema o subsistema individual. Si es necesario, confirmar si el sistema cumple con el
Los requisitos contractuales, las partes relevantes del PQ deben realizarse en esta fase.
(Las pruebas adicionales de PQ contra otros requisitos del usuario a menudo aún son requeridas después de
aceptación). Los resultados de pruebas anteriores, por ejemplo, FAT, también se pueden utilizar en esta fase.

Estos resultados de un IQ/OQ deben ser reportados como un informe formal (combinados a menudo se les llama
un informe de pruebas de aceptación). En esta etapa, el sistema está aprobado para ser entregado al usuario
para que PQ tenga lugar.
 GMP

7.4.9 Implementación y aceptación

A menudo, en el momento de la aceptación del sistema por parte del proveedor, se requieren pruebas adicionales y/o
se requiere documentación antes de que el sistema pueda liberarse para uso en producción
medio ambiente.

Las actividades típicas y los resultados en esta fase son:

Actividad Salida
Desarrollar un plan de implementación Plan de implementación
Calificación de Desempeño (PQ) informe PQ
Desarrollar procedimientos Procedimientos
Descripción completa del sistema Descripción del sistema
Capacitación de usuarios adicionales Personal calificado
Escribir informe de validación Informe de validación
Revisión de validación Informe de auditoría interna

El sistema informático puede ser liberado formalmente para PQ. PQ se llevará a cabo en una producción.
medio ambiente. Durante el período de Calificación de Desempeño del sistema adicional
se lleva a cabo el monitoreo. Dependiendo de la naturaleza del sistema, el PQ puede consistir en un
período de monitoreo o validación de procesos (por ejemplo, producción de lotes de validación).
El plan de implementación especifica las acciones para implementar el sistema informático en su
entorno operativo
Actividades necesarias y otra documentación según lo requiera la operación en curso
fase
Capacitación de usuarios adicionales del sistema
Actividades de prueba restantes, como la producción de lotes de validación de procesos

Al aprobar el informe final, se completa la implementación del sistema.

7.4.10 Operación en curso;

Una vez que un sistema relacionado con computadoras ha sido validado, el estado validado tiene que ser
mantenido. Esto requiere un sistema de mantenimiento adecuado y (a) Procedimientos Operativos Estándar
Procedimiento(s) que está(n) incorporado(s) en el Sistema de Gestión de Calidad pertinente.

Los siguientes problemas deben ser abordados según corresponda en el o los procedimientos:
Uso del sistema
Seguridad/Control de Acceso
Copia de seguridad y restauración
Recuperación de desastres
Planificación de contingencias
Continuidad del negocio
Mantenimiento preventivo
Mantenimiento correctivo (informes de problemas)
Control de Cambios (incluyendo la gestión de configuraciones); ver también el capítulo 8.5 Cambio
Control
Rastro de auditoría (equivalente a la alteración de datos GMP)
Entrenamiento
Evaluación periódica
 GMP

Archivado
Retiro del sistema (puede abordarse en una etapa mucho más avanzada)

7.4.11 Uso del sistema

En este procedimiento, se deben definir las principales tareas y responsabilidades de los usuarios. Si
se pueden incluir instrucciones detalladas sobre cómo utilizar el sistema.

7.4.12 Seguridad
Deben existir procedimientos adecuados de control de acceso en tres niveles:
Nivel de red ancha y/o local
2. Nivel de Sistema o Aplicación
3. Nivel de PC.

Los elementos que deben ser cubiertos incluyen cómo se controla el acceso, una política de contraseñas y una auditoría.
caminos. En los tres niveles debería haber listas de usuarios aprobados que se actualicen continuamente y
sus niveles de autorización.

7.4.13 Copia de seguridad y restauración

Los siguientes elementos deben ser cubiertos por estos documentos:

procedimientos de copia de seguridad y restauración
frecuencia de copia de seguridad
verificación de la capacidad para recuperar datos y archivos de respaldo
al menos se deben mantener dos generaciones o dos copias de respaldo, a menos que se indique lo contrario
se toman medidas para evitar que las versiones de respaldo se dañen.
Las copias de seguridad deben almacenarse separadas del sistema de manera que sean altamente
poco probable que tanto el original como la/s copia/s de respaldo puedan dañarse.
disponibilidad de la copia de seguridad dentro de un período apropiado
para sistemas con una baja frecuencia de copias de seguridad, las copias de seguridad deben ser verificadas para
accesibilidad, durabilidad y precisión a una frecuencia adecuada para el almacenamiento
medio, que también debe especificarse, pero al menos una vez al año para sistemas críticos.
en caso de que no haya copias de seguridad de baja frecuencia, el control de cambios debe garantizar la disponibilidad y
integridad de las copias de seguridad restaurando los datos de manera regular (particularmente después de
se han realizado cambios en el sistema).
incluso con copias de seguridad de alta frecuencia, demuestra que el sistema de restauración funciona, por ejemplo, una vez por
año. No es necesario probar el sistema completo; esto se puede hacer seleccionando al azar
uno o algunos archivos para restaurar en un área especial.
Nota: si se utilizan las mismas cintas, es posible que las cintas estén empeorando sin que se dé cuenta.
Los procedimientos deben llevarse a cabo, controlarse y documentarse.

7.4.14 Recuperación ante desastres

Los procedimientos de recuperación ante desastres deben estar disponibles para los desastres más comunes, a menudo
falla de energía o falla de disco duro. El tiempo de inactividad máximo del sistema debería ser
documentado, incluyendo las medidas para cumplir con eso. Si es posible, procedimientos de recuperación de desastres
debería ser probado.

7.4.15 Planificación de contingencias

En caso de destrucción completa del hardware, software y archivos de datos, el conocimiento y
las copias de seguridad del sistema deben estar disponibles para construir un sistema nuevo completo. Debería ser
 GMP

documentado si y en caso afirmativo, cómo se continúa el proceso en caso de un desastre

(no disponibilidad del sistema).

7.4.16 Continuidad del negocio

Se deben tomar medidas para garantizar la disponibilidad del código fuente en caso de que el proveedor del sistema
detiene el negocio por cualquier motivo. Esto debe abordarse en los Acuerdos de Nivel de Servicio.
y/o en acuerdos de depósito en garantía.

7.4.17 Mantenimiento preventivo

Los elementos a cubrir son:
Lista de componentes críticos del sistema
Debería haber un sistema en su lugar (por ejemplo, Acuerdo de Nivel de Servicio SLA) que asegure
que el mantenimiento se realice a tiempo. Para los componentes de hardware, la fecha del último
y/o el próximo mantenimiento debe ser fácilmente visible o recuperable.
Todo el mantenimiento debe ser documentado (por ejemplo, en un registro de bitácora)
En caso de que el mantenimiento preventivo conduzca a cambios, los procedimientos de control de cambios
debe ser seguido.

7.4.18 Mantenimiento correctivo (Informe de problemas)

Cada problema debe estar registrado bajo un número o código único, mencionando el problema,
fecha
etc.
Si la solución de un problema conduce a un cambio en el hardware o el software, los procedimientos para
se debe seguir el control de cambios.

Control de cambios
Refiérase a la sección 8.5

7.4.20 Registro de auditoría

Registros de auditoría generados por computadora y con sello de tiempo que registran de manera independiente la fecha y la hora
entradas de operador y acciones que crean registros electrónicos modificados o eliminan registros. Registro
los cambios no deben oscurecer la información previamente grabada.
El rastro de auditoría debería ser buscable y estar protegido de cualquier cambio.
Debe poder interrogar por fechas, horas, personas, tipo de cambio y razones.
cambio.

7.4.21 Entrenamiento
Todos los usuarios del sistema deben recibir capacitación. Esta capacitación debe ser documentada y donde
aplicable evaluado. Los usuarios deben ser informados sobre los estándares actuales o cambios de la
El sistema. Las responsabilidades de formación deben ser definidas.

7.4.22 Evaluación periódica

En intervalos predefinidos (por ejemplo, una vez al año) se deben realizar evaluaciones del rendimiento.
de los sistemas que utilizan los datos de la documentación de control de cambios y reporte de problemas.
Se debe tomar y documentar una decisión sobre la posible necesidad de cambios en y/o
 Validación de computadora de la fuerza de tarea

GMP

revalidación del sistema. Las decisiones sobre la evaluación periódica deben ser aprobadas por al menos
el propietario del sistema y QA.

7.4.23 Archivado
Toda la documentación generada en la Operación y Mantenimiento y Control de Cambios
los procedimientos deben ser archivados adecuadamente.
Los datos y el software necesario para recuperarlos deben ser archivados.

7.4.24 Fase de jubilación

En cierto punto del ciclo de vida del sistema informático, pueden ocurrir circunstancias que obliguen a un
decisión de retirar el sistema informático. Esta decisión iniciará la Fase de Jubilación (y
probablemente una fase de planificación para el reemplazo del sistema.
En caso de retiro del sistema, se deben seguir los siguientes pasos:
Establezca un plan de preservación de datos que podría incluir una de las siguientes opciones:
asegúrate de que un nuevo sistema pueda recuperar datos de sistemas anteriores
preservar aplicaciones anteriores
archivar copias en papel (cuando esté permitido)
Finalización de la documentación del sistema y del dosier de validación
Ejecución del plan de preservación de datos
Auditoría de QA sobre la documentación de conservación

7.4.25 Infraestructura
La calificación de la infraestructura, por ejemplo, de la red de área local, contiene lo siguiente
elementos
documentación de alto nivel de la red, p. ej. seguridad, fiabilidad y disponibilidad.
documentación de instalación incluyendo diagrama esquemático actual.
gestión de configuraciones (un inventario actualizado de hardware y software
[incl. versiones] componentes)
monitoreo del rendimiento de la infraestructura

La prueba de la infraestructura normalmente se incluye en las pruebas funcionales de la aplicación (por ejemplo.
pruebas de bucle, sistemas de control de procesos, etc.)

7.4.26 Entregables y actividades de validación

El modelo del ciclo de vida del sistema, tal como se define en este documento, sirve como la columna vertebral para el
proceso de validación.
Dependiendo de la complejidad y la categoría GAMP del sistema computerizado, las actividades
y/o la salida relacionada puede ser omitida, combinada racionalmente o subdividida aún más.

Categoría 1 Sistemas Operativos

Se deben utilizar sistemas operativos bien conocidos. Registre el nombre y el número de versión en el
Pruebas de aceptación de hardware o IQ de equipos. Las nuevas versiones de los sistemas operativos deberían ser
revisado antes de su uso y se tuvo en cuenta el impacto de nuevos, enmendados o eliminados
características de la aplicación. Esto podría llevar a un programa de re-pruebas formal de la aplicación,
particularmente cuando ha ocurrido una actualización importante del sistema operativo.

página 19/ 39
Categoría 2 Instrumentos Estándar, Microcontroladores, Instrumentación Inteligente, Integrados
software

La configuración debe ser registrada en el IQ del equipo. La no intencionada y

La introducción no documentada de nuevas versiones de firmware durante el mantenimiento debe ser
evitado a través de la aplicación de un control de cambios riguroso. El impacto de nuevas versiones en
se debe revisar la validez de la documentación de CI y tomar las medidas adecuadas.

Categoría 3 Paquetes de Software Estándar

No hay ningún requisito para validar el paquete de software. El esfuerzo de validación debería
concentrarse en la aplicación, que incluye:

- Requisitos del sistema y funcionalidad.

- El lenguaje de alto nivel o macros utilizados para construir la aplicación.
- Algoritmos y parámetros críticos.
- Integridad de datos, precisión y fiabilidad.
- Procedimientos operativos.

En cuanto a otras categorías, el control de cambios debe aplicarse de manera estricta, ya que cambiar estos
Las aplicaciones son a menudo muy fáciles y con una seguridad limitada. La capacitación del usuario debe enfatizar el
importancia del control de cambios y la integridad validada de estos sistemas.

Categoría 4 Paquetes de software configurables

El ciclo de vida debería usarse parcialmente para especificar, diseñar, probar y mantener la aplicación.
Se debe prestar especial atención a cualquier código adicional o modificado y a la
configuración de los módulos estándar. Una revisión de software del código modificado (incluyendo cualquier
deberían llevarse a cabo algoritmos en la configuración.
Además, se requiere una auditoría/revisión del proveedor para determinar el nivel de calidad y
pruebas estructurales integradas en el producto estándar. La auditoría/revisión necesita considerar el
desarrollo del producto estándar, que puede haber seguido una metodología de prototipado
sin la intervención de un usuario. La Guía Europea de Buenas Prácticas de Fabricación, Anexo
11, requiere que el proceso de desarrollo sea controlado y documentado.
Se debe preparar un Plan de Validación para documentar con precisión qué actividades son necesarias para
validar una aplicación, basada en los resultados de la auditoría y en la complejidad del
aplicación.

Categoría 5 Sistemas a medida o personalizados

Para estos sistemas, se debe seguir todo el ciclo de vida para todas las partes del sistema. Una auditoría
del proveedor se requiere examinar sus sistemas de calidad existentes y un Plan de Validación
debería estar preparado para documentar con precisión qué actividades son necesarias, basándose en el
resultados de la auditoría y sobre la complejidad del sistema personalizado propuesto.

La orientación sobre la documentación de validación requerida para cada categoría de software GAMP se proporciona
en la tabla a continuación. Los sistemas operativos GAMP 1 no están incluidos en esta tabla, ya que solo la versión
se debe aplicar control. Siempre que sea posible y práctico, se deben listar documentos o elementos
a continuación se pueden combinar. Si los documentos se combinan, debería quedar claro cuáles de los
los elementos indicados están realmente cubiertos en qué documento(s).
Las actividades enumeradas a continuación no están necesariamente en un orden cronológico.

Actividades / resultado GAMP 2, 3 GAMP 4 GAMP 5

Necesidad empresarial + +
(Principal) requisitos del sistema + +
Resultados del estudio de viabilidad + +
Plan de Proyecto + +
Plan de validación o IQ/OQ + +
protocolo
Especificación de Requisitos del Usuario (URS) + + +
Criterios de aceptación + + +
Informe de análisis de riesgos Si es aplicable + +
Plan de pruebas de aceptación (IQ/OQ/(PQ) O Validación + +
protocolos) *) Plan
Solicitud de propuesta + +
Informe de revisión/auditoría del proveedor + +
Contrato con proveedor; con contractual + +
requisitos
Orden de adquisición + +
Especificación funcional + +
Especificación de diseño del sistema + +
Informe de DQ (puede incluirse en el URS) + +
matriz de trazabilidad
Informe de prueba del módulo de software Opcional +
Informe de auditoría de proveedores sobre el sistema Opcional +
desarrollo
Descripción del sistema (incluyendo + +
diagramas de hardware/software
Procedimiento de instalación del sistema + +
Manuales y guías de usuario Si corresponde + +
Informe de IQ (FAT, SAT pueden ser incluidos) + + +
Informe OQ (FAT, SAT se pueden incluir) + + +
Informe de auditoría/revisión interna Si es aplicable + +
Informe final aprobado (informes IQ/OQ)1 + + +
Plan de implementación + +
informe PQ + +
Procedimientos + + +
Registro de entrenamiento Si corresponde + +
Informe de validación + + +

1
1. Los resultados de un IQ/OQ pueden ser reportados como un informe formal (combinados a menudo
se llama un informe de pruebas de aceptación). En esta etapa, el sistema es aprobado para la entrega.
pasa al usuario para que se lleve a cabo el PQ. El PQ se llevará a cabo en un entorno de producción. Durante
el período de Calificación de Desempeño del sistema de monitoreo adicional es
realizado. Dependiendo de la naturaleza del sistema, el PQ puede consistir en un monitoreo
validación de período o proceso (por ejemplo, producción de lotes de validación).
 Validación de computadora del grupo de trabajo

GMP

8 Apéndices

8.1 Glosario: ver 8.9

lista de definiciones
término utilizado Definición
Aplicación ver software de aplicación
Software de aplicación todos los programas de aplicación informatizados que se utilizan en
de manera controlada por una organización
dispositivos informáticos La combinación de computadoras (servidores, clientes) y
equipos que proporcionan instalaciones informatizadas
software de control software de aplicación como utilidades y herramientas que es
se utiliza para controlar y gestionar sistemas informatizados.
infraestructura ver infraestructura técnica
red La combinación de cableado de backbone, activo
componentes (puentes, enrutadores) y servidores de red más
software de red utilizado para comunicarse entre
dispositivos informáticos
procedimiento operativo
validación prospectiva
validación retrospectiva
ciclo de vida del sistema
software del sistema El sistema operativo más el software en capas y bibliotecas,
se utiliza para controlar el hardware de la computadora y proporcionar
servicios a software de aplicación.
infraestructura técnica La infraestructura técnica consiste en software de control,
Software del sistema, computadoras y red
Infraestructura de TI ver infraestructura técnica

8.2 Listas de verificación prácticas para la validación de computadoras

Esta lista de verificación es una referencia rápida; para más información se hace referencia a la correspondiente
capítulos
PLAN DE VALIDACIÓN PÁRRAFOS INFRAESTRUCTURA APLICACIÓN

1) Introducción  descripción corta del sistema

 la posición del sistema de aplicación relacionada
a otros sistemas
 visión esquemática del sistema

páginas22/ 39
PÁRRAFOS DEL PLAN DE VALIDACIÓN INFRAESTRUCTURA SOLICITUD

2) Alcance  describir el propósito de la validación

proceso
 describe ownership, customer and supplier
rol
 sujeto de calificación, nombramiento para
Categoría GAMP

3) Cambios en la documentación mencione los cambios de la versión anterior

de este documento.
4) Equipo de validación, miembros y responsabilidades
Miembros del equipo/participantes X X
Autorización de protocolos y documentos X X
¿Quién hace las pruebas / quién hace la verificación? X
Responsabilidades del miembro X X
Autorización de documentos X X
Recursos X X
5) Estrategia / Actividades de Validación
Verificación de URS X X
Categorías GAMP X
Análisis de riesgo X
Referencias a URS - DQ X X
Criterios de prueba / criterios de aceptación X X
Referencias a los SOP aplicables - control de cambios X X
Protocolos IQ, OQ y PQ X X
Actividades de prueba X X
Actividades de IQ, OQ X X
Documentación de hallazgos, reporte X X
Creación de manuales de infraestructura y aplicación X X
Actividades PQ X
Revisión de validaciónX X
X
Validación de archivos X
informe
6) Planificación de actividades X X

Calificación de Diseño (DQ)

INFRAESTRUCTURA SOLICITUD

Requisitos del sistema en el URS que deben ser cubiertos por el Hardware, red, I/O Software de aplicación
especificaciones de requisitos exitosas tarjetas, estaciones de trabajo,
servidores
URS detallado que incluye configuraciones específicas de usuarios
X X
Cumplimiento de los estándares relevantes (BPM, metrología...)
X X
Asegurar la equivalencia con el sistema antiguo (mínimo)/ ¿qué pasa si? X X
Calificación de Diseño (DQ)
INFRAESTRUCTURA SOLICITUD

análisis X X
Coherencia organizacional X X
Enlaces internos y externos con otros sistemasX X
Compatibilidad de software global X
Flexibilidad del sistema (sin reconfiguraciones) X X
Alarmas X X
Copia de seguridad y restauraciónX X
Diseño general, visión general del sistema X
Categorización GAMP

Calificación de Instalación (IQ) Conformidad documentada con el URS, a la

DQ y a las especificaciones del proveedor
Lista de instrumentos del sistema de componentesX
Verificación de softwareX X
Integridad y conformidad con el DQ, el X X
especificaciones y el pedido X X
Cumplimiento de las normas relevantes X X
Manuales (M&I, etc.), documentación y verificación de versiones X X
Pruebas del proveedorX
Requisitos del entorno X X
Instalación y pruebas de instalación

Calificación Operativa (OQ) Las pruebas se llevarán a cabo en operación real

condiciones ambientales
Entrenamiento X X
Manual(es) de usuario y SOP X
Calibrations (if applicable) X
Pruebe todas las funcionalidades críticas según las especificaciones
X X
Pruebas de integridad de datos X X
Pruebas de alarmas X X
Pruebas de copia de seguridad y restauración X x
Control de acceso X X
Control de cambio del sistema en su lugar X X
Recolección y revisión de datos X
Robustez, pruebas de límite X X
Revisión global, informes y conclusiones X

Calificación de Desempeño (PQ) Tras la emisión positiva de la fase anterior, en

condiciones operativas actuales
Condiciones y límites de operación actuales X
Recopilación de datos X
Controles de fiabilidad contra DQ X X
Verificaciones de fiabilidad contra el sistema manual o anterior X
Impacto / efecto actual en la calidad del producto X X
Corrección de defectos (dentro del marco de control de cambios) X X
Idoneidad de los SOP
X X
Calificación de Diseño (DQ)
INFRAESTRUCTURA SOLICITUD

Apéndice 2 Matriz de Trazabilidad

8.3 Matriz de Trazabilidad de Especificación de Requisitos del Usuario

Propósito: Esta matriz brinda garantías de que los requisitos del usuario
estaban completamente cubiertos en la documentación de validación. La matriz
también permite una verificación rápida de que todos los relevantes
la funcionalidad fue probada durante la validación.
 CSV URS
GMP

8.4 Definición:
Las primeras dos columnas identifican el número de sección y el título en las Especificaciones de Requisitos del Usuario. Las columnas restantes identifican el
documento y la sección específica donde se verificó cada requisito del usuario.

Usuario
Especificación URS Especificación de Requerimientos del Usuario Validación y Funcional Instalación Operacional Aceptación Rendimiento
Referencia Descripción Plan del Proyecto Especificaciones Calificación Calificación Pruebas Calificación
< Documento < Documento < Documento < Documento < Documento < Documento
< Referencia del documento > referencia referencia > referencia > referencia referencia > referencia >

Aprobación del documento

System owner (name, date, signature)

Quality Assurance (name, date, signature)

página 26 / 39
 Validación de computadoras del grupo de trabajo

GMP

8.5 Control de Cambios

8.5.1 Alcance
Durante el proceso de desarrollo, construcción, validación, uso y terminación de
Los sistemas informatizados deben tener un SOP/sistema para controlar los cambios.
El propósito es asegurar que cualquier cambio en la aplicación del sistema computarizado sea
controlado de tal manera que permanecerá conforme a las regulaciones GMP. Esto puede
incluir hardware, software, autorizaciones, formación y documentos.
Debe considerarse muy importante que se adopte una visión global al abordar el cambio
control.

Se aconseja identificar la categoría de cambio.

Por ejemplo, las categorías 1 a 3 a continuación se refieren a la aplicación y se clasificarían como rutina.
cambiar y se puede controlar mediante un procedimiento sencillo.
Las categorías 4 y 5 a continuación tratan sobre procesos nuevos, modificados o adicionales que pueden tener
impacto en la calidad del producto. Para estos casos se requiere un control más cuidadoso del cambio
y la necesidad de revalidación debería ser revisada.

Ejemplos de diferentes niveles de cambios:

1. otorgar nuevos derechos a un usuario,
2. ingresando un nuevo tipo de materia prima en un ERP
3. reemplazar un disco duro
4. instalar un sistema de identificación basado en códigos de barras en un almacén
5. conectando un LIMS a un ERP

8.5.2 Sistema de control de cambios

Debería haber procedimientos establecidos que aseguren lo siguiente:
 Solicitud de cambio (razón y descripción, identificación)
 Cambio de evaluación y autorización (análisis de impacto; autorización por parte del propietario del sistema o)
delegar y función de QA, si es aplicable
 Implementación y prueba (los esfuerzos de prueba/validación deben basarse en el impacto
análisis
 Cambio de finalización, evaluación y aprobación (actualizar documentación y lanzamiento formal)

Si, basándose en el análisis de impacto, el cambio es menor y no se requiere prueba ni documentación.

Se requieren actualizaciones, esto debe ser documentado.

El sistema debe mantenerse lo más simple posible: un procedimiento que utilice formularios de solicitud de cambio.
puede ser adecuado.

8.6 Matriz
Consulte la sección 7.3.9

8.7 Beneficios
Los beneficios de la validación informática son indudables, sin embargo, la burocracia de
la documentación a menudo las opaca.
 Validación de computadora de la fuerza de tarea

GMP

Beneficios empresariales:
Una sólida gestión de proyectos minimizará la reingeniería/diseño y reducirá el rediseño
costos. La disciplina del proyecto que la validación informática aporta puede ayudar a garantizar que el
el equipo tiene control del sistema automatizado.
Al resaltar las fases críticas, se puede asegurar que el equipo del proyecto dedique la mayor parte.
esfuerzo y tiempo en los sistemas más críticos. Documentación de Requisitos del Usuario bien definida
proporcionar indicaciones claras sobre los requisitos futuros y hacer que los proveedores estén al tanto de ellos.
La validación informática también aporta disciplina a un entorno idealista

Beneficios de cumplimiento:
Al seguir el enfoque del ciclo de vida del sistema, se lograrán los siguientes beneficios.
Usted hará:
cumplir con las expectativas regulatorias para sistemas informatizados y asegurar que el
el sistema es adecuado para su propósito.

asegúrese de que el sistema tenga datos que sean seguros y controlados con protección contra
fraude, errores, fallos del sistema.
utiliza registros de auditoría y contraseñas para ayudar al control del sistema.
asegurar que los cambios no causen fallos en el sistema mediante el control y la prueba
cambios.
cumplir con las nuevas regulaciones incluyéndolas en los requisitos del usuario, p. ej. Electrónico
registros y firmas
asegúrese de que los proveedores comprendan los requisitos de cumplimiento antes de diseñar
mediante el control de versiones ayuda con la depuración y la recuperación ante desastres.
mediante pruebas de límite, asegurar que el sistema funcione como se requiere y no falle durante
tiempos de estrés o cuando se realizan combinaciones de entrada inusuales.

8.8 Referencias

8.8.1 FDA (Sitio web[Link]

. [Link]
. [Link]
. [Link]
. [Link]
. [Link]
. [Link]
. [Link]

o21 CFR Parte 211 G8 (a) y (b) - equipo

o21 CFR Parte 211 180 (a) (c) (d) (e) – Documentación, Registros
o21 CFR Parte 11 – Registros Electrónicos y Firmas Electrónicas.
oSección 704 (a) de la Ley FD y C - Inspección de software.
8.1 Directrices de la FDA

CPGs Guías de políticas de cumplimiento de la FDA sobre el procesamiento automatizado de medicamentos

CPG 7132a.07 Verificación de entrada / salida
CPG 7132a.11 Aplicabilidad de cGMP a hardware y software
7132a.12 Responsabilidad de los proveedores

página28/ 39
 GMP

Principios generales de validación de software. Orientación preliminar; Versión 1.1. (junio de 1997)

8.8.2 ICH

Buenas Prácticas de Manufactura para Ingredientes Farmacéuticos Activos

(directriz actual); capítulo 12

8.8.3 G.A.M.P. (Guía para la Validación de Sistemas Automatizados); versión actual

Cumpliendo con 21CFR Parte 11 Registros Electrónicos y Firmas Electrónicas. Gamp
Grupo de Interés Especial. Borrador Final 01 de septiembre de 2000. Ref.: GAMP/SIG/21 CFR
Parte 11.

8.8.4 IEEE (Instituto de Ingenieros Eléctricos y Electrónicos) 730, 828, 829, 830
1012; (incluyendo orientación sobre la calidad del software y el desarrollo).

8.8.5 Normas ISO: ISO/CEI/2207, CEI 9126 – 94, ISO 12119

8.9 Apéndice/Glosario

Niveles de acción: Niveles o rangos distintos de las especificaciones del producto que, cuando
desviadas de, señal de una desviación de las condiciones operativas normales y que requieren
acciones.

Niveles de alerta o advertencia: niveles o rangos que, cuando se desvían, señalan un potencial
desviaciones de las condiciones de operación normales pero que no requieren necesariamente acción.

Software de Aplicación (PMA CSVC): Un programa adaptado o personalizado para el usuario específico
requisitos para el propósito de la recolección de datos, la manipulación de datos, el archivado de datos o el proceso
control.

Archivado: La disposición para garantizar los requisitos de retención a largo plazo para el tipo de datos
mantenido y la vida útil esperada del sistema informatizado. Los cambios en el sistema deben prever
acceso continuo y retención de los datos en bruto sin riesgos de integridad.

Auditoría (ANSI N45.2.10-1973): Una actividad para determinar a través de la investigación la adecuación de,
y cumplimiento de los procedimientos, instrucciones, especificaciones, códigos y normas establecidos
o de otros requisitos contractuales y de licencia aplicables, y la eficacia de
implementación.

Auditado: La organización que será auditada.

Auditor: Una persona calificada para realizar auditorías de calidad.

Registro de auditoría: Para el propósito de sistemas informatizados, el registro de auditoría significa un sistema seguro.
registro electrónico generado con marca de tiempo que permite la reconstrucción del curso de los acontecimientos
relacionado con la creación, modificación y eliminación de un registro electrónico. Los datos deben ser
capaz de ser interrogado, clasificado por fecha, hora, razón del cambio, persona.
 GMP

Sistema Automatizado: Término utilizado para abarcar una amplia gama de sistemas, incluidos los automatizados.
equipos de fabricación, sistemas de control, sistemas de laboratorio automatizados, fabricación
sistemas de ejecución y computadoras que ejecutan bases de datos de laboratorio o de manufactura.
El sistema automatizado consiste en los componentes de hardware, software y red,
junto con las funciones controladas y la documentación asociada. Sistemas automatizados
a veces se les refiere como sistemas informatizados; en esta Guía, los dos términos son
sinónimo.

Copia de seguridad: Provisiones hechas para la recuperación de archivos de datos o software, para reiniciar de
procesamiento, o para el uso de equipo informático alternativo después de una falla del sistema o un desastre
(ver restaurar).

Hecho a medida: Un sistema producido para un cliente, específicamente por encargo, para cumplir con un conjunto definido de
requisitos del usuario.

Error (ANSI/IEEE): Una manifestación de un error en el software (una falla).

Calibración (PMA CSVC): Demostración de que un dispositivo de medida particular produce

resultados dentro de límites especificados por comparación con los producidos por un estándar de referencia
dispositivo en un rango apropiado de mediciones. Este proceso resulta en correcciones que
puede aplicarse para optimizar la precisión.

Certificación(b. ANSI/ASQC A3 1978):

• Testimonio documentado de autoridades calificadas de que una calificación del sistema, calibración,
la validación o revalidación se ha realizado adecuadamente y que los resultados son
aceptable.

• El procedimiento y la acción por parte de un organismo debidamente autorizado para determinar, verificar, y
atestando por escrito las calificaciones del personal, procesos, procedimientos o artículos en
de acuerdo con los requisitos aplicables.

cGMP (Código de Regulaciones Federales): Abreviatura de Buenas Prácticas de Manufactura actuales

Práctica.

Control de Cambios (PMA CSVC): Un sistema formal mediante el cual representantes calificados de
las disciplinas apropiadas revisan los cambios propuestos o reales que podrían afectar a un validado
estado. La intención es determinar la necesidad de una acción que asegure y documente que
el sistema se mantiene en un estado validado.

Nota de Cambio: Un documento que especifica los detalles de una solicitud de cambio autorizada.

Plan de Cambio: Un plan que define los detalles de la solicitud de cambio autorizada, definiendo acciones,
responsabilidades y procedimientos.

Compilador (ANSI/IEEE): Un programa utilizado para traducir un lenguaje de orden superior en su re-
código máquina ubicable o absoluto equivalente.

Sistema Computarizado (PMA CSVC): Un proceso u operación integrado con una computadora
sistema.
 Validación de computadoras del Grupo de Trabajo

GMP

Hardware de Computadora (PMA CSVC): Cualquier elemento físico utilizado en un sistema informático.

Sistema Informático (PMA CSVC): Un grupo de componentes de hardware y asociados

software diseñado y ensamblado para realizar una función o grupo de funciones específicas.

Configuración: Las características físicas y funcionales documentadas de un artículo particular

o sistema. Un cambio convierte una configuración en una nueva.

Gestión de Configuración (ANSI/IEEE): El proceso de identificar y definir el

elementos de configuración en un sistema, controlando la liberación y el cambio de estos elementos
a lo largo del ciclo de vida del sistema, registrando e informando el estado de los elementos de configuración
y solicitudes de cambio, y verificando la integridad y corrección de la configuración
artículos.

Plan de contingencia: Un documento que describe cómo se continúa el trabajo después de un fallo total de
el sistema durante un período de tiempo
NOTA: En combinación con este plan, debe haber un plan de recuperación ante desastres. (Ver:
plan de recuperación ante desastres

Calificación de construcción: Evidencia documentada para mostrar que esas construcciones

los aspectos de una instalación que pueden afectar la calidad del producto se han construido de acuerdo con
la especificación aprobada.

Parámetros de control: Aquellas variables operativas a las que se les pueden asignar valores que se utilizan
como niveles de control.

Rango de Parámetro de Control: Rango de valores para un determinado parámetro de control que se encuentra entre
sus dos límites externos o niveles de control.

Parámetro Crítico del Proceso: Una variable relacionada con el proceso que, cuando está fuera de control, puede
pueden causar un efecto adverso en la aptitud para el uso de un producto final.

Cliente: La organización farmacéutica o usuario que contrata a un proveedor para

proporcionar un producto. En el contexto de este documento, es sinónimo de Usuario.

Base de datos (ANSI): Colección de datos fundamentales para un sistema.

DCS: Sistema de Control Distribuido.

Código Fuente Muerto (K.G. Chapman):

1.Código reemplazado de versiones anteriores. Evitado mediante el uso de software de desarrollo de calidad
estándares;

2. Residuo de la modificación del sistema. Evitado mediante controles efectivos de cambio de configuración;

3. Código raramente utilizado que parece muerto como:

- módulos en algunos programas configurables grandes;

- ciertos programas de diagnóstico que están destinados a estar inactivos hasta
necesitado.

página 31/39
La eliminación de código en la categoría 3 puede llevar a serios problemas potenciales en el futuro. El "código inactivo" puede ser
"estacionado" en bibliotecas hasta que sea necesario.

Depuración (IEEE): El proceso de localizar, analizar y corregir fallos sospechosos.

Especificación de Diseño (a. Foro GAMP, b. IEEE):

a. Esta es una definición completa del equipo o sistema con suficiente detalle para permitirle
ser construido. Esto se vincula a la Calificación de Instalación que verifica que el equipo correcto o
el sistema se suministra, según los estándares requeridos y se instala correctamente.

b. La especificación que documenta el diseño de un sistema o componente del sistema para satisfacer
requisitos especificados.

Calificación de Diseño (DQ): Verificación formal y sistemática de que los requisitos

definidos durante la especificación están completamente cubiertos por la especificación sucesiva o
implementación.

Plan de recuperación ante desastres: Un documento que enumera todas las actividades necesarias para restaurar un sistema a
las condiciones que prevalecían antes de que ocurriera el desastre (por ejemplo, un fallo de energía).
NOTA: En combinación con este plan, debe haber un plan de contingencia. (Ver:
Plan de contingencia

Documentación (ANSI N45.2.10-1973): Cualquier información escrita o pictórica que describa,

definir, especificar, informar o certificar actividades, requisitos, procedimientos o resultados.

Firma Electrónica: Una compilación de datos informáticos de cualquier símbolo o serie de símbolos
ejecutado, adoptado o autorizado por un individuo para ser el equivalente legalmente vinculante de la
firma manuscrita del individuo.

Límite de fallo: Un valor de parámetro de control que, si se excede, significa un efecto adverso en
estado de control y/o aptitud para el uso del producto.

Aprobación Electrónica: Un comando de entrada que requiere una entrada restringida realizada bajo un nivel de
autorización superior, lo que significan un acto de aprobación.

Identificación Electrónica (eID): Una medida electrónica que puede ser sustituida por una mano-
firma manuscrita o iniciales con el propósito de significar aprobación, autorización o verificación
de entradas de datos específicas.

Verificación Electrónica: Un comando de entrada que permite a un usuario designado, o el

sistema informatizado en sí mismo, para significar electrónicamente la verificación o aprobación de un específico
paso, transacción o entrada de datos. La fuente de la verificación electrónica puede hacerse visible o
invisible para los usuarios de los datos.

Sistema Embebido: Un sistema, generalmente basado en microprocesador o PLC, cuyo único propósito
es controlar un equipo automatizado en particular. Esto se contrasta con un independiente
sistema informático.

Planificación de Recursos Empresariales

Programa Ejecutivo (ANSI/IEEE/ASO): Un programa de computadora, generalmente parte del sistema operativo
sistema, que controla la ejecución de otros programas informáticos y regula el flujo de
trabajar en un sistema de procesamiento de datos.

Auditoría de Calidad Externa: Un examen sistemático e independiente para determinar si

las actividades de calidad y los resultados relacionados cumplen con un Sistema de Calidad documentado y si
este sistema de calidad documentado se implementa de manera efectiva y es adecuado para lograr el
requisitos contractuales impuestos por el cliente.

FAT: Prueba de Aceptación en Fábrica (pruebas de aceptación en el sitio del proveedor).

Diagrama de flujo (ANSI/IEEE): Una representación gráfica de la definición, análisis o solución de

un problema en el que se utilizan símbolos para representar operaciones, datos, flujo y equipos.

Software Congelado: Este es un software que está bajo control de configuración y puede no ser
alterado sin control de cambios.

Funcionalidad: Ver requisitos funcionales.

Requisito Funcional (ANSI/IEEE): Un requisito que especifica una función que un

el sistema o componente del sistema debe ser capaz de realizar.

Pruebas funcionales; también conocidas como pruebas de "CAJA NEGRA", ya que el código fuente no es
necesario. Implica ingresar casos de prueba normales y anormales; luego, evaluar las salidas en contra de
aquellos esperados. Puede aplicar a software informático o a un sistema total.

GAMP: Buenas Prácticas de Fabricación Automatizadas

Especificación de Prueba de Aceptación de Hardware: (ver Calificación de Instalación a continuación).

Verificación documentada de que todos los aspectos clave de la instalación de hardware se adhieren a lo apropiado.
códigos e intenciones de diseño aprobadas y que las recomendaciones del fabricante
han sido debidamente considerados.

Especificación de Diseño de Hardware (APV): Descripción del hardware sobre el cual se ejecuta el software
reside y cómo está conectado a cualquier sistema o equipo.

Revisión de Alto Nivel del Software:

Propósitos: determinar si los programas cumplen con las especificaciones de diseño según lo descrito por tales
documentos como diagramas de flujo modulares, gráficos HIPO, pseudocódigo y operación
manuales.

Características: implica comparar las especificaciones de diseño y los criterios de aceptación con
mecanismos cognitivos que representan el programa en términos más fácilmente entendidos por
practicantes de automatización y no informáticos.

Usos: revisión de aceptación de calidad por auditoría de software de QA, por ejemplo para
complemento 'recorrido', para inspecciones y para solucionar problemas.

Infraestructura: Software de control, software de sistema, computadoras y red.

Calificación de Instalación [IQ](PMA CSVC): Verificación documentada de que todos los aspectos clave
la instalación de [software y] hardware se adhiere a los códigos apropiados y al diseño aprobado
intenciones y que las recomendaciones del fabricante han sido adecuadamente consideradas.

Pruebas de Integración (IEEE): Una progresión ordenada de pruebas en la que los elementos del software,
elementos de hardware, o ambos se combinan y prueban hasta que todo el sistema ha sido
integrado.

Interfaz(ANSI/IEEE): Un límite compartido. Para interactuar o comunicarse con otro.

componente del sistema.

Sistema heredado: Aplicaciones de software y sistemas informatizados que han estado funcionando.
durante muchos años y nunca han sido validados. Para sistemas que son críticos para un regulado
debe llevarse a cabo una evaluación retrospectiva.

Concepto de Ciclo de Vida (PMA CSVC): Un enfoque para el desarrollo de sistemas informáticos que
comienza con la identificación de los requisitos del usuario, continúa a través del diseño, la integración,
calificación, validación de usuarios, control y mantenimiento, y termina solo cuando se utiliza comercialmente
del sistema está descontinuado.

LIMS: Sistema de Gestión de Información de Laboratorio.

Pruebas de bucle: Verificación de la combinación instalada de elementos que caracterizan cada tipo de
bucle de entrada/salida.

Revisión de Bajo Nivel de Software:

Propósitos:

• detectar posibles errores de codificación

• determinar la adherencia a las especificaciones de diseño

• determinar la adherencia a los estándares

• implementar análisis de rutas

Características:

• requiere expertos altamente capacitados que estén familiarizados con sistemas de software/hardware en w
sobre qué programa se basa.

• realizar una inspección de código fuente línea por línea a bajo nivel requiere un equipo de expertos
trabajando no más de dos sesiones de 2 horas al día; esto significa alrededor de 100-150 líneas de
código por día-hombre (1.5 millones de líneas = 40 años-hombre)

Utilizar: principalmente durante el desarrollo de software

Código de máquina (ANSI/IEEE): Una representación de instrucciones y datos que es directamente

ejecutable por una computadora (lenguaje de máquina).

Cambio Mayor (PMA CSVC): Un cambio a un sistema validado que, en opinión del cambio-
el control de los revisores requiere una revalidación del sistema.
Cambio menor (PMA CSVC): Un cambio a un sistema validado que, en opinión del cambio-
los revisores de control, no requieren una revalidación del sistema.

Modularidad (Software)(ANSI/IEEE): El grado en que el software está compuesto de elementos discreto

componentes de manera que un cambio en un componente tenga un impacto mínimo en los demás
componentes.

MRP: Planificación de Requerimientos de Materiales.

MRP II: Planificación de Recursos de Manufactura.

Network(a. ANSI/IEEE, b. GAMP Forum)

a. Un grupo de nodos interconectados o interrelacionados.

b. Una instalación de comunicaciones interconectada. Una red de área local (LAN) es alta
ancho de banda (permitiendo una alta tasa de transferencia de datos) red informática funcionando sobre un
área pequeña como una oficina o grupo de oficinas.

Entorno de operación: Todas las influencias externas que interfieren con el sistema informático.

(a. PMA CSVC, b. ANSI/IEEE)

a. Un conjunto de programas provistos con una computadora que funcionan como la interfaz entre
el hardware y los programas de aplicación.

b. Software que controla la ejecución de programas. Un sistema operativo puede proporcionar

servicios, como la asignación de recursos, programación, control de entrada/salida y datos
gestión.

Calificación Operativa [OQ](PMA CSVC): Verificación documentada de que el equipo-

el sistema o subsistema relacionado funciona como se pretende a lo largo de un período representativo o anticipado
rango de operación.

Calificación de Desempeño [PQ]: Verificación documentada de que el proceso y/o el total

el sistema relacionado con el proceso funciona como se espera en todos los rangos operativos anticipados.

Cambio Planificado (PMA CSVC): Un cambio intencionado a un sistema validado para el cual el
el programa de implementación y evaluación está predeterminado.

PLC: Controlador Lógico Programable.

Política (PMA CSVC): Una directiva que generalmente especifica lo que se debe lograr.

Procedimiento (PMA CSVC) o Procedimiento operativo estándar (SOP): Una directiva generalmente
especificando cómo se deben llevar a cabo ciertas actividades.
condiciones probadas de peor caso altas y bajas.

Sistema de Proceso (PMA CSVC): La combinación de equipos de proceso, sistemas de soporte

(como servicios públicos) y procedimientos utilizados para ejecutar un proceso.
Producto: Cualquier sistema informático suministrado por el proveedor al cliente como resultado de un
contrato acordado entre las dos partes.

Validación prospectiva: La validación de sistemas nuevos o recién instalados tras una Vida
Concepto de Ciclo (ver definición de PMA).

Rango Aceptable Comprobado (PAR): Todos los valores de un parámetro de control dado que se encuentran entre
Criterios de Aceptación (ANSI/IEEE): Los criterios que un producto de software debe cumplir para tener éxito.
completar una fase de prueba o alcanzar los requisitos de entrega.

Código pseudo (ANSI/IEEE): Una combinación de lenguaje de programación y un natural

lenguaje utilizado para el diseño de programas informáticos.

Protocolo de Calificación: Un plan experimental prospectivo que, cuando se ejecuta, tiene la intención de
produzca evidencia documentada de que un sistema o subsistema ha sido debidamente calificado.

Aseguramiento de la Calidad [QA](a. ANSI/IEEE, b. Dr J M Juran)

a. Un patrón planificado y sistemático de todas las acciones necesarias para proporcionar adecuadamente
confianza en que el artículo o producto cumple con los requisitos técnicos establecidos.

b. La actividad de proporcionar, a todos los interesados, la evidencia necesaria para establecer

confianza en que la función de calidad se está realizando adecuadamente.

Control de Calidad [CC] (Dr. J M Juran): El proceso regulatorio a través del cual la industria
mide el rendimiento de calidad real, lo compara con los estándares y actúa en consecuencia
diferencia.

Función de Calidad: La colección completa de actividades de las cuales se logra la idoneidad para el uso.
sin importar dónde se realicen estas actividades.

Plan de Calidad: Un plan creado por el proveedor para definir acciones, entregables y responsabilidades
y procedimientos para satisfacer los requisitos de calidad y validación del cliente.

Sistema de Calidad: La estructura organizativa, responsabilidades, procedimientos, procesos y

recursos para implementar la gestión de calidad.

Prueba de rango: Verificando cada bucle de entrada y salida a través de su rango de operación previsto.

Cualquier hoja de trabajo, registros, memorandos, notas o copias exactas de estos que sean
el resultado de observaciones y actividades originales y que son necesarios para el
reconstrucción y evaluación de un proyecto de trabajo, proceso o informe de estudio, etc. Los datos crudos pueden
ya sea en formato duro/copia física o electrónica, pero debe ser conocido y definido en los procedimientos del sistema.

Re-cualificación (PMA CSVC): Repetición de la cualificación o de una parte de la misma.

Requisito (ANSI/IEEE):

• Una condición o capacidad necesaria para que un usuario resuelva un problema o alcance un objetivo
• Una condición o capacidad que debe ser cumplida o poseída por un sistema o sistema
componente para satisfacer un contrato, norma, especificación u otro requisito formalmente impuesto
El conjunto de todos los requisitos forma la base para el desarrollo posterior
del sistema o componente del sistema

Restaurar: Recuperación de archivos de datos o software de una copia de seguridad, para reiniciar el procesamiento, o para
uso de equipos informáticos alternativos tras una falla del sistema o un desastre (ver copia de seguridad).

Validación retrospectiva (PMA CSVC): Establecer evidencia documentada de que un sistema

hace lo que pretende hacer basado en un análisis de información histórica.

Revalidación: Repetición del proceso de validación o de una parte específica del mismo.

SAT: Prueba de Aceptación en el Sitio; Prueba de aceptación en el sitio del cliente.

SCADA: Control de Supervisión y Adquisición de Datos.

Seguridad (IEEE): La protección del hardware y software de computadoras contra accidentes o

acceso, uso, modificación, destrucción o divulgación maliciosa. La seguridad también se refiere a
personal, datos, comunicaciones y la protección física de las instalaciones informáticas.

Deberá: esta palabra se utiliza en los procedimientos de ejemplo a lo largo de los apéndices para que ellos
puede ser utilizado sin alteración.

Se recomienda encarecidamente el requisito indicado.

Simulación (ANSI/IEEE/ISO): La representación de características seleccionadas de la

comportamiento de un sistema físico o abstracto por otro sistema. En una computadora digital
sistema, la simulación se realiza mediante software; por ejemplo, (a) la representación de lo físico
fenómenos por medio de operaciones realizadas por un sistema informático, (b) la representación
de operaciones de un sistema informático por las de otro sistema informático.

SLC: Ciclo de Vida del Sistema (ver concepto de ciclo de vida).

Software (PMA CSVC): Una colección de programas, rutinas y subrutinas que controlan
el funcionamiento de una computadora o un sistema computarizado.

Ciclo de Vida del Software (ANSI/IEEE): El período de tiempo que comienza cuando un producto de software es
concebido y termina cuando el producto ya no está disponible para su uso. El ciclo de vida del software
típicamente incluye una fase de requisitos, fase de pruebas, fase de instalación y verificación, y
fase de operación y mantenimiento.

Código fuente (PMA CSVC): Un programa informático original expresado en un formato legible por humanos
forma (lenguaje de programación), que debe ser traducida a una forma legible por máquina antes de
se puede ejecutar por la computadora.

Calificación de especificaciones: Una evaluación documentada de la especificación detallada, llevada a cabo.

salir con el propósito de confirmar el cumplimiento con el Requisito del Usuario y Funcional
Especificaciones y proporcionar la documentación de diseño detallada requerida para la siguiente
etapas de validación (por ejemplo, Calificación de Instalación y Calificación Operacional) y operación continua de
la instalación o sistema en cumplimiento con los requisitos regulatorios relacionados con la calidad del producto.
Sistema Autónomo: Un sistema informático autónomo que proporciona procesamiento de datos.
funciones de monitoreo o control pero que no está integrada dentro del equipo automatizado. Esto
se contrasta con un sistema embebido, cuyo único propósito es controlar un particular
pieza de equipo automatizado.

Pruebas Estructurales (Bluhm, Meyers, Hetzel): Examinando la estructura interna de la fuente

código. Incluye revisión de código a bajo y alto nivel, análisis de rutas, auditoría de programación
procedimientos y normas realmente utilizados, inspección de 'código muerto' extraño, límite
análisis y otras técnicas. Requiere conocimientos específicos de informática y programación
experticia.

Subcontratista: Cualquier organización o individuo utilizado por un proveedor para proporcionar material o
servicios que están incorporados en el producto a ser suministrado.

Subprograma: Una unidad de programa independiente que forma parte de un programa. Subprogramas
a veces se les conoce como procedimientos, subrutinas o funciones.

Proveedor: Cualquier organización o individuo contratado directamente por el cliente para suministrar un
producto.

Un sistema: Un conjunto de unidades que consiste en uno o más microprocesadores, asociados

hardware y todas las capas del sistema y del sistema de aplicaciones.

Especificación de Prueba de Aceptación del Sistema: Verificación documentada de que el automatizado

el sistema o subsistema funciona como se define en la Especificación Funcional a lo largo de
rangos de operación representativos o anticipados.

Software del sistema (ANSI/IEEE): Software diseñado para un sistema o familia de computadoras específica
de sistemas informáticos para facilitar la operación y mantenimiento del sistema informático y
programas asociados, por ejemplo, sistemas operativos, compiladores, utilidades.

Especificaciones del Sistema (PMA CSVC propuesto): Describe cómo el sistema cumplirá con el
requisitos funcionales.

Probador: Una persona que realiza la prueba.

Pruebas (IEEE): El proceso de ejercer o evaluar un sistema o componente del sistema por
medios manuales o automatizados para verificar que cumple con los requisitos especificados o para identificar
diferencias entre los resultados esperados y los resultados reales.

Pruebas: Estructurales y Funcionales: Ambas formas de prueba son esenciales. Ninguna forma de
las pruebas pueden ser agotadoras. Las pruebas estructurales deben ocurrir principalmente durante el software
desarrollo.

Procedimiento de prueba: Un procedimiento que, al ejecutarse con éxito, proporciona documentación.

evidencia de que parte del sistema automatizado funciona según lo especificado.

Cambio no planificado (de emergencia) (PMA CSVC): Un cambio necesario no anticipado a un

sistema validado que requiere una rápida implementación.
URS: Especificación de Requisitos del Usuario.

El cliente u organización de usuario de la industria farmacéutica / química que contrata un

proveedor para proporcionar un producto. En el contexto de este documento, por lo tanto, no se pretende
se aplica solo a individuos que utilizan el sistema, y es sinónimo de Cliente.

Software de utilidad (ANSI/IEEE): Programas o rutinas informáticas diseñados para realizar alguna
función de soporte general requerida por otro software de aplicación, por el sistema operativo, o
por usuarios del sistema.

Establecer evidencia documentada que proporcione un alto grado de certeza

que un proceso específico producirá consistentemente un producto que cumpla con sus requisitos preestablecidos
especificaciones y atributos de calidad". - Directrices de la FDA sobre Principios Generales de Proceso
Validación, mayo de 1987.

Plan de Validación: Un plan creado por el cliente para definir actividades de validación.
responsabilidades y procedimientos.

Protocolo de Validación (PMA CSVC): Un plan experimental prospectivo que al ser ejecutado es
destinado a producir evidencia documentada de que el sistema ha sido validado.

Testigo: Una persona que observa la prueba y los resultados.

Peor escenario (FDA 1987): Un conjunto de condiciones que abarcan el procesamiento superior e inferior
límites y circunstancias, incluidas aquellas dentro de los procedimientos operativos estándar, que plantean
la mayor probabilidad de fallo en el proceso o producto en comparación con las condiciones ideales. Tal
las condiciones no necesariamente inducen a la falla de productos o procesos.