Posts tagged ‘análisis de riesgo’

Podría decir, sin mayor error, que muchas de las actividades que efectuamos, son requeridas por las Agencias, pero también quiero hacer foco en la importancia de las mismas, en el valor agregado que tienen, en los beneficios que aportan a nuestra operación.

La gestión de riesgos (GR), no es la excepción y es más que un simple requisito normativo con el que las empresas farmacéuticas tienen que cumplir. La GR es un proceso de mejora continua. Es una metodología mediante la cual identificamos, analizamos, evaluamos, mitigamos y monitoreamos el riesgo a lo largo del ciclo de vida y es de suma importancia que esté incorporado dentro de la cultura de la empresa.

No solo se trata de tener en la empresa dos personas especialistas en la GR, los operadores, los analistas deben entender los principios de la GR, la idea de ser más proactivos que reactivos, ya que la GR nos da el potencial de reducir la posibilidad de que ocurra un riesgo y su impacto potencial.

¿Qué es la cultura del riesgo y cómo la logramos? y en este punto, quiero dejarles dos preguntas:

¿Estamos trabajando en la identificación del riesgo? y cuando lo identificamos, ¿Nos asusta o lo ignoramos?

El comportamiento frente al riesgo cuando lo identificamos, es una parte fundamental del proceso.

Por supuesto que escondernos o no reconocer el riesgo, dejándo todo como está, no es una posición aceptable.

Una vez que el riesgo es comprendido, es esencial la exploración de mitigaciones para ese riesgo o la formación de una justificación de aceptación del riesgo.

Esos son los dos componentes principales que luego equivalen a construir una cultura de riesgo. Pero un aspecto crítico en este proceso es:

¿De qué forma la Dirección impulsa esta Cultura? ¿Existe una apertura a identificar y hablar sobre el riesgo? ¿O preferiría que siguiéramos adelante, sin pensar en los posibles problemas que podrían surgir?

Una vez que se identifican los riesgos pronosticados, la asignación de recursos donde se necesitan para mitigar esos riesgos también es un desafío.

Es usual la asignación de recursos donde ocurren problemas y debemos tomar acciones correctivas o preventivas, pero cuando se trata de un riesgo potencial, sobrecalificamos: ¿Cuánto dinero debemos invertir en esa acción sino sabemos si realmente va a suceder?

Debemos sentirnos seguros con nuestro proceso y aceptar que identificar el riesgo puede hacernos mejores. Enseñar a nuestros equipos a usar los datos y aprovechar su capacidad para minimizar el riesgo son factores para fomentar la cultura del riesgo.

¿Cuáles son los requerimientos mínimos de Calidad y Compliance para la Resiliencia de la continuidad del negocio, la gestión de la continuidad de los servicios de IT y la planificación de recuperación de desastres? 

Nos estamos refiriendo a los procesos del negocio soportados por sistemas computarizados, dentro del laboratorio y a todos los sistemas computarizados y los servicios que los soportan.

¿Qué deberíamos considerar?

  • Gestión de la Continuidad del Negocio

Esta gestión debe asegurar para todos los procesos de negocios del laboratorio, que tras la disrupción, la operatividad comercial se mantiene en un nivel aceptable.

Cuando no se requieran planes de continuidad del negocio, esta decisión debe ser documentada y justificada con una evaluación de riesgos adecuada que tenga en cuenta el impacto sobre el negocio.

  • Gestión de la Continuidad del Servicio de IT

La Gestión de la Continuidad del Servicio de IT debe asegurar que la infraestructura de IT del laboratorio y sus servicios se pueden restaurar en los plazos determinados de conformidad con los Niveles de Servicio después de un desastre. Todos los Servicios de IT   requieren planes de recuperación y procedimientos establecidos de acuerdo a su criticidad.

Los planes de Gestión de Continuidad del Servicio de IT debe incluir la planificación de procesos y ajuste de procedimientos durante desastres, así como de Planes de recuperación Servicio específicos direccionados a la recuperación técnica.

Estos planes deben revisarse y ensayarse sobre bases regulares para asegurar viabilidad y efectividad. Los planes y capacidades de recuperación deben ajustarse de acuerdo a los resultados de los ensayos realizados.

