Validación de la base de datos de seguridad en Farmacovigilancia: qué se necesita realmente para superar una auditoría

Si tuviera que identificar la única pregunta que hace saltar de la silla a muchos equipos de PV durante una inspección, sería esta:

“¿Pueden mostrarme la evidencia de que su base de datos de seguridad está validada para el uso previsto, que los datos son íntegros y que los cambios están bajo control?”

El punto crítico no es tener “un software conocido”. Es demostrar que el sistema produce ICSRs correctos, mantiene la integridad de los datos y permite rastrear quién hizo qué y cuándo, especialmente cuando el volumen de casos crece y aumenta la presión sobre los plazos. En la Guía Master, la base de datos de seguridad se describe como el corazón tecnológico de la farmacovigilancia, y se explica de forma explícita lo crucial que es que esté validada y sea segura.

Por qué la base de datos de seguridad es GxP-critical (aunque no la llamen “GxP”)

En farmacovigilancia, la base de datos no es un simple archivo: es un sistema que debe soportar procesos regulatorios con impacto directo en pacientes y compliance. En la práctica, debe:

• mantener la auditabilidad end-to-end (data entry → medical review → submission),
• generar outputs estructurados (E2B(R3)) sin errores de mapping o interfaces,
• gestionar el versionado de MedDRA y los recodings sin perder trazabilidad,
• proteger la confidencialidad (accesos perfilados) y garantizar la business continuity (backup/restore).

La Guía Master deja claro que el QPPV debe estar informado sobre el estado del sistema y que la base de datos debe garantizar integridad y seguridad de los datos.

El mito peligroso (contrarian insight): “El vendor ya lo validó, así que estamos cubiertos”

Esta es una práctica obsoleta y arriesgada.

Por qué es un mito:
La validación del proveedor cubre el producto estándar. Una auditoría, y la lógica GxP sólida, exigen evidencia de su intended use: configuraciones, workflows, roles, interfaces, reporting y, sobre todo, cómo se utiliza realmente el sistema dentro de la empresa.

Riesgo típico en auditoría: una base de datos “vendor-validated” pero con:

• configuraciones cambiadas “sobre la marcha” sin pruebas documentadas,
• perfiles de usuario demasiado permisivos (sin segregación de funciones),
• audit trail presente pero nunca revisado,
• parches/upgrades aplicados sin regression testing.

El enfoque que resiste en inspección: CSV risk-based + Data Integrity (ALCOA+)

Cuando hablamos de Computer System Validation (CSV) en PV, el enfoque más defendible es:

• definir el intended use (qué debe hacer el sistema dentro de su sistema PV),
• aplicar una validación risk-based (no “probar todo”, sino probar lo que impacta compliance y al paciente),
• demostrar la Data Integrity mediante la lógica ALCOA+.

LSI terms (nuevos respecto a artículos anteriores): ALCOA+, audit trail review, Computer System Validation (CSV), URS, IQ/OQ/PQ, GAMP 5, Annex 11, 21 CFR Part 11, RBAC, Validation Traceability Matrix.

Deliverables “mínimos” que un auditor espera (y que deberían encontrarse en 2 minutos)

Los 7 puntos técnicos que casi siempre generan findings

1) Audit trail: existe, pero no se usa

Un audit trail no sirve de nada si:

• nadie sabe cómo extraerlo,
• no existe un procedimiento de audit trail review,
• no hay criterios para definir qué es “anómalo”.

Práctica que funciona: una revisión periódica risk-based (por ejemplo mensual) centrada en:

• cambios en seriousness/expectedness,
• cambios en suspected/concomitant products,
• eliminaciones/merges,
• overrides de reglas automáticas.

2) Accesos mal perfilados y “cultura de super-user”

En auditoría, el patrón más frecuente es ver:

• demasiados usuarios con privilegios elevados,
• cuentas compartidas,
• ausencia de revisión periódica de accesos.

Sugerencia operativa: establecer una User Access Review trimestral con evidencia firmada (PV + QA/IT).

3) Time zone & date logic (enormemente subestimadas)

A los auditores les encantan los bugs “silenciosos”:

• fecha de recepción vs fecha de awareness,
• zonas horarias de affiliates → cálculo incorrecto de plazos,
• campos obligatorios que en realidad no son obligatorios.

Impacto real: late reporting “del sistema”, no “humano”.

4) Interfaces y mapping E2B(R3)

Si tienen gateways hacia EudraVigilance o integraciones (MI/CRM/email intake), el auditor suele pedir:

• evidencia del mapping,
• resultados de la reconciliación,
• gestión de fallos (re-try, queue, incident management).

5) Migraciones de datos y reconstrucción de la historia

¿Cambio de versión o cambio de vendor? Sin una estrategia de data migration con controles de completitud, pueden acabar con:

• casos sin historial de follow-up,
• narratives truncadas,
• adjuntos no vinculados.

6) MedDRA: gestión de versiones y recoding controlado

No es un tema “solo médico”. Es data governance:

• ¿cuándo cambian de versión MedDRA?
• ¿cómo gestionan el recoding y su impacto en aggregate outputs/reports?

7) Backup & disaster recovery: declarados, no probados

Aquí el auditor quiere evidencia concreta: un restore test documentado e idealmente un disaster recovery test periódico.

Mini-checklist “30 segundos” (para QPPV y QA/IT)

Si hoy llegara una notificación de inspección, ¿podrían presentar inmediatamente:

• URS aprobada + matriz de trazabilidad,
• últimos change control reports y regression tests,
• evidencia de audit trail review,
• evidencia de access review (RBAC),
• último reporte de backup/restore test,
• incident log y desviaciones del sistema PV,
• training records de usuarios clave (PV/IT/QA)?

Recuadro “Para recordar”

Validación no significa “no tener problemas”. Significa tener un sistema que:

• detecta errores,
• los rastrea,
• los corrige mediante change control,
• demuestra que los datos siguen siendo fiables.

Conclusión (y por qué conviene hacerlo bien)

Una CSV bien ejecutada en PV no es burocracia. Es lo que evita late reporting sistémicos, envíos E2B erróneos y, sobre todo, findings críticos que después se convierten en CAPAs costosas y urgentes.