PHARMA LAB · PL-06-007

Revisión del audit trail en el CDS: ejemplos, prioridades y decisiones

Un informe sin anomalías no demuestra un historial completo. La revisión del CDS debe comprobar eventos incluidos, contexto y decisiones.
Ilustración técnica de una revisora comparando una cronología completa de eventos con un informe resumido en dos pantallas de laboratorio.

El informe del audit trail no muestra anomalías, pero el CDS contiene una secuencia interrumpida que el informe omite. El problema no consiste solo en leer mejor las filas: debe demostrarse que la revisión cubre el historial pertinente. Un registro disponible, una revisión realizada y una investigación concluida son tres evidencias distintas.

1. Partir del conjunto de datos y distinguir los registros

Defina la decisión que respalda la revisión y las muestras, secuencias, inyecciones, métodos y resultados relacionados. Identifique después los registros necesarios: adquisición, procesamiento, configuración y seguridad pueden estar distribuidos en distintas vistas o repositorios. Un registro de acceso no reconstruye por sí solo los cambios de integración; el informe de resultados no documenta todos los eventos.

Para cada evento pertinente, relacione identificador del objeto, usuario, fecha y hora, acción, valores o versiones anteriores y posteriores, y el motivo correspondiente. Comprenda la zona horaria y el significado del sello de tiempo; ordenar una exportación por fecha no garantiza por sí solo una cronología correcta.

Los fundamentos generales del audit trail se tratan por separado. Aquí se busca reconstruir el recorrido de un conjunto cromatográfico concreto, sin presumir que cada evento del sistema es una anomalía analítica.

2. Establecer alcance, responsabilidades y frecuencia

Identifique primero los requisitos aplicables a la revisión del registro. La guía FDA de 2018, Q7–8, vincula la revisión de cambios con la del registro e indica respetar las frecuencias establecidas por las reglas CGMP pertinentes. Cuando no se especifica frecuencia, la evaluación del riesgo considera criticidad, controles e impacto en el producto. El riesgo no autoriza a posponer un control obligatorio.

Asigne revisores formados en el método y el CDS, con acceso suficiente a las evidencias e independencia apropiada respecto de quienes generaron o modificaron los datos. QA no tiene que realizar necesariamente toda la revisión: defina tareas del departamento y supervisión de la unidad de calidad según el sistema de calidad y los requisitos aplicables.

Distinga la revisión vinculada a la operación del examen periódico de eventos del sistema, configuraciones y privilegios. Si un evento del sistema puede afectar al conjunto revisado, relaciónelo con la evaluación actual; reservarlo para un control futuro no basta. No existe una única frecuencia adecuada para todos los CDS.

3. Verificar que filtros e informes no oculten eventos

Documente las fuentes consultadas, intervalo temporal, zonas horarias, usuarios, proyectos, estados y tipos de evento incluidos o excluidos. Compruebe si el informe muestra solo secuencias completadas, resultados aprobados o versiones actuales. Evalúe también paginación, límites de exportación y posibilidad de volver al evento y al dato originales.

Un ejemplo editorial de prueba utiliza cinco eventos sintéticos conocidos: adquisición completada, interrupción, reprocesamiento, cambio del método y cambio de rol autorizado. Antes de aplicar el filtro, establezca qué eventos deben aparecer y cuáles se revisan mediante otro registro. Compare cobertura esperada y observada y documente diferencias, no solo el número de filas.

Diseñe la prueba en un entorno aislado y autorizado; no requiere eliminar datos ni desactivar el audit trail. Repítala cuando cambios en consultas, configuración o versión afecten a la cobertura. La revisión por excepción exige criterios justificados y fiabilidad demostrada: «sin excepciones» solo tiene valor si la selección funciona.

4. Relacionar cada evento con una pregunta y una acción

Esta matriz original orienta la revisión sin sustituir el procedimiento ni predeterminar su resultado. Un evento puede estar explicado, requerir información adicional o iniciar una investigación; la etiqueta del software no decide por sí sola.