Se deben realizar  evaluaciones y revisiones de riesgo periódicas para identificar si la probabilidad de un desastre o interrupción del servicio serio para el laboratorio ha cambiado y / o para identificar nuevas amenazas o vulnerabilidades. Los planes de Mitigación de Riesgo / Mejora de Servicio se deben desarrollar según el caso.

  • Gestión de Recuperación de Desastre (incluyendo recuperación de aplicaciones)

Se deben considerar Planes de Recuperación de Desastre y de Aplicaciones para todos los sistemas computarizados utilizados por el laboratorio.

El Propietario del Sistema es responsable por asegurar la existencia, en el lugar, de un Plan de Recuperación de Desastre y Aplicaciones y de las pruebas asociadas.

Cuando los Planes mencionados no se necesitan, la decisión se debe documentar y justificar con un análisis de riesgo que considere el impacto en el negocio.

En caso de un evento de Desastre, todas las aplicaciones y sistemas computarizados serán recuperados de acuerdo al orden de prioridad, el cual se basa en aquellos sistemas que están dentro de los Planes de Recuperación (o contrato) del lugar. De no existir contratos de Recuperación de Desastres, la recuperación de las aplicaciones y sistemas se hará de manera “comercialmente razonable”, basando el orden en prioridad para el negocio (las aplicaciones sin contrato de recuperación de desastres se podrían recuperar dentro de un período de semanas o meses).

  • Sistema Crítico

Un Sistema Crítico o conjunto de sistemas se define como un conjunto de sistemas computarizados críticos y la infraestructura soporte, que, si no es accesible, podría afectar seriamente al laboratorio. 

Factores a evaluar:

  • La dependencia del negocio de la aplicación o servicio y
    • El Tiempo de Recuperación que se requiere para evitar un impacto no aceptable en el negocio.

Los Sistemas que están dentro del listado de críticos, junto con la infraestructura soporte y los procesos, deben tener Planes de Continuidad de negocio y Recuperación de Desastre, disponibles en el lugar.

El listado de Conjuntos críticos debe ser revisado trimestralmente, para su actualización.

Excepciones

No todos los procesos y sistemas requieren planes de Continuidad de Negocio o de Recuperación de Desastre. Esto se basa en su uso y en el nivel de riesgo e impacto que representan en lo que respecta a la criticidad del negocio.

La decisión acerca de que un proceso o sistema no requiera plan de Continuidad de Negocio o de Recuperación de Desastre debe ser documentada y aprobada por el Propietario  del Sistema o el Proceso de Negocio.

 (*) Según Wikipedia:

La resiliencia es la capacidad de los seres humanos para adaptarse positivamente a las situaciones adversas. Sin embargo, el concepto ha experimentado cambios importantes desde la década de los 60. En un principio se interpretó como una condición innata luego se enfocó en los factores no solo individuales, sino también familiares y comunitarios y actualmente en los culturales. Los investigadores del siglo XXI entienden la resiliencia como un proceso comunitario y cultural, que responde a tres modelos que la explican: un modelo «compensatorio», otro de «protección» y por último uno de «desafío».

Asimismo, la resiliencia es la capacidad de tener éxito de modo aceptable para la sociedad a pesar de un estrés o de una adversidad que implica normalmente un grave riesgo de resultados negativos. También se define como un proceso de competitividad donde la persona debe adaptarse positivamente a las situaciones adversas.

Etimología

Resiliencia viene del término latín resilio, «volver atrás, volver de un salto, resaltar, rebotar». El término se adaptó al uso en psicología y otras ciencias sociales para referirse a las personas que a pesar de sufrir situaciones estresantes no son afectadas psicológicamente por ellas.

La palabra resiliencia, en cuanto a la física y la química, designa la capacidad del acero para recuperar su forma inicial a pesar de los golpes que pueda recibir y a pesar de los esfuerzos que puedan hacerse para deformarlo. La palabra proviene del latín saliere, que se traduce como “saltar hacia atrás, rebotar, ser repelido o surgir”, antecedido por el prefijo “re”, que indica repetición o reanudación.

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

Las 3 etapas son:

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

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

1. Diseño del proceso

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

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

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

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

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

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

2. Calificación del proceso

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

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

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

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

3. Verificación continua del proceso

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

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

