Posts tagged ‘QA’

El objetivo de la Revisión de Batch Record (BRR) no es simplemente identificar excepciones (errores, olvidos, entradas ilegibles, etc.), tener el registro corregido oportunamente provee una documentación exacta de las etapas que comprenden la manufactura o el empaque del lote en cuestión.

El BR puede ser requerido semanas, meses o incluso años después, para buscar información. Además puede ser solicitado por parte de la agencia, por lo tanto necesitan ser corregidos y ser claros antes de ser archivados.

Si bien la importancia de la Revisión de BR es indiscutible, hay desafíos logísticos en el proceso de corrección. Esto surge desde la necesidad de controlar la BRR y la disponibilidad del personal requerido para hacer las correcciones. Idealmente, todos los errores ingresados deben ser identificados en el departamento revisor antes que el BR vuelva a Aseguramiento de Calidad (QA) para la revisión de calidad.

La revisión debe ser para identificar cualquier información faltante y que las entradas sean correctas y están dentro de los parámetros establecidos.

documentin

Asumiendo sin embargo, que hay una pregunta o corrección requerida a nivel de la revisión de QA, la persona que hizo la entrada original (o falla al hacer la entrada) sobre el BR, cumple con el revisor que identificó la excepción. Esta pregunta o corrección requerida será asentada en el BR para permitir cualquier persona subsecuente entienda el problema.

Cuando una corrección inmediata nos es posible debido a un tema de turno, persona de vacaciones, licencia, etc. entonces el revisor debe informar al supervisor o jefe de la situación para la resolución de la misma.

Hay ocasiones donde falta información vital, la cual no puede ser corroborada a través de registros electrónicos u otros registros. El revisor entonces tiene la responsabilidad de informar esto a quienes son responsables del desvío y la investigación interna. Esta etapa debe ser anotada o remarcada en el BR (debe ser indicada una referencia a la investigación). La terminación de la revisión del BR se demorará hasta que la investigación sea completada y la disposición de la desviación es determinada. La revisión debería ser completada y firmada aún si el batch será retrabajado (si está permitido) o destruido. El BR y el check list y la planilla de correcciones, debe entonces ser enviada al área de QA y el estatus de revisión actualizado en el log o base de datos.

Revisión periódica de los BR revisados

De acuerdo a nuestra experiencia, es de mucha utilidad efectuar una revisión periódica por medio de la supervisión o jefatura o gerencia, dentro de la unidad de calidad para determinar que se está alcanzando la consistencia deseada en el proceso de revisión. Una revisión de las planillas de corrección provenientes de varios revisores proveerá una perspectiva útil sobre el número de excepciones citadas y / o correcciones requeridas, los tipos de excepciones citadas o las correcciones procuradas, y una comparación de los hallazgos de los distintos revisores. La tendencia de los resultados de producción es una herramienta muy útil para detectar desvíos en el proceso de manufactura y a partir de ellos identificar etapas de corrección para ser tomadas. Si el número de correcciones es elevado, entonces uno debe cuestionarse si el personal de manufactura y los revisores de los BR tienen el mismo conocimiento o entendimiento de que constituye una documentación de BR exacta y suficientemente completa. Si existe un desentendimiento, tal vez el entrenamiento inicial para el personal de manufactura, personal calificado, o ambos no fue lo suficientemente detallado, o el lenguaje del BR es ambiguo y debido a esto, puede ser malinterpretado. El objetivo es asegurar que el personal de manufactura y los revisores están trabajando hacia el mismo objetivo de buena documentación.

Desde una perspectiva ligeramente diferente, si el tipo de excepciones o correcciones requeridas es alto para un BR particular, entonces el lenguaje de dicho MBR debería ser cuidadosamente examinado. Si el lenguaje aparentemente es claro, entonces la documentación en cuestión debería ser revisada con el personal de manufactura. La variación es observada principalmente en un turno? Es requerido un entrenamiento adicional? Si el lenguaje es ambiguo, tal vez la próxima etapa es siguiendo los lineamientos del SOP de control de cambios modificar el BR y luego reentrenar el personal.

Finalmente, hay una discrepancia entre los revisores individuales sobre el número y los tipos de excepciones o correcciones observadas? Esta determinación puede llevar a una discusión muy útil y de fina sintonía para hacer el proceso de revisión más consistente entre los revisores.

A continuación les voy a describir 3 situaciones de inconsistencias en el proceso de revisión, las cuales pueden ser detectadas por medio del proceso de análisis periódico y corregido por medio de la intervención de los supervisores.

  • Conveniencia vs exactitud

