SAE Reconciliation in Clinical Trials: Key Challenges

2.1 Event-level (CDB) vs. Patient-level (SDB) structure

The CDB records SAEs per event, whereas the SDB records them per patient/case, creating mismatches in row structure, event counts and follow up behaviour. A single clinical episode may be split differently across systems and follow up updates in the SDB can shift the entire case, breaking previous mappings. The solution is to reconcile at the event level by decomposing SDB cases into discrete events, applying a composite matching key (Subject ID + verbatim/PT + onset date), and using field level match rules with defined ownership. This aligns both systems on a common unit of comparison and removes most structural discrepancies.

A direct consequence of this mismatch is the decision required when a second SAE occurs in the same patient: whether it is a follow up or a new ICSR. The CDB simply adds another event row, but the SDB must determine whether the new information relates to an already reported event or represents a distinct new event. Incorrect splitting creates duplicate ICSRs, broken follow up chains and distorted aggregate counts. The solution is to define an explicit case versus follow up convention in the Safety Management Plan: progression, seriousness upgrades or new information constitute follow up, while a new clinically distinct event constitutes a new case. Each new serious event must retain its own Day 0 and reporting clock, and reconciliation should continue at the event level to maintain consistency.

2.2 GDPR misinterpretation on safety data fields

Clinical teams often apply clinical‑trial minimisation rules to dedicated safety fields, stripping information that pharmacovigilance is legally required to collect under GDPR Art. 6(1)(c)/(e), Art. 9(2)(i) and Regulation 520/2012. This results in under‑populated safety records, unnecessary follow‑up and reconciliation discrepancies that are governance artefacts rather than true data errors. The solution is targeted minimisation: clearly flag safety fields in the EDC, define the personal‑data elements PV requires and why, align Legal/DPO, Clinical and PV on the correct privacy model, and handle onward masking to EudraVigilance per GVP VI Addendum II rather than by under‑collecting at source. This ensures PV receives the data it is legally obliged to process while maintaining appropriate privacy safeguards.

2.3 Manual, time-consuming reconciliation performed at long intervals

Manual, infrequent reconciliation, often performed only pre‑lock, leads to large volumes, faded case memory, timing artefacts and late discovery of discrepancies. This is a recurrent inspection finding. The solution is to automate and increase the frequency of reconciliation through validated scripts or tools, scheduled monthly or quarterly cycles, automated presence checks for events missing in one system, and discrepancy‑age tracking. Regular cadence keeps both systems aligned and ensures reconciliation never lags expedited reporting timelines.

2.4 Recurring field-level discrepancies

Even when cases are correctly matched, individual fields frequently disagree. Typical discrepancies include differences in verbatim terms, MedDRA coding, onset or outcome dates, action taken, seriousness criteria, causality assessments and event outcomes. These inconsistencies usually arise from independent updates, different MedDRA versions, partial date handling, mismatched picklists or follow up applied to only one system. Because seriousness, causality and expectedness determine SUSAR reportability, these discrepancies carry significant regulatory weight. The solution is upstream harmonization: standardising extracts and variable names, aligning MedDRA versions and coding conventions, mapping picklists one to one, defining a single source of truth per field, and ensuring medical and coding differences are routed to the correct owner rather than treated as data entry errors.

2.5 Multi‑level vs. binary causality

Investigators assess causality within the CDB using a graded scale, while the SDB requires a binary value. Without a documented mapping, middle‑scale values such as “unlikely” or “possible” are interpreted inconsistently, producing recurrent discrepancies and potentially altering SUSAR reportability. The solution is to define a conservative, study‑specific mapping from graded to binary values, capture both the original and derived assessments, and train sites, DM and PV on consistent application. This preserves traceability and ensures that the binary value never understates reportability.

2.6 Additional difficulties observed in practice

Non‑standardised extracts, blinding constraints, latency between systems, identifier mismatches, follow‑up drift, weak traceability and privacy exposure during manual comparison all complicate reconciliation and weaken inspection readiness. The solution is strengthened governance: formalising roles, frequency, matching keys and escalation triggers in a reconciliation plan; maintaining a controlled, auditable reconciliation log; applying privacy‑by‑design to the reconciliation process; and agreeing blinding rules before first‑patient‑in. This creates a stable, compliant and auditable reconciliation framework.