Posts tagged ‘Validación’

La microbiología en el laboratorio de control de calidad está sujeta a variabilidad. Esta variabilidad puede ser evidente en los resultados de los tests y algunas de las causas puede ser la forma en que son tomadas las muestras, el tamaño de la muestra y además podríamos agregar la variabilidad innata de un proceso fuertemente dependiente de la interacción humana.

Por ejemplo, en la operación de plaqueo, podemos encontrar con una variedad de errores involucrados en ésta operación como, error de pipeteo, falla en el medio de cultivo, falla en la incubación, etc.

Los errores en este tipo de ejemplo pueden ser divididos en 2 principales tipos, algunos que podrían ser considerados errores evitables (errores de plaqueos, errores de cálculos) y otros que podrían llamar errores inevitables (error de muestreo, error de dilución, error de distribución).

No podemos eliminar cualquier tipo de error en el laboratorio, pero la categoría general de errores inevitables no es susceptible de corrección por medio del entrenamiento o técnica del laboratorio adecuada. Por eso es que debemos trabajar sobre la idea de minimizar los errores evitables. Afortunadamente, estos pueden ser afectados bastante fácilmente por el entrenamiento y un sólido liderazgo del laboratorio, esto no llevará a resultados de estudios microbiológicos menos variables.

El sistema de SOPs

La clave para un trabajo consistente en el laboratorio de microbiología es un sólido sistema de SOPs con una adecuada documentación.

La organización de un sistema lógico de SOPs puede dividirse de distintas maneras, por ejemplo de forma funcional, como sigue:

  • Requerimientos de calidad
  • Medios
  • Cepas
  • Equipamiento
  • Entrenamiento
  • Manejo de muestras
  • Operaciones del laboratorio
  • Metodología de testeos
  • Manejo, reporte y archivo de datos
  • Investigaciones

Aunque este no es la única forma, en la distintas regulaciones podrá encontrar otras formas, sin embargo disponer de un buen sistema de SOPs debe servir como guía para el cumplimiento normativo, ayudar en la investigación y ser útil como marco para la capacitación.

Al observar el sistema SOP desde una perspectiva funcional, podemos agrupar fácilmente los requisitos de medios, cepas de existencias, equipos y documentación para probar la actividad, lo que hace que la creación de “habilidades laborales” sea relativamente sencilla. Esto, a su vez, simplifica la asignación de SOP a personas en función de sus funciones laborales y simplifica el seguimiento de las personas afectadas por las revisiones de SOP.

La microbiología como disciplina es inherentemente variable (sensible a los efectos del operador), con una cultura empresarial que da como resultado el aumento de algunos aspectos de esta variabilidad (generalmente en un esfuerzo por minimizar los gastos generales y laborales). Es por eso, que un sistema de SOPs sólido y coherente junto con una capacitación y estricto seguimiento minimizará al menos la variabilidad evitable en los datos del laboratorio de testeos y de validación.

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.

Desde finales de los años 70, “Validación” es una de las palabras GMP más poderosas que pueden usar los reguladores y en los informes de inspectores o auditores. O, mucho más precisamente, las dos palabras “no validado” que provocan un caso de discusión largo y probablemente litigioso entre la industria y las agencias. ¿Por qué esto? Probablemente porque estar involucrado en la protección de la vida y la protección de la salud, nuestra industria no tiene el derecho ético de empeorar la situación de ningún paciente. Luego se considera un producto “validado” (es decir, un producto obtenido a través de un proceso validado) como la calidad mínima que la industria farmacéutica tiene para ofrecer. Las personas que usan productos farmacéuticos deben estar seguras de que se curarán o encontrarán alivio sin ningún efecto adverso derivado de los procesos de fabricación. Aquí, la validación se utiliza para demostrar que nuestra industria ha funcionado bien en la producción de productos efectivos y cualquier falla durante una validación puede realmente considerarse como un problema crítico. El nuevo paradigma de validación sobre la verificación en curso ahora es obligatorio para los nuevos productos y es más que alentador para los productos heredados (tradicionales) en ambos lados del Océano Atlántico por la FDA y la EMA. Sin embargo, dado que no todos los procesos pueden convertirse al nuevo enfoque QbD, la validación tradicional del proceso como se describe en la reciente guía de la EMA debería seguir siendo aceptable durante los próximos años o incluso décadas, y el dossier incluirá: “la descripción del proceso de fabricación, las pruebas que se realizarán y los criterios de aceptación, una descripción de los controles adicionales implementados y los datos que se recopilarán ”. Uno podría decir “como de costumbre” …

