Troubleshooting en procesos estériles: de la causa raíz a la red causal

Cuando se produce una desviación durante la fabricación de un medicamento estéril, una de las primeras preguntas que hacemos es aparentemente sencilla:

¿Cuál ha sido la causa raíz?

La lógica es conocida. Identificamos la causa que provocó la desviación, definimos las acciones correctivas y preventivas correspondientes, evaluamos su eficacia y tratamos de evitar que el problema vuelva a producirse.

Sobre el papel, el proceso parece lineal:

Sin embargo, quienes han participado en investigaciones de procesos asépticos saben que la realidad rara vez se comporta de una forma tan ordenada.

Un evento microbiológico, una intervención no prevista, una parada de línea, un resultado ambiental fuera de tendencia o una pérdida temporal de las condiciones esperadas pueden ser el resultado de la interacción de múltiples elementos: personas, equipos, materiales, procedimientos, condiciones ambientales, mantenimiento, diseño, organización o decisiones tomadas mucho antes de que la desviación llegase a ser visible.

Y precisamente ahí aparece uno de los principales riesgos de una investigación: confundir una explicación posible con una comprensión suficiente del problema.

La atractiva simplicidad de una única causa

En muchas investigaciones se termina llegando a conclusiones como estas:

• El operario cometió un error.
• Se produjo un fallo del equipo.
• El procedimiento no era suficientemente claro.
• El material presentó una variabilidad inesperada.
• No se siguió correctamente una instrucción.

Todas ellas pueden ser ciertas.

El problema aparece cuando damos por hecho que, por ser ciertas, son también la explicación completa.

Encontrar una causa sencilla resulta enormemente atractivo. Reduce la incertidumbre, facilita la definición de una CAPA, permite completar el informe de investigación y acerca la desviación a su cierre administrativo.

Pero cerrar una investigación no es necesariamente lo mismo que comprender un evento.

En sistemas complejos, y la fabricación estéril por proceso aséptico lo es, la causa inmediatamente visible puede ser solamente el último elemento de una cadena de condiciones que se han ido acumulando hasta hacer posible la desviación.

La propia filosofía del Anexo 1 apunta hacia una visión integral. La “Contamination Control Strategy” debe considerar conjuntamente controles de diseño, técnicos, procedimentales y organizativos, así como comprender las interacciones entre los distintos sistemas. Además, el documento señala que las medidas de control de contaminación constituyen una serie de eventos y controles interrelacionados cuya eficacia colectiva debe ser considerada.

Esto tiene una implicación importante para el troubleshooting:

El sistema no debería investigarse por piezas aisladas cuando el evento ha sido producido por la interacción entre esas piezas.

Un ejemplo: la excursión microbiológica después de una intervención

Imaginemos una línea de llenado aséptico.

Durante la operación se produce un atasco. El operario realiza una intervención para restablecer el funcionamiento de la línea y posteriormente aparece una excursión microbiológica.

Disponemos además de grabación en vídeo. Al revisarla observamos que el operario realizó un movimiento inadecuado cerca de una zona crítica.

La conclusión parece evidente:

Causa raíz: técnica aséptica incorrecta.

CAPA: realizar de nuevo la formación del operario.

La investigación podría incluso considerarse técnicamente razonable.

Pero imaginemos que decidimos continuar investigando.

Descubrimos entonces que:

• El atasco que provocó la intervención ya había ocurrido anteriormente;
• Existía cierta variabilidad dimensional en uno de los componentes;
• El diseño del equipo dificultaba la resolución del atasco;
• La intervención obligaba al operario a aproximarse a una zona crítica;
• La maniobra no había sido suficientemente estudiada mediante visualización dinámica de los flujos de aire;
• El procedimiento describía el objetivo de la intervención, pero no suficientemente la secuencia de movimientos;
• La desinfección posterior de los guantes no estaba claramente definida;
• Existían pequeñas paradas anteriores clasificadas únicamente como pérdidas de eficiencia;
• Los datos de esas paradas nunca se habían analizado conjuntamente con los resultados de monitorización microbiológica.

La pregunta cambia entonces completamente.

¿Fue el operario la causa raíz?

¿O fue simplemente el último elemento visible de una combinación de condiciones que hacía el evento cada vez más probable?

