Pat 057-3

ARMSTRONG LABORATORIOS DE MÉXICO S.A. DE C.V.

PROCEDIMIENTO NORMALIZADO DE OPERACIÓN
DOCUMENTACIÓN DEL CICLO DE VIDA DE LOS EQUIPOS,
INSTRUMENTOS Y SISTEMAS AUTOMATIZADOS
CLAVE: PAT-057/3
ELABORÓ:
O. NÁJERA
ING. DE VALIDACIÓN DE SISTEMAS AUTOMATIZADOS
REVISÓ:
E. CRUZ
SUPERVISOR DE VALIDACIÓN

L. OBREGÓN
JEFE DE ASISTENCIA TÉCNICA

AUTORIZÓ:
L. MOLINA
GERENTE DE GARANTÍA DE CALIDAD
FECHA DE APROBACIÓN:
FECHA DE APLICACIÓN:
FECHA DE EXPIRACIÓN:

SEP/10
OCT/10
SEP/12

L. GONZÁLEZ
RESPONSABLE SANITARIO PLANTA DIVISIÓN
DEL NORTE
SUSTITUYE A:PAT-057/2

RMSTRONG LABORATORIOS DE MÉXICO, S. A. DE C. V.
DOCUMENTACIÓN DEL CICLO DE VIDA DE LOS EQUIPOS, INSTRUMENTOS Y SISTEMAS DE CÓMPUTO

PAT-057/3

1.0 OBJETIVO
Establecer los lineamientos para documentar el ciclo de vida de los equipos, instrumentos y sistemas automatizados.
2.0 ALCANCE
Aplica a todos los equipos, instrumentos y sistemas de cómputo que tengan un impacto directa o indirectamente con
los procesos de fabricación, administración y comercialización.
3.0 RESPONSABILIDADES
3.1 Gerente de Área (Cliente)
3.1.1 Asegurar que todos los equipos existentes a su cargo sean inventariados, clasificados e integrados a un
ciclo de vida a través del área de Validación de Sistemas Automatizados.
3.1.2 Garantizar que toda la documentación del ciclo de vida sea generada, revisada y aprobada.
3.1.3 Controlar y mantener los equipos, instrumentos y sistemas de cómputo bajo el ciclo de vida durante toda
su vida útil.
3.1.4 Participar en la revisión y aprobación de la documentación generada.
3.2 Validación de Sistemas Automatizados
3.2.1 Asegurar que todos los equipos, instrumentos y sistemas de cómputo que se adquieran sean integrados a
un ciclo de vida generando la documentación indicada en este procedimiento.
3.2.2 Orientar y apoyar a los gerentes de área en la integración al ciclo de vida de los equipos existentes.
3.2.3 Elaborar inventario general, hacer la clasificación correspondiente, generar los protocolos y participar en la
ejecución de los mismos hasta su cierre.
3.2.4 Participar en la elaboración, revisión y dar seguimiento para la aprobación de la documentación generada.
3.2.5 Mantener y dar seguimiento a las actividades indicadas en la documentación que así lo requiera.
3.3 Gerente de Informática
3.3.1 Participar en la elaboración y revisión de los documentos que se requieren durante el ciclo de vida.
3.3.2 Solicitar la participación de un grupo de trabajo para la revisión y aprobación de los documentos que
aplique.
3.3.3 Mantener y dar seguimiento a las actividades indicadas en la documentación que así lo requiera.
3.3.4 Notificar y mantener actualizado el inventario de los equipos, instrumentos y sistemas de cómputo.
3.4 Usuario
3.4.1 Cumplir con los lineamientos establecidos en este procedimiento.
3.4.2 Participar en la elaboración de los documentos del ciclo de vida.
3.4.3 Solicitar los cambios de acuerdo a los procedimientos establecidos.
3.4.4 Participar en la calificación del equipo.
3.4.5 Verificar que el equipo adquirido cumple con los requerimientos establecidos.
3.4.6 Estar capacitado en el uso del equipo, instrumento o sistema de cómputo.
3.5 Administrador de Sistemas de Cómputo
3.5.1 Participar en la revisión y aprobación de la documentación que aplique.
3.5.2 Apoyar al gerente de área en la clasificación de los equipos de nueva adquisición.
3.5.3 Participar el las actividades que así lo requieran.
4.0 GENERALIDADES
El desarrollo de la validación de los Sistemas Automatizados para las industrias del cuidado de la salud, requiere
intima cooperación entre clientes y proveedores, desarrollando conjuntamente la documentación necesaria para el
cumplimiento del ciclo de vida de los sistemas.