Guía de Buenas Prácticas de Validación de la ECA.

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.

La construcción de estos bloques nos permitirán atar el cumplimiento y la calidad al proceso de validación:

fly_ash_bricks_hollow_blocks_solid_blocks

  1. Conocer el proceso (es clave)
  2. Evaluar los riesgos de fabricación al producto
  3. Identificar los controles y las estrategias de control incorporados en el diseño
  4. Implementar los controles de riesgo de los aspectos críticos
  5. Efectuar la calificación / validación (documentación)
  6. Manejar el concepto de ciclo de vida, NO de evento
  7. Efectuar la revisión continua y la mejora en base a datos de calidad – escuchar la “voz del proceso”

Espero que les resulte útil.

Cualquier evaluación de integridad de datos dentro de una operación de laboratorio manual o electrónica debe basarse sobre un análisis de riesgo vs. las características detalladas en la tabla adjunta y utilizando el ciclo de vida de los datos (recolección, procesamiento, revisión y reporte de los datos).

imagen12_integridad-de-datos

Característica Definición
Atribuible ¿Quién adquirió los datos o realizó una acción y cuándo? Si un registro es modificado por quién y porqué.

Esto debería ser claro quien crea un registro y cuando. De todos modos, debería ser claro quien hace una enmienda en un registro, cuando y porqué.

Legible Los datos deben ser registrados de forma permanente en una forma duradera y fácil de leer.
Contemporáneo Los datos deben ser registrados al mismo tiempo que el trabajo es efectuado con marca de fecha y hora.

Esto significa que la evidencia o los resultados de los tests son registrados como son observados, de esta forma permite la reconstrucción de los eventos alrededor de los datos.

Original La información registrada deben ser datos originales (datos crudos) o una copia certificada del proceso.

Los datos NO deben ser transcritos de u a fuente a otra sin justificación y control certificado del proceso in place.

Exacto Sin errores o ediciones efectuadas sin enmiendas en los documentos.

La información registrada es correcta.

El análisis de riesgo es el proceso de identificar los peligros y los modos de falla y evaluar las consecuencias potenciales de esos peligros. Esto es críticamente dependiente de que la gente con el correcto conocimiento sea involucrada.

Los análisis de riesgos de calidad comienzan con una descripción bien definida del problema, una pregunta de riesgo o un análisis de un área de riesgo particular. En el caso de integridad de datos el proceso de laboratorio individual debe ser mapeado en detalle, comenzando por la preparación de la muestra, a través de los resultados de verificación / aprobación y finalizando con el archivo y recuperación de los datos.

Una vez que el proceso fue analizado para las áreas de riesgo crítico de integridad de datos, por ej. cuál es el riesgo y que impacto podría tener sobre la calidad del producto y la seguridad del paciente, entonces pueden ser asignadas etapas de mitigación.

El proceso de análisis debe seguir las siguientes preguntas (por ejemplo):

  • ¿Qué podría salir mal?
    • Datos han sido perdidos
    • Los sistemas fallan y no hay un plan de business continuity (continuidad del negocio) in place
    • Los datos no están siendo registrados
    • Los datos no están siendo verificados
    • El audit trail no está siendo revisado
    • El audit trail no está encendido
    • El entrenamiento y la concientización del instrumento es inadecuado
    • Los passwords están siendo compartidos
    • Los resultados no son atribuibles, etc.
  • ¿Cuál es la probabilidad de que esto salga mal?
  • ¿Cuáles son las consecuencias (severidad) para la calidad del producto o la seguridad del paciente?
  • La falla ¿Será detectada? ¿Cómo?

