Posts tagged ‘Control de Cambios’

El tema de la revalidación rara vez se menciona en las regulaciones. La verificación continua del proceso ha reemplazado la revalidación regular (con excepciones en el área estéril). Pero, ¿Qué puede suceder después de un control de cambios? Lea la opinión de la FDA a continuación.

En una carta de advertencia, la FDA describe lo que espera en caso de un cambio en el proceso. ¿De qué se trata?

Se criticó la falta de validación suficiente. Además, como resultado de las quejas de los clientes sobre la viscosidad del producto, la empresa cambió dos ingredientes sin control de cambios. El nuevo proceso no fue (re)validado. La FDA no se refiere explícitamente a la revalidación, sino únicamente a la validación. En relación con sus directrices de validación de procesos, la FDA explica a continuación lo que entiende por validación de procesos.

La respuesta de la empresa de que había iniciado un enfoque estructurado para la validación de procesos no fue suficiente para la FDA. La autoridad exige la demostración de procedimientos y planes de validación de procesos adecuados. Además, la FDA desearía ver un cronograma para la implementación de medidas CAPA o evaluaciones de riesgos en productos que se han lanzado sin la validación o las pruebas adecuadas.

La FDA exige además:

  1. Un plan para garantizar que exista un seguimiento continuo durante todo el ciclo de vida de fabricación de todos los medicamentos.
  2. Un programa basado en datos y en la ciencia para identificar la variabilidad del proceso y garantizar que se mantengan los parámetros necesarios y la calidad del producto.
  3. Un resumen del programa de validación para garantizar que se mantenga un estado de control durante todo el ciclo de vida del producto, junto con los procedimientos asociados.
  4. Una descripción del programa de Calificación del Desempeño del Proceso (PPQ).
  5. Una descripción de las actividades de monitoreo para evaluar la variabilidad intralote e interlote para asegurar el estado de control.
  6. Un programa para la implementación del PPQ para cada uno de los medicamentos comercializados
  7. Un programa detallado para el desarrollo, validación, mantenimiento, control y monitoreo de cada proceso de fabricación, con respecto a la variabilidad intralote e interlote para asegurar un estado de control
  8. Un programa para la calificación de instalaciones, servicios y equipos.