DOCUMENTACIÓN DEL CICLO DE VIDA DE LOS SISTEMAS:
Página 2 de 12


Paso
1

PAT-057/3

3

Descripción
El sistema debe ser categorizado e identificar el cumplimiento con GxP.
La URS debe definir claro y preciso que es lo que el sistema debe de hacer, así
como el cumplimiento con lineamientos nacionales e internacionales.

•

2

Tarea
Identificación del sistema
Especificaciones
de
Requerimientos de Usuario
Determinación
de
la
estrategia de validación:
Evaluación del riesgo

La evaluación del riesgo inicial debe de elaborarse durante el plan de validación.
Esta evaluación debe ser útil para el desarrollo de las especificaciones del sistema.

•

Evaluación
de
los
componentes del sistema

Los componentes que integran al sistema deben ser evaluados y categorizados
para determinar el grado de validación, este se refleja en el plan de Validación.

•
4
5

Evaluación del proveedor

Plan de Validación
Revisión y aprobación de las
especificaciones funcionales
Protocolo de Validación:
•
•

Revisión y aprobación de
las pruebas

•

6

Elaboración
pruebas

Reporte de validación

de

las

7

Mantenimiento del sistema

8

Retiro del sistema

Realizar auditoria al proveedor, con el objetivo de establecer el cumplimiento con
lineamientos de calidad y cumplimiento en GxP. La decisión de realizar la auditoria
al proveedor debe tomarse de acuerdo a la categorización del sistema.
Debe definir las actividades, procedimientos y establecer las responsabilidades
para la adecuación de los sistema. En este punto se define quien es el responsable
de realizar la evaluación del riesgo.
El cliente debe revisar y aprobar las Especificaciones Funcionales (FS), elaboradas
por el proveedor.
El cliente debe participar en la elaboración de las pruebas de Calificación del
sistema.
Debe de participar en la ejecución de las pruebas y resolución de discrepancias.
El reporte de validación provee evidencia de las actividades realizadas y que el
sistema se encuentra Validado.
Una vez validado el sistema el cliente debe de establecer un periodo de vida útil
del sistema, procedimientos de mantenimiento, administración y operación del
sistema.
Estable los criterios por los que el sistema debe de retirarse o reemplazarse.

4.1 Ciclo de Vida.- Se llama así al ciclo que describe: el diseño, las pruebas, el control del sistema, validación y
operación o trabajo, que en un proceso de mejora continua alimenta nuevamente al diseño, cerrando el ciclo.
4.2 Addendum.- Es el medio usado para documentar una recalificación, cuando ésta es requerida, al protocolo y al
reporte original y a través de la solicitud de cambio. La recalificación es requerida cada vez que hayan cambios
en un sistema de computadoras y que puedan afectar su estado de calificación.
4.3 Apéndice.- Formulaciones en donde la información y los resultados requeridos para la instalación y las
calificaciones operacionales, son registrados.
4.4 Calificación de Instalación (IQ).- Evidencia documentada que certifica que el sistema e instrumento ha sido
instalado según los criterios de diseño.
4.5 Calificación de Operación (OQ).- Pasos desarrollados que establecen que los sistemas e instrumentos son
capaces de operar consistentemente dentro de los límites y tolerancias establecidas.
4.6 Especificaciones de Diseño (DS).- Documento que contiene las especificaciones de diseño del sistema o
instrumento.
4.7 Procedimiento Normalizado de Operación.- Procedimientos escritos que describen los pasos bajo condiciones
normales y definidas que son necesarios para asegurar procesos controlados.
Página 3 de 12


