Posts tagged ‘Plan de Validación’

En este artículo quiero mencionarles algunos problemas en la validación de los sistemas computarizados que es muy probable verlos una y otra vez.

Nuestro objetivo es que al abordar estos desafíos de validación, si Ud. los considera se ahorrará tiempo, dinero y dolores de cabeza.

Pero mencionemos algunos de ellos:

  1. Falta de información

Algunos documentos o registros omiten información fundamental o contenido que debería haber sido incluido.

  1. Inconsistencia

Algunos documentos contienen ciertas declaraciones inconsistentes con otras declaraciones acerca del mismo tema, en el mismo o en otro documento del paquete de validación.

  1. Falta de detalles necesarios

Esta deficiencia se aplica principalmente a los documentos de requerimientos. Los requerimientos del paquete de validación no describen adecuadamente las características de los datos, las interacciones de los usuarios con los procesos de negocio o los procesos claves internos del software.

A veces los requerimientos son compuestos, no son únicos, por ejemplo una declaración estipula 2 o más características del sistema. Esta deficiencia o falla frecuentemente trae aparejado problemas de trazabilidad.

También podes mencionar la falta de criterios de aceptación.

  1. Trazabilidad:

La matriz de trazabilidad está incompleta. Los detalles de los requisitos no se numeran explícitamente y se relacionan a las etapas de prueba asociadas

  1. Vaga redacción o texto ambiguo

Los documentos usan generalidades tales como “de acuerdo con un procedimiento aprobado” o “requisitos reglamentarios aplicables” o “todos los GxP y procesos de negocio asociados”. Además, los documentos utilizan palabras vagas como “puede”, “posiblemente”, “más o menos”, y “aproximadamente”.

A veces el texto puede ser interpretado de más de una manera, por lo que no estableció un requisito único y único. Las palabras “cualquiera” y “o” en el requisito son fuertes indicadores que el texto es ambiguo.

  1. Resultados de las pruebas no verificables

Los resultados esperados no son suficientemente descriptos para que un revisor independiente pueda comparar y verificar los resultados reales. El estándar IEEE para documentación de prueba de software, std. 829.1988, la cláusula 6.2.4 (1) establece “… proporcionar el valor exacto (con las tolerancias cuando sea apropiado) para cada salida o característica requerida”. Para los scripts ejecutados, los resultados reales no fueron registrados ni capturados de manera que permitiera a un revisor independiente compararlos con los resultados esperados. Por ejemplo, “OK” se anotó en la columna de resultados reales sin referencia a la captura de pantalla.

  1. Buena práctica de documentación (BPD)

Registros poco claros, a veces los datos que confirman un requisito específico son difíciles de encontrar en la evidencia proporcionada (por ej. Una planilla llena de datos pero no está clara la evidencia), fallas en la corrección de errores documentales.

Se hacen correcciones escritas a mano que cambian el sentido del requisito o el resultado esperado de la prueba, pero no se presenta informe de discrepancia o solicitud de cambio (ej. Cambio de un resultado esperado del indicador “Off” a “On”). En las BPD, se siguen las correcciones de la mano sin documentación adicional solo cuando se trata de un obvio error tipográfico, como letras que faltan o están transpuestas (ej. Corrección “mantenimeinto” a “mantenimiento”)

  1. Pruebas incompletas:

Los scripts de prueba no prueban completa o adecuadamente el requisito asociado.

  1. Requerimientos incompletos:

El análisis del sistema indica que el software tiene funcionalidades que fueron usadas pero NO han sido descriptas en el URS.

Análisis de impacto regulatorio y análisis de riesgo indican la necesidad de requerimientos que no están en el URS.

Un requerimiento implica otro requerimiento, posiblemente complementario, que necesita ser explicitado para asegurar su verificación.

  1. Falta de 1 proceso para resolver desvíos

Los documentos y registros más vulnerables:

  • Especificaciones (incluyendo el URS) las más frecuentes
  • Scripts de testeo
  • Plan de validación
  • Matriz de trazabilidad
  • Resultados de testeos

Menos problemas relacionados a CSV conducen a una inspección exitosa.

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.

La calificación de un equipo consiste en una serie de verificaciones y testeos efectuados sobre el equipo con la finalidad de asegurar que el mismo cumple con las especificaciones de diseño, instalación y operación y que todas las operaciones futuras serán confiables y estarán dentro de los límites especificados, de manera de evitar problemas en el funcionamiento de los equipos y sus posteriores repercusiones sobre la calidad del producto elaborado.

Todas las actividades a desarrollar durante la calificación del equipo deben ser planeadas y aprobadas en un protocolo de calificación, el mismo servirá como guía de los pasos a seguir.

Además como parte del PMV (Plan Maestro de Validación) debe elaborarse un Plan de calificación de equipos o sistemas, conteniendo un inventario de los equipos, con responsables designados y una agenda de trabajo según prioridades.

CALIFICACION DE DISEÑO (DQ):

El diseño del proyecto requiere la preparación de especificaciones de requerimientos del usuario aprobadas.

El responsable del proyecto (Ingeniería, Producción, etc.) debe preparar la siguiente documentación:

  • Diagrama de flujo de proceso / materiales / personal / desechos
  • Clase de seguridad del equipo
  • Limpieza del equipo
  • Componentes del equipo
  • Diagramas de cableados / esquemas eléctricos
  • Especificaciones técnicas de ingeniería
  • Descripciones de materiales de construcción (materiales en contacto directo con el producto)