Si alguna vez han revisado BR, saben que es una tarea tediosa, repetitiva, y demandante. Las etapas requeridas para obtener correcciones de documentos requiere tiempo adicional y seguimiento, un revisor puede caer en el hábito de minimizar el número de correcciones requeridas de un documento como una forma de cerrarlos más rápidamente. Esta es una peligrosa tendencia porque los atajos tienden a convertirse en hábitos, y la inconsistencia introducida por medio de la no revisión de todas las partes del BR puede llevar a dos situaciones indeseables: primero, la exactitud del registro y la información que provee se convierte en sospechosa y segundo, el personal de manufactura se priva de la oportunidad de aprender de los errores o equivocaciones que podría conducir a mejoras.

  • Desvío no intencional

Aquí un revisor bien entrenado y experimentado ha revisado muchos BRs que tienen desvíos no intencionales respecto del estándar interno. Mientras el revisor tiene acceso al SOP y al check list para la revisión de los BRs, esos documentos de guía no son para él necesarios, a pesar que el check list es firmado. El proceso de revisión ha tomado una actividad robótica durante la cual el proceso mental no está completamente comprometido, pudiendo haber ausencia de datos o ingresos de datos incorrectos.  Esta inconsistencia puede emerger cuando auditorias periódicas de las revisiones conducidas por varios revisores muestran muy diferentes hallazgos.

  • Exageración (exceso)

Mientras la falta de plena atención en el proceso de revisión es una fuente de inconsistencia, así también es una inconsistencia el revisor que va mucho más allá del estándar interno. En este escenario, el revisor insiste en que cada detalle, incluso lo que no tiene impacto, sea corregido de acuerdo a su estándar. Esto puede incluso incluir desafíos a la gramática o la ortografía de aquellos que han escrito un comentario satisfactorio o que han corregido en el BR. Algunos revisores pueden indicar algo como: “si Ud. Quiere que yo firma este registro, el mismo debe estar completamente correcto” o “No estoy completamente conforme con este registro”.

Esto no solo consume mas esfuerzos adicionales del personal de manufactura, sino también envía un  mensaje desafortunado para aquellos que hacen el producto. La aceptabilidad de un registro aparentemente depende más sobre quien revisa el BR que sobre como el mismo fue completado.

Cualquier inconsistencia en el proceso de revisión de BR desafía la reputación de la unidad de calidad y su gestión, porque demuestra una falta de la vigilancia adecuada de su equipo. La vigilancia es uno de los roles claves de la unidad de calidad en las organizaciones. La gestión de la unidad de calidad asegura que su personal además cumple consistentemente con los estándares establecidos.

Los tipos de controles y los registros y reportes que soportan la manufactura de productos terminados están bien definidos ambos en términos de requerimientos regulatorios y en la práctica de la industria. La revisión adecuada de los BR ejecutados sirve al menos para dos propósitos importantes. El proceso satisface los requerimientos regulatorios y el proceso provee feedback útil para el grupo funcional responsable de manufactura.

Como indicamos, una alta tasa de error puede indicar inadecuado entrenamiento o supervisión pobre, pero además podría indicar un procedimiento escrito pobre. Apropiados revisores y aprobadores de BRs entrenados proveen un valor de servicio de la unidad de QA a la organización de manufactura. Su entrenamiento debe incluir un objetivo de consistencia en el proceso de revisión en adición a la exactitud y minuciosidad, esto puede ser mejor determinado por medio de la revisión periódica de los hallazgos de los revisores.

Espero que les resulte útil.

La revisión de los BRs de producción junto con la tendencia de los rendimientos y los desvíos son partes claves del proceso de QA para la elaboración de productos.

La revisión de BRs es típicamente una etapa de verificación que confirma la aceptabilidad del proceso de elaboración y empaque del producto. Si, de la revisión surge un desvío, el laboratorio gana información de valor desde la investigación que puede llevar a un CAPA y a la mejora del proceso.

Estas situaciones pueden ser detectadas antes que el rendimiento u otro parámetro exceda los límites de alerta o acción.

Debido a que es un proceso muy común, esta importancia puede ser pasada por alto más allá de los requerimientos regulatorios de las cGMP. Sin embargo la importancia de los registros está relacionada con el respaldo de la elaboración de los productos terminados.

Los requerimientos claves para el registro de la producción y control son encontrados en la subparte J del 21 CFR parte 211, la cual es una de las secciones más largas de la regulación cGMP de la FDA.

Logo_elearning

Hay un requerimiento cGMP para la confección de Master BR (21 CFR 211.186) identificando las etapas de elaboración / empaque de los productos. El MBR es usualmente la culminación de la transferencia tecnológica, scale up, lotes de validación, y la verificación de las etapas de manufactura alineadas con los requerimientos regulatorios.

El Batch Record, también llamado Batch Production Record o registro de producción del lote, es un documento que confirma el procedimiento paso a paso que los operadores o técnicos deben seguir para elaborar el producto.

Según el 21 CFR 211.188 “Un registro de producción y control de la producción del lote debe ser preparado para cada lote de producto producido y debe incluir información completa relacionada a la producción y control de cada lote”.

