Abstract

Because serious adverse event (SAE) data are typically stored in a safety database separate from the clinical trial data, a reconciliation of the two datasets must be carried out to ensure consistency. In covering the procedures for completing this task, this chapter discusses the importance of cooperating with safety representatives, and of creating proper documentation of discrepancies, missing data, reconciliation and other issues encountered during this process.

Introduction

Serious adverse event (SAE) data reconciliation involves the comparison of key safety data variables between two databases. Reconciliation is performed to ensure consistency between events residing in any SAE database and those residing in the clinical database. It is an iterative process that occurs several times during the study. When to reconcile is determined by the frequency of data receipt, scheduling of safety updates, and timing of interim and final reports.

Scope

This procedure applies to all projects where both a clinical database and a drug or device safety SAE database are maintained as two separate databases.

Minimum Standards

• Create entry and edit instructions, including deletion and change control procedures.
• Standardize the capture of SAE data elements in both the clinical database and the safety database.
• Conduct the reconciliation of event terms so they are at least similar if not exactly the same.

Best Practices

• Establish the time intervals in the project where reconciliation will be performed and in particular the mechanisms to cover interim analyses or safety data reporting. Often SAEs continue to be reported after a clinical trial has concluded. Some companies collect information in a single database and some companies collect information in two separate databases: a safety database and a clinical database. It is important to establish a cutoff point after which no SAEs will be added to the clinical database, even if the safety data or safety database is updated.

• Identify the data items to be reconciled. This may include, but not be limited to the following:

  • Protocol

  • Investigator

  • Subject identification

    • Randomization number

  • Initials

    • Date of Birth

    • Gender

    • Race

  • Event number

  • Diagnosis

  • Verbatim

  • Coded or preferred term

  • Onset date

  • Resolution date

  • Date of death

  • Outcome

  • Severity

  • Causality assessment

  • Action taken with study drug

Sometimes data items are used from other modules for further reconciliation or clarification.

• From the demography module, items used may include but not be limited to the following:
  • Subject identification
  • Weight
    
  • Date of birth
    
  • Gender
  • Race

• From the discontinuation module, items used may include but not be limited to the following:
  • Subject identification
  • Primary reason for discontinuation being an event
    
  • Cause of hospitalization
  • Cause of death listed on the death certificate
    
  • Autopsy result

• From the concomitant medications module, items used may include but not be limited to the following:

  • Subject identification

  • Medication name

  • Start date
  • Stop date or ongoing
  • Indication

• When possible, customize database fields used in reconciliation to be programmatically compared without compromising the integrity of the software or databases. Even programmatic reconciliation of fewer than 100 events can be cost effective in both time and quality. The process can be validated once and run as frequently as data and time allow.

• When initiating the reconciliation process, clinical data management should confirm that all data to be included in the reconciliation have been entered and validated. Clinical data management should also confirm that any data clarifications have been returned and applied to the clinical database, and that the coding of AE verbatim terms against the common dictionary has been completed.

• Clinical data management, safety leads, and clinical operations should establish a mutually agreeable turnaround time for researching, retrieving, and correcting any discrepancies found during or since the last reconciliation period.

• Read–write access to either database (but not both) is granted to personnel trained in data entry for the purpose of and whose responsibilities include data entry, data modification, or data validation. Read–only access is granted to personnel related to reconciliation, but who are not directly responsible for those tasks related to data modification. System administration rights are limited to personnel responsible for database configuration.

Procedures

• Some companies maintain two databases: a safety database and a clinical database. Conversely, some companies collect all information in a single database. When two databases are used, obtain the SAE information to be reconciled from both the safety and the clinical databases.
  • Listings are produced from either the safety database or the data management database, and the two databases are manually reconciled through direct comparison of these listings. However, in some instances the two databases can be compared programmatically and a listing of differences provided. Either way, the differences will require manual review by trained staff. Ancillary documents can also be used for clarification or corroboration, such as hospitalization discharge summaries, death certificates, or autopsy reports.
• Verify that all SAEs from the clinical database also reside in the drug safety database. Note that some SAEs from the safety database may not be in the clinical database until all CRFs are collected and entered.
• Document all SAEs included in the clinical database but not included in the safety database. These are potentially unreported events. Include copies of the appropriate CRFs to be forwarded to the safety contact person.
• Research all SAEs in the safety database that are not found in the clinical database.
  • If the visit has been monitored, collected, and entered by CDM, the site should be queried to request the original missing event page. Do not add SAEs to the clinical database without the data for that visit having been monitored against source documents according to the study’s clinical monitoring guidelines. Only those updates signed and dated by site staff after the CRF page has been monitored and retrieved are acceptable for updating the clinical database.
• Research and resolve all differences between SAEs that are present in both databases.
• Depending on the nature of discrepancies, it may be necessary to seek input from the medical monitor or designee before deciding on a course of action.
• Some discrepancies are acceptable. For example, slight variations in terminology used in describing events may be of no consequence. Also, start dates may differ, as an event may start as nonserious before progressing to serious.
• Site-authorized updates to CRFs received by clinical data management are copied to drug safety for assessment and, if appropriate, for inclusion in the safety database. Clinical data management generates queries to clarify discrepancies, and forwards them to the sites for resolution. Resolved queries from the site are returned through data management, to be used to update either or both databases by their respective staff. Communication of these updates can be facilitated by use of a standard template, such as the Sample SAE Data Reconciliation Form provided in Appendix A of this chapter.
• Prior to data lock, verify that all queries have been correctly returned and integrated into the database. A quality control process should be in place to ensure this is done accurately and consistently. Ensure that all expected SAE information has been received and reconciliation has been performed on all events. Written notification should be made when reconciliation has been successfully completed. This helps avoid confusion should the safety database be held open for updates after the study ends.
• Any final inconsistencies that cannot be resolved should be documented in a CDM Data Handling Report or the equivalent.

Recommended Standard Operating Procedures

• Safety Database Setup, Management, and Validation
• Serious Adverse Event Reconciliation Work Instruction
• Coding of Clinical Data