Hay muchas herramientas y técnicas que pueden ser usadas para ayudar a identificar peligros y /o modos de fallas y evaluar los riesgos. No hay una sola herramienta o técnica que cumpla con todos los requerimientos.

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.

  1. Hay una separación clara de responsabilidades y cooperación entre todo el personal relevante tal como propietario del proceso de negocios, propietario del sistema, una persona calificada de QA e IT?
  2. Hay un Análisis de riesgo documentado efectuado a lo largo del ciclo de vida del sistema computarizado, teniendo en cuenta la justificación para la validación, seguridad del paciente, integridad de datos y la calidad del producto?
  3. La documentación de validación incluye los registros de Controles de Cambios (si los hay) y los reportes sobre cualquier desvío observado durante el proceso de validación?
  4. Hay una URS para cada sistema, donde se describen las funciones esperadas por los usuarios y estas son trazables a lo largo del ciclo de vida de los documentos?
  5. Para la validación de SC customizados / categoría 5 GAMP5, hay un proceso “in place” para asegurar el análisis formal y el reporte de calidad y medidas de la performance para todas las etapas del ciclo de vida del SC?
  6. En el caso que sean transferidos datos a otro formato de datos o sistema. La validación incluye la verificación que los datos no han sido alterados en valor y/o significado durante el proceso de migración?
  7. En el caso que el SC intercambie datos electrónicamente con otros sistemas. Hay chequeos incorporados apropiados para verificar el correcto y seguro ingreso y proceso de los datos, de manera de minimizar los riesgos?
  8. En el caso que sean ingresados datos de forma manual. Hay una verificación adicional efectuada por una segunda persona o medio electrónico validado para asegurar la exactitud de los mismos? La criticidad y las consecuencias potenciales de potenciales errores o datos ingresados de forma incorrecta debería ser cubierta por la gestión de riesgo.
  9. Cómo es la seguridad de los datos frente al daño (tanto física como electrónica)? Los datos almacenados deberían ser chequeados para su accesibilidad, lectura y exactitud. El acceso a los datos debe ser asegurado a lo largo del período de retención.
  10. Es efectuado un back up de los datos de forma regular? La integridad y exactitud del back up de datos y la capacidad para recuperar datos debe ser verificada durante la validación y el monitoreo periódico.
  11. Es posible obtener copias impresas de datos almacenados electrónicamente de forma clara?
  12. Para registros que soportan la liberación del lote, es posible generar impresiones indicando si alguno de los datos ha sido cambiado desde la entrada original?
  13. Hay un “Audit Trail” diseñado dentro del sistema el cual registra todo cambio GMP relevante y las eliminaciones?
  14. Todos los cambios y eliminaciones de datos GMP relevantes son documentadas con una justificación?
  15. Los audit trails están disponibles y convertibles a un formulario comprensible?
  16. Los cambios a un SC son incluidos en un sistema de configuración hecho en una forma controlada de acuerdo a un procedimiento definido?
  17. Todos los SC son periódicamente evaluados para confirmar que ellos se mantienen en un estado validado y están en cumplimiento de las GMP? Las evaluaciones deberían incluir, si es apropiado, el rango actual de funcionalidad, el registro de los desvíos, incidentes, problemas, historial de las actualizaciones, performance, confiabilidad y reportes de estatus de validación.
  18. Hay controles físicos y lógicos, “In Place” para restringir el acceso a los SC a las personas autorizadas? Por ejemplo, uso de claves, tarjetas, código personal con contraseñas, biométricas, para restringir el acceso a áreas del equipamiento computarizado y almacenamiento de datos.
  19. Los sistemas de gestión de datos y documentos están diseñados para registrar la identidad de los operadores que ingresan, cambian, confirman o borran datos incluyendo la fecha y la hora?
  20. Cómo son reportados y evaluados los incidentes? La causa raíz del incidente debe ser identificada y debe ser la base de la acción correctiva (CAPA).
  21. Ha sido efectuada la evaluación de la parte 11 para los sistemas relevantes?
  22. Hay un procedimiento que confirma que la firma electrónica tiene el mismo impacto que las formas manuscritas dentro de los límites de la compañía?
  23. Las firmas electrónicas permanecen relacionadas a sus respectivos registros electrónicos?
  24. Cuando el sistema computarizado es usado para la certificación y liberación de lotes, el sistema permite solo personas calificadas para certificar la liberación de los lotes y claramente identificada y registra la persona que libera y certifica los lotes? Esto podría ser efectuado utilizando una firma electrónica.
  25. Los datos han sido chequeados para su accesibilidad, disponibilidad e integridad?

CSV

Si Ud. quiere mejorar tiene que hacer algo diferente.

A continuación le dejamos un cuestionario sobre 10 temas GMP:

Políticas y Procedimientos:

  1. Sus procedimientos son escritos por los usuarios y para los usuarios?
  2. Están disponibles en los lugares de trabajo?
  3. Sus políticas describen el por qué (visión general) y sus procedimientos el cómo (detalles)?
  4. Utiliza figuras, esquemas y flujogramas para darles más claridad?
  5. Tienen el nivel de detalle apropiado para el usuario?
  6. Ensaya los procedimientos claves antes de implementarlos?
  7. Revisa, corrige y mejora los procedimientos claves después de 6 meses de uso?

Educación:

  1. Hace foco en la educación (cambios de conducta) NO solo en cumplir con el entrenamiento?
  2. Tiene una estrategia de educación a 3-5 años?
  3. Dispone de un presupuesto para educación?
  4. Sus programas de educación están diseñados para satisfacer todos los estilos de aprendizaje?
  5. La mayoría de su educación ocurre en el lugar de trabajo, o sea fuera de la sala de capacitación?
  6. evita que el entrenamiento termine en la presentación?
  7. Hace foco en proveer el fundamento básico (el porqué)?
  8. El repaso de las GMP, se renueva anualmente?

Gestión de Riesgos de Calidad (GRC):

  1. Aplica la GRC para la priorización y la mejora continua y NO para apagar incendios, manejar las crisis o cuando las cosas salen mal?
  2. Acepta que no existe el riesgo cero?
  3. Los principios y las prácticas de la GRC son entendidas a todos los niveles (desde el Gerente de la Planta hasta los operadores de la misma)?
  4. Usa la GRC a lo largo del ciclo de vida del producto? Por ejemplo:
  • Para enfocar sus actividades de validación?
  • Para escalar los eventos de calidad?
  • Para optimizar sus recursos de auditorías?
  • Para clasificar los desvíos o reclamos de clientes?
  • Para optimizar el monitoreo ambiental?
  • Para proporcionar un marco para la toma de decisiones basado en el riesgo?
  1. Hay un excelente conocimiento de sus procesos y productos a lo largo de su empresa… sin el cual es imposible la GRC?
  2. NUNCA usa la GRC para justificar lo que sabe que es de baja calidad?

Manejo de desvíos y sistema CAPA:

  1. Tiene una cultura abierta, libre de culpables, donde las personas son alentadas a reportar los desvíos?
  2. Los incidentes son reportados inmediatamente, sin demoras?
  3. Efectúa una clasificación de los incidentes objetivamente dentro de 24 hs. Para priorizar los recursos y efectuar las investigaciones?
  4. Inicia sus investigaciones dentro de un día de trabajo hábil, como máximo?
  5. Investiga proporcionalmente al riesgo, en vez de tratar cada incidente de la misma forma?
  6. Las investigaciones son efectuadas donde ocurre el incidente, o son manejadas detrás de un escritorio?
  7. Las investigaciones son hechas por personas con conocimiento de los procesos y productos, o sólo por QA?
  8. Los CAPAs están focalizados en prevenir la re-ocurrencia en vez de ocuparse de los síntomas superficiales?
  9. Implementa CAPAs tan pronto como es posible, o cae en asignarle por regla 30 días?
  10. Cree que el error humano es la “consecuencia” y rara vez la “causa” de los desvíos?
  11. Lleva una tendencia de los eventos repetidos?
  12. Comparte incidentes y CAPAs a lo largo de la organización para fomentar la mejora continua?
  13. Arma una agenda para verificar la efectividad de cada CAPA para evaluar cuan exitosos han sido para prevenir la re-ocurrencia del desvío?

Métricas de Calidad y KPI (Indicadores Claves de Performance):

  1. Tiene métricas orientadas a la mejora de los procesos?
  2. Usa usted el enfoque de “Pareto”, centrándose en el 20% de las métricas que proporcionan el 80% del beneficio?
  3. Son sus métricas de “propiedad” de los usuarios? Las mismas se ven impulsadas hacia arriba, no de arriba hacia abajo?
  4. Los datos son compartidos con los usuarios y los grupos de interés para impulsar la mejora continua?

Auditorías internas y autoinspecciones:

  1. Su programa está basado en el riesgo?
  2. Tiene un proceso de escalada rápido y efectivo para las observaciones críticas y las tendencias negativas?
  3. Sus auditores están plenamente calificados, educados a partir de todas las áreas, no sólo de aseguramiento de calidad?
  4. Sus auditores ofrecen consejos prácticos y soluciones, no solo críticas?
  5. Las inspecciones son usadas para agregar valor, no solo por el bien de compliance?
    • Para ayudar a prevenir problemas
    • Para compartir las mejores prácticas en todas las áreas
    • Para expulsar a la complejidad, no crearla
  6. Hace una tendencia de los hallazgos de la auditoría para evaluar la imagen completa?
  7. Sus programas de auditorías internas y autoinspecciones aseguran que está listo para ser inspeccionado en todo momento?

