You are on page 1of 6

UNIPHARM DE MEXICO, S.A. DE C.V.

PROCEDIMIENTO NORMALIZADO DE
OPERACIÓN

CONTROL DE CAMBIOS SOFTWARES

Página 1 de 6
1.- OBJETIVO.

1.1 Proveer un procedimiento para manejo de medios de comunicación, documentación y control


de cambio de procesos de sistemas computarizados y de programas de computo (software)
que ellos realizan.

2.- REFERENCIAS.

2.1 Carleton, F.J. Agalloco, Validation of Pharmaceutical Processes, 2da edición, Marcel-Dekker, USA.
2.2 Norma NOM-059-SSA-1-2006. Buenas prácticas de fabricación para establecimientos de la industria
Químico Farmacéutica dedicados a la Fabricación de Medicamentos.

3.- ALCANCE.

3.1 Los sistemas computarizados y programas de cómputo aplicables a este procedimiento que son
utilizados en la manufactura, análisis, proceso, almacenamiento o retención de productos en la planta
de Unipharm Veracrúz S.A de C.V..
3.2 Los sistemas de cómputo indicados en el plan maestro de validación.

4.- RESPONSABILIDAD.

4.1 Sistemas. Generar el formato de control de cambio de sistemas computacionales y detallar el


propósito del cambio y el procedimiento de prueba. Implementar el cambio en el software o hardware,
realizar la prueba para evaluar la precisión del sistema, revisar y mantener los documentos que
soportan la modificación del sistema e informar al personal del cambio.
4.2 Gerente del Área
Aprobar y revisar todas las categorías de cambios y pruebas realizadas.
4.3 Gerente de Validación
Aprobar y revisar las categorías 1,2,3 de cambios.
4.4 Gerente de Ingeniería
Aprobar y revisar las categorías 1,2,3 de cambios.

5.- PROCEDIMIENTO.

5.1 El protocolo deberá estar integrado por los puntos descritos en el procedimiento de codificación y
elaboración de protocolos.

5.2 La categoría de nivel de cambio define lo crítico de la modificación de un sistema computarizado o


aplicación. Estas categorías son definidas a continuación:

5.2.1 Categoría 1:
Estos cambios no tienen efecto en la calidad del producto o actividades externas del departamento. Por
consiguiente no influyen en la operación de equipos o requiere una modificación de un modulo o parte de un
sistema. Un ejemplo incluye pero no está limitado: cambios cosméticos, tales como correcciones de sintaxis
o de letras, cambios en la disposición del informe y cambios estáticos de la información para su visión. Estos

Página 2 de 6
cambios pueden ser realizados llenando el formato de controles de cambio de sistemas de computo (Anexo
I) y obteniendo la aprobación del gerente del departamento al cual afecta el cambio, el gerente de Ingeniería
y del Gerente de Validación.

5.2.2 Categoría 2:
Estos cambios afectan actividades externas del departamento, pero no afectan a la calidad del producto.
Además, impactan en la operación del sistema y/o modificación de más de un módulo o porción del sistema
pueden resultar del cambio. Ejemplos Un ejemplo incluye pero no está limitado: Adición de un Nuevo punto
I/O, modificación de un lote de operación, y actualizaciones de la versión del sistema del programa. Se
requiere realizar un requerimiento de cambio de ingeniería para hacer estos cambios, adicionalmente al
formato de cambio de sistemas de computo (Anexo I).
5.2.3 Categoría 3:
Estos cambios afectan al producto / calidad del proceso. El cambio afecta la calidad, tiene un impacto en la
operación del sistema y requiere modificación de más de un módulo o parte del sistema. Un requerimiento de
cambio de ingeniería es necesario para hacer los cambios, adicionalmente al formato de cambio de sistemas
de cómputo. (Anexo I).
5.3 Números de Referencia

5.3.1 Números de Referencia (Categoría 1 Solo cambios)


Los números de referencia para la categoría 1 serán asignados de acuerdo al siguiente formato YY-MM-
NNN, donde YY son los dos últimos dígitos del año en curso, MM es el numero de mes en curso y NNN es
un numero consecutivo iniciando con 001

5.3.1.1. Un registro de los números de referencia por categoría 1 es mantenido en documentación. El


número de referencia, el originador, la fecha y la descripción deben ser llenados cuando el número es
asignado. La fecha de término debe ser llenada cuando el documento ha sido cerrado (utilizando la fecha de
la última firma en el formato del anexo IB).
5.3.2 Referencia del requerimiento de Cambio de ingeniería (Categoría 2 y 3 de cambios)
Referencia el número de Control de cambio asociado con el número de control de cambio de sistemas
computacionales

5.4 Fecha de Termino

5.4.1 Categoría 1
Los cambios de categoría 1 deben ser completados dentro de 1 mes después a la fecha en que
documentación registra el número de referencia y se firma el formato de control de cambios
computacionales.
5.4.2 Categorías 2 y 3
Los cambios a categorías 2 y 3 deben ser completados en la fecha establecida de vencimiento indicada en el
correspondiente control de cambio. (Ver procedimiento 10-08)

5.5 La modificación del sistema computarizado o aplicaciones, como se define arriba, puede ser iniciado
completando el formato de control de cambio de sistemas computarizados (Anexo I). Las instrucciones
para completar el formato están listadas abajo.