PAT-057/3

4.8 Recalificación.- Una vez que el sistema o instrumento ha sido calificado, es ya considerado aceptable para su
uso. Cualquier modificación significante o cambio de ubicación del sistema de computadora va a requerir una
recalificación.
4.9 Reporte de Calificación.- Un reporte detallado de los resultados derivados de la ejecución de una instalación y
del protocolo de calificación.
4.10 Sistema computarizado.- Este término se refiere al sistema que está siendo controlado, así como al sistema de
control.
4.11 Sistema de Computadora.- Grupo de componentes de Hardware y Software relacionados, diseñados y
montados para ejecutar una función específica o grupo de funciones.
4.12 Elaborado por.- Escrito por el autor o la persona que lleva acabo la operación que está siendo documentada. La
persona que realiza un paso debe tener conocimiento técnico y conocimiento del contenido del paso a ser
ejecutado y/o analizado para asegurar que la documentación es apropiada.
4.13 Verificado por.- Una segunda persona que es testigo y corrobora que la persona que ejecuta la acción o
instrucción la completa como es requerido. Este ejercicio será efectuado en el momento en que se lleva a cabo
la instrucción. La persona que verifica debe tener conocimiento técnico y conocimiento del contenido del
documento a ser verificado. En caso de documentos de calificación y validación, el verificador debe tener como
mínimo el mismo nivel de conocimiento que el autor del documento.
4.14 Cotejado por.- Una segunda persona que corrobora que la información, cálculos, etc. son los especificados por
el autor. Este ejercicio será efectuado lo más cercano al momento de haber ejecutado un paso y antes de
continuar con el paso siguiente. La persona que coteja debe tener conocimiento técnico y conocimiento del
contenido del documento a ser cotejado para asegurar que la documentación es apropiada además de asegurar
que los resultados y/o análisis cumplan con los parámetros establecidos. En el caso de documentos de
calificación y validación, la persona que coteja debe tener como mínimo el mismo nivel de conocimiento que el
autor del documento.
4.15 Revisado por.- Volver a examinar con detenimiento un documento cuyo propósito es garantizar que no haya
errores sin corregir, tachaduras sin explicar, espacios en blanco, eventos sin investigar, que la secuencia usada
es la correcta y/o análisis cumplan con los parámetros establecidos. La persona que revisa debe tener un
conocimiento general de la operación relacionada al documento revisado. En el caso de los documentos de
calificación y validación, el departamento autor es responsable de revisar el documento antes de proceder con el
proceso de aprobación.
4.16 Aprobado por.- La persona que aprueba, está de acuerdo con el contenido y las conclusiones del documento y
certifica que el documento está alineado a las políticas del departamento que representa. La persona que
aprueba, debe tener bien claro las consecuencias que pueden tener en la operación las conclusiones del
documento que está aprobando.
5.0 DESCRIPCIÓN DEL PROCEDIMIENTO
5.1 Categorización de los Sistemas
Los sistemas están compuestos de múltiples componentes, por lo que deben desmembrarse por cada una de sus
partes, evaluando el grado de complejidad y alcance de la validación dependiendo el riesgo y la categoría en
Hardware y Software. A continuación se hace una breve descripción de cada una de las categorías establecidas
por GAMP.
5.1.1 Software Categoría 1: Sistemas Operativos
Esta categoría la componen los sistemas operativos estándares del mercado, las aplicaciones se
desarrollan para correr bajo control de los sistemas operativos. Los sistemas operativos por si mismos no
deben ser considerados como objeto de validación salvo en aplicaciones particulares que se ejecuten
sobre ellos. Durante el desarrollo de las pruebas se debe registrar el nombre y versión del sistema
operativo.
Todo cambio debe documentarse, ya sea por actualización o por falla del equipo, mediante el
procedimiento de control de cambios en equipos, instrumentos y sistemas de cómputo (PAT-056),
Página 4 de 12


PAT-057/3