El Anexo 1 refuerza precisamente la importancia de minimizar las manipulaciones asépticas mediante soluciones de ingeniería y establece que las intervenciones deben diseñarse cuidadosamente teniendo en cuenta, entre otros aspectos, su posible impacto sobre los flujos de aire, las superficies críticas y el producto. También señala que deben utilizarse soluciones de ingeniería siempre que sea posible para reducir la incursión de los operarios durante las intervenciones.

Por tanto, si una intervención obliga sistemáticamente al operario a ejecutar una maniobra difícil en una zona crítica, el análisis no debería limitarse únicamente a valorar si el movimiento del operario fue correcto.

También deberíamos preguntarnos por qué diseñamos un sistema que necesita ese movimiento.

Del evento observado a la red causal

Una manera útil de estructurar estas investigaciones consiste en separar diferentes niveles causales.

1. Evento observado: ¿qué ocurrió?

Es el hecho objetivo que inicia la investigación.

Por ejemplo:

Se detectó una excursión microbiológica después de una intervención correctiva durante el llenado.

Conviene mantener inicialmente esta descripción lo más libre posible de interpretaciones.

2. Mecanismo inmediato: ¿cómo ocurrió?

Describe el mecanismo físico, microbiológico, mecánico u operativo que podría explicar el evento.

Por ejemplo:

Durante la intervención se produjo una alteración de la protección de la zona crítica.

O:

El movimiento del operario pudo interferir con el patrón esperado de flujo de aire.

Aquí podemos estar explicando cómo se produjo la desviación, pero todavía no necesariamente por qué fue posible.

3. Factores contribuyentes: ¿qué aumentó la probabilidad?

Son elementos que por sí solos quizá no habrían provocado la desviación, pero que aumentaron su probabilidad.

Por ejemplo:

• Elevada frecuencia de micro paradas;
• Variabilidad de componentes;
• Acceso difícil al punto de intervención;
• Secuencia de movimientos compleja;
• Ergonomía inadecuada;
• Experiencia limitada con esa intervención específica;
• Condiciones de presión operativa.

Estos factores empiezan a revelar que el evento difícilmente puede reducirse a una única causa.

4. Condiciones latentes: ¿qué debilidades existían antes del evento?

Son probablemente las más interesantes desde el punto de vista del aprendizaje para la organización.

Pueden llevar meses o incluso años presentes en el sistema sin producir una desviación evidente.

Por ejemplo:

• Diseño poco robusto del equipo;
• Mantenimiento excesivamente reactivo;
• Aceptación histórica de determinadas microparadas;
• Procedimientos desarrollados desde una perspectiva documental y no desde la observación del trabajo real;
• Escasa conexión entre datos de Producción, Ingeniería, Mantenimiento y Microbiología;
• Evaluación insuficiente de determinadas intervenciones;
• Criterios de seguimiento de tendencias demasiado fragmentados.

El evento simplemente hace visible una vulnerabilidad que ya existía.

5. Barreras fallidas: ¿por qué el sistema no previno o detectó el problema?

Esta pregunta es especialmente potente.

Porque un sistema robusto no debería depender exclusivamente de que una persona ejecute cada movimiento perfectamente cada día.

Debería disponer de distintas barreras que reduzcan la probabilidad de error o limiten sus consecuencias.

Podemos entonces preguntarnos:

• ¿Por qué el diseño no evitaba la intervención?
• ¿Por qué el procedimiento no prevenía la maniobra?
• ¿Por qué el estudio de visualización de los flujos de aire no había identificado esa situación?
• ¿Por qué el APS (Validación del proceso aséptico o Media Fill) no había desafiado suficientemente esa intervención?
• ¿Por qué las micro paradas anteriores no generaron una señal?
• ¿Por qué el mantenimiento no había identificado una tendencia?
• ¿Por qué la información disponible permanecía fragmentada entre departamentos?

Cada respuesta abre una parte diferente de la red causal.

El error humano: ¿causa raíz o síntoma del sistema?

Probablemente uno de los puntos más delicados de cualquier investigación sea el denominado error humano.

Naturalmente, las personas cometemos errores. También existen incumplimientos conscientes, falta de atención, deficiencias de entrenamiento o ejecuciones incorrectas de procedimientos.

Negarlo sería igualmente peligroso.

Pero concluir simplemente que “el operario cometió un error” aporta muy poca información para mejorar el proceso.

La pregunta verdaderamente útil es:

¿Qué condiciones hicieron posible, favorecieron o no detectaron ese error?

Podemos plantearnos, por ejemplo:

• ¿La tarea era innecesariamente compleja?
• ¿Era físicamente difícil realizarla correctamente?
• ¿Existía presión para recuperar rápidamente la producción?
• ¿El procedimiento representaba realmente la operación?
• ¿El operario había practicado la intervención en condiciones suficientemente representativas?
• ¿Existían indicaciones ambiguas?
• ¿El diseño permitía una forma más segura de intervenir?
• ¿Habían aparecido señales previas similares?

Este enfoque no elimina la responsabilidad individual cuando corresponda.

Lo que evita es confundir responsabilidad con causalidad.

Una investigación técnicamente madura debe ser capaz de analizar simultáneamente el comportamiento humano y las condiciones del sistema en el que dicho comportamiento tuvo lugar.

Esta idea está alineada con la ICH Q9 (R1), que contempla expresamente que el análisis de causa raíz puede identificar no solamente la causa o causas raíz, sino también otros factores causales, incluidos factores relacionados con las personas.

Cuando la CAPA corrige a la persona pero no corrige el sistema

El mismo problema aparece al diseñar las CAPA.

Supongamos que concluimos que el operario realizó incorrectamente una intervención.

Lo reentrenamos.

Documentamos el entrenamiento.

Realizamos una evaluación.

Cerramos la CAPA.

Seis meses después, otro operario se encuentra con el mismo atasco, en el mismo equipo, con el mismo acceso difícil y bajo condiciones operativas similares.

El resultado puede ser exactamente el mismo.

La CAPA fue ejecutada.

Pero el sistema apenas cambió.

Reentrenar puede ser necesario, naturalmente. Sin embargo, una CAPA sólida debería preguntarse también qué medidas pueden actuar sobre las condiciones que generaron el riesgo.

Por ejemplo:

• Eliminar intervenciones innecesarias;
• Rediseñar un punto del equipo;
• Reducir la variabilidad de determinados componentes;
• Mejorar sistemas de alimentación o transporte;
• Modificar la secuencia de intervención;
• Incorporar herramientas específicas;
• Revisar los estudios dinámicos de visualización del flujo de aire;
• Mejorar el entrenamiento práctico mediante simulación;
• Incorporar determinadas intervenciones al APS;
• Revisar los criterios de mantenimiento preventivo;
• Desarrollar indicadores que relacionen microparadas e intervenciones;
• Integrar tendencias de Producción, Microbiología, Ingeniería y Calidad.

No todas estas acciones serán necesarias en cada caso.

Pero esta forma de pensar cambia una cuestión fundamental:

Dejamos de preguntarnos exclusivamente quién cometió el error y empezamos a preguntarnos qué debemos cambiar para que el sistema tenga menos oportunidades de fallar.

Adicionalmente, desde hace más de 10 años inspectores de la FDA raramente se conforman con el resultado de las investigaciones que llegan a que la causa raíz es error humano.

El troubleshooting necesita datos que normalmente viven separados

Otro aspecto importante es que muchas señales precursoras de una desviación ya existen dentro de la organización antes de que ocurra.

El problema es que suelen encontrarse dispersas.

Producción dispone de información sobre paradas y rendimiento.

Mantenimiento conoce determinadas averías recurrentes.

Ingeniería conoce las limitaciones de diseño.

Microbiología observa tendencias ambientales.

Calidad dispone del histórico de desviaciones.

Los proveedores conocen la variabilidad de determinados componentes.

Cada departamento posee una pieza del puzzle.

Pero nadie necesariamente está viendo la imagen completa.

Una investigación sistémica requiere conectar esas fuentes.

Por ejemplo, una pequeña parada repetida veinte veces durante tres meses quizá no parezca relevante para Producción porque apenas afecta al OEE.

Un ligero aumento de resultados microbiológicos dentro de límites puede no resultar preocupante para Microbiología.

Una intervención adicional puede considerarse rutinaria por los operarios.

Una pequeña variación dimensional puede estar dentro de especificaciones para el proveedor.

Sin embargo, la combinación de todos esos elementos puede estar describiendo una degradación progresiva de la robustez del proceso.

Aquí aparece una oportunidad especialmente importante para las organizaciones: pasar del análisis individual de eventos al análisis de relaciones entre datos.

Porque muchas desviaciones no aparecen de repente, se anuncian mediante señales débiles que no hemos conectado.

De una visión reactiva a una verdadera “Contamination Control Strategy”

Este enfoque también conecta directamente con el concepto de “Contamination Control Strategy”.

Una CCS no debería entenderse simplemente como un documento que recopila controles de contaminación.

