SAE Reconciliation with Pharmacovigilance (PV)

Why this matters

Sites record adverse events in the Electronic Data Capture (EDC) system and separately report each serious one directly to the Pharmacovigilance (PV) team, usually within 24 hours. PV maintains the official safety case database used for expedited reporting and periodic submissions. These systems are built for different purposes, so they will never be identical. If you don’t apply a simple, repeatable reconciliation pattern, important Serious Adverse Event (SAE) cases can be missing in one system, dates may drift, and subject identities can be mis‑matched. The result: delayed database locks, high‑stress fire drills at submission time, and inspection findings.

A disciplined approach—presence → identity → timing—keeps the noise down and makes root‑causing fast and auditable.

Core concepts & definitions

• Adverse Event (AE) vs Serious Adverse Event (SAE) An SAE is an AE that meets any seriousness criterion: death, life‑threatening, inpatient hospitalization or its prolongation, persistent or significant disability, congenital anomaly, or another important medical event. Severity (mild/moderate/severe) is not the same as seriousness.

• PV safety case / ICSR The PV database stores Individual Case Safety Reports (ICSRs). An ICSR can be updated many times; each update is a version of the same case.

• Presence reconciliation Does a given SAE appear in both the EDC SAE pages and the PV safety database?

• Identity reconciliation Do subject identifiers, site identifiers, and PV case numbers match the same real‑world person and event?

• Timing reconciliation Does the same date (onset, end, admission, death) agree in both systems? Compare like with like: the clinical onset date and the PV initial receipt/awareness date are different fields, both correct, and normally differ.

• Owner routing Who takes the action?

  • Site/Investigator reports each SAE and its follow‑up directly to PV, and enters and corrects the case report form (CRF) in EDC.
  • PV creates/updates the safety case, reviews the investigator’s seriousness and causality assessments, decides expectedness, and handles regulatory reporting.
  • Data Management (DM) coordinates, logs, and confirms alignment without unblinding the study.
  • Medical Monitor (MM)/Safety Physician answers medical questions.

Reconciliation flow, step‑by‑step

1. Set scope & cadence Reconcile cumulatively: each run covers all SAEs to date, with both extracts taken at the same cut‑off date. The data management plan (DMP) names who leads, the fields compared, and the cadence (e.g., monthly). Increase cadence near data monitoring committee (DMC, also called DSMB) meetings and database lock (weekly or even daily).

2. Extract aligned lists

   • From PV: case line listing with case number, subject ID, site, event term, clinical onset date, PV awareness/receipt date, seriousness criteria, outcome, and latest version.
   • From EDC: SAE page listing with subject ID, site, event term, onset date, seriousness criteria fields, outcome, and a field to store the PV case number (also called PV case ID).

   Event term, seriousness criteria, and outcome are compared as well as dates; PV and DM code terms separately, so the same medical concept counts as a match.

3. Normalize keys Clean and standardize subject IDs and site identifiers in the comparison files, not the source systems. Resolve common issues (dashes vs spaces, case sensitivity, rescreens).

4. Compare presence (two directions)

   • PV‑only → Query site to add/complete the SAE in EDC or document why the event is not recorded as an SAE in EDC.
   • EDC‑only → Alert PV, which checks for a case under another ID. If there is none, query the site to send its SAE report to PV at once; PV opens the case, and the late report is documented. The only exceptions: the protocol exempts the event from immediate SAE reporting (e.g., a pre‑specified endpoint; it is still documented and reconciled with PV), or the site confirms the event is not serious and corrects the EDC.

5. Check identity Match subject ↔ site ↔ PV case number. Resolve mapping errors (e.g., subject re‑assignment, merged subject records, wrong site code) at the owner: PV corrects the safety case, the site corrects the EDC through a query, and DM records the mapping.

6. Align timing Compare each date with the same date in the other system: onset, end, admission, and death dates should match, and a mismatch goes to the site or PV to correct. The PV awareness/receipt date is a different field, normally later than clinical onset; record the rationale for that gap (e.g., the site learned of the event four days after onset).

7. Protect blinding Route questions using neutral language (“Please confirm PV case exists and provide case number”) and keep treatment assignments segregated with unblinded safety personnel where applicable. PV may have unblinded single cases for expedited reporting, so its listing for DM excludes treatment and unblinded fields.

8. Close the loop

   • Record the PV case number on the EDC SAE page (entered by the site or loaded by a validated integration, not typed by DM).
   • Ensure PV records include the EDC subject and site identifiers.
   • Update a Reconciliation Log with the discrepancy, owner, action, date fixed, and evidence.

9. Sign‑off & file DM reviews the resolved set, obtains PV/Safety sign‑off if required, and files the run results to the trial master file ((e)TMF). The final run before lock uses a fresh PV extract; DM and PV sign that every discrepancy is closed or documented.

What good looks like

• A simple decision table everyone follows (see below).
• A mandatory PV Case ID field on EDC SAE pages, populated before lock.
• A time‑boxed cadence (e.g., monthly; weekly near DSMB/lock) with each run signed and filed.
• A Reconciliation Log that shows what was changed, by whom, when, and where the evidence lives.
• Clear blinding safeguards (who can see what, and how queries are worded).

Decision table (presence → identity → timing → action)

Worked examples

The examples below are self‑contained—you can read each one independently.

Example A — PV has a case; EDC is missing the SAE page (Presence)