El ISPE nos da algunos principios para efectuar las actividades de calificación:

  • Enfoque en la calidad del producto: la calidad del producto debe ser garantizada por las actividades de calificación.  
  • Requisitos: el URS debe basarse en el proceso y esto se confirma en el PQ (calificación de performance). Esto significa que tanto el IQ como el OQ están subordinados en importancia.
  • Evaluaciones de riesgo: el desarrollo del proceso y el diseño experimental son los elementos clave para identificar funciones y parámetros críticos, los cuales serán la base para las actividades de calificación.
  • Actividades basadas en el riesgo, las mismas dependerán de la complejidad de la instalación (ej. Clasificación GAMP) y deben agregar valor a la calificación. No deberíamos incorporar solo actividades por el hecho de hacer volumen de documentación.
  • Uso de la documentación del proveedor: Si es posible.
  • Pruebas: por regla general, las pruebas deben realizarse una sola vez.
  • Fomento de la innovación: en este punto, se requiere la flexibilidad de los programas de calificación para poder implementar nuevas tendencias.

Todo esto requiere grandes cambios organizativos en las empresas (quizás es una de las partes más difíciles), que a menudo tienen conceptos relativamente rígidos de calificación y validación.

La gestión de calidad se centraría más en los procesos y análisis de riesgo, los planes de calificación y los informes de calificación. Por otro lado, también sería necesario fortalecer los sistemas de calidad de los departamentos especiales (por ejemplo, Ingeniería, IT, etc.) y la producción. El riesgo para la calidad del producto se determinaría en el contexto de una divulgación de riesgo sobre la base de la comprensión del proceso. El control de esos riesgos se calificaría entonces en la calificación de la performance.

La nueva disposición de la ANMAT tiene establecidos requerimientos para los sistemas computarizados o informatizados en el Anexo 6 Sistemas Informatizados de la nueva Disposición.

Este Anexo aplica a todas las formas de sistemas informatizados usados como parte de las actividades reguladas por las BPF y se utilicen para crear, modificar, mantener,  archivar, obtener o distribuir registros electrónicos.

Además de Validar las aplicaciones, debemos calificar la Infraestructura  informatizada (IT).

La inclusión de un sistema informatizado en la manufactura no debe aumentar el riesgo total del proceso.

Estos lineamientos de la nueva GMP están basados en la GAMP5 (ISPE) A Risk-based Approach to Compliant GxP Computarized Systems.

Como parte del sistema de gestión de riesgos, las decisiones sobre la extensión de la validación y de los controles de la integridad de datos deben basarse en una evaluación de riesgos del sistema informatizado justificada y documentada.

La norma menciona diferentes figuras que deben existir, como: el propietario del proceso (process owner), el propietario del sistema (system owner), las Personas Calificadas e IT. Obviamente todo el personal debe estar calificado, con su nivel de acceso y definidas sus responsabilidades.

Los proveedores de sistemas informatizados deben estar evaluados y debe disponerse de acuerdos técnicos y acuerdos de confidencialidad (ppalmente. para acceso remoto). La necesidad de auditarlos debe estar basada en un análisis de riesgo del mismo.

Debe disponerse de un inventario de los sistemas computarizados del laboratorio.

La Validación debe ser proporcional al riesgo del sistema (clasificación del riesgo, por ejemplo Categoría GAMP5 y calificación del proveedor), a más riesgo más esfuerzos de validación.

La transferencia de datos debe ser efectuada de forma segura.

En cuanto a la Operación de los SC, debemos asegurar que los datos son guardados regularmente de forma integra durante el período de conservación de los mismos. Debe haber un Audit Trail y debe ser considerada la Gestión de cambios y configuración.

Los sistemas informatizados deben ser revisados periódicamente para verificar la validez de la validación. Esta revisión incluye por ejemplo documentos de operación, validación, cambios, eventos, accesos y manejo de back up, por ej.

También hace referencia a otros temas de importancia como el manejo de firmas electrónicas, plan de Disaster Recovery, etc.

Desde cGMPdoc les ofrecemos distintas alternativas como:

  1. Entrenamientos “In Company” para capacitar a su personal
  2. La implementación del proceso de CSV (Validación de Sistemas Computarizados), lo cual incluye la discusión del procesos internamente con el laboratorio, la confección de los SOPs necesarios, el entrenamiento del personal, la confección del PMV de sistemas computarizados y la ejecución de una validación a modo de ejemplo, de manera que Uds. puedan luego continuar con las actividades del Plan.
  3. La validación de un sistema computarizado
  4. Asesoramiento en la revisión de su proceso de CSV si lo necesita
  5. Pack de SOPs y documentos modelos sobre CSV