Cada BR es un documento controlado desde que es emitido hasta que puede ser eventualmente destruido.

Contiene la misma información que el master BR porque es una reproducción exacta del mismo que ha sido chequeado para su exactitud, fechado y firmado.

El registro del lote será ejecutado por varios operadores para documentar que cada etapa significativa en la manufactura, proceso, empaque o holding del lote fue cumplido.

Esto incluye entre otras cosas, lo siguiente:

  • Fechas; cualquier firma además requiere tiempos
  • Identidad de equipos individuales mayores y líneas utilizadas
  • Identificación específica del lote de componente o material en proceso usado
  • Pesos y mediciones de componentes usados durante el proceso
  • Resultados de los controles en proceso y del laboratorio
  • Inspección del área de elaboración / empaque / rotulado antes de su uso
  • Una declaración del rendimiento actual y una declaración del porcentaje de rendimiento teórico para cada fase apropiada del proceso
  • Registros de control de rotulados completos, incluyendo muestras o copias de todos los rótulos usados
  • Descripción de los contenedores de producto y sus cierres / precintos
  • Todo muestreo efectuado
  • La identificación de las personas que efectuaron y supervisaron directamente o chequearon cada etapa significativa en la operación
  • Cualquier investigación efectuada de acuerdo al 211.192
  • Los resultados de las examinaciones hechas de acuerdo con el 211.134

Es destacado enfatizar que el “control” es el corazón de las cGMP y este control extiende a cada etapa crítica en el proceso de manufactura y empaque.

El BR para cada lote es una extensión de este control porque no es suficiente para liberar un producto para la venta hacerlo solo a partir de los resultados analíticos. Los datos de laboratorio deben confirmar los resultados esperados del proceso.

Cada lote ha sido elaborado con controles en proceso. El BR provee una documentación etapa por etapa de esos controles de la manufactura.

El BR completo se convierte en la verificación que todas las etapas críticas fueron efectuadas como estaban descriptas y cuando se combina con los resultados del laboratorio, la firma elaboradora tiene la documentación adecuada para efectuar la disposición del lote.

No nos olvidemos que en paralelo a estos requerimientos de las cGMP tenemos los de las BP de documentación.

Fundamentos del proceso de revisión:

Una vez que el proceso de empaque ha sido completado y que los registros han sido devueltos a la unidad de calidad quien registra tales documentos, el paso siguiente es la revisión de los BR para exactitud y conformidad de los estándares establecidos en los documentos.

Es recomendable, es más diría que hoy es un requerimiento, que sea efectuada una revisión del BR de manufactura o empaque por parte del equipo de manufactura o personal de empaque antes de regresar el registro del lote al departamento de QA.

El requerimiento regulatorio para BRR es hallado en el 21 CFR 211.192 y declara: “todo registro de producción y control de producto, incluyendo aquellos de empaque y rotulado, deben ser revisados y aprobados por la unidad de control de calidad para determinar su cumplimiento con todo lo establecido, aprobado en procedimientos escritos antes que el lote sea liberado o distribuido. Cualquier discrepancia no explicada (incluyendo un porcentaje de rendimiento teórico que excede el máximo o mínimo establecido en el Maestro de producción y los registros de control) o la falla de un lote o cualquiera de sus componentes para cumplir con cualquiera de sus especificaciones debería ser exhaustivamente investigada, haya sido o no distribuido el lote. La investigación debe ser extendida a otros lotes del mismo producto e incluso a otros productos que hayan podido ser afectados por la falla o discrepancia. Un registro escrito de la investigación debe ser efectuado y debe incluir conclusiones y seguimiento”.

Cada BR es típicamente específico para el producto y potencia del producto porque contiene las cantidades de API y excipientes requeridos. En el caso de comprimidos el Br puede indicar por medio de imagen o foto, o un dibujo, la descripción del tamaño, forma, color y cualquier estampado en relieve sobre el comprimido. Si el comprimido es recubierto, las letras sobre el comprimido y el color puede ser registrado.

En el caso de líquidos orales, pueden ser descriptos su color y aroma. Estos detalles pueden ser parte del MBR.

Así como la elaboración de productos es guiada por procedimientos y por los BR, la revisión del BR debe ser manejada a través de un SOP. A pesar que la revisión del BR puede ser menos complicada que la elaboración y empaque de productos, un SOP debería hacer que el proceso sea más consistente y disponer además de un check list para la revisión asegurará que las etapas y parámetros críticos sean revisados.

En un segundo artículo hablaremos sobre el SOP de BRR (revisión de BR) y su check list, correcciones de BR y algunas inconsistencias en la revisión de BRs.

El proceso de Análisis de riesgos conducido como parte del ciclo de vida de validación de sistemas computarizados, nos permite poner el énfasis y la atención apropiada en aquellas partes del sistema que pueden tener potencial impacto sobre la seguridad al paciente, la calidad del producto y la integridad de datos.