Los requerimientos son enviados a los proveedores para que elaboren su propuesta (cotización), además los mismos presentarán:

  • Diagramas del equipo
  • Datos de consumo de potencia del equipo (eléctrica, aire, hidráulica, etc.)
  • Certificados de materiales de construcción
  • Listado de repuestos recomendados
  • Testeos de rendimiento
  • Procedimientos de operación y limpieza

Luego la documentación de diseño / ingeniería debe ser chequeada y aprobada en comparación con los elementos de base (requerimientos del usuario), aquí tiene participación importante el responsable del proyecto y otros departamentos como producción, mantenimiento, aseguramiento de la calidad e higiene y seguridad.

CALIFICACION DE LA INSTALACION (IQ):

Debe documentarse que el equipo esté instalado según las especificaciones y los requerimientos de diseño. Ejemplos de chequeos:

  • Ubicación del equipo respecto de planos
  • Alineamiento de acoples (equipo rotativo)
  • Servicios (cumplimiento de requerimientos)
  • Cañerías (materiales, pendientes, soldaduras, pasivado y limpieza, etc.)
  • Donde el diseño disponga de planos, certificados de materiales, etc., es una buena práctica incluirlos en la documentación de la calificación. Esto permitirá reducir tiempos y costos de calificación y contribuye a obtener una mejor calidad acerca de como está construido el equipo.

Dentro del IQ incluimos la calibración de los instrumentos, este tema merece un párrafo aparte, pues muchas veces nos preguntamos que cosas debemos contemplar para garantizar un exitoso programa de calibración de instrumentos. A continuación detallamos algunos puntos que creemos de real importancia:

* Como primer paso debemos listar todos los instrumentos de medición de la planta, no solamente instrumentos que se utilizan en la fabricación de los productos sino aquellos que sirven de apoyo en los sistemas auxiliares. Estos listados deberán ser actualizados mínimo cada período de calibración de los instrumentos. Actualmente, una manera eficiente de tener todos los instrumentos bajo control, es a través de un software que permita cargar la historia de los instrumentos.

* Asimismo, se deberá establecer una frecuencia de calibración que puede variar de acuerdo a la necesidad de cada área y de la criticidad del mismo.

* La ejecución de la calibración de cada instrumento será realizado en base a un procedimiento operativo standard. En caso de que no se realicen las calibraciones con personal de la compañía, una compañía contratada deberá aportar los SOPs correspondientes, a fin de que se pueda tener documentado como se realizó la calibración.

* Una vez calibrado y aprobado el instrumento, se le colocará una identificación (etiqueta) que indique como mínimo lo siguiente: fecha de calibración actual y próxima, nombre de la persona que realiza la calibración, la firma de V° B°, etc. Dicha etiqueta deberá ser colocada en lugar visible a modo que el usuario pueda verla fácilmente y así le de seguimiento adecuado. Asimismo, se deberá emitir un reporte de calibración, el cual debe incluir como mínimo los siguientes datos: descripción del instrumento, modelo y/o N° de serie, patrón de referencia empleado en la calibración, firma de la persona que realizó la calibración, status, etc.

CALIFICACION DE OPERACION y DE PERFORMACE (OQ y PQ):

Antes del comienzo de los testeos funcionales, cualquier equipamiento que esté controlado por computadora debe seguir el llamado loop check en el cual se corrobora y se documenta la correcta comunicación entre las direcciones de entrada y salida de los dispositivos.

Los testeos funcionales deben demostrar que el equipo se comporta según lo especificado a través de los rangos operativos definidos anteriormente. Los parámetros críticos y los criterios de aceptación a cumplir deben ser especificados de antemano en el Plan de testeo.

Una vez que se ha completado la calificación del equipo se vuelcan todos los datos y anexos sobre un reporte de calificación, el mismo tendrá conclusiones y recomendaciones además de las observaciones a corregir.

CUALQUIER CAMBIO O MODIFICACION DEL EQUIPO, DURANTE O DESPUES DE LA REALIZACION DE LA CALIFICACION DEBE SEGUIR LOS LINEAMIENTOS DEL SOP DE CONTROL DE CAMBIOS.

Cómo mantenemos los equipos calificados?

Para asegurar que el equipo calificado se mantiene en ese estado, debemos disponer de procedimientos de operación, limpieza, mantenimiento preventivo y de control de cambios.

Es muy importante que el sistema de mantenimiento preventivo esté aprobado y en funcionamiento.

Además los instrumentos del equipo deben ser ingresados a un Plan de calibración anual  de  donde los mismos serán recalibrados según la frecuencia establecida.

Ambos sistemas (calibración y mantenimiento) pueden tener registros electrónicos o manuales.

Además se debe disponer de procedimientos para el manejo de los desvíos (sobre todo en las operaciones de mantenimiento preventivo y calibración) y y de los cambios sobre el equipo.

Por último les dejo algunas preguntas las cuales podrán servirle para conocer cómo se halla su sistema de calidad en lo que respecta a este tema.

  • ¿Tiene un SOP para la calificación de equipos y áreas?
  • ¿Tiene un Plan de Validación que contemple la calificación de los equipos de producción y del laboratorio?
  • ¿Dispone de un Plan de calibración anual de instrumentos?
  • Cuando un instrumento no funciona o está fuera de tolerancia ¿Qué medidas correctivas aplica?
  • ¿Cómo maneja las no conformidades o desvíos surgidos de las calificaciones de equipos?

Espero que le resulte útil. Hasta el próximo artículo.