Espero que les resulte de utilidad.

Es de suma importancia identificar las posibles fuentes de Impurezas Elementales (IE), para luego evaluar los niveles de dichas IE en los productos terminados y compararlos con los PDE (Permitted Daily Exposure) establecidos para cada elemento.

Este análisis debe ser documentado y las medidas de control necesarias deben ser tomadas en el caso que los controles existentes no sean suficientes.

El objetivo es asegurar que las IE Potenciales no excedan los valores permitidos (PDE).

Como fuentes potenciales de IE tenemos:

  • Residuos de IE incorporados en el proceso de síntesis de API / Excipientes, como por ej. catalizadores.
  • IE que puedan estar presentes en APIs / Excipientes.
  • IE que puedan ser aportadas por algún servicio utilizado como por ej. agua.
  • IE que pueda ser aportada por las superficies en contacto con el equipo de elaboración del producto (estudios de compatibilidad).
  • IE aportadas por los materiales de empaque primario (estudios de compatibilidad).

Para efectuar el análisis de identificación puede ser utilizado como herramienta el diagrama de Ishikawa.

El Análisis de Riesgo puede indicar que:

  1. NO hay Impurezas Elementales identificadas
  2. Que hay determinadas IEs  y sus fuentes identificadas

El contenido puede ser determinado por dos formas distintas, por medio de los componentes o por medio del producto terminado (en este caso es requerido al menos 3 análisis de la IE en lotes full scale o 6 en lotes tamaño piloto).

Si el resultado del contenido de la IE en el producto es < 30 % de la PDE, no es necesario tomar acciones adicionales, caso contrario es esperado la toma de acciones adicionales, sobre todo si estamos en valores >100 % de la PDE.

Ejemplos de medidas de control pueden ser: modificaciones de alguna de las etapas del proceso, cambio de material de empaque primario, cambio de material del equipo (por ejemplo si el producto interacciona con el acero inoxidable, identificar un material plástico que no reaccione con el producto, demostrar esto a través de un estudio de compatibilidad de materiales).

PDE: Permitted daily exposure. The maximum acceptable intake of elemental impurity in pharmaceutical products per day.

(*) ICH Q3D Elemental Impurities: Guidance for Industry (Septiembre 2015).

 

Determinar el riesgo asociado con cada CPI (Critical Process Input o entrada crítica del proceso)

Cada CPI puede ser correlacionado a 1 o más atributos críticos de calidad (ACC), por lo tanto, el riesgo asociado con cada CPI es el producto de:

  • La severidad de no cumplir el ACC y
  • La probabilidad que la variación inherente en el CPI resultará en esta falla

Cuanto más alta es la criticidad del ACC, más extensivo será el testeo requerido para conjuntamente esta relación.

La probabilidad que la variación inherente en el CPI resultará en esta falla debería además ser posible de estimar en esta etapa en el proceso desde la combinación de información reunida en las etapas previas del ciclo de vida del proceso de validación y cualquier otra fuente viable de información del proceso. Si una cantidad de información significativa es ya conocida, esto puede ser aprovechado para reducir la extensión de los testeos requeridos.

El riesgo asociado con cada CPI es el producto de la S x la P evaluados. El nivel de riesgo será usado para determinar cuánto testeo es requerido y cuando / donde el testeo será efectuado.

Determinar cuánto testeo es requerido

En general, el mayor de los riesgos presentados por medio de la variación en el CPI, es el más extensivo de los testeos de la variabilidad que se necesita hacer. La tabla siguiente ilustra este concepto:

Probabilidad que el CPI impacte el ACC
Baja Alta
Nivel de Severidad del ACC asociado con el CPI Baja Mínimo riesgo para el ACC. Mínimos testeos requeridos. Puede ser posible justificar que no es necesario testear la variación del CPI. Algún grado de testeo es probable que sea requerido para confirmar que el impacto conocido sobre el ACC no causa problemas de calidad en el producto.
Alta Algún grado de testeo es probable que sea requerido para verificar que la variación en el CPI no impacto sobre los ACC. Es requerido un testeo extensivo para confirmar que la variación natural del CPI no impactará la calidad del producto.