mitigarriesgo1

Es recomendable conformar un equipo para el manejo de la validación de los sistemas computarizados inicialmente, y para el posterior manejo de los cambios que pudiera tener el sistema durante su uso productivo. Este equipo debe tener como mínimo de los siguientes roles:

  • Propietario del sistema (inicialmente este role puede ser llevado a cabo por el manager del proyecto)
  • Propietario de procesos del negocio
  • Proveedor (o representante técnico)
  • Representante de IT (con formación en Compliance)
  • Representante de Quality Assurance

Los principios de evaluación y gestión de riesgos son aplicados desde que se introduce un sistema informático a la planta, y además durante el control de cambios, la revisión periódica y el decomiso del mismo.

Como parte de la implementación inicial del sistema computarizado, se evalúan los riesgos del proyecto, por ejemplo: restricciones de recursos, falta de conocimiento técnico, financiación, estabilidad del proveedor, etc. Estos riesgos del proyecto pueden ser manejados por el Propietario de procesos del negocio o Project Manager.

Registro del sistema y determinación del impacto regulatorio

Se trata de la primera etapa de análisis de riesgos del sistema, donde se efectúa una evaluación regulatoria (por ej. si el sistema tiene impacto GxP), o es crítico para el negocio, SOx, Finanzas, Privacidad de datos, eDiscovery. Luego de esta evaluación, se toma y se registra la decisión sobre si el sistema será validado.

Clasificación de riesgo del sistema

Si un sistema computarizado debe validarse entonces debe llevarse a cabo una clasificación de riesgo del sistema para ayudar a determinar el nivel y el alcance de las actividades de validación requeridas. Los resultados de la clasificación de riesgos deben ser registrados.

La clasificación de riesgos del sistema asigna un score que puede ser Alto, Medio o Bajo basado en:

  • El status GxP del sistema
  • El status de evaluación del proveedor (Rojo, Amarillo o Verde)
  • La categoría GAMP5 del sistema
  • Si el sistema almacena registros GxP
  • Si el sistema tiene una red de conectividad.

Estos factores son registrados en el sistema de registro.

Esta clasificación de riesgo pretende reflejar el potencial nivel de riesgo que el sistema tiene para el proceso de negocio, por ej. Si el sistema fue desarrollado a medida, de acuerdo a las GAMP es categoría 5, o el proveedor tiene un sistema de gestión de calidad que NO es lo suficientemente maduro, la clasificación de riesgo del sistema establecida será mayor para asegurar que se aplican controles más exhaustivos durante el ejercicio de validación del sistema.

Para cada sistema, los entregables requeridos son descriptos en el Plan de Validación del sistema computarizado. El nivel de las actividades de validación dependerá de la clasificación del sistema, bajo, medio o alto, el paquete de testeos y su ejecución podría ser efectuado por el proveedor en el caso de un sistema de bajo riesgo, aunque en el caso de un sistema de alto riesgo, el paquete suele ser desarrollado en conjunto (proveedor + laboratorio) y la ejecución puede ser efectuada por el proveedor con la aprobación final del laboratorio o efectuada por el laboratorio.

Análisis de riesgo funcional

Si es requerido, un análisis de riesgo funcional es llevado a cabo. Esto se puede hacer a un nivel alto y / o un nivel funcional. El factor clave para llevar a cabo una evaluación de riesgos funcional es en los casos donde los escenarios de riesgo y la probabilidad y controles de mitigación no pueden determinarse sólo por hacer una evaluación de alto nivel y donde se requiere más detalle. Evaluación del riesgo sólo puede llevarse a cabo una vez que el diseño del sistema se ha acordado y aprobado. Los sistemas de bajo riesgo no necesitan someterse a una Evaluación de Riesgos. Los sistemas clasificados como de medio y alto riesgo deben someterse a una evaluación de riesgos en un nivel alto como mínimo. Una evaluación de riesgo alto nivel considera requisitos en grupos.

  • La primera etapa es para clasificar los requerimientos. Dentro del URS, para cada requerimiento:
    • Establecer el impacto GxP
    • Establecer la criticidad para el negocio
    • Establecer cualquier otra área sujeta a regulación, ej. SOx, Financiera, Privacidad de datos, eDiscovery.
  • La segunda etapa implica la realización del análisis de riesgo para cada requerimiento

El foco de la evaluación está en la interacción del sistema con el proceso de negocio.

El análisis de riesgo debe considerar, para cada requerimiento:

  • Qué podría salir mal (modos de fallas);
  • Probabilidad
  • Impacto
  • Detectabilidad

Luego se lleva adelante un sistema de score de riesgos basados en la probabilidad de ocurrencia, el impacto o severidad del evento y la detectabilidad del mismo (según el enfoque de la GAMP5), el foco debe estar en aquellos ítems donde la clasificación final del riesgo del sistema es medio o alto.