considerar el impacto que las nuevas características tengan en la aplicación que se ejecuta sobre ellas
para determinar si se requiere una serie de pruebas para aseverar que el sistema o plataforma interactúa
con los demás de forma transparente con los sistemas que soporta.
5.1.2 Software Categoría 2: Firmware
La instrumentación y los controladores a menudo incorporan firmware (memoria fija). La configuración del
Firmware puede ser requerida para establecer condiciones de tiempo de activación y parámetros del
proceso. Deben ser documentados y verificados durante el IQ en la fase de pruebas: nombre, número de
versión, y configuración o calibración. La funcionalidad debe ser probada durante la calificación
Operacional (OQ).
Todo cambio de Firmware o parámetros de configuración deben documentarse, mediante el procedimiento
de control de cambios en equipos, instrumentos y sistemas de cómputo (PAT-056). Para aplicaciones
altamente criticas o complejas se debe auditar al proveedor (PAT-055). Los Firmware hechos a la medida
se deben considerar en la categoría 5.
5.1.3 Software Categoría 3: Paquetes de Software Estándar
Existen comercialmente paquetes de software estándar que proporcionan por si solos la solución a un
negocio o proceso de fabricación. El paquete por si mismo no esta configurado para definir el negocio o
proceso de fabricación, la configuración se limita a establecer las condiciones bajo las cuales opera el
paquete (ejemplo conexiones a la red e impresora). Los requerimientos de validación y requerimientos de
usuario (Ejemplo: seguridad, alarma, manejo de eventos, cálculos y algoritmos) deben ser documentados,
revisados y aprobados durante OQ.
Para aplicaciones sumamente críticas o complejas o donde la experiencia en aplicaciones reguladas por
GxP es limitada se debe contar con la Auditoria al proveedor (PAT-055).
5.1.4 Software Categoría 4: Paquetes de Software Configurable
Paquetes de software configurable con interfaces y funciones estándar que facilitan la configuración para
uso especifico de negocio o proceso de manufactura. Esto implica configuraciones predeterminadas de
módulos de software y posiblemente más adelante desarrollo de arreglos o módulos personalizados. Los
sistemas complejos a menudo tienen parches, y en el sistema se incluyen varias categorías de software.
Los paquetes de software y la plataforma deben ser bien conocidos antes de ser considerado en la
Categoría 4, de otro modo la Categoría 5 podría ser más apropiada.
Para éste tipo de Categoría se debe tener la Auditoría al Proveedor, confirmar que el paquete de software
se ha desarrollado utilizando sistemas apropiados de calidad, que el desarrollo de la aplicación y el
soporte ofrecido es robusto y competente. Los usuarios son responsables de asegurar la calidad del
software y hardware y que cumplen con el propósito del diseño. Durante la validación se debe asegurar
que el paquete de software reúna los requisitos del usuario con particular enfoque en las configuraciones
para la empresa o proceso de manufactura.
El Plan de Validación debe definir una estructura enfocada a la validación de la aplicación y cubrir por
completo el ciclo de vida, incluyendo la evaluación del proveedor y la configuración del paquete. El
enfoque debe dirigirse a las capas o parches de software involucrados y a sus respectivas categorías. El
Plan de Validación debe reflejar la evaluación del proveedor y cualquier observación de la auditoria,
aplicaciones críticas, tamaño y complejidad. Se deben definir las estrategias para mitigar cualquier
vulnerabilidad identificada en el proceso de desarrollo del proveedor. Ejemplo: La Categoría 4 incluyen
paquetes de Sistema de Control de Distribución (DCS), Control de Supervisión y Datos de Adquisición de
paquetes (SCADA), Sistemas de Ejecución Industrial (M), y algún LIMS, ERP; y paquetes de MRPII.
5.1.5 Software Categoría 5: Software Personalizados (Hecho a la Medida)
Estos sistemas son desarrollados de acuerdo a las necesidades específicas del usuario. Los desarrollos
personalizados pueden ser de un sistema completo o extensión a un sistema existente. Los sistemas
complejos a menudo tienen capas ó parches de software, con un sistema incluyendo componentes de
varias categorías de software. Se requiere la Auditoria al proveedor para confirmar que el sistema de
calidad es apropiado para el control durante el desarrollo y subsiguiente soporte de la aplicación. En
ausencia de un sistema de calidad documentado, el proveedor debe establecer un sistema de calidad
adecuado para manejar el desarrollo de la aplicación y soporte.