El propósito de los testeos es confirmar el impacto de la variación del CPI. Por lo tanto, el equipo debe entender las fuentes de variación inherente de manera de construir un programa de PPQ que testeará adecuadamente esta variación.

Tipo de Input (entrada) Fuentes de variación
Variables ambientales Cambios en la iluminación de fondo pueden impactar significativamente la performance de un sistema de inspección, sin embargo la relación exacta puede ser difícil de cuantificar, por lo tanto un test del sistema puede ser necesario para abarcar todos los escenarios posibles. En algunos casos esto puede llevar a requerir testeos durante operaciones de turnos de día y de noche.

Variaciones estacionales en la calidad del agua de alimentación puede afectar la performance del sistema de agua purificada de una planta, por lo tanto la calificación del sistema de agua debe incluir ensayos estacionales para verificar dichas variaciones.

Materias primas (PKG y químicas) Una típica fuente de variación en las MP es la variación lote a lote de las MP provistas por el proveedor del material. Una estrategia de validación robusta incluirá el testeo la variación intra e inter lote y puede que más de un lote de MP sea incluido en el programa de PPQ (ejemplo 2 activos distintos para la validación de los 3 lotes).
Servicios (electricidad, aire, agua, etc.) Para sistemas que no están equipados con métodos automáticos de eliminación de variación (ej. Power conditioners, PID loops), esto puede ser necesario considerar en la estrategia de validación.
Personal La interacción del personal no es comúnmente testeada durante el PPQ, ellos son normalmente descartados como una variación variable la base de un programa de entrenamiento robusto. Las más grandes excepciones a estos son los ensayos de medios con lainstalación de proceso estéril y la inspección humana de defectos cosméticos y materia particulada, donde el riesgo presentado por la interacción humana es considerado muy alto y por lo tanto esta variable debe ser incluida en los protocolos de testeos. No es una práctica frecuente incluir a cada operador en el PPQ, sin embargo una estrategia típica de PPQ podría incluir testeos a lo largo de un turno de operación.
Upstream / dowstream Equipment El conocimiento del impacto del proceso anterior puede resultar en la necesidad de incluir en el test de validación para evaluar el impacto.

El bracketing puede ser usado en el programa de PPQ, para reducir su duración, por ejemplo ejecutar un programa de PPQ en un depósito de temperatura controlada durante un período de tiempo de alta temperatura (por ejemplo a mitad del verano), podría eliminar la necesidad de efectuar cualquier estudio de calificación en condiciones frías cuando el aire además está funcionando.

En la conclusión de esta etapa en el proceso la estrategia general de testeos del PPQ debería tener desarrollo de cual de todas las entradas críticas del proceso (CPI) incluir que necesitan ser variadas  y la forma en la cual ellos serán variados a lo largo de protocolo de ensayos de PPQ.

Determinación de cuando ejecutar los testeos

Hay típicamente 3 opciones para ejecutar los ensayos del PPQ.

  1. Testeos que ocurren antes de las actividades de producción comercial en un entorno que replica el proceso de elaboración comercial.
  2. Testeos que ocurren durante la producción comercial pero es completado antes de la liberación de cualquier producto comercialmente (Validación prospectiva).
  3. Testeos que ocurren durante la producción comercial y es completada a veces después de la liberación del producto comercial (validación concurrente).

En general los testeos deben ser ejecutados tan pronto como sea posible en el proceso (opción 1), esto minimiza el riesgo de calidad del producto comercial y puede además ser una ventaja para reducir los requerimientos del programa PPQ, sin embargo puede haber restricciones de negocios legítimas que impidan que todas las posibles variaciones en los IPC se están probando antes de la producción comercial.

La decisión en cuanto a si puede ser aceptable efectuar algunos o todos los testeos del PPQ como validación prospectiva durante la producción comercial debe ser basada sobre el riesgo a la calidad del producto. Esto está ilustrado a continuación:

Probabilidad que el CPI impacte el ACC
Baja Alta
Nivel de Severidad del ACC asociado con el CPI Baja Mínimo riesgo para el ACC. Mínimos testeos requeridos. Puede ser considerado para testeo como parte del PPQ de producción comercial. Testeos podría ser efectuado durante la producción comercial dependiendo de circunstancias de mitigación.
Alta Testeos podría ser efectuado durante la producción comercial dependiendo de circunstancias de mitigación. El testeo debe ser efectuado antes de ingresar al PPQ  para aumentar el conocimiento del proceso antes de testeos durante la producción comercial.

Un ejemplo de una situación que puede requerir este tipo de evaluación es lo que sigue:

Cuando desarrollamos la estrategia de PPQ para un proceso de empaque de comprimidos, es sabido que la variación lote a lote en los atributos de los comprimidos (medidas, dureza, etc.) es un CPI para el proceso de empaque de comprimidos, por lo tanto es necesario evaluar el impacto de estos CPI para asegurar que ello no resultará en un nivel inaceptable de defectos de calidad.

El equipo determina que debido a la combinación de la severidad de los posibles defectos de calidad y el conocimiento actual del proceso de la relación entre este CPI y los ACC asociados, será necesario evaluar 3 lotes distintos de comprimidos formulados. Sin embargo, hay legítimas restricciones financieras asociadas asociadas con la producción de 3 lotes completos de comprimidos para testeos en un entorno de desarrollo (ej. Producto que no será adecuado para subsecuente empaque comercial y venta).

Por lo tanto el equipo tiene dos operaciones posibles:

  • Si el riesgo global de la variación del comprimido lote a lote es considerado de medio a bajo (cuando se evalúa por la metodología descripta en esta sección del procedimiento), el equipo puede decidir ejecutar un programa de PPQ de tres lotes prospectivos durante la producción comercial.
  • Si el riesgo es considerado alto (debido a la combinación de una alta severidad y un mínimo conocimiento del proceso) puede ser necesario ejecutar un programa inicial de testeos de desarrollo para aumentar el conocimiento del proceso, luego del cual puede entonces ser adecuado ejecutar un programa de PPQ prospectivo reducido durante la producción comercial.

El uso de la validación concurrente debería ser evitado, sin embargo, puede haber circunstancias atenuantes que justifiquen una estrategia de validación concurrente. Un ejemplo posible de esto podría ser una situación donde el tamaño del lote de producción es muy pequeño y el número inicial de lotes requeridos es mínimo. En este caso puede ser necesario permitir la liberación de cada lote de manera individual antes de completar las actividades enteras del programa de PPQ.

Cualquier justificación para el uso de validación concurrente debe ser claramente documentada en el VMP o en el protocolo de PPQ.

Más adelante veremos los lineamientos sobre como estructurar el plan de muestreos y testeos de un protocolo de validación de proceso concurrente tal que la calidad de cada lote individual sea asegurada antes de la liberación.

Antes de comenzar con la guía rápida de FMEA, creo que sería bueno revisar el proceso general.

Visión global del Proceso

  • Es deseable un buen entendimiento del proceso.
  • Los procesos largos, deben ser fraccionados en subprocesos, en etapas o componentes.
  • Cada punto o modo de falla de cada etapa o componente, debe ser identificado.
  • Luego debe ser identificado el efecto de cada uno de los puntos o modos de falla.
  • Finalmente es evaluado cada uno de los simples puntos de falla, para ver su riesgo y la necesidad de acciones de mitigación.

Hay diferentes herramientas para efectuar dicho análisis, nosotros hemos optado por el uso del FMEA (o en español AMFE = Análisis de Modo de Falla y Efectos).

A los interesados en el tema, disponemos de una Planilla Excel, que les servirá para llevar adelante el análisis de riesgo con FMEA, donde en una de las solapas encontrará los criterios de aceptación para cada uno de los 3 criterios utilizados y en la otra una planilla para registrar las evaluaciones efectuadas, solicítela enviando email a: info@cgmpdoc.com.

El FMEA utiliza 3 criterios:

  1. Severidad
  2. Probabilidad
  3. Detectabilidad

Los criterios están establecidos en un rango numérico, los valores altos implicando un mayor impacto. El rango utilizado puede ser bajo, como por ejemplo de 1 a 3 (Bajo, Medio o Alto) para usar la herramienta de forma más simple, sin embargo lo más común es usar un rango de 1 a 5 o de 1 a 10, dependiendo de la definición deseada del score. Un estudio largo con muchos eventos que evaluar debería estar adecuado con largos rangos de valores.