A modo de ejemplo podemos utilizar los siguientes valores:

Probabilidad (1-3)

Severidad (1-3)

Detectabilidad (1-5)

De acuerdo a estos valores, el score mínimo es 1 y el máximo a obtener es 45 y podemos valorar los riesgos de la siguiente manera:

Bajo riesgo (1-4)

Riesgo medio (5-10)

Alto riesgo (>10)

  • La tercera etapa en el proceso es para identificar los controles de mitigación para cada requerimiento. Los controles incluyen testeos técnicos y de negocios, SOPs, requerimientos de entrenamiento, etc.
  • El reporte de la Evaluación de Riesgos funcional, puede ser elaborado utilizando un modelo o template adecuado, y el mismo debe ser aprobado por QA.

Hace tiempo incluimos un Check de verificación del estatus de CSV (Validación de sistemas computarizados) y parte 11 (Firmas y registros electrónicos), acá les dejo el link.

Este check que estamos incluyendo en este artículo intenta ser una guía para auditar el cumplimiento de CSV en el laboratorio (o en su proveedor). Esperamos que le sirva de ayuda.

auditoria_3

  1. Desarrollo del Sistema
    • Proveedores
  • Verificar si hay un método para aceptar el producto, incluyendo los requerimientos técnicos y de calidad del producto.
  • Verificar como los requerimientos técnicos y de calidad son considerados por el proveedor y/o sub contratado. ¿Hay un proceso definido? ¿El mismo es cumplido?
  • En el caso de sub contratar actividades, verificar la experiencia y calificación del mismo (por ej. verificar entrenamientos o certificaciones).
  • Si la evaluación del proveedor involucró una auditoria, verificar el estatus de los hallazgos.
  • ¿Dispone de un procedimiento para la evaluación de proveedores?, ¿dicho procedimiento es seguido?
  • Si el Sistema es provisto por un proveedor, verificar si el mismo ha sido evaluado.
  • Verificar si el Sistema fue elaborado “In House” o desarrollado por un proveedor.
    • Requerimientos
  • Verificar que todos los requerimientos GMP del proceso, incluyendo la parte 11 (firmas y registros electrónicos) han sido incluidos.
  • Verificar que los requerimientos son revisados y aprobados por los departamentos apropiados, incluyendo como mínimo responsable del proceso de negocios y al responsable de QA.
    • Diseño y codificación
  • Verificar que existe un documento de diseño cubriendo todos los requerimientos del usuario y la trazabilidad entre los requerimientos y los elementos del diseño.
  • Verificar que la especificación de diseño es revisada y aprobada por los departamentos apropiados.
  • Confirmar que la especificación de diseño fue aprobada antes de que el codificado comience.
  • Confirmar que existe un estándar de codificado (por ej. Java, etc.). En caso de no haberlo, debe haber una justificación adecuada.
  • Verificar que la revision de código fue efectuada.
  • Determinar si todo el código es revisado o si es revisado una muestra, en éste ultimo caso, determinar como fue seleccionada la muestra.
  • Confirmar que los revisores de código son independientes y están adecuadamente calificados.
  • Confirmar que los defectos encontrados durante la revisión son corregidos y las acciones correctivas tomadas para evitar su re ocurrencia.
    • Testeo
  • Revisar la documentación de testeo asociada con el Sistema a auditar.
  • Verificar que existe una estrategia de testeo explicando los testeos efectuados en cada etapa de desarrollo (ej. Testeos de módulo, testeo de integración, testeos de interface) y testeos de aceptación.
  • Confirmar a través del proceso de testeo que los requerimientos funcionales críticos han sido testeados.
  • Verificar que los testeos cubren condiciones límites, fallas y estrés, así como pruebas diseñadas para confirmar que el sistema funciona como se espera. Además, que incluye el control de seguridad de accesos lógicos.
  • Verificar que los testeos sean efectuados por personal independiente y calificado (el desarrollador y el autor de los ensayos).
  • Confirmar que los scripts de testeo están escritos, y que los mismos contienen claramente los criterios de aceptación.
  • Verificar que los resultados de los ensayos han sido documentados y se dispone de la evidencia adecuada. Donde hay desvíos los mismos son documentados.
  • Verificar que el test que falló ha sido evaluado respecto de la criticidad del requerimiento funcional.
  • Verificar que cuando un test ha fallado la funcionalidad requerida no es crítica para el proceso ni para el cumplimiento GMP. Confirmar que existe una solución de procedimiento adecuada.
  • Si es utilizada una herramienta automatizada para los testeos, verificar que la misma ha sido calificada para asegurar que funciona correctamente, que hay procedimientos para su uso, que las firmas de las aprobación de los scripts de testeos son registradas y que los cambios a la herramienta o scripts electrónicos son controlados y aprobados.
    • Entregables de Validación
  • Verificar que hay un conjunto de documentos de validación consistente con una clara relación de los mismos a los requerimientos.
  • Verificar que los entregables de validación son declarados en el plan de validación, han sido completados y están resumidos en el reporte de validación.
  • Verificar que las excepciones (si aplica) del reporte de validación han sido registradas como acciones para su seguimiento.
    • Liberación
  • Revisar como es liberado el Sistema para el uso.
  • Verificar los controles y chequeos utilizados para asegurar que todas las actividades fueron completadas.
  • Verificar que los roles y responsabilidades para la liberación están claras y se han cumplido.
  • Verificar que todos los entregables requeridos fueron parte del paquete de liberación, por ej. un código de construcción del Sistema, certificado de liberación, manuales de uso, material de entrenamiento.
  1. Gestión del sistema
    • General
  • Establecer como es provisto el soporte al Sistema, confirmar que los roles y responsabilidades del hepdesk, de los administradores y soporte técnico están claramente definidas. Asegurar que el entrenamiento adecuado para cada rol fue suministrado.
  • Verificar que el Sistema tiene un propietario que lo maneja con suficiente autoridad y con un presupuesto para su mantenimiento.
    • Manejo de problemas
  • Confirmar que hay un procedimiento vigente para el reporte de problemas, con registro, investigación y resolución de los mismos.
  • Verificar que las acciones correctivas y preventivas son implementadas.
  • Verificar que hay una relación entre el reporte de incidentes y la gestión de cambios para el Sistema.
    • Gestión de cambio
  • Asegurar que los procedimientos para iniciar, autorizar y documentar los cambios del Sistema están vigentes.
  • Confirmar que los cambios son evaluados para asegurar que el impacto sobre las funcionalidades relacionadas es entendido.
  • Asegurar que la gestión de los cambios incluye la actualización de la documentación del Sistema, instrucciones de uso, entrenamiento, datos maestros como la funcionalidad técnica.
  • Asegurar que los testeos hechos como soporte de los cambios del Sistema confirman que las funciones relacionadas no son adversamente afectadas y además aseguran que los cambios requeridos son alcanzados.
    • Accesos y seguridad
  • Revisar que las medidas de seguridad físicas están definidas para el Sistema y están en uso efectivo. Verificar como son controlados los accesos físicos al hardware.
  • Revisar que las medidas de seguridad del software están definidas para el Sistema. Verificar como son controlados los accesos a las funcionalidades críticas son restringidas a los usuarios apropiados. Verificar que donde la capacidad de enmendar datos maestros ha sido restringida.
  • Verificar la existencia de un procedimiento para otorgar y remover los accesos al Sistema de los usuarios. Verificar que los accesos son revisados periódicamente para asegurar que solo tengan acceso al Sistema los usuarios requeridos.
  • Asegurar que los ambientes de desarrollo, de testeo y productivo son rutinariamente revisados en búsqueda de virus.
  • Determinar si los elementos del Sistema tales como Sistema operativo, base de datos y aplicaciones del software son mantenidos con los últimos parches de seguridad disponibles.
    • Datos maestros
  • Asegurar que existe un proceso para el mantenimiento de los datos maestros requeridos por el Sistema.
  • Confirmar que los roles y responsabilidades están claras respecto a la gestión y aprobación de datos maestros.
  • Verificar si los datos maestros son chequeados periódicamente para verificar su exactitud.
    • Planeamiento de Business Continuity /Disaster Recovery (incluyendo back up y recuperación)
  • Verificar que el Sistema tiene un plan de continuidad del negocio (BC), y que el mismo tiene en cuenta la criticidad del sistema.
  • Verificar que el Sistema tiene un plan de disaster recovery (DR), y que el mismo tiene en cuenta la criticidad del sistema.
  • Verificar que existe un régimen de back up y recuperación para el Sistema y que el mismo está documentado, mantenido y testeado. Verificar si el mismo tiene en cuenta la criticidad del Sistema.
  1. Revisión periódica
  • Verificar que el Sistema es sujeto a revisiones periódicas para determinar que actividades tienen que ser efectuadas para mantener el estado validado.
  • Confirmar que los resultados de la revisión son registrados y cualquier acción es seguida hasta que se complete.

