thebench.bio #1 Ecosystem for the Bio-Tech Industry
All Pharmacovigilance questions

Question 16 of 20 Advanced Practical

How would you quality-check the transfer of adverse event data between safety databases?

Short answer

Treat the migration as a validated process: map every field, rehearse with mock and real sample data, then reconcile case counts, key fields and reportability after the move. Pay most attention to fields that drive regulatory decisions, such as seriousness, expectedness, causality, dates and MedDRA codes.

Why

EMA's GCP inspectors' guideline on computerised systems uses moving individual safety reports from one safety database to another as its example of data migration. It says migration validation deserves no less focus than validating the system itself, and asks for a risk analysis, a rehearsal with mock data, documented mapping and verification focused on key data. In safety, the key data are those that decide whether a case is reported, when, and to whom: seriousness criteria, expectedness against the reference safety information, causality, day zero, country and product.

A migration that silently converts 'unknown' seriousness to 'non-serious' would lead to missed reports and wrong aggregate counts. Case versions and audit history must also come across, or at least remain accessible, so an inspector can see when each decision was made. MedDRA versions may differ between systems, so recoding rules need sign-off.

After go-live, run reports from both systems on the same cut, such as counts by seriousness and by product, and investigate any difference before the old system is retired.

How to work it through

  1. Inventory source and target fields and write a mapping with transformation rules.
  2. Rank fields by regulatory impact, putting seriousness, expectedness, causality and dates first.
  3. Rehearse the migration on mock data and a representative sample of real cases.
  4. Reconcile counts and key fields between systems, case by case for a sample and in aggregate for all.
  5. Check that case versions and audit history are migrated or kept accessible.
  6. Sign off and keep the old system readable until reconciliation is closed.

An example

A company moves 48,000 cases to a new safety database. Rehearsal on 2,000 cases shows 312 with seriousness 'unknown' mapped to blank, which the new system treats as non-serious. The mapping is fixed to keep an explicit unknown.

In production, total counts match, and counts by seriousness, product and country match within zero. A 500 case sample review finds 4 cases where follow-up versions were merged into one. These are restored from the legacy archive before sign-off.

Where the answer stops holding

Sample checks cannot prove every case migrated correctly, so aggregate reconciliation is needed too. Some legacy fields have no equivalent in the new system and need documented decisions. Migrations during heavy reporting periods risk late submissions if processing is paused.

A strong answer covers

  • Migration validated like a system
  • Fields ranked by regulatory impact
  • Rehearsal with mock and sample data
  • Case and aggregate reconciliation
  • Versions, audit history and MedDRA recoding

Common mistakes

  • Checking only total case counts.
  • Losing case version history in the move.
  • Retiring the old system before reconciliation is complete.