El malentendido que genera hallazgos “gratis”

“Es un método oficial, así que funciona.”
En una auditoría, esa frase es una invitación al hallazgo. La guía destaca que la ausencia de method verification es una de las observaciones más frecuentes (“compendial methods not verified”), porque un método —aunque sea compendial— puede comportarse de forma distinta en su laboratorio (equipos, reactivos, matriz, analistas, condiciones ambientales).

Verification vs Validation: cómo explicarlo en 30 segundos (sin atascarse)

En auditoría hace falta una distinción clara (práctica, no académica):

• Method validation: se demuestra que un método (a menudo desarrollado internamente o modificado de forma significativa) es adecuado para su uso previsto.
• Method verification (compendial): se demuestra que el método compendial adoptado es ejecutable y funciona correctamente en su contexto real (producto/matriz, equipos, set-up).

Cuándo la verification es prácticamente “no negociable”

Desde una perspectiva inspectiva, la necesidad de verification aumenta cuando:

• la matriz es compleja (oleosa, con alto contenido de excipientes, etc.);
• cambia el equipo/la columna/el kit respecto al contexto típico;
• el método es crítico para release (assay, impurezas, dissolution, microbiología);
• se han hecho incluso pequeños cambios operativos (que aun así afectan a parámetros críticos).

Estructura del dossier “audit-proof”: qué debe contener

Si quiere que la verification cierre la pregunta del inspector, constrúyala como un mini-dossier estandarizado:

1) Portada + objetivo + referencias

Producto/material, ensayo, referencia compendial (capítulo/monografía), versión aplicada.
Declaración de intención: “Verificar la idoneidad del método compendial en las condiciones del laboratorio”.

2) Gap assessment frente al compendio

• Qué se aplica as is.
• Qué difiere (aunque solo sea una columna equivalente, un reactivo distinto o el software).
• Justificación técnica + risk statement.

Este punto es esencial porque la guía señala como red flags las desviaciones no documentadas y las SOP genéricas.

3) Diseño experimental (risk-based)

La guía sugiere un enfoque ágil: repetir ensayos clave como precisión/especificidad y, cuando sea relevante, linealidad.

Ejemplo de set mínimo (a adaptar al ensayo):

• Precisión (repeatability): réplicas sobre muestra real (y/o estándar enriquecido).
• Especificidad: interferencias de matriz/impurezas conocidas cuando aplique.
• Linearity/range: si el método es cuantitativo y el riesgo lo requiere (por ejemplo, assay).
• System suitability: demostrar que se cumplen y registran los criterios compendiales (SST records siempre disponibles).

4) Acceptance criteria “defendibles”

Regla de oro: definir los criterios antes de ejecutar el estudio, no después.
Si el inspector oye “lo revisamos y parecía estar bien”, la probabilidad de un hallazgo aumenta.

5) Ejecución + raw data + desviaciones

• Raw data completos (cromatogramas, integraciones, cálculos, registros del instrumento).
• Gestión de desviaciones (si ocurre algo durante el estudio, debe quedar trazado).

6) Informe + conclusión + aprobaciones

• Conclusión clara: “Método adecuado / adecuado con limitaciones / no adecuado”.
• Aprobación QA.
• Formación de los analistas y fecha de go-live.

Las 5 red flags que desencadenan preguntas en cadena

Según la guía, las más comunes son:

• Desviaciones no documentadas (“cambiamos la fase móvil/la columna porque así funciona”).
• Versión farmacopeica desactualizada.
• SST no registrada o no archivada.
• SOP demasiado genérica (no reproducible).
• Personal no formado (no sabe explicar diferencias ni justificación).

“Tuvimos que adaptar el método”: cómo decirlo sin marcarse un autogol

Si ha cambiado algo, la guía es clara: sin justificación y datos comparativos, esto es un hallazgo típico.

En auditoría, la fórmula más segura es:

• Declaro la diferencia (transparencia).
• Muestro la justificación (científica).
• Muestro los datos (comparability/verification/validation).
• Muestro la gobernanza QA (change control + aprobaciones).
• Muestro que el impacto regulatorio se ha gestionado (si aplica).

Mini-script: preguntas de inspección y respuestas “buenas”

P: “¿Dónde está la verification del método USP/Ph. Eur.?”
R: “Tenemos un dossier de verification para cada método compendial crítico: aquí están el protocolo, los raw data y el informe aprobado por QA. Verificamos los parámetros de mayor riesgo en nuestro contexto”.

P: “¿Por qué utilizan una columna distinta?”
R: “Es una columna equivalente; documentamos la evaluación y demostramos que la SST y el rendimiento son comparables. Aquí están los datos comparativos y el change control”.

Checklist rápida (para colgar en el laboratorio)

• He identificado la versión compendial correcta y vigente
• He realizado el gap assessment y documentado las diferencias
• He definido acceptance criteria antes de la ejecución
• He archivado raw data + SST + cálculos
• QA ha aprobado el informe y el go-live
• Formación completada y registrada

Si quiere un soporte listo para usar para construir dossiers defendibles (estructura, checklists y lógica inspectiva), la guía completa incluye la hoja de ruta y ejemplos prácticos para prepararse para inspecciones multi-región.