Página 5 de 12


PAT-057/3

En el plan de validación se debe definir el ciclo de vida completo, enfocado a la validación de la
aplicación. El enfoque se debe dirigir a las capas o parches de software involucrados y a sus respectivas
categorías, debe reflejar la evaluación del proveedor y cualquier observación de la auditoria, aplicaciones
críticas, tamaño y complejidad y definir las estrategias para la mitigar cualquier vulnerabilidad identificada
en el proceso de desarrollo del proveedor.
5.1.6 Hardware Categoría 1: Componentes Estándar de Hardware
Los componentes estándar de hardware deben ser documentados incluyendo detalles del fabricante o
proveedor, y los números de la versión. Durante la aceptación y ejecución del IQ se debe verificar la
instalación y conexión de los componentes El modelo, número de versión y donde sea adecuado el
número de serie del hardware preensamblado se debe registrar. El Hardware preensamblado sellado no se
tiene que desmontar si esto rompe la garantía. En tal caso los detalles de hardware pueden ser tomados
de la hoja de datos del hardware u otro material de especificación. La Administración de la configuración y
el Control del Cambio aplican.
5.1.7 Hardware Categoría 2: Componentes de Hardware Personalizados (Por Orden)
Estos requisitos se suman a los requisitos de los componentes Hardware Categoría 1. Los Hardware
hechos a la medida deben tener especificación de diseño y estar sujetos a pruebas de aceptación. Una
Auditoria al proveedor se debe realizar para revelar el desarrollo del hardware. Los sistemas ensamblados
que usan Hardware hechos a la medida de diferentes fuentes requieren confirmar la verificación de la
compatibilidad de las intersecciones de los componentes de Hardware. Cualquier configuración se debe
definir en la documentación del diseño y verificarse durante la Calificación de Instalación. La
Administración de la Configuración y el Control del Cambio aplican.
CATEGORÍA

TIPO DE
SOFTWARE

ENFOQUE DE V AL I DACIÓ N

Registrar versión (incluir Service Pack). El sistema operativo
Sistemas Operativos debe ser desafiado indirectamente por pruebas funcionales de
la aplicación.
Para firmware
no- configurable,
registrar
versión.
Para
instrumentos calibrados es necesaria. Verificar la operación
contra los requerimientos del usuario.
Para firmware configurable registrar versión y configuración.
2
Firmware
Para instrumentos calibrados es necesaria y verificar la
operación contra los requerimientos del usuario.
Firmware personalizado (hecho a la medida) es software
categoría 5.
Paquetes de
Registrar versión y configuración del sistema operativo.
3
Software Estándar Verificar la operación contra los requerimientos del usuario.
Registrar versión y configuración. Verificar la operación contra
los requerimientos del usuario.
Paquetes de
Normalmente se auditará al proveedor para aplicaciones
4
Software
críticas y complejas.
Configurable
Cualquier programa personalizado (hecho a la medida) es
software categoría 5.
Software
5
Auditar al proveedor y validar el sistema completo.
Personalizado
Caen dentro de las categorías 3, 4 o 5 dependiendo del uso.
Ejemplos:
Categoría 3: Usadas estrictamente para generar documentos
Hojas de Cálculo
en papel.
(Consideración Especial)
Categoría 4: Aplicaciones más complejas que incluyen
Templates.
Categoría 5: Aplicaciones de hojas de cálculo que utilizan
macros personalizadas.
1

Página 6 de 12


Aplicaciones Desarrolladas y
Herramientas de Diagnostico

CATEGORÍA
1
2

TIPO DE
HARD W A RE
Componentes
Estándar
Componentes
Personalizados

PAT-057/3