Sistema de control de cambios:

  1. Su sistema de control de cambios ha sido diseñado con la participación activa de todas las partes interesadas y no solo QA?
  2. Su sistema de control de cambios es simple y entendible para todos?
  3. El control de los cambios es considerado vital para la mejora del negocio y la gestión de los riesgos o solo se lo considera por un tema de cumplimiento de las regulaciones?
  4. El sistema tiene un requerimiento del cambio el cual es revisado y aprobado en hs o días, no meses?
  5. Su sistema de control de cambios utiliza una evaluación de impacto basada en los riesgos como soporte para la aprobación o el rechazo de las solicitudes de cambios?
  6. Efectúa el seguimiento de todos los cambios aprobados para asegurarse que los mismos fueron efectivos?

Validación:

  1. Sus actividades de validación están bajo un Plan?
  2. Dispone de los recursos necesarios para el cumplimiento de las actividades de validación?
  3. Realmente entiende la variabilidad el proceso?
  4. Cada uno entiende o conoce los puntos críticos de control del proceso?
  5. Cada uno entiende los atributos claves del producto, aquellos que impactan en la seguridad del paciente?
  6. Sus métricas confirman un proceso bajo control? “Cero” retrabajos y/o reprocesos, 100% correcto a la primera vez?

Integridad de datos:

  1. Todo su personal entiende que una pobre integridad de los datos, genera pérdida de confianza regulatoria?
  2. Tiene back up y archivo de sus datos?
  3. Rutinariamente revisa y comprueba la integridad de los datos?
  4. Rutinariamente desafía todas las transacciones (audit trail)?
  5. Tiene validados sus sistemas de gestión de datos?

Su Cultura de Calidad:

  1. Qué hace la gente cuando nadie la observa?
  2. QA está integrado a la planta?
  3. Los supervisores dedican más tiempo a la planta que a las reuniones?
  4. Cada uno tiene objetivos personales de performance de calidad?
  5. Sus líderes predican con el ejemplo y demuestran las conductas de calidad correctas?
  6. La gente habla sobre Calidad, no solo sobre resultados?
  7. Desarrolla, recompensa y retiene los conocimientos en lugar de permitir que dejen la organización cada vez que vean algo mejor?
  8. Trata a sus proveedores como una extensión de su línea de producción?
  9. Selecciona a sus proveedores en base a calidad, no en base a precio?
  10. Cada uno se siente conectado al paciente?
  11. Regularmente compara sus estándares con los del mejor en su categoría?

Si alguna de las respuestas no fue del todo satisfactoria, Ud. ha detectado una oportunidad de mejora sobre alguno de los 10 temas, asegúrese tener un plan de acciones de remediación.

Desde cGMPdoc podemos darle soporte en entrenamientos, implementación o actualización de procesos, auditorías, evaluación de sus proveedores, consulte en info@cgmpdoc.com

 

 

 

 

Un sistema computarizado es un software, con su hardware, la gente y los procedimientos.

El resultado de la validación del sistema computarizado, como solemos decir, es la evidencia documentada. Las regulaciones requieren que los sistema computarizados sean validados, a pesar de que definen varios niveles.

La validación de los sistemas computarizados aplica a lo largo del proceso de implementación del proyecto, la operación y el decomiso del mismo.

Vmodel

Disponer de procedimientos y modelos o templates de validación, así como una organización dirigida a validar los sistemas computarizados, son las herramientas claves para estar en cumplimiento.

A este esquema solo quiero agregarles el concepto de ciclo de vida basado en el riesgo:

El enfoque de los ´90 era que independientemente del riesgo que representara cada sistema, los esfuerzos de validación eran idénticos.  El ciclo de vida basado en el riesgo, nos lleva a orientar los esfuerzos principalmente en los sistemas que representan algo riesgo y luego los de medio y bajo riesgo.

Esto no representa reducir pasos del modelo en V (Vmodel), SI hacer foco en los sistemas de alto riesgo principalmente.

Espero que les resulte interesante.