Les dejo 13 preguntas para autoevaluarse respecto de 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? Siempre?
  7. Las investigaciones son hechas por personas con “know how” 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, en vez de aplicar la “infundada regla de los 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?

Si alguna de las respuestas no fue del todo satisfactoria, Ud. ha detectado una oportunidad de mejora sobre el manejo de los desvíos y sistema CAPA, asegúrese tener un plan de acciones de remediación, también desde cGMPdoc podemos proponerle una solución o le dejamos a mano la posibilidad de un taller “In Company” teórico-práctico:

 in-company-capa-final

 

 

¿Cómo conducir una revisión anual de productos efectiva?

Antes de comenzar quiero volver sobre una idea mencionada anteriormente y que supongo la habrán escuchado muchas veces y en distintos lugares: el APR es más que un requerimiento regulatorio, es una revisión que le permite al elaborador entender más su proceso y tomar acciones de mejora.

Las cGMP necesitan una evaluación anual de los estándares de calidad de los productos para determinar la necesidad de ajustar sus especificaciones y los procedimientos de elaboración y de control.

Las guidelines acentúan la importancia del análisis de las investigaciones o desvíos conducidos y los reclamos de productos recibidos, mientras el reporte de APR debe explorar, en profundidad, las causas de recalls y de devoluciones de productos, si las hubiera.