5.6 El formato de modificación de sistema/software (Anexo 1) debe ser completado antes de iniciar el
cambio.

Página 3 de 6
El número de referencia ó RCI Control de cambio es asignado por documentación, quien firma y coloca fecha
de cumplimiento.
Nombre del sistema: Lista de la aplicación / sistema de computo que se ve afectado.

1 Descripción de la modificación

1.1 Condiciones existentes


Brevemente describa las condiciones actuales del equipo, sistema y/o software contemplado para el cambio.
Liste la versión actual del software con la fecha de la última revisión. Anexe los documentos históricos
apropiados describiendo los programas existentes o definición de sistema, como sea necesario. Esto puede
incluir un código, dibujos o protocolos.

1.2 Propósito de la modificación


Brevemente describa la descripción propuesta del equipo, sistema y/o software contemplado para el cambio.
Anexar los documentos apropiados describiendo del programa propuesto o modificación definida del sistema,
como sea necesario. Esto puede incluir “para revisión”, código del programa, dibujos o protocolos.

1.3 Razón de la modificación y Resultados esperados.


Brevemente describa la razón para hacer la modificación propuesta y los resultados esperados. Esto puede
incluir justificación relacionada con la calidad del producto, reducción de costos o aspectos de seguridad.

1.4 Revisión del impacto en la validación


Se debe considerar la naturaleza de la modificación propuesta y el grado al cual puede afectar el cambio.
Esta sección define los requerimientos para la verificación y documentación del cambio.

1.4.1 Requerimientos de Pruebas de validación


Si se requieren pruebas de validación, se debe especificar el tipo de prueba a ser realizada. Registre la
revisión actual del software.
1.4.2 Análisis de Riesgo
Seleccionar el nivel de riesgo 1, 2, o 3 basado en la tabla siguiente. Por ejemplo, ¿si el sistema falla, con
que posibilidad podría esto ocurrir, y que daño podría generarse derivado de esto?
Costo del Daño
Impersibible

Inaceptable
Ligero

Serio
Posibilidad de falla

Improbable 1 1 2 3

No muy probable 1 2 2 3

Posible 2 2 2 3

Probable 3 3 3 3

2 Aprobaciones

Página 4 de 6
Las firmas apropiadas serán requeridas y recopiladas, indicando la aceptación para implementación.

5.7 Formato de cierre de modificación a sistema / software (Anexo 1B) – es para ser completado después
de que la modificación ha sido aprobado y completada.
Numero de referencia de Control de Cambio: Indique el número de referencia del control de cambio ECR
Firma del Responsable de Documentación: firma y fecha cuando la fecha de término ha sido ingresada a la
bitácora; firma y fecha de cuando los formatos han sido llenados.

Nombre del sistema: Indique los sistemas de computo / softwares afectados.


1 Liberación de los softwares / sistemas.
1.1 Pruebas de validación completa y aprobada
Llene el recuadro apropiado (Si, No, o N/A) y proporcione un razonamiento de soporte, si aplica. Si el
software ha sido actualizado, registre el número de la nueva versión.
2 Aprobaciones
Las firmas apropiadas serán requeridas y recopiladas, indicando la aceptación de las pruebas y
modificaciones.
Desaprobaciones
Las firmas de aprobación serán requeridas y recopiladas, indicando que la modificación ha sido cancelada, y
los sistemas regresan a su estando original.
3.1 Razón para cancelación
Debe darse una explicación breve pero concisa indicando la razón por la cancelación de la modificación
propuesta. Se debe anexar documentación de soporte como sea necesario.
3.2 Regreso a la condición original
Indique en el recuadro correspondiente si el sistema ha sido regresado a sus estado original y confirme
realizando la prueba correspondientes o documentación; anexar la documentación de soporte.
5.8 Después de que las aprobaciones han sido obtenidas, el cambio se considera completo. Los cambios
categorías 1 deberán ser regresados a documentación para archivo y resguardo. Los cambios categorías 2 y
3 deben ser anexados al correspondiente reporte de control de cambios y resguardados en documentación.

Página 5 de 6
ANEXO 1

Numero de Referencia (Categoria 1)________ RCI de Referencia (Categoria 2 y 3) : RCI-____


Documentacion: (Firma /Fecha debida de termino): _____________________________________

Nombre del sistema: _______________________________________________________________

(1) Descripción de la Modificación:  Categoria 1  Categoria 2  Categoria 3

(1.1) Condiciones Existentes:  Anexo(s)

Revision actual de:

(1.2) Modificación Propuesta:  Anexo (s)

(1.3) Razón(es) para la modificación y Resultados esperados de la Modificación Anexo(s)

(1.4) Revisión del Impacto en la Validación:

(1.4.1) ¿Requiere Pruebas de Validación?  Si  No


Sí, si, especifique el tipo de pruebas a continuación:

(1.4.2) Evaluación del Riesgo (Referencia sección 6.2 de este PNO):


 Nivel 1  Nivel 2  Nivel 3

(2) Aprobaciones:

Esto certifica que el protocolo indicado ha sido revisado y es aceptable para su implementación
Titulo Firma Fecha
Gerente de Sistemas
Gerente de Area

Gerente de Ingenieria

Gerente de Validación

Página 6 de 6

You might also like