Context: A cardiac hospitalization was phoned to PV and processed as an ICSR last week. No SAE page exists in EDC for Subject 102‑004.

Steps:

1. DM confirms the PV case number and the subject/site mapping.
2. DM raises a neutral query to the site: “PV holds an SAE report from your site for this subject (cardiac hospitalization, reported last week). Please record the event on the SAE page and enter the PV case number quoted in this query.”
3. Site enters the SAE page; DM checks that the seriousness criteria, dates, and outcome agree with the PV case.
4. DM records resolution in the Reconciliation Log.

Outcome/Evidence: EDC SAE page present and complete; PV case number filled; log updated with date and owner.

Example B — EDC marks SAE “Yes”; PV has no case (Presence)

Context: EDC shows “SAE = Yes” for Subject 205‑011 with onset 15‑May. PV finds no corresponding ICSR.

Steps:

1. DM alerts PV; PV confirms no case is filed under another subject or site ID.
2. DM queries the site: “The event with onset 15‑May is marked serious. Please confirm it has been reported to PV.” The site sends its SAE report at once; PV opens a new case, assigning a PV case number.
3. DM queries the site to add the PV case number to EDC and confirm any missing fields (hospitalization dates); the late report is documented.

Outcome/Evidence: New PV case exists; EDC contains the PV case number; both systems agree on presence.

Example C — Identity mismatch due to rescreen (Identity)

Context: A subject was rescreened and randomized under a new ID. PV recorded the SAE under the old ID; EDC uses the new ID.

Steps:

1. DM confirms with the site the correct mapping of old → new subject IDs.
2. PV updates the ICSR subject identifier in a new case version; any EDC field that links the old and new IDs is completed by the site, not DM.
3. DM places the mapping note in the log and files the site confirmation email to the TMF.

Outcome/Evidence: PV and EDC use the same subject/site identifiers; decision recorded.

Example D — Onset vs PV awareness date differ (Timing)

Context: Subject 109‑007 had a stroke on 01‑Jun (onset) but the site learned of it on 05‑Jun after hospital records arrived. PV uses awareness/receipt date = 05‑Jun.

Steps:

1. DM checks that the EDC SAE page shows onset 01‑Jun (a doubt about the date would go to the site as a query).
2. PV confirms the case also has onset 01‑Jun and that 05‑Jun is when the sponsor first learned of the event.
3. DM documents that “onset dates match (01‑Jun); the four‑day gap to PV awareness/receipt (05‑Jun) reflects when the site learned of the event.”

Outcome/Evidence: No data changes; a clear rationale is in the log; inspectors can see why dates differ.

Example E — Late discovery one week after lock (Presence & Timing)

Context: One week after database lock, DM notices an SAE in PV without a matching EDC page. PV already holds the case; an SAE missing from PV would be reported by the site to PV at once, whatever the lock decision.

Steps:

1. DM convenes cross‑functional review (PV, Biostatistics, Clinical Ops, MM).
2. Assess impact on analyses, listings, and submissions.
3. Decide action: unlock (if impact is material), issue an addendum/updated listing, or document no impact with justification. After an approved unlock, the site (not DM) enters the SAE page before re‑lock.

Outcome/Evidence: Impact memo approved; chosen action executed; lock documentation updated.

Pitfalls & misconceptions

• Treating PV as a copy of EDC. They serve different purposes: shared fields must agree, but PV also holds dates (awareness, receipt) that the EDC does not.
• Ignoring identity merges/splits (rescreens, site transfers) until submission—fix mappings as soon as they appear.
• Leaving PV case number optional in EDC—make it mandatory before lock.
• Unblinding risk in queries. Don’t include treatment or randomization clues in messages to blinded staff.
• Assuming any post‑lock find requires instant unlock. Do an impact assessment first and document the decision.

Practice in the wild (checklist)

• Stand up a PV↔EDC reconciliation job that classifies issues as Presence / Identity / Timing.
• Add a PV Case ID field to EDC and require it before lock.
• Normalize subject and site identifiers (trim, case, dashes) in both exports.
• Run on a fixed cadence; increase frequency near DSMB and lock.
• Maintain a Reconciliation Log with: discrepancy, owner, action, date closed, evidence path.
• Use neutral wording in queries to protect blinding.
• For late discoveries, convene a cross‑functional impact assessment and file the outcome.

Key points to remember

• Follow the reconciliation sequence: Presence → Identity → Timing.

• Route actions to the right owner and keep roles clear:

  • Site/Investigator: report each SAE and its follow‑up directly to PV; create/update SAE pages in EDC and complete missing fields.
  • PV: create/update the safety case, review seriousness and causality (the investigator assesses them first), decide expectedness and regulatory reporting; provide the PV case number.
  • DM: coordinate the process, maintain the reconciliation log, protect blinding in communications, ensure PV case number is captured in EDC, and confirm both systems align on case and key dates.
  • Medical Monitor/Safety Physician: answer medical questions.

• Compare the same date in both systems (onset with onset); EDC clinical onset vs PV awareness/receipt is a legitimate date difference: validate and document the rationale rather than forcing a match.

• Make the PV case number on EDC SAE pages mandatory before lock.

• Protect blinding with neutral, treatment‑agnostic wording and segregated access.

• For late discoveries near/after lock, run a cross‑functional impact assessment (DM, PV, Biostats, Clin Ops, MM) to decide unlock vs addendum vs no impact, then document and file the decision.