De manera general, el mandato de las Agencias regulatorias (por ej. FDA) es mirar a través y sistemáticamente por todas las áreas de mejora y alinear los procesos consistentemente a la elaboración de productos de calidad.

Por estas mismas razones generales, las GMP requieren a los elaboradores analizar previa revisión, examinar los resultados del análisis de productos terminados y los controles en procesos críticos y revisar: lotes fallidos, desvíos, CAPAs, controles de cambio, estudios de estabilidad, devoluciones, reclamos, calificaciones en equipos críticos y acuerdos de calidad.

Los CAPAs de la revisión anual de productos necesitan ser comunicados al Senior Management y completados de manera efectiva y a tiempo, su efectividad debe ser chequeada por medio de las auditorías internas.

Estructura de un informe de APR:

Puede variar según la compañía, o incluso el producto. La idea de seguir un template o modelo asegura que todos los aspectos requeridos son evaluados.

Pero un APR es un documento que evoluciona.

Estructura de informe de APR: http://wp.me/p1Hn5Y-fs

Cambios y correcciones

La Revisión de los cambios puede ser desglosada en: cambios de materia prima, en los componentes de empaque, en especificaciones y documentos maestros. La sección de no conformidades y desvíos necesita ser revisada sobretodo considerando las acciones correctivas y su efectividad. Cualquier CAPA vencido o inefectivo necesita ser discutido en el informe. Este es uno de los aspectos fundamentales.

Cualquier tendencia observada necesita ser direccionada, no solo las que son OOS.

Racionalización de los datos de origen y administración del APR

Compilar los datos crudos es siempre un esfuerzo de equipo, pero el departamento de QA debe tomar el liderazgo y ser el último responsable de la administración del programa.

Un comité de APR podría típicamente incluir un representante de QA, QC, validaciones, operaciones, estabilidad, ingeniería, y logística. Un borrador de informe es completado sobre el análisis crítico de los datos crudos, luego se discute en una reunión del comité de APR para determinar los CAPAs efectivos.

Otro desafío para el administrador de APR es la recuperación de datos para el propósito de la revisión.

Las empresas con sistemas de adquisición de datos calificados pueden usar sus bases de datos, mientras los elaboradores que se manejan con papeles pueden tener que revisar los documentos de lote en forma individual para ver los parámetros del proceso, los controles en proceso, los análisis finales, los rendimientos, etc. En cualquiera de las dos formas, los datos crudos usados para el análisis deben ser exactos de manera de completar una análisis/evaluación efectivo. Si son observadas desviaciones del proceso durante la revisión, puede ser requerido colectar información adicional para justificar dichos hallazgos.

Los datos deben estar disponibles para el administrador del APR en el momento oportuno. Todos ellos deben ser verificados por una segunda persona si son colectados manualmente.

Si son utilizadas planillas de cálculo, las mismas deben estar validadas previo a su uso.

Conclusiones

Efectuar un APR es un requerimiento para los mercados regulados. Pero más que eso, la revisión ayuda al elaborador a entender y conocer mejor sus procesos y para reunir información adicional para posteriores mejoras.

Es una enorme ayuda en la determinación si un producto aún cumple las especificaciones, si necesita un cambio de formulación, modificación del empaque, una revisión de especificación, o un proceso más robusto. Una conclusión de APR es un paso previo al desarrollo futuro del producto y por lo tanto debería ser exacto y respaldado mediante datos adecuados.

Las guías de validación de procesos de la FDA piden la verificación continua del proceso. Así, un programa de APR puede servir como un sistema on going (etapa 3: verificación continua del proceso) para colectar y analizar los datos del producto / proceso que relaciona la calidad del producto.

Las necesidades del APR son parte del plan de mitigación de riesgos de acuerdo a las recomendaciones del ICH Q9.

La información reunida y las tendencias observadas pueden ayudar al desarrollo de un nuevo producto como tal y entonces esto es esencial para distribuir el reporte a todas las partes pertinentes e interesadas. El esfuerzo puede además ser revisado y compartido con equipos de mejora continua (lean process) mientras el desarrollo de CAPAs de un APR son críticos en evitar riesgos potenciales para un producto en el futuro.