Conclusión: Los cambios de proceso pueden desencadenar una (re)validación relacionada con eventos, por lo que la FDA no utiliza el término revalidación, sino que solo se refiere a la validación.

    Puede encontrar la Carta de Advertencia completa en el sitio web de la FDA.
    Publicado en la News Letter de la ECA (7/8/2024)

    Una gestión de cambios eficiente debe ser ejecutada conjuntamente con la gestión de configuración. Los elementos claves incluyen:

    1. Descripción documentada y beneficios del cambio para el negocio

    2. Confirmación de la disponibilidad de recursos

    3. Evaluación del impacto del cambio sobre la aplicación, la infraestructura necesaria, personal (usuarios, staff de soporte de Ingeniería) y la documentación

    4. Aprovechamiento de la información del análisis de riesgos del proyecto original y evaluar cualquier riesgo nuevo introducido por el cambio para definir la estrategia de mantenimiento, esto incluye la necesidad de cualquier testeo de regresión.

    5. Evaluación del cambio desde finanzas, IT (o ingeniería) y la perspectiva de cumplimiento al más bajo nivel de competencia técnica antes de gestionar la aprobación

    6. Establecer y mantener la distinción entre cambios a nivel del sistema de calidad farmacéutico (impacto sobre el ciclo de vida del producto medicinal) vs cambios a nivel de la gestión del servicio de IT

    7. Minimizar el número de puntos de aprobación en el proceso

    8- Documentar y comunicar la decisión

    9. Ejecutar y verificar el cambio, usando trazabilidad para identificar testeos existentes que aplican

    10. Cerrar los registros del cambio en tiempo y forma

    Debilidades en los sistemas de gestión de cambio que pueden llevar a ineficiencias, incluyen:

    1. Falta de escalada de los cambios, ej cambios menores o de componentes de infraestructura que cambian regularmente

    2. Falla en la ejecución de las etapas de gestión del cambio en la secuencia apropiada

    3. Falla en la agenda de actividades o en identificar dependencias

    4. Abuso o aplicación errónea de un proceso de cambios de emergencia

    5. Falta de habilidad para prevenir cambios innecesarios

    6. Falla en mantener las especificaciones vigentes

    7. Falla para aprovechar documentación relativa a análisis de riesgos y control, matriz de trazabilidad o protocolos

    8. Falta de seguimiento del proceso para cerrar un registro de cambio

    9. Procesos de cambio independientes llevan a duplicar esfuerzos para procesos, equipos y Sistemas Computarizados.

    10. La aplicación inadecuada de los principios de “like for like” en gestión de cambio.

    11. Inadecuada gestión de cambios conducidos por un proveedor, conducen a ciclos de vida de documentos y registros de gestión de configuración que están fuera de fecha

    12. Falta de un adecuado seguimiento de los cambios de emergencia

    Basado en la GAMP5 edición 2 (julio 2022)

    ¿Qué influencia pueden tener los cambios de proceso en la validación del proceso?

    ¿De qué se trataba? Para ahorrar tiempo de producción, un fabricante de APIs había realizado un cambio de proceso en 3 puntos importantes de dos APIs. Después del cambio de proceso, también se produjeron lotes de Calificación del rendimiento del proceso (PPQ). Sin embargo, algunos de estos lotes no cumplieron con la especificación sobre uniformidad de mezcla. Los otros lotes fueron liberados.

    La FDA comentó en la Warning Letter que el fabricante carecía de datos que mostraran que el proceso estaba en “estado de control” antes de la liberación del lote.

    La evaluación del fabricante después del cambio de proceso mostró que el nuevo proceso conducía a deficiencias en la uniformidad de la mezcla. El proceso “antiguo” era más consistente y robusto. A este respecto, los lotes inéditos deben continuar retenidos durante la discusión sobre cómo proceder con el cambio de proceso. Después de 8 meses, se volvió al proceso “antiguo”. Sin embargo, el fabricante decidió que los lotes retenidos podrían distribuirse. Esto fue criticado por la FDA. El fabricante respondió que “revisaría” estos lotes y los retiraría si fuera necesario. En su respuesta también escribió que sólo los primeros lotes producidos consecutivamente “con éxito” son elegibles para el lanzamiento al mercado y que los lotes de PPQ no conformes se consideran de antemano. Si se observa un error en los lotes de PPQ y no hay una “causa raíz” clara para la causa, estos lotes no deberían recibir el lanzamiento de mercado.

    A pesar de esta respuesta del fabricante, la FDA considera que la estrategia de validación del fabricante es insuficiente. Esto se debe a que la estrategia de validación no garantiza que los lotes de PPQ se evalúen correctamente para indicar que el proceso está en “estado de control”.

    La FDA también señala que se le informó que el fabricante recientemente tomó la decisión de retirar todos los lotes de PPQ producidos con el nuevo proceso. Sin embargo, la FDA desea ver:

    • una descripción detallada del programa de validación que garantiza que el estado de control se mantenga durante todo el ciclo de vida del producto
    • instrucciones de trabajo adjuntas
    • una descripción de la Calificación del rendimiento del proceso y un seguimiento adicional de la variabilidad intralote e interlote
    • una descripción de si se ha realizado correctamente una PPQ para cada producto comercializado con los criterios adecuados

    Puede encontrar la Warning Letter completa en el sitio de la FDA.

    Tomado de Boletín ECA GMP 12/dic/2020

    El acceso remoto por parte del proveedor ofrece muchas ventajas al mantener el software, solucionar problemas e instalar nuevas funcionalidades. Sin embargo, ¿qué regulaciones deben existir para el acceso remoto de los proveedores de servicios a los sistemas críticos de GxP? ¿Qué requisitos de integridad de datos se deben incluir?

    ¿Cómo se puede hacer que este proceso sea compatible con GxP?

    El acceso remoto permite a los proveedores de servicios acceder a sistemas computarizados a través de una conexión de red para corregir errores o cambiar la configuración. Si se accede a un sistema computarizado crítico GxP de forma remota, las actividades del proveedor de servicios o la compañía de servicios pueden modificar el sistema de tal manera que el estado validado ya no se mantenga. Por lo tanto, el acceso remoto y las acciones realizadas durante esta sesión deben controlarse y documentarse. Esto significa que el acceso debe ser habilitado activamente por el RU (usuario regulado). Además, esto debe hacerse a través de una conexión de red segura y se debe mantener un registro de las actividades realizadas. Si es necesario, se debe iniciar un proceso de control de cambios.

    El objetivo es mantener y controlar el estado validado del sistema.

    Publicado en el Boletín GMP de la ECA (6/5/2020)

    Aplicaciones en la Nube | Enkicode

    Les dejo este artículo relacionado sobre aplicaciones en la nube.

    Como usualmente solemos decir, la validación de los sistemas computarizados GxP es requerida para asegurar que cumplimos con las regulaciones, y además para demostrar que son adecuados para su propósito de uso.

    Previo a la puesta en uso y nuevamente cuando hay cambios en el SC, la validación puede ser intensa en cuanto al tiempo y los recursos necesarios. Frecuentemente el mismo rigor es aplicado a todos los cambios en los SC, independientemente del impacto potencial, esto provoca un ahogo que puede llevar a tener SC estancados y un GAP creciente entre las soluciones y las necesidades de los usuarios del SC o del negocio.

    Los vendedores actuales han reducido la carga de validación por medio de las ejecuciones de IQ y de OQ y/o proveer la documentación, sin embargo algunas soluciones en la nube tienen actualizaciones frecuentes y mandatorias.

    Un proceso de gestión de cambio optimizado (basado en el riesgo) puede hacer que los sistemas se mantengan vigentes. Este enfoque consistente, permitirá reducir tiempos y esfuerzos.

    Para esto es fundamente que el entrenamiento (conocimiento) del proceso de cambios sea adecuado.

    Aplicaciones GxP en la nube.

    La popularidad de aplicaciones basadas en la web, dispositivos inteligentes, usuarios están listos, hace que tengamos un ritmo constante de release de actualizaciones, introduciendo cambios más frecuentes que en el pasado. Por tal razón, es fundamental disponer de un proceso para el manejo de los cambios de los sistemas.

    Las características de las aplicaciones de la nube tienen un impacto significativo en la validación de las organizaciones y en la estrategia de control de cambios.

    En general hay dos tipos de opciones en la nube:

    •           Hosted (alojado)

    •           Multitenant (multiinquilino)

    Una diferencia fundamental entre ambas es como sus vendedores gestionan y entregan las nuevas versiones de sus aplicaciones a sus clientes.

    Hosted Cloud (HC)

    Con este tipo de aplicaciones cada cliente tiene su propio software y un enfoque tradicional es usado para proveer una nueva versión.

    El vendedor notifica al cliente cuando un nuevo release está disponible y el cliente decide si quiere la nueva versión, y cuando el vendedor debería efectuar la actualización.

    Después de la actualización, son efectuadas las actividades de validación y su liberación para uso productivo.

    No todos los clientes actualizan la última versión de un HC al mismo tiempo y alguno nunca lo hacen. Como resultado de esto, los vendedores de aplicaciones en la nube deben soportar múltiples versiones de sus aplicaciones.

    Multitenant Cloud (MC)

    En este modelo, múltiples clientes usan una versión única del software y coexiste sobre una infraestructura de IT compartida.

    Se entrega una nueva versión del software para todos los clientes al mismo tiempo sobre una agenda predefinida por el vendedor. Como resultados de esto, cada cliente está siempre con la última versión de la aplicación y no hay viejas versiones para que el vendedor soporte.

    Los clientes son notificados con anticipación cuando una actualización tomará lugar. Luego son efectuadas las actividades de validación y su liberación para uso productivo.

    En este punto es de suma importancia trabajar con proveedores aprobados y disponer de un acuerdo de calidad.

    La expectativa es la existencia de un proceso de cambio robusto, que nos permita mantener el estado validado de nuestros sistemas computarizados GxP y no comprometa la calidad del “producto” del sistema.

    De acuerdo a la FDA, la Validación de procesos es un ciclo de 3 etapas, con el objetivo de asegurar que el proceso validado permanece en un estado de control.

    Las 3 etapas son:

    • Diseño del proceso
    • Calificación del proceso
    • Verificación continua del proceso

    Veamos en cada una de ellas, la importancia del Risk Assessment.

    1. Diseño del proceso

    El diseño del proceso, o la etapa 1 del enfoque del ciclo de vida para la validación del proceso, es donde se define el proceso de fabricación. El proceso de fabricación se basará en datos científicos sólidos de actividades de desarrollo y scale up. La evaluación del riesgo en esta etapa incluye la forma del producto, la población de pacientes y la evaluación del riesgo en materiales, equipos, flujo de proceso y operaciones unitarias.

    La evaluación de riesgos en esta etapa comenzará con el entendimiento de las fuentes de variación en el proceso; Esto identificará el riesgo. Al definir el proceso a validar, identifique los parámetros críticos de control de proceso (CPP) y los atributos de calidad crítica (CQA). La comprensión del riesgo asociado con cada parámetro se puede determinar haciendo las siguientes preguntas:

    • ¿Qué pasa si el parámetro está fuera de control?
    • ¿Qué parámetros realmente afectan el proceso?

    Identificar el riesgo de tal manera ayudará a definir el alcance de la validación.

    También se debe evaluar el riesgo para cada operación de la unidad (por ejemplo, mezcla, molienda). Se deben establecer los controles necesarios para reducir el riesgo. Los atributos o parámetros de mayor riesgo requerirán un mayor grado de control.

    En esta etapa, muchos profesionales cuando el diseño madura, o sea cuando hay mas conocimiento del proceso, utilizan el modo de falla y el análisis de efectos (FMEA) como herramienta de análisis de riesgo.

    2. Calificación del proceso

    La calificación del proceso, o etapa 2, es lo que se considera como la “validación tradicional”. El diseño del proceso, de la etapa 1, se lleva a la fabricación comercial capaz o reproducible.

    En esta etapa, será necesario identificar el nivel de esfuerzo y la documentación de las actividades de calificación.

    El riesgo se evaluará al establecer la cantidad requerida de muestreo y ensayos. El número de muestras debe ser adecuado para proporcionar suficiente confianza estadística de calidad dentro de un lote y entre los lotes. El nivel de confianza seleccionado se puede basar en el análisis de riesgo, ya que se relaciona con el atributo particular que se examina. La evaluación de riesgos también apoyará las razones para ensayar los lotes.

    El plan de validación, posiblemente sea el documento de la etapa 2 más importante.

    3. Verificación continua del proceso

    La verificación continua del proceso, etapa 3, es la garantía continua de que el proceso permanece en un estado de control.

    Un aspecto de esta etapa es el control de cambios. Cuando se ejecute un control de cambios, se deberá evaluar el impacto del cambio. Además, el riesgo para el paciente, el producto / proceso, el cambio potencial, el riesgo de cumplimiento y el riesgo empresarial deben determinarse para el riesgo potencial. Además, al evaluar y documentar las desviaciones o no conformidades en esta etapa, se debe evaluar el riesgo asociado con cada desviación. Las evaluaciones de riesgo completadas con los documentos de validación aplicables deben mantenerse.

    En un artículo anterior mencionamos que aplicando ciertas reglas a los patrones de los datos de la carta de comportamiento del proceso nos ayuda a evaluar si el proceso es estable y está bajo control. Estas reglas están referenciadas como las Western Electric Pattern Rules (WEP rules) y decíamos que cuando son aplicadas on time, las violaciones a las reglas específicas pueden proveer una percepción del proceso para ayudar a la toma de CAPAs inmediatas.
    Las violaciones de las reglas deben investigarse y documentarse cuando son detectadas. La investigación debe cubrir al menos todos los lotes incluidos en la violación de la regla y tiene como objetivo evaluar si se ha producido un verdadero cambio en el proceso.
    Para poder concluir que se ha producido un cambio en el proceso, la investigación debe haber cubierto, y descartado, los posibles errores de laboratorio, este concepto es similar al de manejo de resultados OOS. Cuando está claro que el resultado es correcto, entonces se debe dirigir el enfoque de la investigación para que entienda la influencia del proceso en el resultado a través de una investigación del proceso / producto.
    Cuando se investiga la causa de la violación de una regla, es útil usar diferentes tipos de gráficos y procesar gráficos de comportamiento. El gráfico de control de suma acumulativa (CUSUM chart) podría ser útil para identificar cuándo comenzó una tendencia o cambio en los datos. Los gráficos de promedios móviles, los gráficos de promedios móviles ponderados exponencialmente y otras técnicas y gráficos de suavizado también son útiles para comprender el comportamiento del proceso.
    Durante una investigación, es útil realizar una tendencia de los datos clasificados tanto en la fecha de fabricación como en la fecha de análisis. También podría haber otras fechas para las etapas de producción intermedias durante la fabricación del producto terminado que podrían ser de interés.
    Dado que en muchos de nuestros procesos se observan fluctuaciones de rutina por varios motivos (por ejemplo, diferentes lotes de materia prima, diferentes estándares para pruebas, lotes probados en la misma ejecución analítica), pueden ocurrir frecuentes violaciones de las reglas. Si bien algunos de estos pueden representar eventos molestos fuera de control, se deben realizar investigaciones para determinar si existen oportunidades para mejorar el proceso. En tales casos, las CAPAs deben identificarse con Desarrollo Farmacéutico para desarrollar una mejor comprensión del proceso.
    Si no se puede identificar una causa inmediata para un cambio en el proceso, los límites de control se mantienen sin cambios y se deben seguir utilizando hasta que se haya identificado una causa.
    Las violaciones frecuentes de las reglas indican que el proceso es inestable y podría estar sujeto a fuentes de variabilidad que anteriormente no se habían identificado. En tales casos, debemos identificar las causas para la toma de las CAPAs necesarias.
    Después de concluir que se ha producido un cambio en el proceso y que se ha identificado la razón del cambio y que el proceso se encuentra nuevamente bajo control estadístico, se pueden calcular nuevos límites de control. Los nuevos límites deben basarse en los datos recopilados después de que se produjeron los cambios identificados. Si los datos son limitados, se debe realizar un nuevo cálculo cuando haya datos adicionales disponibles.
    Todos los límites de control deben estar justificados y documentados.
    Los nuevos límites de control deben pasar por Control de cambios antes de ser implementados.

    La innovación, la mejora continua, los resultados del monitoreo de la performance del proceso y la calidad del producto y el sistema CAPA, conducen al cambio.

    Una compañía debe tener un efectivo sistema de gestión del cambio de manera de evaluar, aprobar e implementar los cambios apropiadamente.

    El sistema de cambio asegura que la mejora continua es emprendida en tiempo y de manera efectiva y debe asegurar que no habrá consecuencias no esperadas a partir del mismo.

    El sistema de gestión del cambio es aplicado en todas las etapas del ciclo de vida del producto: desarrollo farmacéutico, transferencia tecnológica, elaboración comercial, y discontinuación del producto, y debe incluir lo siguiente:

    • Uso de la Gestión de riesgos de calidad para evaluar los cambios propuestos (el nivel de esfuerzo y formalidad de la evaluación debe ser acorde con el nivel de riesgo), ICH Q9,
    • Evaluación del cambio propuesto vs. la autorización regulatoria, incluyendo el espacio de diseño (si fue establecido) y el conocimiento actual del proceso / producto. Si bien de acuerdo a la ICHQ8 trabajar dentro del espacio de diseño no es considerado como cambio, desde el punto de vista de sistemas de calidad farmacéutico, todo cambio debe ser evaluado por medio del sistema de control de cambios de la Compañía,
    • Los cambios propuestos deben ser evaluados por un equipo de expertos en las áreas relevantes (ej. Desarrollo, Manufactura, Calidad, Asuntos Regulatorios, etc.),
    • Luego de la implementación del cambio, debe ser efectuada una evaluación para confirmar que los objetivos del cambio fueron alcanzados y que no hubo impacto perjudicial sobre la calidad del producto.

    Espero que les resulte útil estas líneas tomadas de la ICH Q10, relacionada a Sistemas de Calidad Farmacéuticos.

    He pensado en tomarme unos minutos para hablar sobre este tema, ya que es muy frecuente que discutamos sobre el tema central, la validación de las planillas Excel, pero siempre que tenemos la oportunidad, en talleres, en cursos o simplemente cuando hacemos una evaluación de riesgo para saber como estamos en este tema, surge la pregunta…

    ¿Cómo administramos las planillas Excel?, ¿Lo hacemos de una forma segura?

    Veamos un poco el tema.

    Les recuerdo que hemos hablamos de la importancia de determinar el impacto GMP de una planilla Excel (PE), considerando,  si la misma tiene impacto directo sobre la  pureza, seguridad, eficacia, identidad del producto, o la medición o monitoreo de estos atributos, o si el Excel produce datos que serán usados para aceptar o rechazar el producto, o también si los resultados obtenidos del Excel interactúan con otros sistemas que tienen efecto directo sobre la calidad del producto.

    También mencionamos la construcción de las planillas y las actividades de validación para asegurar que las mismas, fórmulas, instrucciones, macros, etc., cumplan con las especificaciones y sean seguras.

    Pero hoy quiero hacer foco en dos aspectos muy importantes:  la administración de las planillas y el uso apropiado de las mismas.

     

    Pero que pasa luego que la planilla ya está validada y el personal del laboratorio está entrenado en su uso?

    El responsable de administrar las planillas del laboratorio (usualmente QA), debe proteger las planillas, usualmente asignarles una codificación, podría ser por ejemplo:

    PE-NNN vXX

    Donde:

    PE: acrónimo de Planilla de cálculo Excel

    NNNN: número único para cada PE, comenzando por el 001

    V: correspondiente a versión

    XX: número de

    Luego QA registra la información de la PE en un listado o inventario de planillas Excel del laboratorio conteniendo las planillas validadas vigentes.

    Desprotege la PE y workbook.

    Asegura que cada impresión del worksheet incluye la siguiente información en cada página:

    • Nombre del archivo / nombre del worksheet (hoja) en el encabezado
    • Número de página en el pié de página
    • Estado y fecha de vigencia en el pié de página
    • Ruta donde está la planilla de cálculo Excel en el pié de página
    • Fecha y hora de impresión

    Verifica que la información agregada no altera el número de páginas impresas (ajusta de forma necesaria para mantener el número de páginas como está testeada y documentada en los test del usuario de la PE).

    Respeta los códigos de color establecidos para la fuente y las celdas.

    Setea la PE para ser compartida, de la siguiente manera, accede al ítem menú: Tools>share workbook y chequea el ítem “permitir cambios por más de un usuario al mismo tiempo”.

    Protege la PE y el workbook con un password. Ingresa al menú Herramientas / proteger Hoja y hace click, ingresa la contraseña y luego presiona “enter” o click en el botón aceptar. Registra el password (s) en el inventario de planillas validadas vigentes.  Salva el archivo y lo cierra. Coloca la PE validada en la carpeta de la red dedicado para ese propósito y liberada para su uso.

    Para efectuar la administración de las Planillas Excel, suelen crearse carpetas para ubicar a las planillas según su status, por ejemplo:

    • Planillas Validadas y vigentes
    • Planillas No vigentes
    • Planillas en modificación / validación
    • Templates o modelos (como por ej. Especificación de diseño, protocolo de validación, etc.)

    Los permisos de acceso a tales carpetas son los siguientes:

    Posición Validadas/vigentes No vigentes En modificación/validación
    Supervisor QC Solo lectura No acceso Copia/borra/modifica
    Usuario Solo lectura No acceso No acceso
    Personal QA Acceso completo Acceso completo Acceso completo
    Adm. IT Backup / recovery Backup / recovery Backup / recovery

    Uso de las planillas Excel validadas:

    Cada usuario debe verificar que la planilla está disponible en la carpeta de planillas de cálculo Excel vigentes.

    Cada impresión de planilla debe incluir los nombres del archivo y planilla, la información del número de página, la fecha y la hora de impresión, el estado de la planilla y la fecha de vigencia.

    En cuanto al uso de las mismas, quiero que recuerden que dado que las planillas Excel “perse” no cumplen con la parte 11, el uso esperado es abrir la planilla, completar los campos necesarios con datos, generar una impresión, revisarla y firmarla.

    No está permitido que los usuarios finales salven la PE de manera de permitir que el archivo sea cargado de la misma forma cada vez que se accede a él.

    Cambios a una PE existente, los mismos deben ser efectuados a través del sistema de control de cambios o a través de un log de cambios de la planilla, de manera que las modificaciones sean documentadas y aprobadas antes de ser efectuadas.

    Una vez aprobado el cambio, QA efectúa una copia de la planilla existente para que sea efectuada la nueva versión, luego de creada la misma sigue el mismo camino que vimos anteriormente.

    La planilla modificada reemplaza a la anterior, la cual es retirada a obsoleta.

    Espero que les resulte útil.

    Control de cambios es un término común para describir el proceso del manejo de cómo los cambios son introducidos dentro de un sistema controlado.

    La mayoría de los problemas de los softwares y sistemas computarizados son introducidos cuando son efectuados cambios durante el uso de los mismos. El control de cambios es requerido para asegurar que los sistemas validados permanecen bajo control aun cuando son sometidos a cambios.

    La falta de documentación y pobres testeos después de los cambios son unas de las principales observaciones de las auditorías. De ahí la importancia de disponer de un sistema de control de cambios robusto.

    El proceso de control de cambios

    cambio

    Los sistemas computarizados no son estáticos y requieren un programa de mantenimiento robusto luego de la validación inicial. Un procedimiento de control de cambios es crítico para asegurar que los cambios son evaluados, documentados, efectuados y seguidos consistentemente a lo largo de su ciclo de vida. Este procedimiento define el proceso a seguir para evaluar la implementación de los cambios.

    El proceso de control de cambios está típicamente definido por medio de la propuesta de necesidad de un cambio, la aprobación del mismo, la ejecución del cambio y la aprobación final de todas las actividades y el cierre del control de cambio.

    Veamos cada una de las etapas:

    1. Cambio propuesto: el solicitante del cambio efectúa el requerimiento formal del mismo, el cual necesita ser evaluado para asegurar que es apropiado y que el cambio propuesto no impactará negativamente sobre otros aspectos o capacidades del sistema.

    El cambio debe ser clasificado, por ej. de emergencia, de rutina, etc. Algunos cambios no esenciales pueden ser reunidos y ejecutados de manera conjunta. Esta clasificación indicará el ritmo de implementación y las actividades asociadas. Es esencial que el procedimiento de control de cambios provea una vía expeditiva para los cambios de emergencia. Estos cambios, frecuentemente son necesarios para corregir problemas en el software o reestablecer operaciones del proceso rápidamente. Si bien los cambios deben ser completados en un período de tiempo muy corto, deben ser implementados de forma controlada. Los cambios de emergencia deben estar sujetos a controles similares a los cambios de rutina. Sin embargo el proceso puede ser relativamente abreviado para el requerimiento del cambio, su evaluación y aprobación para asegurar que los cambios queden hechos rápidamente.

    Siempre que sea posible, los cambios de emergencia deben ser testeados antes de la implementación.

    Si IT no está plenamente disponible para testear las modificaciones de emergencia antes de su instalación, es crítico que se disponga de apropiados back up de archivos y programas, como también tener un plan de back out in place.

    1. Aprobación y planeamiento: Un equipo multifuncional debe determinar como el cambio podría afectar al sistema antes que el cambio sea efectuado. Este equipo debe incluir al menos al Propietario del sistema, Aseguramiento de Calidad e IT. Dependiendo del análisis de riesgo del cambio, el nivel y rigor de la documentación y los testeos a efectuar.

    La aprobación para avanzar con el cambio debe ocurrir antes que cualquier cambio en el sistema sea efectuado.

    En el caso de cambio de emergencia (situación urgente) un cambio podría ser aceptado antes de completar el proceso formal del control de cambio. Sin embargo, el mismo debe ser documentado de la misma forma de acuerdo a lo indicado en el procedimiento de control de cambios.

    La decisión sobre si aceptar o rechazar un cambio podría ser basada en una serie de preguntas:

    • El cambio es inevitable?
    • El cambio aumenta el beneficio general de la organización?
    • El equipo está disponible para hacer tal cambio?
    • Es mejor hacer el cambio ahora o puede ser mejor diferirlo?
    • El cambio impactará otras áreas o sistemas?

    La determinación del impacto ayudará a definir el nivel de testeos requeridos para el sistema.

    Adicionalmente la matriz de trazabilidad (MT) es un documento que vincula formalmente los requerimientos de diseño y los testeos a través del proceso de validación.

    El análisis de regresión podría indicar la funcionalidad que requiere testeos de regresión así como también un racional sólido para excluir aquellas funciones que no son impactadas por el cambio.

    Los siguientes documentos deben ser evaluados para el impacto potencial debido al cambio y sus actualizaciones deberían ser planeadas si son requeridas;

    • Paquete de validación incluyendo URS, especificación de requerimiento técnico (TRS), TM, DQ, IQ, OQ, PQ y plan y reporte de validación
    • Procedimientos para el uso y mantenimiento del sistema

    Los cambios deben ser planeados y ejecutados mínimamente involucrando a IT y QA y al propietario del sistema o del negocio. Los cambios deben ser comunicados a todas las áreas y funciones afectadas.

    1. Ejecución del cambio: el cambio es en esta etapa efectuado en un entorno de testeo de manera que puede ser testeado antes de la implementación en productivo. El cambio (y otros aspectos del sistema que pueden haber sido afectados) es testeado para asegurar la exactitud del sistema, confianza y asegurar una performance consistente acorde a su propósito.

    El ensayo debe ser documentado y los resultados deben conducir a correcciones y testeos adicionales o confirmar que los resultados finales después del cambio son lo que se pretendía. La documentación asociada con el cambio debe ser además completada.

    Los cambios deben ser inicialmente implementados lejos del entorno de producción del sistema validado. Esto asegurará que no son efectuados cambios en el entorno de producción hasta que ellos han sido completamente validados y funcionan bien.

    En relación a los sistemas computarizados es recomendable tener algunos entornos virtuales como por ejemplo:

    • Entorno de desarrollo (a veces se lo llaman “sandbox” o arenero), un entorno virtual donde un código / configuración experimental toma lugar, como el configurador / desarrollador está probando diferentes soluciones haciendo testeos preliminares, etc.
    • Sistema de testeo, un entorno virtual usado para testear preliminares del sistema conducidos por IT.
    • Validación, un entorno virtual que está congelado y es representativo de producción, seteado para el testeo de validación y controlado y NO modificable a lo largo de los testeos de validación.
    • Entrenamiento, no siempre usado por todos las compañías para todos los sistemas, un entorno virtual usado para manejar entrenamientos sobre un sistema nuevo o revisado.
    • Producción, es el entorno del negocio vivo o “instancia” del sistema.

    El testeo debe verificar lo siguiente:

    • La performance del sistema luego que los cambios son efectuados y que los nuevos cambios no introducen errores que mantienen el sistema fuera de la performance buscada.
    1. Aprobación final / implementación del cambio: la aprobación final para liberar la nueva versión a productivo es concedida basada sobre los resultados de testeos exitosos y luego de disponer del paquete documental completo.

    Si es requerido entrenamiento, el personal afectado (por ej. Usuarios, super-users, soporte de IT) deben ser entrenados antes que ellos estén notificados para el uso del sistema o antes de la implementación del sistema en el entorno productivo.

    La aprobación final es típicamente concedida por medio del propietario del sistema y aprobada por personal autorizado de QA e IT.

    La nueva versión del sistema es entonces liberada para el entorno productivo.

    Cuando en una auditoría es incluida la inspección de cualquier sistema computarizado utilizado para un propósito regulado, los inspectores revisan típicamente la documentación del sistema, incluyendo los registros de los cambios, como fueron evaluados y la documentación de los mismos.

    Resumiendo:

    El proceso de control de cambios es importante para asegurar y evitar potenciales riesgos del negocio. Un proceso de toma de decisión objetivo debe ser usado para determinar el nivel y la complejidad de los cambios propuestos. El nivel del impacto que el cambio podría tener debe ser además determinado y esto nos indicará la profundidad de los testeos y  documentación requerida.

    Un proceso de control de cambios es necesario para prevenir inapropiadas modificaciones o modificaciones que conducirán a efectos adversos. Un control de cambio efectivo es un aspecto importante para mantener el estado validado de los sistemas, permitiendo continuas mejoras y previniendo gaps de compliance.