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ÁJERAING. DE VALIDACIÓN DE SISTEMAS AUTOMATIZADOS

REVISÓ:

E. CRUZSUPERVISOR DE VALIDACIÓN

L. OBREGÓNJEFE DE ASISTENCIA TÉCNICA

AUTORIZÓ:

L. MOLINAGERENTE DE GARANTÍA DE CALIDAD

L. GONZÁLEZRESPONSABLE SANITARIO PLANTA DIVISIÓN DEL NORTE

FECHA DE APROBACIÓN: SEP/10 SUSTITUYE A:PAT-057/2FECHA DE APLICACIÓN: OCT/10FECHA DE EXPIRACIÓN: SEP/12

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 OBJETIVOEstablecer los lineamientos para documentar el ciclo de vida de los equipos, instrumentos y sistemas automatizados.

2.0 ALCANCEAplica 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 Automatizados3.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ática3.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 Usuario3.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ómputo3.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 GENERALIDADESEl 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 Tarea Descripción1 Identificación del sistema El sistema debe ser categorizado e identificar el cumplimiento con GxP.

2Especificaciones de Requerimientos de Usuario

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.

3

Determinación de la estrategia de validación:

• Evaluación del riesgo

• Evaluación de los componentes del sistema

• Evaluación del proveedor

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.

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.

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.

4 Plan de ValidaciónDebe 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.

5Revisión y aprobación de las especificaciones funcionales

El cliente debe revisar y aprobar las Especificaciones Funcionales (FS), elaboradas por el proveedor.

6

Protocolo de Validación:

• Elaboración de las pruebas

• Revisión y aprobación de las pruebas

• Reporte de validación

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.

7 Mantenimiento del sistemaUna 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.

8 Retiro 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


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 SistemasLos 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 OperativosEsta 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


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: FirmwareLa 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ándarExisten 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 ConfigurablePaquetes 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


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 HardwareLos 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 VALIDACIÓN

1 Sistemas OperativosRegistrar versión (incluir Service Pack). El sistema operativo debe ser desafiado indirectamente por pruebas funcionales de la aplicación.

2 Firmware

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. 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.

3 Paquetes de Software Estándar

Registrar versión y configuración del sistema operativo. Verificar la operación contra los requerimientos del usuario.

4Paquetes de

Software Configurable

Registrar versión y configuración. Verificar la operación contra los requerimientos del usuario.Normalmente se auditará al proveedor para aplicaciones críticas y complejas.Cualquier programa personalizado (hecho a la medida) es software categoría 5.

5 Software Personalizado Auditar al proveedor y validar el sistema completo.

Hojas de Cálculo(Consideración Especial)

Caen dentro de las categorías 3, 4 o 5 dependiendo del uso.Ejemplos:Categoría 3: Usadas estrictamente para generar documentos en papel.Categoría 4: Aplicaciones más complejas que incluyen Templates.Categoría 5: Aplicaciones de hojas de cálculo que utilizan macros personalizadas.

Página 6 de 12


Aplicaciones Desarrolladas y Herramientas de Diagnostico

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)

CATEGORÍA TIPO DE HARDWARE ENFOQUE DE VALIDACIÓN

1 Componentes Estándar

Registrar modelo, versión, número de serie. Verificar la correcta instalación / conexión. Aplica el control de cambios.

2 Componentes Personalizados

Es como en los componentes estándar pero también se requiere de una especificación de diseño y pruebas de aceptación. El proveedor debe ser auditado.

5.2 Categorización de los Equipos Automatizados de Laboratorio

5.2.1 Categoría ASon 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 BSon 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 CSon 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 DSon 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 ESon 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 FSon 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


software de análisis estadísticos. Regularmente estos sistemas contienen componentes de software, categoría 4.

5.2.7 Categoría GEstos 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ómputoAsegurar 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ómputoLa 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


5.4.1 PlaneaciónDurante 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


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 RiesgoEste 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 FuncionalesLas 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 PruebasLas 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 ValidadoEl 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 SistemaDebido 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


• Los procedimientos de administración de archivos que abarcan medio, almacenamiento, la localización, el etiquetado y la integridad a largo plazo.

6.0 REFERENCIAS6.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ÓN7.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


8.0 CONTROL DE CAMBIO

CLAVEFECHA DE

APLICACIÓNDESCRIPCIÓN DEL CAMBIO

PAT-057/1 JUN/06

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.

PAT-057/2 AGO/08 Actualización por fecha de vencimiento.

PAT-058/3 OCT/10

Se actualiza la referencia de la norma: NORMA OFICIAL MEXICANA NOM-059-SSA1-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

Documents