Les dejo un artículo adicional:http://wp.me/p1Hn5Y-f3

Desde cGMPdoc, le ofrecemos la posibilidad de una promoción compuesta de 1 SOP para el manejo de los APR el cual incluye un informe modelo y una capacitación powerpoint con notas aclaratorias y su respectivo cuestionario de evaluación: http://wp.me/p1Hn5Y-3R

Además si Ud. Lo necesita podemos ofrecerle efectuar la revisión anual de sus productos, consultenos aquí.

Hace poco tiempo un colega de la industria me comentaba el siguiente caso:

El laboratorio de control de calidad reportó un resultado OOS (Out Of Specification=fuera de especificación) de uno de los activos de un jarabe antitusivo, el resultado obtenido fue de 82.2 % cuando la especificación requiere un valor de 95.0 – 105.0 % de la dosis declarada.

De acuerdo a sus procedimientos el laboratorio dió inicio al reporte del resultado OOS y su correspondiente investigación.

La conclusión de la fase de investigación del laboratorio fue que no hallaron error de laboratorio alguno, por lo cual solicitaron al departamento de QA (Aseguramiento de Calidad) que revisara el batch record.

QA chequeó el batch record, encontrando que la pesada del activo, así como también la incorporación del mismo a la preparación fueron correctas. Pero saben que?

El batch record solicita al final del proceso ajustar la preparación del  producto a peso de 2,400 Kg (el reactor dispone de celdas de carga calibradas para tal caso) y por error el lote fue llevado a un volumen de 2,400 litros y como dato adicional para confirmar el título del activo obtenido, les cuento que la densidad del producto es de 1,210 g/ml.

El resultado OOS fue confirmado y un desvío fue iniciado de manera de investigar la causa raíz de tal evento.

En primera instancia QA revisó la instrucción, entendiendo que la misma era clara. Luego entrevistó al experimentado elaborador del lote, quien les dijo lo siguiente: “Es el único producto de todos los que elaboramos que se ajusta por peso, todos los restantes son llevados a volumen.”

De esta situación, QA concluyó que a pesar que la instrucción era clara y que el trabajador era experimentado, la tarea fue realizada en forma automática y manera incorrecta, el elaborador no estaba conciente de lo que estaba solicitando el batch record del lote.

Recuerdo haber leído un artículo de David C. Markovitz (*) (Presidente de GMP Training Systems, Inc.) en su blog titulado: Pensar antes de actuar. Quiero compartir con Uds. algunos de los tips que según David pueden fortalecer el cumplimiento de las GMP en su organización:

  • Introducir el concepto de “piense antes de actuar” dentro de su organización, en las sesiones de entrenamiento, en el día a día.
  • Trabajo y tareas de rutina, redundantes o repetitivas, muchos desvíos de los SOPs, políticas o de las GMP pueden ser adjudicables a errores mentales o a lapsus. ¿Cuántos trabajos o tareas en su organización pueden ser caracterizados como rutinarios, redundantes o repetitivos? ¿Que puedo hacer para reducir la probabilidad de errores o lapsus mentales?

David sugiere un par de ideas para ello:

    • Rotar a la gente en distintas tareas a través del turno de trabajo
    • Tomar pequeños y frecuentes cortes, si el tipo de actividad lo permite

Estoy seguro que puede pensar en otras ideas que sean específicas a las tareas de su empresa.

  • Las personas son generalmente proclives a los hábitos y descuidos que conducen a problemas. Revisar las políticas y los procedimientos periódicamente puede mantener a las personas con sus conocimientos actualizados.
  • Reconocimiento y recompensas, reconocer y premiar a la gente por pensar y aportar ideas de mejora. Crear una nueva categoría: el premio reconocimiento en su sistema de reconocimiento y premio alentando a las personas a pensar.
  • Descripciones de puesto, porque no incorporar el concepto de pensamiento a cada descripción de puesto de la compañía. Deje a las personas conocer cuando ellos son recientemente incorporados que está la expectativa que ellos piensen como parte de su trabajo.
  • Piense dentro del box, todos hemos escuchado este viejo cliché: “Piense fuera del box” para alentar la innovación y creatividad. Deje además a la gente alentarla a que piense dentro del box para reducir la probabilidad de errores en las actividades del día a día.

CONCLUSION

De manera de minimizar la ocurrencia de errores, piense sobre como puede aplicar el concepto de “piense antes de actuar” en su organización y comience ya a utilizarlo.

GMP Tips:

Comentarios, preguntas y sugerencias al lector son bienvenidas. Casos de estudio, ilustrando las aplicaciones de entrenamientos enviados por lectores son realmente bienvenidos.

Por favor, envíenos sus comentarios, consultas, o sugerencias al administrador del blog a la dirección info@cgmpdoc.com o comunicaciones@cgmpdoc.com.

 

(*) David Markovitz, www.gmptrainingsystems.com