Pueden ser hechos a la medida o bien de anaquel.
Las exigencias de validación dependen de la categoría de
software y de si la herramienta soporta directamente el
proceso del negocio (Ej. Builder Application) o sólo apoya el
desarrollo de las aplicaciones (Ej. Configuration Management
Tool)
ENFOQUE DE V AL I DACIÓ N
Registrar modelo, versión, número de serie.
correcta instalación / conexión. Aplica el control de
Es como en los componentes estándar pero
requiere de una especificación de diseño y
aceptación. El proveedor debe ser auditado.

Verificar la
cambios.
también se
pruebas de

5.2 Categorización de los Equipos Automatizados de Laboratorio
5.2.1 Categoría A
Son sistemas digitales que no producen datos crudos, resultados de pruebas o expedientes de pruebas.
Estos sistemas requieren calibración, pero no usan una interfase computacional. Ejemplos: hornos de
laboratorio, centrífugas, incubadoras, controles de temperatura, cámaras climáticas, sonicadores. Esta
categoría regularmente contienen componentes de software, categoría 2.
5.2.2 Categoría B
Son sistemas digitales que producen datos crudos, resultados de pruebas o expedientes de pruebas pero
no son almacenados. Estos sistemas requieren calibración y la información de la calibración debe ser
resguardada. Estos sistemas no utilizan una interfase computarizada y el software no es modificable por el
usuario del sistema. Ejemplos: balanzas de laboratorio, medidores de pH, termómetros electrónicos,
viscosímetro, medidores de conductividad. Estos sistemas regularmente contienen componentes de
software, categoría 2.
5.2.3 Categoría C
Son sistemas digitales que producen datos crudos, resultados de pruebas o expedientes de pruebas pero
no son almacenados. Estos sistemas tiene la capacidad de guardar y re-usar la configuración o
parámetros de proceso. Estos sistemas no utilizan una interfase computarizada. Ejemplos: Reacción en
cadena de polimerización (PCR), contador de partículas, sistema robótico simple y algunos HPLC de
líquidos de alto rendimiento o sistemas de cromatografía de gases. Estos sistemas Regularmente
contienen componentes de software, categoría 3.
5.2.4 Categoría D
Son sistemas digitales que producen datos crudos, resultados de pruebas y estos son almacenados. Estos
sistemas cuentan con una interfase computarizada 1 a 1. Estos sistemas tienen la capacidad de
almacenar y re-usar la configuración o parámetros de proceso. Los datos pueden ser manipulados desde
las salidas del sistema. Ejemplos: espectrofotómetros simples, sistemas robóticas integrados. Estos
sistemas regularmente contienen componentes de software, categoría 3.
5.2.5 Categoría E
Son sistemas digitales que producen datos crudos, resultados de pruebas y estos son almacenados.
Entrada de parámetros de configuración y de procesos, los cuales son almacenados. Estos sistemas son
capaces de procesar una post-adquisición, usualmente utilizan sistemas propios de manejo de datos.
Ejemplos: Secuenciado de DNA, HPLC’s, Robots Integrados, Sistemas de Adquisición de datos y
procesamiento de datos, Espectrofotómetro de masas, Espectrofotómetro de resonancia magnética
nuclear (NMR) y equipo de electrocardiogramas (ECG). Estos sistemas contienen regularmente
componentes de software, categoría 4.
5.2.6 Categoría F
Son sistemas digitales que producen datos crudos, resultados de pruebas y estos son almacenados.
Entrada de parámetros de configuración y de procesos, los cuales son almacenados, Estos sistemas son
capaces de procesar una post-adquisición, usualmente utilizan sistemas propios para el manejo de datos.
Cuentan con elementos de programación. Pero su configuración no cambia el código fuente. Ejemplo:
Página 7 de 12


PAT-057/3

