SAE reconciliation between the safety and clinical databases

SAE reconciliation, also called safety database reconciliation, is the comparison of every serious adverse event in a sponsor's safety database with the same event in the clinical trial database, so that the two agree with each other and with source before database lock. It confirms that each event exists in both systems and that the event term, onset and stop dates, seriousness criteria, causality and outcome match. Each discrepancy goes back to the site, data management or the safety team until it is resolved or explained.

Each discrepancy costs data management and pharmacovigilance hours. Sponsors compare that line across contract research organization bids and see it in the time between last patient visit and database lock. When a discrepancy turns out to be two readings of the same note rather than new safety information, those hours produce no safety finding.

Why is every SAE recorded in two databases?

Under 21 CFR 312.64(b), an investigator must immediately report any serious adverse event to the sponsor, "whether or not considered drug related," with an assessment of whether the drug may have caused it. The same paragraph carves out study endpoints: an SAE that is an endpoint, such as all-cause mortality, "must be reported in accordance with the protocol" unless there is evidence suggesting the drug caused it. ICH E6(R3), adopted on January 6, 2025, carries the same rule and exception in section 2.7.2(b) (page 15), and asks for follow-up information as a follow-up report.

So most serious adverse events are recorded twice:

• The safety database holds the SAE case: the site's report, the sponsor's MedDRA coding, its causality assessment and every follow-up. It feeds expedited reporting, including IND safety reports under 21 CFR 312.32.
• The clinical database holds every adverse event, serious or not, in the eCRF adverse event log. It feeds the analysis tables and the clinical study report.

Different people enter the two records, at different times, from the same source. E6(R3) lists "SAE reconciliation" in the Essential Records Table of Appendix C, under "Documentation relating to data finalisation for analysis" (page 69). Section 4.2.6(b) (page 48) names "reconciliation of relevant databases" among the steps that finalize data sets before analysis. The Society for Clinical Data Management's Good Clinical Data Management Practices chapter on safety data (2023) recommends a standard operating procedure for it.

Which fields does SAE reconciliation compare?

Each sponsor sets its list in the data management plan. The comparison usually covers these fields:

Field	Clinical database (eCRF AE log)	Safety database (SAE case)	Why the two drift apart
Presence	Every event the site marked serious	Every SAE report received	Serious in the EDC with no report, or the reverse
Event term	The investigator's term, coded in MedDRA by data management (in oncology, the CTCAE term, itself a MedDRA lowest level term)	A MedDRA term coded from the report	Symptom against diagnosis; different MedDRA versions
Onset date	When the event began	When it began, or became serious, by convention	Late reports, cycle-relative dates, conventions
Stop date or ongoing	When the event resolved or changed grade	Updated by follow-up reports	A follow-up that reached one system only
Seriousness criteria	Serious yes or no, often with the criterion	The criteria met	A grade read as seriousness; a different criterion
Causality	The investigator's assessment, often five categories	The investigator's, beside the sponsor's own	Scale mapping; an update made in one place
Outcome	Recovered, recovering, not recovered, sequelae, fatal or unknown	The same, from the latest follow-up	Follow-up timing

ICH E2A (1994) states that "seriousness (not severity) serves as a guide for defining regulatory reporting obligations," so a clinical database that treats grade as a proxy for seriousness will disagree with a safety database that does not. The criteria are in why serious is not severe.

Three fields need rules written before first patient in, because the same answer can look like a mismatch: event term and causality, below, and dates, covered in the section on onset and stop dates.

Event term. NCI states that "each CTCAE v6.0 term is a MedDRA v28.0 LLT" (CTCAE v6.0, NCI, 2025), and the MedDRA Introductory Guide, version 28.0 (MSSO, 2025) states that "each LLT is linked to only one PT." So compare coded terms at the preferred term level: two lowest level terms under one preferred term are agreement.

Compare under one MedDRA version, too. MedDRA is released each March and September. The MSSO recommends the latest version for single case reports, while one of its recommended options for clinical trial data freezes a version at the start of each trial (MedDRA Best Practices, MSSO, 2018). Some lowest level terms become non-current between versions, so the plan names the version the comparison uses.

A symptom on one side and a diagnosis on the other is different. Fever and cough in the AE log against a discharge diagnosis of pneumonia on the SAE report is a medical question for the investigator, not a clerical one.

Causality. Common Toxicity Criteria version 2.0 introduced the collection of attribution in March 1998 (Hillman et al., Journal of Clinical Oncology, 2010). Hillman and colleagues grouped its five categories as unrelated (not related, unlikely) and related (possible, probable, definite). In the placebo arms of two phase III trials, when the same adverse event was reported for the same patient at several visits, its attribution category changed at least once 31 to 36% of the time.

A safety database holding a binary "reasonable possibility" needs that five-to-two mapping agreed in advance. The sponsor's own assessment is a separate field and need not match: ICH E2A counts a case as an adverse drug reaction when it is judged "by either the reporting health care professional or the sponsor" to have a reasonable suspected causal relationship.

Why do onset and stop dates drift between the two databases?

Dates drift even when everyone reads the same records. Two medical oncologists reviewing the same charts differed by 5 to 188 days in the assessed onset of immune-related adverse events, while agreeing almost always on when immunotherapy started and stopped (Hsiehchen et al., JAMA Network Open, 2019). The authors attribute this to interpretation, not to finding the information. Five reasons recur:

1. Late reports. A symptom reported on Friday as starting two weeks ago began two weeks back, not on the day of the call.
2. Cycle-relative dates. "Cycle 3 day 7" becomes a calendar date only with the actual dosing date for that cycle, and cycles slip for delays and holds.
3. Convention. The SAE form may record when the event became serious, such as the admission date, and the AE log when symptoms began. Unless the plan says which date each system holds, the two disagree by design.
4. Grade changes. Some sponsors want a new AE log record at each grade change; others want one record at the highest grade. The safety database holds one case with follow-ups, so stop dates line up only under the same convention.
5. The wrong date. The visit date, the assessment date or the signing date ends up in the onset field.

How do you run SAE reconciliation before database lock?

1. Write the rules first. The data management and safety management plans name the events in scope (every SAE, plus any the protocol adds, such as adverse events of special interest), the endpoint SAEs the protocol exempts from immediate reporting, and any difference between the SAE and AE collection windows. They also set the match keys, the fields, the MedDRA version each system codes to, the coding level, date conventions, causality mapping, frequency and owners.
2. Reconcile during conduct. Passes through the study keep each discrepancy close to its encounter, so the final pass confirms rather than discovers. A plan can tie passes to data monitoring committee reviews, interim analyses and the DSUR data lock point.
3. Pull and match. Export the SAE listing from the safety database and the serious events from the clinical database. Match on subject and the SAE or case number where the eCRF carries one, then compare term and onset as fields, not keys.
4. Classify each discrepancy. Missing in one system; a recording difference; new information, such as a follow-up; or expected by design, such as an endpoint SAE reported per protocol or an event outside one system's collection window. The last class is documented rather than queried.
5. Route it. Source questions go to the site as queries, coding and case updates to the safety team, and eCRF corrections to data management. E6(R3) section 2.12.6 (page 22) asks that data reported to the sponsor be "consistent with the source records or the discrepancies explained." Sites resolve those queries against the chart, the same check behind source data verification for adverse events.
6. Close and file. Sign off the final reconciliation before lock and file it in the trial master file.

Example: reconciling one hospitalized SAE

An illustrative case:

Discrepancy	Clinical database	Safety database	Class (step 4)	Route (step 5)
Onset	Date symptoms began	Date of admission	Recording difference: date convention	Data management applies the plan's convention
Term	Fever; cough	Pneumonia, the discharge diagnosis	Recording difference needing medical review	Query to the investigator, then coding update
Causality	"Possible" on a five-category scale	Reasonable possibility: yes	Recording difference: scale mapping	Confirm against the agreed mapping; no query

What changes when each event is graded and coded once at the source?

Reconciliation stays with the sponsor's teams; what can change is what reaches them. Burna AI grades each adverse event in the note against the CTCAE version the protocol names, attaches the MedDRA lowest level term code from that version's MedDRA release, and scores attribution for each drug in the regimen using WHO-UMC and Kramer, with the reasoning shown. Every grade traces to the line in the medical record that produced it. The public record of what Burna AI does today lists the grading, the attribution and the reports below.

The fields that drift most are kept as facts from the note:

• Onset as stated. A calendar date in the note is the onset. "Cycle 3 day 7" is kept in those words rather than converted with a guessed cycle date, and a duration has its own field, so it is never read as an onset.
• One episode per grade. Each grade an event holds is its own episode with its own start. A single highest-grade record can be built from the episodes when a sponsor's convention asks for one; the episodes cannot be rebuilt from a single record.
• Seriousness apart from grade. A person records seriousness, and it rests at "not yet assessed" until someone answers. Recording an event serious opens its SAE case. Sponsor SAE and FDA MedWatch reports come from the same graded record, and where the study runs Medidata Rave, so does the AE log entry (from the note to the EDC).
• A record of what was sent. Each signed version of the SAE is kept when a newer one supersedes it, and each submission is recorded with its route: the sponsor's EDC, or a form to the sponsor's safety mailbox with the confirmation the site kept.

A grade becomes a record when a qualified investigator signs it under 21 CFR Part 11. AI suggests, clinicians decide. Human-in-the-loop, always.

When the SAE report and the AE log entry start from one signed record, a later discrepancy points to something that happened afterward: a follow-up that reached one system, a sponsor-side coding choice, or a convention applied differently. That is what reconciliation exists to find, and what a CRO prices in query economics across the portfolio.

Common questions about SAE reconciliation

Is SAE reconciliation required?

ICH E6(R3) treats it as an essential record: Appendix C lists SAE reconciliation in its Essential Records Table. The sponsor's data management and safety teams run it, or a CRO acting for them, under the procedure their plans set.

Can a discrepancy stay open at database lock?

Yes, if it is explained. E6(R3) asks for data consistent with source "or the discrepancies explained," so a difference that cannot be resolved before lock is documented with its reason in the signed final reconciliation. Expected-by-design differences are documented the same way.

What happens to SAE follow-up received after the final reconciliation?

Safety reporting continues after lock. Under 21 CFR 312.32(d), relevant follow-up information to an IND safety report "must be submitted as soon as the information is available." Whether it also changes the locked clinical database is for the sponsor's data management plan to define.

What is database lock?

Database lock is the point at which the clinical database is closed to changes so the data sets can be extracted for analysis. SAE reconciliation, query resolution and coding completion are finished before it, and E6(R3) cites a database lock checklist as an example of an essential record (section C.3.1(d), page 65).

---

Costing the SAE reconciliation line on a multi-site oncology study? See one note become a graded, attributed and coded record with its source line attached. Book a 15-minute conversation.