Tag Archives: SAE reporting

Data Management Plan – Coding and Reconciliation

All Adverse Events and Previous/Concomitant Medication should be coded and/or approved prior and during the trial.

Before adverse event terms can be reported or analyzed, they must be grouped based on their similarities. For example, headache, mild headache and acute head should all be counted as the same kind of event. This is done by matching (or coding) the reported adverse events against a large codelist of adverse events which is also known as dictionary or thesaurus.

Test cases and other documentation associated with the testing of auto-coding should be produced/documented.  This documentation is not part of the plan. It is a product of the design process and should be filed separately in the TMF system.

In the DMP. you should document the variables and the dictionary to be used.

For Concomitant Medications, WHO drug reference list is used.  Also document the version used and if applicable, the final version of the who drug (for trials running over 6 months).

For Adverse event, MedDRA dictionary is the choice of coding method. Document the version used.

Serious Adverse Event (SAE) Reconciliation:

Indicate SAE Reconciling Approach to be used to compare SAE database (e.g. Argus) to the Clinical study| database (e.g. EDC):

  • Indicate tools to be used
  • Location of SAE data
  • Planned timing
  • Planned frequency of SAE Reconciliation activities

What to look for during reconciliation:

  • There are matched cases but minor differences such as onset date
  • Case found in the CDMS but not in the SAE system
  • Case found in the SAE system but not in the CDM system

Methods for Reconciliation:

For electronic-automatic reconciliation between systems, there are some challenges you need to identify first such as which type of data is to be reconciled and then which fields to compare. Best practice is to reconciled those considered serious according to regulatory definitions.

For manual reconciliation, reports such as SAS listings extracted from both systems with study information, subject or investigator and other key data can be used to perform manual review.  A manual comparison of the events can then assure that they are both complete and comparable.

Central Coding Anayansi Gamboa
Central Coding

No matter which method you used for reconciliation, each type of data (eg, AE, MedHist, Conmed) should document which glossaries and version were used.

When data from the clinical trial database is entered into a drug safety database for coding, the data between the two systems should be reconciled to verify the data in both systems are

identical. The processes and frequency of reconciliation should be specified.

Source:

DIA -A Model Data Management Plan StandardOperating Procedure: Results From

the DIA Clinical Data Management Community, Committee on Clinical Data Management Plan

-FAIR ;USE-
“Copyright Disclaimer Under Section 107 of the Copyright Act 1976, allowance is made for “fair use” for purposes such as criticism, comment, news reporting, teaching, scholarship, and research. Fair use is a use permitted by copyright statute that might otherwise be infringing. Non-profit, educational or personal use tips the balance in favor of fair use.”

Anayansi Gamboa has an extensive background in clinical data management as well as experience with different EDC systems including Oracle InForm, InForm Architect, Central Designer, CIS, Clintrial, Medidata Rave, Central Coding, Medrio, IBM eCOS, OpenClinica Open Source and Oracle Clinical.

Advertisements

iReview in Clinical Data Management

JReview® is the web-enabled version of Integrated Review™ (iReview). It allows users to view, create, print, and interact with their Integrated Review™ objects locally on an Intranet or securely over the Internet. JReview® can be run in two different modes of operation (authoring and non-authoring) in addition to two modes of communication (clear-text and SSL).

iReview Common Development Practice:

  • iReview allows you to saved the library of objects to be deployed at “Global” level in the production environment.
  • Create separate categories (folders for DEV/QC/UAT) before approval (deployment into production)
    – “Development”
    – “QC”
  • Create study specific folders under those categories (e.g. DEV/QC/UAT)
  • Configure UserGroups to manage privileges appropriately at the category level– – “Developers can access – Development”
    – “QR/QT can access QC”

QC/UAT PROCESS

  • You can query iReview metadata
  • Business rule verification by checking

– “Panel names, item names”
– “Object location e.g. Public, private or usergroup”

  • Use of SQL to query iReview objects metadata
  • The information in CONTENTBLOCK is parsed to get
    additional metadata information for a particular iReview
    object
  • Define a detailed QC checklist for each object in the Global Library
  • Maintain a lessons learned document (knowledge base) to improve the development process

  • Continuously improve processes by collecting Metrics

    – Development time

    – QC time

    – Rework time

Advance Functionality

  • Deploy reports with dynamic Filter values
  • Filter values are not static and change during trial conduct
  • Deployment for non-technical end-users
  • Provide easy access to report
  • Create Lookup table(s) in the backend
  • Populate Lookup table(s) with study specific Filter values

  • Using “Filter Output” in IR, add appropriate nested queries to the WHERE clause

  • The use of ImportSQL, more complex dynamic filtering so no need to hardcode values in the front end

  • Saves development time by avoiding the creation of study specific filters and increases re-usability

  • Flexibility to activate/inactivate filter values via backend

Import SQL

  • Modify an Import SQL panel by adding more items will not impact existing reports already using this Import SQL

  • Import SQL has a limitation with max of 2000 characters (will result in the error below)

A workaround would be to create a stored procedure or a view

Patient Selection Criteria

  • Modifying a PSC has no impact on already saved existing reports using this PSC

Object Specifications window

  • Removing Objects (missing folders)
    – When all the objects are removed from a folder in the Object
    Specifications window, the folder with no objects will be hidden but
    not removed
    e.g. Drug Safety ..> All AEs ..> SAE Reports ..>SAE reconciliation
  • Removing all objects under “SAE Reports” folder will result in the “SAE Reports” folder being hidden
  • The workaround would be to use the Category section of Object Management tool to remove these hidden folders

Navigating iReview Windows

  • If you have hundreds of saved objects, typing the first few letters (similar to Windows Explorer) will help with easy scrolling and navigation in the Object Specifications window

Reference: Integrated Clinical Systems, Inc.