software de análisis estadísticos. Regularmente estos sistemas contienen componentes de software,
categoría 4.
5.2.7 Categoría G
Estos sistemas son personalizados para un sistema específico o un laboratorio especifico o bien puede ser
un categoría E o F que requiera personalización de acuerdo a requerimientos específicos de una empresa.
Estos sistemas pueden ser construidos por personal dentro de la organización, o pueden ser contratados
por terceras personas. Ejemplos: hojas de cálculo para resultados analíticos, base de datos y macros
personalizados. Estos sistemas regularmente cuentan con software, categoría 5.
5.3 Integración al Ciclo de Vida de Equipos, Instrumentos y Sistemas de Cómputo
Asegurar que todos los equipos, instrumentos y sistemas de cómputo sean integrados a la documentación del
ciclo de vida de acuerdo a la clasificación asignada.
5.4 Documentación del Ciclo de Vida de Equipos, Instrumentos y Sistemas de Cómputo
La metodología utilizada para el desarrollo del ciclo de vida de los sistemas es la V extendida propuesta en la
GAMP (Good Automated Manufacturing Practice).
Ciclo de Vida de los Sistemas Automatizados

Página 8 de 12


PAT-057/3

5.4.1 Planeación
Durante la fase de planeación el cliente debe determinar, si el proveedor del servicio se encuentra como
proveedor aprobado o bien es necesario efectuar una auditoria y el alcance de esta.
El proveedor debe desarrollar un plan de proyecto. En donde se describen todas las actividades
relacionadas con el proyecto como: desarrollo de Software y Hardware e instrumentación.
El proveedor debe de ayudar con la elaboración del la evaluación del riesgo, revisión del impacto en las
especificaciones del sistema y funcionalidad, partiendo de su diseño instalación y operación, los cuales
tiene un gran impacto con la calidad del producto.
5.4.2 Identificación del Sistema
Página 9 de 12


PAT-057/3

Se debe establecer un método para el registro, modificación y aprobación de la lista de componentes del
sistema. Como mínimo esta lista debe contener todos los sistemas regulados GxP.
5.4.3 Especificación de Requerimientos del Usuario (URS)
Describe lo que se suponme el sistema va a hacer y puede ser un documento contractual. Es escrita
normalmente por los usuarios. Pero puede ser escrita por terceros o un proveedor. Debe ser revisada y
aprobada por el usuario, incluyendo el área de Aseguramiento de Calidad. Ver documento URS.
5.4.4 Evaluación del Riesgo
Este proceso trata las preguntas:
• ¿Este sistema requiere validación?
• ¿Qué validación se requiere para este sistema?
• ¿Qué aspectos del sistema o del proceso son críticos para la seguridad del producto y del paciente?
• ¿Qué aspectos del sistema o del proceso son críticos al negocio?
La respuesta a estas preguntas permite que el esfuerzo de la validación sea centrado en estas críticas y
facilita el desarrollo de las estrategias de disminución del riesgo.
5.4.5 Especificaciones Funcionales
Las especificaciones funcionales normalmente son escritas por el proveedor y describen las funciones
detalladas del sistema, es decir, que es lo que el sistema hará. El usuario debe revisar y aprobar las
especificaciones funcionales.
Las especificaciones de diseño deben contener el suficiente detalle para permitir al sistema ser construido
y ser mantenido. En algunos casos el diseño se puede incluir en la especificación funcional.
5.4.6 Pruebas
Las especificaciones de pruebas deben reflejar la arquitectura y la complejidad del sistema que es
desarrollado. Las especificaciones de pruebas se deben producir para cubrir lo siguiente:
• Módulo de pruebas
• Pruebas de integración
• Pruebas de aceptación de Hardware y Software
Los resultados de la prueba se deben documentar en las hojas de resultados retando los criterios
predefinidos de aceptación indicados en las especificaciones de pruebas. Cada hoja del resultado de la
prueba debe contener una declaración de que pasó o falló, que confirma el resultado de la prueba, una
sección para que quién efectúa la prueba y un testigo firmen así como se registre la fecha. Las anomalías
de la prueba se deben capturar y revisar junto con el resultado documentado.
5.4.7 Mantenimiento del Estado Validado
El usuario debe establecer y mantener planes y procedimientos que definan como todas las actividades de
apoyo se deben realizar y manejar después de la aceptación. Estos procedimientos y planes pueden
involucrar al proveedor en actividades de apoyo y de mantenimiento.
5.4.8 Retiro del Sistema
Debido a los volúmenes de datos y de expedientes, la identificación puede ser una tarea particularmente
importante, para los sistemas. Se debe poner atención a:
• Establecer los procedimientos que cubran el retiro del sistema.
• Que evidencia documental debe ser conservada para las acciones tomadas durante el desarme y retiro
del sistema.
• Qué registros GxP deben ser mantenidos, qué periodos de validez son requeridos y qué expedientes
pueden ser destruidos.
• La necesidad de emigrar y posiblemente archivar expedientes al nuevo sistema, el método para
verificar y documentar este proceso.
• La capacidad de recuperar los registros emigrados en el nuevo sistema.
• Conservar el Hardware y Software legado para propósitos de la retención y la recuperación del registro.
No se recomienda como solución a largo plazo.
• Oportunidades para emigrar a los formatos portátiles del archivo.
Página 10 de 12