Su verdadero valor aparece cuando permite comprender cómo interactúan esos controles y dónde se encuentran las vulnerabilidades del sistema.

El Anexo 1 establece una prioridad muy significativa: primero un diseño adecuado de instalaciones, equipos y procesos; después procedimientos bien diseñados; y finalmente sistemas de monitorización capaces de demostrar que esos controles continúan funcionando según lo previsto. El propio Anexo 1 advierte de que la monitorización o el ensayo, por sí solos, no proporcionan garantía de esterilidad.

Esta secuencia contiene una filosofía importante.

No deberíamos intentar monitorizar hasta hacer seguro un proceso mal diseñado.

Ni deberíamos esperar que el entrenamiento compense indefinidamente una operación demasiado vulnerable.

La verdadera robustez debería construirse desde el diseño.

El término causa raíz (root cause) seguirá siendo útil y seguirá formando parte de nuestros sistemas de calidad.

Pero quizás debamos utilizarlo con cierta prudencia.

En algunos problemas existe realmente una causa dominante y perfectamente identificable.

En muchos otros, especialmente en sistemas complejos, encontramos combinaciones de factores que interactúan.

En esos casos puede ser más útil pensar en una red causal:

El evento ocurre cuando determinadas condiciones de esa red coinciden y las barreras disponibles no consiguen prevenirlo o detectarlo.

Esta perspectiva no hace las investigaciones más fáciles.

De hecho, probablemente las hace intelectualmente más exigentes.

Obliga a trabajar con hipótesis.

Obliga a integrar disciplinas.

Obliga a diferenciar hechos de interpretaciones.

Obliga a analizar la fortaleza de las evidencias.

Y obliga, en ocasiones, a aceptar que quizá no podamos demostrar una única causa con absoluta certeza.

Pero proporciona algo mucho más valioso:

Una representación más realista de cómo funciona el proceso.

ICH Q9(R1) plantea el “Quality Risk Management” como un proceso sistemático de evaluación, control, comunicación y revisión del riesgo a lo largo del ciclo de vida, y subraya además la necesidad de reducir la subjetividad en la toma de decisiones basada en riesgo.

Aplicado al troubleshooting, esto significa que una investigación no debería conformarse con una historia plausible.

Debería buscar una explicación suficientemente respaldada por datos, observaciones y conocimiento científico del proceso.

El verdadero objetivo de una investigación

El objetivo del troubleshooting no debería ser exclusivamente encontrar una causa que permita cerrar una desviación.

Debería ser comprender mejor cómo funciona realmente nuestro sistema cuando se aleja de sus condiciones ideales.

Cada desviación ofrece información sobre esa realidad.

Puede mostrarnos dónde se concentran las intervenciones.

Qué variabilidades acepta el proceso.

Qué controles funcionan.

Qué barreras son demasiado débiles.

Qué información no estamos conectando.

Qué supuestos de diseño ya no son válidos.

Y, sobre todo, dónde existe una oportunidad para aumentar la robustez.

Por ello, quizás al finalizar una investigación deberíamos formular una pregunta diferente.

En lugar de preguntar únicamente:

“¿Hemos identificado la causa raíz?”

podríamos preguntarnos:

“¿Comprendemos suficientemente qué combinación de condiciones permitió este evento, qué barreras fallaron y qué hemos cambiado para reducir de forma demostrable su probabilidad de recurrencia?”

La diferencia parece pequeña.

Pero cambia por completo el propósito de la investigación.

En el primer caso, investigamos fundamentalmente para cerrar una desviación.

En el segundo, investigamos para aprender cómo mejorar el sistema.

Y a lo mejor sea precisamente esa capacidad de aprendizaje la que diferencia a una organización que gestiona adecuadamente sus desviaciones de una organización que utiliza las desviaciones para construir procesos cada vez más robustos.

---

Referencias regulatorias de interés

• European Commission. EU GMP Annex 1 – Manufacture of Sterile Medicinal Products. Especialmente los principios de Quality Risk Management, Contamination Control Strategy, diseño de procesos e intervenciones asépticas.
• ICH Q9(R1) – Quality Risk Management. Marco para evaluación y control del riesgo, análisis de causa raíz, factores causales y toma de decisiones basada en riesgo.
• FDA – Sterile Drug Products Produced by Aseptic Processing — Current Good Manufacturing Practice. Guidance enfocada en la protección robusta del producto mediante diseño y control de instalaciones, equipos, procesos y sistemas.