EventoPregunta del revisorEvidencias relacionadasPosible resultadoAcción
Secuencia interrumpida¿Qué adquisiciones se realizaron?Secuencia, señales y estado de las inyeccionesInterrupción explicada o datos ausentesConciliar y evaluar el impacto
Reprocesamiento¿Por qué cambió el resultado?Versiones, parámetros, motivo y métodoMotivo demostrado o no sustentadoAceptar con justificación o investigar
Cambio del método¿Estaba autorizado para este conjunto?Versión, vigencia y aprobaciónUso correcto o versión inadecuadaEvaluar conjuntos afectados
Eliminación registrada¿Qué objeto y qué impacto?Evento, objeto, motivo y datos conservadosGestión prevista o pérdida relevantePreservar evidencias y escalar
Cambio de privilegios¿Permitió actuar sobre el registro?Autorización y actividades del periodoAcceso justificado o conflictoImplicar al responsable del sistema y QA
Cambio temporal¿Puede reconstruirse la cronología?Relojes, zonas y eventos relacionadosDiferencia explicada u orden dudosoAclarar antes de concluir

Para evaluar un reprocesamiento de picos, lea el registro junto con la señal y el método. Repeticiones, exclusiones o cambios posteriores a la revisión requieren contexto. Un acceso fallido no demuestra automáticamente manipulación: evalúe identidad, actividades posteriores y controles.

5. Caso simulado y registro de la conclusión

Un resumen muestra una secuencia completada. La comparación con la lista de adquisiciones revela una secuencia anterior interrumpida sobre las mismas muestras. El revisor comprueba el filtro: seleccionaba únicamente el estado «completado». Preserva ambas secuencias y reconstruye inyecciones realizadas, motivo de la interrupción, reanudación y resultados utilizados.

Si la reconstrucción es completa, documente la conclusión analítica y corrija de forma controlada el proceso de reporting. Evalúe también qué revisiones anteriores podrían estar afectadas. Si faltan datos o motivos, mantenga abierta la anomalía y active la escalada prevista. No declare completa la revisión porque la secuencia final sea conforme.

Registre alcance, fuentes, versión del informe o criterios de búsqueda, revisor, fecha, evidencias consultadas, preguntas, respuestas, conclusión y vínculos con investigaciones. Una firma sin alcance no hace reproducible el control. Cerrar una pregunta de revisión no cierra automáticamente una investigación ni libera un lote.

Reevalúe periódicamente el proceso: filtros modificados, eventos no reconocidos, formación y problemas recurrentes pueden exigir actualizaciones. Evalúe calidad de las conclusiones y cobertura, sin medir la eficacia únicamente por el número de filas leídas.

6. Referencias y aplicabilidad

Fuentes verificadas el 1–2 de octubre de 2026. Contexto de laboratorio GMP para medicamentos humanos; ejemplos simulados, ninguna actividad sobre sistemas reales. Los detalles operativos dependen del CDS y de los procedimientos aprobados.

  • FDA — Data Integrity and Compliance With Drug CGMP, versión final de diciembre de 2018, Q1c y Q7–8: definición, responsabilidades y frecuencia. Guía no vinculante que debe leerse junto con las reglas CGMP aplicables.
  • Comisión Europea — Anexo 11, revisión de enero de 2011, aplicable desde el 30 de junio de 2011, §§9, 12–13: audit trails, seguridad e incidentes. La propuesta de 2025 sigue diferenciada del texto adoptado.
  • PIC/S — PI 041-1, versión final del 1 de julio de 2021, §9.6: configuración, comprensión y revisión de audit trails. Guía de inspección GMP/GDP; la matriz anterior es original y no reproduce la del PIC/S.
Contenido técnico para decisiones informadas: no sustituye procedimientos aprobados, requisitos aplicables ni el manual del instrumento.

Seguir explorando