PAT-057/3

• Los procedimientos de administración de archivos que abarcan medio, almacenamiento, la
localización, el etiquetado y la integridad a largo plazo.
6.0 REFERENCIAS
6.1 General Principles of Software Validation; final Guidance for Industry and FDA Staff, dated January 11,2002.
6.2 FDA. Code of Federal Regulations, Title 21, Food and Drugs, Part 11.”Electronic Records; Electronic signatures:
Final rule. 2Federal Register, 62(54). (March 20, 1997) pp.13429-13466.
6.3 PROYECTO DE NORMA OFICIAL MEXICANA PROY-NOM-164-SSA1-2005, BUENAS PRÁCTICAS DE
FABRICACIÓN DE FÁRMACOS.
6.4 NORMA OFICIAL MEXICANA NOM-059-SSA1-2006, BUENAS PRÁCTICAS DE FABRICACIÓN PARA
ESTABLECIMIENTOS DE LA INDUSTRIA QUÍMICO FARMACÉUTICA DEDICADOS A LA FABRICACIÓN DE
MEDICAMENTOS.
6.5 GAMP 4 Guide for validation of Automated Systems December 2001.
6.6 Validation Of Laboratory Computerized System 2005.
7.0 REFERENCIAS PARA APLICACIÓN
7.1 PAT-056 Control de cambios en equipos, instrumentos y sistemas de cómputo.
7.2 PGA-002 Control de Documentación.
7.3 PAT-001 Elaboración de Procedimientos.
TERMINA PROCEDIMIENTO

Página 11 de 12


PAT-057/3

8.0 CONTROL DE CAMBIO
CLAVE

FECHA DE
APLICACIÓN

DESCRIPCIÓN DEL CAMBIO


PAT-057/1

JUN/06



PAT-057/2

AGO/08




PAT-058/3

OCT/10

Cambio del Título en Clasificación de los Equipos, Instrumentos y Sistemas de
Computo, por Clasificación de los Equipos, Instrumentos y Sistemas Automatizados.
Cambio estructural del PNO, Integración del PFQ-091: Clasificación de los equipos,
instrumentos y sistemas de cómputo al PAT-057: Clasificación de los Equipos,
Instrumentos y Sistemas Automatizados.
Actualización por fecha de vencimiento.
Se actualiza la referencia de la norma: NORMA OFICIAL MEXICANA NOM-059SSA1-1993, BUENAS PRÁCTICAS DE FABRICACIÓN PARA ESTABLECIMIENTOS
DE LA INDUSTRIA QUÍMICO FARMACÉUTICA DEDICADOS A LA FABRICACIÓN
DE MEDICAMENTOS por NORMA OFICIAL MEXICANA NOM-059-SSA1-2006,
BUENAS PRÁCTICAS DE FABRICACIÓN PARA ESTABLECIMIENTOS DE LA
INDUSTRIA QUÍMICO FARMACÉUTICA DEDICADOS A LA FABRICACIÓN DE
MEDICAMENTOS..

Página 12 de 12

Pat 057-3

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Similar a Pat 057-3

Similar a Pat 057-3 (20)

Pat 057-3