Para cada etapa o componente del proceso, determinar el o los modos de fallas y cómo la falla podría ser presentada por sí misma (efecto de la falla – qué defecto es creado).

La pregunta en esta etapa es ¿Qué podría salir mal?

Luego para casa caso de falla, es importante determinar el impacto, el efecto o el riesgo.

Para cada uno de estos casos, se determinan los 3 criterios anteriores (severidad, probabilidad y detectabilidad).

Severidad

Es una medida de las consecuencias / impacto si el evento ocurre, ¿Cuáles son las consecuencias si esto sale mal?

  • Si el riesgo identificado ha sucedido, ¿Cuál es el impacto para el usuario final o para el proceso?
  • NO incluir o considerar cualquier mitigación o control actual, o método de detección en el racional cuando se determina el rango de severidad.
  • El peor escenario debería ser usado si hay una duda entre dos scores, el score más alto debe ser usado.

Probabilidad (Ocurrencia)

Es una medida de la probabilidad de que el evento suceda. ¿Cuál es la probabilidad que esto salga mal?

  • ¿Cuál es la probabilidad que el riesgo ocurra o cuál es la historia de ocurrencia del evento?
  • ¿Hay datos históricos que pueden ser usados?

o   Para el sistema actual que está establecido o

o   Para un sistema análogo si el sistema aún no está establecido

Detectabilidad

Es una medida de la probabilidad que el evento sea detectado si ocurre. ¿Será detectado?

  • ¿Qué métodos están en el lugar disponibles para la detección si el evento ha ocurrido?
  • ¿Cuál es la probabilidad de este método de detectar el evento?

Luego con estos tres scores se calcula el RPN o Risk Priority Number, que es el producto de los 3 puntajes anteriores.

RPN = S x P x D

  • A > RPN > Riesgo
  • Para los scores de RPN que están en el mismo nivel de riesgo, el score de Severidad le da mayor peso, luego el de Probabilidad y finalmente el de Detectabilidad.

Mitigaciones

Los scores de Severidad (impacto al paciente), raramente pueden ser cambiados, pero hay instancias donde el cambio del material / proceso puede disminuir el impacto al paciente.

Prioridades de mitigación:

Las mitigaciones que reducen la probabilidad deberían ser siempre precedentes a las que mejoran la detectabilidad de la falla (es mejor reducir la probabilidad de que el evento ocurra que depender del método de detección para identificar el problema).

Si la probabilidad no puede ser reducida a nivel aceptable, entonces el método de detección que puede identificar que los eventos han ocurrido deberían ser lo más cercanos / próximos al punto de falla como sea posible

Métodos de detección de ingeniería (ejemplo sistemas de visión, alarmas, etc.), son preferidos sobre aquellos procedimentales como (muestreo AQL, testeos sobre el proceso, etc.). Las mitigaciones procedimentales son las medidas de mitigación más débiles, generalmente recaen sobre el muestreo o testeo para detectar la falla, lo cual probablemente aumenta el impacto del evento. En este caso el producto ya está hecho y el defecto puede impactar de una forma la calidad antes que sea detectado.

Documentación del FMEA

Utilizar la planilla Excel adjunta, en la misma encontrará un ejemplo para ver el uso de la misma. Además contiene notas aclaratorias sobre los campos.

Se establecen para el RPN, rango de valores para clasificar a los riesgos como Bajos, Medio o Altos (la planilla tiene una tabla con criterios, los mismos pueden ser ajustados, pudiendo uno ser más o menos exigente).

Finalmente para todos aquellos riesgos de scores alto (Alto riesgo), deben ser tomadas acciones de mitigación adicionales para reducir el nivel de riesgo a nivel bajo o medio al menos.

Luego de planeadas las acciones de mitigación adicional, el factor de RPN debe ser recalculado de acuerdo a la nueva situación.

Las acciones de mitigación (CAPAs) son seguidas usualmente a través del sistema CAPA del laboratorio y además es vital la verificación de la efectividad de las mismas.

NOTA: es sumamente importante a la hora de estimar la probabilidad de ocurrencia de la falla, conocer las posibles causas de la misma (conocimiento del proceso), de la misma forma que para la determinación de las acciones de mitigación.

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.

  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